Obviously, a ClassLoader is used to load classes (and resources) that will then be usable from the application. Most of the ClassLoaders are URLClassLoaders, that means that they are based on a set of URLs. Theses URLs will be the place where the ClassLoader, when asked for a resource (using its fully qualified name, ie including full package name), will try to find the resource.

An URLClassLoader always have a parent ClassLoader. When loading a class, the first thing a ClassLoader do is to ask its parent to load the class (this is recursive). If the parent return the Class, it's returned to the caller. Otherwise, the URLs will be search for the given class. this is the default Java delegation model (parent first).

Let's roll with an example: you have a ClassLoader (let's call it A) that can load the class Test, A is the parent of B, but B do not contains the Test class, and B is the parent of C, with C that contains also the Test class. Clearly, there is a ClassLoader hierarchy here (C->B->A, with "->" meaning "is child of"). If you ask C to load Test, the following steps will be performed:

Java EE makes an heavy use of ClassLoaders: the application server in itself may be composed of multiple ClassLoaders and the Java EE applications (EAR, Rar, War, EjbJar) themselves are using ClassLoaders.

An application is deployed by its own class loader. This means, for example, that if a Web Application and an EjbJar 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 (this concerns local references in the same JVM).

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

Currently, with the Java EE integration and the use of the EAR packaging, that kind of class visibility problems no longer exist and the EjbJar is no longer required in the WEB-INF/lib directory.

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

JOnAS is basically an assembly of modules providing the features that makes JOnAS an application server. Each of the modules have an associated class loader. All theses loaders have visibility constraints, meaning that some of the internal classes or libraries used by JOnAS are hidden from the application class space. In clear, even if JOnAS may use a library also used by a deployed application, there will be no conflicts.

The loaders of JOnAS are not in a tree hierarchy. They all share the same parent class loader (the System classloader), so it's a flat hierarchy. Nevertheless, there are links (aka wires) between theses class loaders. A module can export some of its packages (and thus, all the classes from that package) to the system. Theses exported packages can then be imported by other modules. That creates a wire. As a module can be wired to multiple others modules, the class loaders of the application server forms an oriented graph of loaders.

Java EE modules are following the classic, hierarchical, parent oriented graph of class loaders.

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

By default, all classes exported by the application server can be accessed within an application. Sometimes this may cause problems if there are different versions of the library (in the AS and in the application)

For example, JOnAS is using Apache Commons Digester. If an application wants to use an older version of this library, there is a problem as the default loading mechanism of classes is searching first in the parent classloaders. Then the library provided by JOnAS and not by the application will be used.

For web applications, this mechanism could be changed by using java2-delegation-model but this may raise problems for EAR case, etc.

There is an option for helping to solve these cases. This is by using a filtered classloader. A filtered classloader will hide to applications some packages/resources exported by the Application Server. Some default filters are existing by default in JOnAS. These default filters are located in the JONAS_BASE/conf/classloader-default-filtering.xml file.

<class-loader-filtering xmlns="http://org.ow2.jonas.lib.loader.mapping">

   <!-- List of filters used to exclude packages/resources that are used internally by
        the Application Server but that will not be available to applications.
        An empty list will not hide any packages to the applications
        This list is used both to hide resources and classes to applications. -->
    <default-filters>
        <filter-name>org.apache.commons.digester.*</filter-name>
    </default-filters>
</class-loader-filtering>

By modifying the set of filters, some packages will be hidden to the applications. Note that resources name can be specified. For example, when putting a resource in JONAS_BASE/conf folder, this resource can be obtained by using ClassLoader.getResource() method. By adding a filter on this resource, the resource won't be available to applications (This includes EAR, WAR and EJB-JAR modules)