Миграция с JBoss 6 на JBoss 7 — почему из WAR не виден EJB?

Question

[tavi]

Есть проект, состоящий из одного EJB и одного WAR, использующего методы EJB через локальный интерфейс. Под JBoss 6 они прекрасно работали вместе. Под JBoss 7 - не хотят.
EJB объявляет интерфейс с именем DBLocal (он используется для доступа к БД) и успешно разворачивается под Jboss7, в консоль пишет следующие JNDI bindings:

java:global/ru.test.ejb.orm/DBBean!ru.test.ecm.orm.bean.DBLocal
	java:app/ru.test.ejb.orm/DBBean!ru.test.ecm.orm.bean.DBLocal
	java:module/DBBean!ru.test.ecm.orm.bean.DBLocal
	java:global/ru.test.ejb.orm/DBBean
	java:app/ru.test.ejb.orm/DBBean
	java:module/DBBean

В серверном коде WAR-файла написано вот что:

//Это некий класс сервлета
public class LoginServiceImpl extends RemoteServiceServlet implements LoginService, ServletContextListener
{
        //Вот он, EJB-шник:
	@EJB(lookup="java:global/ru.test.ejb.orm/DBBean!ru.test.ecm.orm.bean.DBLocal")
	private DBLocal dbBean;
       ...
}

Не работает. Не может JBoss 7 обнаружить EJB, пишет в консоль такие ошибки:

Caused by: java.lang.NoClassDefFoundError: Lru/test/ecm/orm/bean/DBLocal;
	at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.7.0_25]
	at java.lang.Class.privateGetDeclaredFields(Unknown Source) [rt.jar:1.7.0_25]
	at java.lang.Class.getDeclaredFields(Unknown Source) [rt.jar:1.7.0_25]
	at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:57) [jboss-as-server-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:68) [jboss-as-server-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	... 10 more
Caused by: java.lang.ClassNotFoundException: ru.test.ecm.orm.bean.DBLocal from [Module "deployment.ecm.war:main" from Service Module Loader]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final-redhat-2]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final-redhat-2]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final-redhat-2]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final-redhat-2]
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final-redhat-2]
	... 15 more

Т.е. он не может обратиться к классу, объявленному внутри EJB-модуля. Чтение документации мне сильно не помогло. Есть способ побороть NoClassDefFoundError, подключив EJB-модуль как библиотеку (путем помещения его в WEB-INF/lib папку в WAR), но тогда он, как я понимаю, используется как простая подключаемая библиотека. Если я разверну на сервере несколько WAR-ников, использующих этото же EJB, для каждого будет использоваться свой экземпляр EJB, что не есть здорово (строго говоря, это не EJB уже будет).
Как всё-таки заставить WAR увидеть EJB и работать с ним нормальным образом?

Answer 1

[Владимир Смирнов]

проект, состоящий из одного EJB и одного WAR

В JBoss (и в терминологии серверов приложений JEE в целом) нет понятия "проект". Правильно ли я понимаю, что под "проектом" подразумевается Enterprise Archive (EAR)? Если у вас нет EAR, то я не вижу способов считать чем-то единым отдельный WAR и отдельный EJB-модуль.

Если есть EAR, попробуйте в папку META-INF добавить файл с именем jboss-deployment-structure.xml со следующим содержанием:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
</jboss-deployment-structure>

Создать EAR можно следующим образом. Создаете в папке deployments папку my.ear со следующей структурой:

my.ear
--META-INF
----application.xml
----jboss-deployment-structure.xml
--myWeb1.war
--myWeb2.war
--myEjb1.jar
--myEjb2.jar

Содержимое application.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">
<application>
    <display-name>myApp</display-name>
    <initialize-in-order>true</initialize-in-order>
    <module>
        <java>myEjb1.jar</java>
    </module>

    <module>
        <java>myEjb2.jar</java>
    </module>

    <module>
        <web>
            <web-uri>myWeb1.war</web-uri>
            <context-root>myWeb1</context-root>
        </web>
    </module>
    
    <module>
        <web>
            <web-uri>myWeb2.war</web-uri>
            <context-root>myWeb2</context-root>
        </web>
    </module>
</application>

Библиотеки, не содержащие EJB (просто "носители" нужных общих классов), можно поместить в папку my.ear/lib

Comments

[tavi]

Под "проектом" я имел в виду собственно приложение. Я упростил картину, в действительности оно состоит из нескольких WAR и нескольких EJB, причем разные WAR-файлы используют методы одного EJB для доступа к данным. Под JBoss 6 такая архитектура вполне себе работала без использования EAR - WAR-модули обращались к методам EJB посредством JNDI.

[Владимир Смирнов]

Если ваши WAR находились вне EAR (находились в папке deploy) - значит фактически это было не одно приложение, а несколько независимых приложений. Непонятно, каким образом в такой структуре разворачивались EJB - куда вы ложили JAR-файлы и каким образом указывали JBoss-у что это приложение, а не что-либо ещё...

В любом случае, настоятельно рекомендую объединить все модули (EJB, WAR и что там у вас еще есть) в EAR, только после этого их действительно можно считать единым приложением. Я добавил рекомендации о том, как это сделать, в свой ответ.

[tavi]

Спасибо за развернутый ответ. В документации мне попадалось упоминание EAR в контексте взаимодействия EJB-WAR, но была надежда обойтись без оного. Сейас проверяю вариант с EAR - вроде заработало.
Одно смущает - в версии с независимыми WAR приложение было легче конфигурировать (не нужна в данном варианте развертывания админка - нужный WAR просто убираем + поправляем конфиг в БД, чтобы в меню не отображалась). Сейчас же для каждого варианта конфигурации надо будет свой EAR собирать...

[Владимир Смирнов]

По поводу конфигурации я не понял, но, вероятно, следует пересмотреть принципы конфигурирования ПО. Конфигурация структуры приложения (в различных xml-файлах WAR-ов и EAR-ов) обычно меняется редко, и практически всегда связана с обновлением и редеплоем приложения. А вот за специфическую конфигурацию логики приложения ответственно оно само, и по хорошему конфигурация логики не должна быть связана со структурой приложения. Если я правильно понял, вы в админке меняете настройки и сохраняете в БД, но они вступают в силу только после редеплоя приложения. Такое может быть если настройки кешируются в памяти приложения. Тут стоит рассмотреть вариант обновления кеша: либо по событию, поступившему из админки при изменении параметра, либо по расписанию...

[tavi]

Приложение изначально разрабатывалось как модульное - при отсутствии части WAR-файлов происходит "сужение функциональности" - приложение работает, но часть функций недоступны. В моем примере "админка" - это как раз такой исключаемый модуль: без неё приложение успешно выполняет основные функции, только недоступно администрирование через web-интерфейс. Это позволяет развертывать версию под конкретные условия у заказчика: нужна админка - подложили WAR-файл, нет - убрали. Именно это я имею в виду под "конфигурированием".
И ещё - разработка WAR-модулей ведется независимо. В принципе, паковать их в EAR - не большая проблема, но я не вижу особого смысла в появлении лишней сущности - EAR, "обволакивающего" WAR и EJB.

[Владимир Смирнов]

Понятно. Имея EAR вам не нужно будет иметь конфиг в БД, его заменит application.xml. Вы же в любом случае при установке принимаете решение какие модули положить на сервер, думаю, что не проблема отразить это в application.xml. В принципе, можно иметь один EAR на все конфигурации, а при установке клиенту удалять ненужные модули в application.xml (JBoss 7 игнорирует модули, находящиеся в EAR, но не указанные в application.xml). Либо иметь набор преднастроенных конфигураций (файлов application.xml) и подменять их в пакете установки перед передачей клиенту.

Про то, чем является "лишняя сущность EAR" я уже итак немало написал. Добавлю лишь, что в JBoss 7 значительно изменились принципы и механизмы загрузки классов и доступности их приложениям. То, что у вас работало под JBoss 6, скорее всего, было идеологически/архитектурно неверно, и JBoss 7 прямо указал вам на ошибки архитектуры, выбросив исключение NoClassDefFoundError. Вы зря так упираетесь в нежелании что-то менять, это я вам говорю как человек, перенесший 2 серьезных JEE Системы по пути JBoss 4 -> JBoss 5 -> JBoss 7. Ни один из переходов не был безболезненным, причем последний JBoss 7 доставил наибольшее количество хлопот. В основном это связано с тем, что для полного его соответствия спецификации JEE 6 пришлось фактически разработать новый продукт.

Вам стоит принять решение - либо переработать ПО и соответствовать архитектуре JBoss 7 и JEE6, либо отказаться от перехода вовсе. В 7-ке нет каких-то особых новых крутых "фич" - лишь обновленные версии сервисов и новая архитектура. Более того, в ней нет многих вещей, которые были в предыдущих версиях и для моих проектов были просто незаменимы, т.е. перейдя на 7-ку пришлось делать их самому.

[tavi]

Я не то, чтобы сильно упираюсь, скорее наоборот - вижу, что JBoss 7 работает заметно быстрее предыдущей версии. Сейчас я пытаюсь оценить масштаб бедствия.
В общем, понял, спасибо. Дальше надо. видимо, J2EE spec смотреть.