JOnAS class loader hierarchy

Target Audience and Content

The target audience for this guide is the EAR application provider, i.e. the person in charge of developing the J2EE application components on the server side. This guide describes a new and important key feature of the J2EE integration: the class loader hierarchy in JOnAS.

The content of this guide is the following:

  1. Target Audience and Content
  2. Understanding class loader hierarchy
  3. Bootstrap class loader
  4. JOnAS class loaders
  5. Conclusion

Understanding class loader hierarchy

An application is deployed by its own class loader. This means, for example, that if a WAR and an EJB JAR are deployed separately, the classes contained in the two archives are loaded with two separate classloaders with no hierarchy between them. Thus, the EJBs from within the JAR will not be visible to the Web components in the WAR.
This is not acceptable in cases where the Web components of an application need to reference and use some of the EJBs.

For this reason, prior to EAR files, when a Web application had to be deployed using EJBs, the EJB JAR had to be located in the WEB-INF/lib directory of the Web application.

Currently, with the J2EE integration and the use of the EAR packaging, class visibility problems no longer exist and the EJB JAR is no longer required in the WEB-INF/lib directory.

The following sections describe the JOnAS class loader hierarchy and explain the mechanism used to locate the referenced classes.

Bootstrap class loader

The bootstrap class loader is a JOnAS-specific class loader that will load all classes required to start the JOnAS server. This class loader has the system class loader as parent class loader. The Bootstrap class loader adds all the libraries required to start the JOnAS server (libraries for the mail, tomcat, etc.); it also loads the classes located in XTRA_CLASSPATH. For example, when loading an unpacked EJB component, the location of its classes must be specified in the XTRA_CLASSPATH.

To have a library available for each component running inside JOnAS, add the required jars file in the JONAS_ROOT/lib/ext directory or in the JONAS_BASE/lib/ext. The jars in JONAS_BASE/lib/ext are loaded first, followd by the jars in JONAS_ROOT/lib/ext. All jars in subordinate directories will also be loaded.
If a specific jar is needed only for a web application (i.e., need to use a version of a jar file which is different than a version loaded by JOnAS), change the compliance of the web application classloader to the java 2 delegation model. Refer to the following: WEB class loader.
It is also possible to use the extension mechanism, which is described in the section dependencies of the J2EE specification (section 8.1.1.28)

JOnAS class loaders

The JOnAS class loader hierarchy that allows the deployment of EAR applications without placing the EJB JAR in the WEB-INF/lib directory consists of the following:

EAR class loader

The EAR class loader is responsible for loading the EAR application. There is only one EAR class loader per EAR application. This class loader is the child of the bootstrap class loader, thus making it visible to the JOnAS classes.

EJB class loader

The EJB class loader is responsible for loading all the EJB JARs of the EAR application, thus all the EJBs of the same EAR application are loaded with the same EJB classloader. This class loader is the child of the EAR class loader.

WEB class loader

The WEB class loader is responsible for loading the Web components. There is one WEB class loader per WAR file, and this class loader is the child of the EJB class loader. Using this class loader hierarchy (the EJB class loader is the parent of the WEB class loader) eliminates the problem of visibility between classes when a WEB component tries to reference EJBs; the classes loaded with the WEB class loader are definitely visible to the classes loaded by its parent class loader (EJB class loader).

The compliance of the class loader of the web application to the java 2 delegation model can be changed by using the jonas-web.xml file. This is described in the section "Customizing jonas-web.xml file."

If the java2-delegation-model element is set to false, the class loader of the web application looks for the class in its own repository before asking its parent class loader.

Conclusion

The resulting JOnAS class loader hierarchy is as follows:

JOnAS class loader hierarchy