Проблема OC4J 10.1.3.4 с развертыванием нескольких EJB 2.1

У меня проблемы с переходом с OC4J 10.1.2.3 на 10.1.3.1.4. Проблема заключается в приложениях, которые имеют несколько EJB (все версии 2.1, нет EJB 3.0). Jdeveloper возьмет файл ejb-jar.xml по умолчанию (тот, который необходим Jdeveloper для запуска его на своем автономном экземпляре OC4J) и упакует его в каждый модуль EJB JAR НЕЗАВИСИМО от чего. Это приводит к тому, что сервер приложений углубляется в каждый модуль EJB JAR при развертывании и находит один и тот же файл ejb-jar.xml N раз (где N = количество модулей EJB). Это приводит к дублированию ссылок EJB и прерывает любые поиски JNDI, такие как: "java:comp/env/ejb/EJBName". Таким образом, развертывание приложения, которое имеет 3 EJB, EJB1, EJB2 и EJB3, приводит к тому, что сервер приложений регистрирует 9 EJB вместо 3. Мне нужен лучший способ, но между тем, как 10.1.3.4 и JDeveloper действуют в ситуации это довольно ужасно...

Примечание: они будут работать, если код поиска JNDI веб-приложения преобразован в просто "ejb/EJBName". Хотя это нежелательно.


java ejb jakarta-ee oc4j ejb-jar.xml
person Zombies    schedule 26.09.2008    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вы должны проверить документацию Oracle, чтобы узнать, что именно в вашем случае. Руководство разработчика Oracle® Containers for J2EE Enterprise JavaBeans — хорошее начало. Согласно Oracle® Containers for J2EE Services Guide, глава 2: Использование JNDI, когда вы используете форму «ejb/EJBName», вы выполняете «локальный» поиск. Если вы хотите использовать полную форму, вы должны проверить раздел «Включение глобального поиска JNDI» в главе «Использование JNDI».

person zloster    schedule 06.10.2008
comment
Я считаю, что заставляя его использовать локальный поиск, я избегаю дублирующих ссылок, которые, похоже, и нарушают это. - person Zombies; 06.10.2008

arrow_upward
0
arrow_downward

Проблема заключалась в множественных ссылках в наших профилях развертывания. Мы создали профиль развертывания для КАЖДОГО EJB. Это означало, что у каждого EJB был свой ejb-jar.xml (этот файл содержал описание всех EJBS в проекте). Таким образом, каждый раз, когда JDeveloper создавал EJB, он помещал дескриптор всех EJBS в каждый сгенерированный EJB, вызывая количество ссылок NxN. Поэтому Nx(N-1) дополнительных ссылок.

Теперь ключевым моментом является то, что Oracle Application Server 10.1.2.3.0 и ниже не заботились об этих повторяющихся ссылках. Однако, как мы видим, 10.1.3.1.4 — это совсем другая версия, и она сломалась.

Наше исправление: иметь только 1 профиль развертывания EJB, который содержит все классы EJB и POJO, которые они используют. Помните, что до того, как для каждого EJB существовал 1 профиль EJB... Все это позволяло Jdeveloper (что, на мой взгляд, дерьмо) правильно генерировать действительный EAR. Это вызвано комбинацией Jdeveloper и дерьма Oracle Application Server.

person Zombies    schedule 08.12.2008