Я не то, чтобы сильно упираюсь, скорее наоборот - вижу, что JBoss 7 работает заметно быстрее предыдущей версии. Сейчас я пытаюсь оценить масштаб бедствия.
В общем, понял, спасибо. Дальше надо. видимо, J2EE spec смотреть.
Приложение изначально разрабатывалось как модульное - при отсутствии части WAR-файлов происходит "сужение функциональности" - приложение работает, но часть функций недоступны. В моем примере "админка" - это как раз такой исключаемый модуль: без неё приложение успешно выполняет основные функции, только недоступно администрирование через web-интерфейс. Это позволяет развертывать версию под конкретные условия у заказчика: нужна админка - подложили WAR-файл, нет - убрали. Именно это я имею в виду под "конфигурированием".
И ещё - разработка WAR-модулей ведется независимо. В принципе, паковать их в EAR - не большая проблема, но я не вижу особого смысла в появлении лишней сущности - EAR, "обволакивающего" WAR и EJB.
Спасибо за развернутый ответ. В документации мне попадалось упоминание EAR в контексте взаимодействия EJB-WAR, но была надежда обойтись без оного. Сейас проверяю вариант с EAR - вроде заработало.
Одно смущает - в версии с независимыми WAR приложение было легче конфигурировать (не нужна в данном варианте развертывания админка - нужный WAR просто убираем + поправляем конфиг в БД, чтобы в меню не отображалась). Сейчас же для каждого варианта конфигурации надо будет свой EAR собирать...
Под "проектом" я имел в виду собственно приложение. Я упростил картину, в действительности оно состоит из нескольких WAR и нескольких EJB, причем разные WAR-файлы используют методы одного EJB для доступа к данным. Под JBoss 6 такая архитектура вполне себе работала без использования EAR - WAR-модули обращались к методам EJB посредством JNDI.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Получается, разрешить полнотекстовый поиск глобально нельзя - либо по расширению, либо в конкретной папке.