Compared to earlier JBoss versions, AS7’s class loading mechanism is entirely different. AS7’s class loading is designed around JBoss modules. For an introduction to JBoss modules, see the previous article JBoss Module Introduction.

Implicit module dependencies

When you deploy an application to a JBoss container, some dependencies are loaded implicitly. For example, if you deploy a Java EE application that contains EJBs, since EJBs need the Javax.ejb.* package and other Java EE API related packages, the JARs containing those packages are already packaged into modules and included in the container by default as part of JBoss AS, so the modules for those JARs are loaded automatically.

So when are implicit module dependencies loaded? When an application is deployed to the container, it passes through a chain called the “deployment processors”. Each processor on this chain has a method to detect whether the application needs certain modules to be loaded implicitly, and if so, loads the relevant dependencies.

There are several detection approaches, such as annotations. If a class is annotated with @Stateless, the container knows that it is an EJB class.

For the list of modules loaded implicitly by JBoss AS7, see: Implicit module dependencies

Class loading priority

The order of class loading is meant to avoid class conflicts. The following order is listed from highest to lowest priority:

1. System dependencies — the implicit dependencies described above.
2. User dependencies — dependencies declared in jboss-deployment-structure.xml; dependencies declared in the manifest file via Dependencies; and dependencies declared via Class-Path all count as user dependencies.
3. Local resources — classes packaged inside the application, including class files under WEB-INF/classes and JARs under WEB-INF/lib.
4. Inter-deployment dependencies — one deployment depending on another; for example, an EAR depending on another deployed application, classes under an EAR’s lib, and so on.

Class loading for WAR archives

A WAR archive is a single module, so a WAR corresponds to a single class loader.

Class loading for EAR archives

An EAR is treated as a multi-module deployment. Generally speaking, the EAR/lib folder is treated as one module, and each WAR or EJB JAR is treated as an independent module. Sub-modules (WARs and EJB-JARs) generally depend on the parent module (EAR/lib), so sub-modules can access JARs under EAR/lib, but sub-modules are not necessarily visible to each other. Visibility can be configured via ear-subdeployments-isolated.

<subsystem xmlns="urn:jboss:domain:ee:1.0" >            
  <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
</subsystem>

The default value is false, so one sub-module can access the classes of another sub-module.

For example, given the following EAR structure:

myapp.ear
 |
 |--- web.war
 |
 |--- ejb1.jar
 |
 |--- ejb2.jar

If ear-subdeployments-isolated is set to false, then web.war can access the classes in ejb1.jar or ejb2.jar; likewise, ejb1.jar and ejb2.jar are mutually visible. However, this parameter does not apply to sub-deployments that have their own class loader — such as WAR archives within an EAR. Because each WAR is a sub-deployment with an independent class loader, classes between WARs are not visible to each other. Similarly, classes in JARs under the EAR cannot access classes within a WAR.

• Tags:
• Java
• JBoss
• Class Loading