Есть вопрос по работе с CDI в нескольких WAR модулях одного EAR приложения.
Был написан WAR модуль с CDI объектами. Назрела необходимость разбить один WAR на два отдельных WAR модуля.
Первый работает по HTTP, второй по HTTPS. Context-root разные.
В обоих WAR модулях наборы классов одинаковые. JBoss ругается


Оставляю только один WAR модуль, ошибка исчезает.

WGA, извините, не совсем понял. При чем здесь EJB бины? Они и так вынесены в ejb jar контейнеры.
CDI должен работать в рамках одного WAR.
Я же говорю о том, что в EAR приложении существует два WAR модуля. Архитектура, естественно, одна и та же. По этой причине, базовые компоненты будут одинаковыми. Например, регистрация сертификата для авторизации.
Один модуль работает, когда пользователь входит в открытую часть системы и хочет пройти процедуру первичной регистрации. Второй модуль - закрытая часть системы, для авторизованных пользователей.
При первичной регистрации надо указать сертификат, которым будет проверяться авторизация.
В личном кабинете можно сменить сертификат, так как в сертификате есть срок действия и он иногда заканчивается.

Логично, что процедура обработки веб запросов находится в WAR модуле, а обработка полученных данных в EJB модулях. Так зачем же выносить обработку WEB (ajax) запроса в EJB? И как это делать, минуя servlet или JAX-RS?

Повторюсь еще раз CDI работает в рамках одного WAR модуля. Получается, что реализация Weld в JBoss противоречит спецификации самого Weld.
Либо, я ничего не понимаю.

WGA,
У нас есть два WAR модуля. В каждом есть набор своих CDI объектов.
Как нам любят показывать, есть компоненты обработки для разных валют или кредитных карт.
Что нам нужно, в CDI, чтобы получить объект нужной реализации? Правильно, добавить свою аннотацию.
В аннотации можно указать параметр value.

Как по содержимому объекта найти нужную реализацию?
Скажем, указан псевдоним валюты "RUR" или "USD".
Мы используем специальный объект для поиска:




И пишем такую хитрую штуку:


Теперь мы можем найти нужную нам реализацию:




Если в каждом WAR модуле есть свой набор реализаций, то объекты первого модуля видны во втором?
Ну, это как-то глупо выглядит.

Уж лучше сразу ставить крест на EJB и переходить на OSGi. Там хотя бы PAX-CDI однозначно утверждает, что CDI работает только в переделах одного OSGi bundle.

Ведь это реальная дыра в безопасности всего проекта. Со стороны клиента может прийти ajax запрос, который не должен обработаться в рамках первого WAR модуля, но успешно обрабатывается во втором WAR модуле.

Ох уж этот форум. Редактировать нельзя, добавить еще, то же нельзя. В примере неправильно написал название конструктора.

Вот и получается, что есть набор одинаковых CDI объектов в каждом WAR модуле. И Weld начинает ругаться.
Выносить общие CDI объекты в оnдельный JAR модуль, то же глупо. Ведь это не решает проблемы видимости чужих CDI объектов.
Если бы чужие CDI объекты были не видимы, тогда изначального конфликта не было бы.

ivanraУ war модулей внутри ear собственные загрузчики, для других модулей настраивается (по умолчанию - модули не изолированы)
https://docs.jboss.org/author/display/AS7/Class Loading in AS7

Легче разобраться с правилами в OSGi, из десятка страницах, нежели в одном предложении от JBoss.

Чем отличается спецификация OSGi и JavaEE. В OSGi пишут спецификацию, потом реализацию. В JavaEE сначала реализацию, потом спецификацию и уже после латают реализацию.

Если честно, я всегда считал, что у каждого WAR модуля обязан быть собственный загрузчик классов. Иначе, все web ресурсы создали кашу. А раз так, то и CDI должен был работать корректно, в рамках своего ClassLoader.

ivanra,
Ну да, замечательно. Берем WildFly 8.2 и радуемся другим ошибкам. Раньше, я замечательно пользовался


Теперь, я радостно ловлю JBAS014237. https://issues.jboss.org/browse/WFLY-1168

Ведь не все объекты в EAR приложении являются EJB CMT объектами. Некоторые, по старинке, создаются через старый, добрый new.
И каким, таким способом, созданный объект осчастливить разрешением аннотаций @EJB, @Resource, @TransactionAttribute?

JPA, это вообще, лебединая песня о транзакциях. Не поймешь, когда нужно начинать транзакцию от Hibernate Session (EntityManager) и руками ставить commit, а когда эта сессия работает в рамках JTA транзакции. Ведь мы познакомились с JBAS014237 от WildFly.
И не дай бог, случайно сделать


Да, и совсем уж в пику JavaEE 7.
Есть @Transactional и @TransactionAttribute. Есть @Inject и @EJB/@Resource.
@TransactionAttribute и @EJB/@Resource, вообще, надо запретить к использованию и предать анафеме в JavaEE API.

В общем виде, спецификация JavaEE нервно курит в сторонке, пока усиленно правятся ошибки в JavaEE серверах.
А относительно недавняя эпопея с изменением имен в lookup с JavaEE 2 на JavaEE 3 от JBoss 7, вам понравилась?
Это то же, спецификация JavaEE была в отпуске?


По поводу Weld CDI я скажу крамольную штуку. Ей не хватает много-модульности и приватных модулей из Guice.
Если бы ребята взяли этот функционал, не было бы проблем с областями видимости объектов в разных JAR/WAR/EJB модулях. Всё бы ограничивалось кругом конкретного модуля.

Atum1Может перед jboss serverом поставить прокси (например апач) -и разворачивать ваш https на нем
а, уже в jboss ходить одинаково по http , передавая инфу в заголовках ?
Увы, это не выход из сложившейся ситуации. Легче тогда поднять два независимых EAR модуля на одном JBoss. Либо, потратить время на адаптацию кода под новые специфики WildFly 8.2.