Verständnis CDI/Weld in Multi-Modul-Anwendung

Question

Ich habe eine Anwendung, die in einem EAR verpackt ist viele JARs (mit EJBs, Bibliotheken, 3rd-Party-Bibliotheken, ...) und eine einzige WAR (wieder enthält einige andere JARs). Die Anwendung wird in einem JEE7-Container (Wildfly 8.0.0.Final) und mit CDI (Weld 2.1.2.Final im Lieferumfang von Wildfly) bereitgestellt.

In meinem Verständnis ist Weld applikationsweit aktiv und hat eine einzige anwendungsweite Sicht. Es ist also egal, wo ich CDI benutzen will - es funktioniert.

Aber es gibt einige Hinweise, die zu der Annahme führen, dass dies nicht wahr ist. Z.B. die toString -Methode der BeanManager zeigen verschiedene Ausgabe in verschiedenen Modulen:

Wenn die BeanManager in einiger Modul, das im Krieg verpackt ich 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].

Wenn es in einer Bibliothek verwendet wird, die direkt in der EAR enthalten ist: Weld BeanManager for test-ear-1.0-SNAPSHOT.ear/test-ejb3-dao-1.0-SNAPSHOT.jar/ [bean count=224]. Es scheint, dass diese BeanManagers "verantwortlich" für verschiedene Teile der Anwendung sind. Ist das wahr?

Answer 1

Dies wird eher von dem Anwendungsserver gehandhabt, der die EAR-Spezifikation versteht.

Aus Wikipedia:

meisten Anwendungsserver Belastungsklassen aus einer entfalteten EAR-Datei als isolierten Baum von Java Classloader, die Anwendung von anderen Anwendungen nicht isoliert, sondern Klassen zwischen eingesetzten Module zu teilen. Für Beispiel könnte eine implementierte WAR-Datei Instanzen von Klassen erstellen, die in einer JAR-Datei definiert sind, die auch in der enthaltenen EAR-Datei enthalten ist, aber nicht unbedingt in JAR-Dateien in anderen EAR-Dateien. Ein Hauptgrund für dieses Verhalten besteht darin, eine vollständige Trennung zwischen Anwendungen zu ermöglichen, die statische Singletons verwenden (z. B. Log4J), die ansonsten die Konfiguration zwischen separaten -Anwendungen verwechseln würden. Dadurch können auch verschiedene Versionen von Anwendungen und Bibliotheken nebeneinander bereitgestellt werden.

So hat jedes Modul seine eigene BeanManager, während der Anwendungsserver die Abhängigkeiten zwischen diesen Instanzen verwaltet.