Informazioni su CDI/Weld nell'applicazione a più moduli

Question

Ho un'applicazione che è inclusa in un EAR contenente molti JAR (con EJB, librerie, librerie di terze parti, ...) e una singola GUERRA (di nuovo contenente qualche altro JAR). L'applicazione è distribuita in un contenitore JEE7 (Wildfly 8.0.0.Final) e utilizzando CDI (Weld 2.1.2.Final fornito con Wildfly).

A mio parere, Weld è attivo in tutta l'applicazione e ha un'unica vista a livello di applicazione. Quindi non importa dove voglio usare CDI - funziona.

Ma ci sono alcune indicazioni che portano a supporre che questo non è vero. Per esempio. la toString -method del BeanManager mostra output diverso in diversi moduli:

Quando si utilizza il BeanManager in qualche modulo che viene confezionato in guerra ottengo 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].

Se utilizzato in una libreria direttamente contenuta nell'EAR: Weld BeanManager for test-ear-1.0-SNAPSHOT.ear/test-ejb3-dao-1.0-SNAPSHOT.jar/ [bean count=224].

Quindi sembra che questi BeanManagers siano "responsabili" di diverse parti dell'applicazione. È vero?

Answer 1

Questo è piuttosto gestito dal server delle applicazioni che comprende le specifiche EAR.

Da Wikipedia:

maggior parte dei server applicativi classi di carico da un file EAR distribuito come un albero isolato di classloader Java , isolando l'applicazione dal altre applicazioni, ma la condivisione di classi tra i moduli distribuiti. Per esempio , un file WAR distribuito sarebbe in grado di creare istanze di classi definite in un file JAR che era anche incluso nel file EAR contenente , ma non necessariamente in quelli JAR in altri file EAR. Una delle ragioni principali per questo comportamento è consentire la separazione completa tra le applicazioni che utilizzano singoletti statici (ad esempio Log4J), che confonderebbe altrimenti la configurazione tra le diverse applicazioni . Ciò consente inoltre di distribuire le diverse versioni delle applicazioni e le librerie affiancate.

Così ogni modulo ha il proprio BeanManager mentre il server delle applicazioni gestisce le dipendenze tra queste istanze.