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:
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.
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)
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:
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.
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.
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.
The resulting JOnAS class loader hierarchy is as follows: