После перехода на свежую версию JDeveloper получил новый эксепшен (см ниже). В результате поисков был обнаружены следующие следы на форуме оракла:

http://forums.oracle.com/forums/thread.jspa?messageID=1650599
и
http://forums.oracle.com/forums/thread.jspa?messageID=631925&#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.

Читать дальше ...

Для начала замечу, что описанная ниже проблема присутствует только при использовании 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. В результате поиска наверняка найдется пара таких пустых файлов, которые необходимо удалить руками и, к тому же, удалить ссылки на них из всех проектов.

Поймал ошибку:

 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:

Естественно, проблема была решена глобальной заменой всех путей во всех файлах на актуальный.

Посмотрим что тут к чему...