Understanding CDI/Weld in multi-module application

Question

I have an application which is packaged in an EAR containing many JARs (with EJBs, libraries, 3rd-party-libraries, ...) and a single WAR (again containing some other JARs). The application is deployed in an JEE7 container (Wildfly 8.0.0.Final) and using CDI (Weld 2.1.2.Final shipped with Wildfly).

In my understanding, Weld is active application-wide and has a single application-wide view. So it doesn't matter where I want to use CDI - it works.

But there are some indications which lead to the assumption that this is not true. E.g. the toString-method of the BeanManager shows different output in different modules:

When using the BeanManager in some module which is packaged in the war I get 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].

If it is used in a library directly contained in the EAR: Weld BeanManager for test-ear-1.0-SNAPSHOT.ear/test-ejb3-dao-1.0-SNAPSHOT.jar/ [bean count=224].

So it seems that these BeanManagers are "responsible for" different parts of the application. Is this true?

Answer 1

This is rather handled by the application server that understands the EAR spec.

From Wikipedia:

Most application servers load classes from a deployed EAR file as an isolated tree of Java classloaders, isolating the application from other applications, but sharing classes between deployed modules. For example, a deployed WAR file would be able to create instances of classes defined in a JAR file that was also included in the containing EAR file, but not necessarily those in JAR files in other EAR files. One key reason for this behavior is to allow complete separation between applications which use static singletons (e.g. Log4J), which would otherwise confuse the configuration between separate applications. This also enables different versions of applications and libraries to be deployed side-by-side.

So each module has its own BeanManager while the application server manages the dependencies between these instances.