As JOnAS is build on a modular system (OSGi™), it's very natural to "extends" the application server's class space.

There are 2 way that can be used to augment the class space:

In order to connect the applications to an external database (not HSQL which is embedded in JOnAS), the user must provide the jar file that contains the JDBC Driver's classes.

Providing theses jar files are just like extending JOnAS class loaders:

This class loader, child of the OSGi™ class loader, contains only the libraries provided by the system level resource adapters (i.e. resource adapters not part of an EAR application).

This class loader is the parent of all the deployed Java EE modules:

This means that all the classes available from this loader are also made available for the child loaders.

A standalone EjbJar classloader contains the classes packaged inside of the ejbjar. The parent of this classloader is the Section 2.1.3.1, “Standalone resource adapters loader”. It can therefore see all the classes available from the system level resource adapters and its ancestors.

The classloading policy of this loader is to ask its parent first, and then (if the class was not found) try to search in itself. There is no way to invert the classloading policy of an EjbJar classloader.

The classloader for standalone web applications modules contains the classes and libraries packaged inside of the war.

It contains the WEB-INF/classes/ directory (that usually matches the classes of the application) and all the jar files located under the WEB-INF/lib/ directory. Notice that only jars directly under the lib/ directory are available, jars in WEB-INF/lib/subdirectory/ will not be accessible from the classloader.

The parent of the standalone webapp classloader is the Section 2.1.3.1, “Standalone resource adapters loader”, meaning that all standalone web applications will be able to use system level resource adapters classes/libraries and the classes available from its ancestors.

A webapp loader also have a direct link with the system classloader (classes of the JVM + what's available from the CLASSPATH environment variable). All class loading actions are first directed to the system classloader to avoid JVM class overloading from the web application (in short, guards the developer from overloading primordial classes).

Then, if the system classlaoder did not find the required class, the loader will ask either the parent, or itself. Asking the parent or itself is configured by the delegation model choosed by the developer.

	Note
	By default, java2 delegation model is turned on.

<?xml version="1.0" encoding="ISO-8859-1"?>
<jonas-web-app xmlns="http://www.objectweb.org/jonas/ns"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="http://www.objectweb.org/jonas/ns
                                   http://jonas.ow2.org/ns/jonas-web-app_4_0.xsd">
    <!--
    true  : the context uses a classloader using the Java 2 delegation model (default)
    false : the class loader looks inside the web application first, before asking parent class loader
    -->
    <java2-delegation-model>false</java2-delegation-model>
</jonas-web-app>

The EAR class loader is the common parent (directly or indirectly) of all the class loaders of the inner modules (ejbjars, rar, webapps). There is only one EAR class loader per EAR application. This class loader is the child class loader, thus making JOnAS classes visible to it. The parent of all the EAR class loaders is a JOnAS special class loader that is able to seek for classes/resources exported by all the other module's class loaders of JOnAS.

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 EJB class loader are definitely visible to the classes loaded by its child class loader (WEB class loader).

The compliance of the class loader of the web application to the java 2 delegation model can be changed by using the WEB-INF/jonas-web.xml file. This is described in the section Defining the Web Deployment Descriptor.

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. See Section 2.1.3.3.1, “Java 2 delegation model” for more detailed explanations.

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.

JOnAS is providing the concept of filtering classloader. A filtered classloader will hide to applications some packages/resources exported by the Application Server.

A FilteringClassLoader is simply placed between a child ClassLoader and its parent and filter any requests coming from the child to the parent.

Figure 2.1. Filtering ClassLoader Principle

This approach allows a fine grain control over what is visible or not from a given ClassLoader.

Any loading request for a resource will trigger a matching against a list of excluded patterns. If any of the pattern match, the resource will not be loaded and the flow will return to the caller.

Loading of a filtered resource (image, static content, ...) will result in null (the usual return for a resource not found) being returned. If the loading request a filtered class, a ClassNotFoundException will be thrown back to the caller (the usual return when a class is not found).

Some filters are configured by default in JOnAS. They will be applied to the "standalone rars" ClassLoader, effectively filtering resource/class request from all the deployed applications (among just the standalone resource adapters). This is a system wide configuration.

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).

In addition of the system wide filters configuration, JOnAS allows Java EE modules to provide themselves the filters they requires.

It can be done by providing a classloader-filtering.xml file in the info directory of the deployed module (META-INF/ or WEB-INF/).

2.1.4.4.1. Supported module types

Not all modules supports the classloader filtering feature.

Supported modules includes:

• EAR applications (.ear)

• Web Applications (.war), inside or outside an application

• EjbJars (.jar), only the ones outside of an application

	Tip
	Web Applications filtering rules also apply when they are in an application (EAR).

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

    <filters>
        <!-- Excludes all CXF resources as another version is embed in the web application -->
        <filter-name>org.apache.cxf.*</filter-name>
        <!-- plus some other dependencies of CXF ... -->
        <filter-name>org.springframework.*</filter-name>
        <filter-name>net.sf.cglib.*</filter-name>
        <filter-name>org.objectweb.asm.*</filter-name>
    </filters>

</class-loader-filtering>