Понимание CDI / Weld в многомодульном приложении

у меня есть приложение, которое упаковано в ухо, содержащее много банок (с EJBs, библиотеками, сторонними библиотеками, ...) и одна война (опять же, содержащая некоторые другие банки). Приложение развертывается в контейнере JEE7 (Wildfly 8.0.0.Final) и использование CDI (сварка 2.1.2.Final поставляется с Wildfly).

в моем понимании, сварка является активным приложением и имеет один вид приложения. Поэтому не имеет значения, где я хочу использовать CDI-он работает.

но есть некоторые указания, которые приводят к предположению, что это не так. Е. Г. элемент toString-метод BeanManager показывает Различный выход в различных модулях:

при использовании BeanManager в каком-то модуле, который упакован в войну, я получаю Weld BeanManager for test-ear-1.0-SNAPSHOT.ear/test-webui-frontend-1.0-SNAPSHOT.war/WEB-INF/lib/test-webui-backend-1.0-SNAPSHOT.jar [bean count=76].

если он используется в библиотеке, непосредственно содержащейся в ухе: Weld BeanManager for test-ear-1.0-SNAPSHOT.ear/test-ejb3-dao-1.0-SNAPSHOT.jar/ [bean count=224].

так кажется, что эти BeanManagers "несет ответственность за" различные части приложения. Это правда?

7
cdi java weld

1 ответов

это скорее обрабатывается сервером приложений, который понимает спецификацию EAR.

Из Википедии:

большинство серверов приложений загружают классы из развернутого файла EAR как изолированное дерево Java classloaders, изолирующее приложение от другие приложения, но совместное использование классов между развернутыми модулями. Для например, развернутый файл WAR может создавать экземпляры классы, определенные в файле JAR, который также был включен в содержащий Файл уха, но не обязательно в файлах JAR в других файлах уха. Одна из ключевых причин такого поведения-разрешить полное разделение между приложениями, использующими статические синглеты (например, Log4J), которые в противном случае путать конфигурацию между отдельными приложения. Это также включает различные версии применений и библиотеки будут развернуты бок о бок.

таким образом, каждый модуль имеет свой собственный BeanManager пока сервер приложений управляет зависимости между этими экземплярами.

4