8

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?

MrD
  • 1,255
  • 1
  • 10
  • 24

1 Answers1

4

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.

thobens
  • 1,729
  • 1
  • 15
  • 34
  • 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? – MrD Apr 02 '14 at 10:00
  • 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. – thobens Apr 02 '14 at 10:04
  • So do the different BeanManagers have any practical influence? If no: why is it worthwhile to mention the modulename/classloader in the `toString` output? – MrD Apr 02 '14 at 10:12
  • 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. – thobens Apr 02 '14 at 11:00
  • And I honestly don't know why the classloader is mentioned in the `toString()` output, maybe for debugging purposes. – thobens Apr 02 '14 at 11:06
  • Did this answer your question or do you need some further explanation? – thobens Apr 02 '14 at 12:49
  • I have to correlate this with my observations. I'll mark your answer as correct if everything is clear. Thank you so far – MrD Apr 02 '14 at 12:52