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?

Nims

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.

Practical

You're right. It looks like the for ... of the toString-output is the classloader which is active in the current context. But does this mean that the application server holds many different "CDI-applications" (or BeanManagers) which handle their CDI-contexts (like the application-scope) completely separately? – Nims

No, the application scope exists in the application, i.e. the EAR application. But each module has its own BeanManager, while the app server is managing dependencies between these instances. – Practical

So do the different BeanManagers have any practical influence? If no: why is it worthwhile to mention the modulename/classloader in the toString output? – Nims

No, and my guess is that this is because you need to access the BeanManager from within the archive (and therefore its class loader) individually. Again, Weld does not know whether your application is an EAR or not, but the application server knows that there are several BeanManagers in the application and ties them together. – Practical

And I honestly don't know why the classloader is mentioned in the toString() output, maybe for debugging purposes. – Practical

Did this answer your question or do you need some further explanation? – Practical

I have to correlate this with my observations. I'll mark your answer as correct if everything is clear. Thank you so far – Nims