JBoss 3 Classloader Architecture DRAFT
(by Scott Stark)
Introduction
JBoss 3.0 introduces a radically different class loading architecture relative to previous JBoss releases. This document introduces the architecture as it exists in the current JBoss 3.0RC2 release.
Architecture Overview
The generalized notion that JBoss 3.0 introduces is the ability to share classes across deployment units. In JBoss 2.x it was difficult to have MBean services interact with dynamically deployed J2EE components, and MBeans themselves were not hot deployable. In JBoss 3.x, everything is hot deployable. A new deployment architecture and class loading architecture makes
this possible.
The new class loading architecture centers around a common repository repository of classes in the form of a JMX MBean. A custom subclass of URLClassLoader known as a UnifiedClassLoader (UCL) is introduced and used as the primary class loader in JBoss 3.0. When a UCL is asked to load a class it first looks to the repository it is associated with to see if the class exist in the repository. Only if the class does not exist in the repository will is load the class. Currently there is a single class repository shared across all UCL instances. This means the UCLs form a single flat class loader namespace. Figure 1 shows an outline of the class heirarchy that would exist for an ear deployment containing ejbs and wars.
System ClassLoaders
The System ClassLoaders node refers to either the thread context class loader (TCL) of the VM main thread or of the thread of the app which is loading the JBoss server if it is embedded.
ServerLoader
The ServerLoader node refers to the a URLClassLoader that delegates to the System ClassLoaders and contains the following boot URLs
* All urls references via the jboss.boot.library.list system property. These are path specifications relative to the libraryURL defined by the jboss.lib.url property. If not specified this default to the jboss.home.url + /lib/.
* The JAXP jar which is either crimson.jar or xerces.jar depending on the -j option to the Main entry point. The default is crimson.jar
* The JMX jar jboss-jmx.jar
* Oswego Concurrent jar concurrent.jar
* Any jars specified as libraries via -L command line options
* Any other jars or directories specified via -C command line options
Server
The Server node represent a collection of UnifiedClassLoaders created by the org.jboss.system.server.Server interface implementation. The default implementation creates UCLs for the
patchDir entries as well as the server conf directory. The last UCL created is set as the JBoss main thread context class loader.
All UnifiedClassLoaders
The All UnifiedClassLoaders node represents the UCLs created by deployers. This covers ears, jars, wars, sars and directories seen by the deployment scanner as well as jars referenced by their manifests and any nested deployment units they may contain. This is a flat namespace and there cannot be multiple instances of a class in different deployment jars. If there are, only the first loaded will be used. If there are different versions of a class chaos will most likely ensue.
EJB DynClassLoader
The EJB DynClassLoader node is a subclass of URLClassLoader that is used to provide RMI dynamic class loading via the simple HTTP WebService. It specifies an empty URL[] and delegates to the TCL as its parent class loader. If the WebService is configured to allow system level classes to be loaded, all classes in the UnifiedLoaderRepository as well as the system
classpath are available via HTTP.
EJB ENCLoader
The EJB ENCLoader node is a URLClassLoader that exists only to provide a unique context for an EJB deployment's java:comp JNDI context. It specifies an empty URL[] and delegates to the EJB DynClassLoader as its parent class loader.
Web ENCLoader
The Web ENCLoader node is a URLClassLoader that exists only to provide a unique context for a web deployment's java:comp JNDI context. It specifies an empty URL[] and delegates to the TCL as its parent class loader.
WAR Loader
The WAR Loader is a servlet container specific ClassLoader that delegates to the Web ENCLoader as its parent class loader. The default behavior is to load from its parent class loader and then the war WEB-INF/{classes,lib} directories. If the servlet 2.3 class loading model is enabled it will first load from the war WEB-INF/{classes,lib} and then the parent class loader.
Advantages and Disadvantages
In its current form there are some advantages and disadvantages to the new class loading architecture.
Advantages include:
* Classes do not need to be replicated across deployment units in order to have access to them.
* Many future possibilities including novel partitioning of the repositories into domains, dependency and conflict detection, ...
Disadvantages include:
* Existing deployments may need to be repackaged to avoid duplicate classes
* Deployments that depend on different versions of the a given class need to be isolated in seperate JBoss servers. This will be addressed in the RC3 release with an ability to isolate classes using ears.
