Гугль открыл просмотр бэклинков
Google продолжает заботиться о веб-мастерах. В этот раз добавив статистику по входящим и исходящим бэк-линкам. До этого же, их можно было посмотреть прямо в поисковике, используя оператор link. Но как утверждает официальный блог, то количество ссылок было неполное. Сейчас все ссылки можно посмотреть в Google Webmaster Central.
Для просмотра backlinks, необходимо зайти на сайт Google Webmaster Central, выбрать ваш сайт и кликнуть на закладку “Link”. Там еще две закладки: “External links” и “Internal links”, которые и показывают ссылки с внешних сайтов и вашего сайта. Есть возможно поиска по списку (как же без поиска) и можно скачать список в CSV-формате
JBO-27022
очередная ошибка JDeveloper 10.1.3.1
После перехода на свежую версию JDeveloper получил новый эксепшен (см ниже). В результате поисков был обнаружены следующие следы на форуме оракла:
http://forums.oracle.com/forums/thread.jspa?messageID=1650599
и
http://forums.oracle.com/forums/thread.jspa?messageID=631925򚑵
Предложенное решение не подошло - сменив тип на CHAR получил всё ту же страницу с ошибкой... Побившись лбом об стену обнаружил, что вся проблема была в файле .xml описывавшем этот ViewObject
<Attribute
Name="Id"
Precision="250"
ColumnName="ID"
Type="java.lang.String"
ColumnType="VARCHAR2"
SQLType="NUMERIC"
TableName="MENU_JSF" >
<DesignTime>
<Attr Name="_DisplaySize" Value="22" />
</DesignTime>
</Attribute>
В поле SQLType почему-то завис NUMERIC, причем это описание прекрасно работало в 10.1.3.0. Этот тип невозможно изменить нигде кроме как в самом файле. Причем редактировать надо в каталоге src, а после изменения необходимо проконтролировать, что этот файл скопируется в classes.
http://forums.oracle.com/forums/thread.jspa?messageID=1650599
и
http://forums.oracle.com/forums/thread.jspa?messageID=631925򚑵
Предложенное решение не подошло - сменив тип на CHAR получил всё ту же страницу с ошибкой... Побившись лбом об стену обнаружил, что вся проблема была в файле .xml описывавшем этот ViewObject
<Attribute
Name="Id"
Precision="250"
ColumnName="ID"
Type="java.lang.String"
ColumnType="VARCHAR2"
SQLType="NUMERIC"
TableName="MENU_JSF" >
<DesignTime>
<Attr Name="_DisplaySize" Value="22" />
</DesignTime>
</Attribute>
В поле SQLType почему-то завис NUMERIC, причем это описание прекрасно работало в 10.1.3.0. Этот тип невозможно изменить нигде кроме как в самом файле. Причем редактировать надо в каталоге src, а после изменения необходимо проконтролировать, что этот файл скопируется в classes.
Почему JDeveloper не любит пакет common
маленькие хитрости умной среды разработки
Для начала замечу, что описанная ниже проблема присутствует только при использовании ORACLE ADF и business components.
В первые дни знакомства с JDeveloper столкнулся с загадочной проблемой - компилятор выдавал ошибку, что-то в стиле "пакет common не может быть скомпилирован".
Оказалось, что JDeveloper при создании Application module автоматом создает каталог common/ в котором размещает файл bc4j.xcfg. После этого девелопер отказывается воспринимать все классы находящиеся в пакете common и впадает в ступор.
Отсюда мой Вам совет - не называйте пакеты словом common в проектах использующих oracle business components.
И ещё один аспект относящийся к файлу bc4j.xcfg
Нередко при работе можно встретить следующий эксепшен:
oracle.jbo.ConfigException: JBO-33005
Это означает, что программа не может найти конфигурацию для вашего модуля. В простейших случаях это решается включением соответствующего модуля в проект с помощью вкладки Dependencies. НО благодаря наличию функции Rename вы можете столкнуться и с другой ситуацией, когда все пакеты включены и вроде бы всё в порядке, но всё равно получаем исключение.
Проблема в том, что при переносе/переименовании Application Module в проекте может зависнуть ссылка на старое место расположения файла bc4j.xcfg.
Поэтому, если получаем исключение JBO-33005 и с путями всё в порядке, то первое что следует сделать - поискать в проекте все файлы bc4j.xcfg. В результате поиска наверняка найдется пара таких пустых файлов, которые необходимо удалить руками и, к тому же, удалить ссылки на них из всех проектов.
В первые дни знакомства с JDeveloper столкнулся с загадочной проблемой - компилятор выдавал ошибку, что-то в стиле "пакет common не может быть скомпилирован".
Оказалось, что JDeveloper при создании Application module автоматом создает каталог common/ в котором размещает файл bc4j.xcfg. После этого девелопер отказывается воспринимать все классы находящиеся в пакете common и впадает в ступор.
Отсюда мой Вам совет - не называйте пакеты словом common в проектах использующих oracle business components.
И ещё один аспект относящийся к файлу bc4j.xcfg
Нередко при работе можно встретить следующий эксепшен:
oracle.jbo.ConfigException: JBO-33005
Это означает, что программа не может найти конфигурацию для вашего модуля. В простейших случаях это решается включением соответствующего модуля в проект с помощью вкладки Dependencies. НО благодаря наличию функции Rename вы можете столкнуться и с другой ситуацией, когда все пакеты включены и вроде бы всё в порядке, но всё равно получаем исключение.
Проблема в том, что при переносе/переименовании Application Module в проекте может зависнуть ссылка на старое место расположения файла bc4j.xcfg.
Поэтому, если получаем исключение JBO-33005 и с путями всё в порядке, то первое что следует сделать - поискать в проекте все файлы bc4j.xcfg. В результате поиска наверняка найдется пара таких пустых файлов, которые необходимо удалить руками и, к тому же, удалить ссылки на них из всех проектов.
Проблема с global.libraries
бьемся дальше с JDeveloper 10.1.3.1.0
Поймал ошибку:
Error initializing server: Для совместно используемой библиотеки "global.libraries" в /D:/jdev10131/jdev/system/oracle.j2ee.10.1.3.39.84/embedded-oc4j/config/server.xml требуется хотя бы один действительный элемент code-source или import-shared-library.
Проблема оказалась в файле server.xml - все пути были прописаны для директории C:\jdev10131 а сам JDeveloper у меня был установлен на диске D:
Естественно, проблема была решена глобальной заменой всех путей во всех файлах на актуальный.
Error initializing server: Для совместно используемой библиотеки "global.libraries" в /D:/jdev10131/jdev/system/oracle.j2ee.10.1.3.39.84/embedded-oc4j/config/server.xml требуется хотя бы один действительный элемент code-source или import-shared-library.
Проблема оказалась в файле server.xml - все пути были прописаны для директории C:\jdev10131 а сам JDeveloper у меня был установлен на диске D:
Естественно, проблема была решена глобальной заменой всех путей во всех файлах на актуальный.