The Classloader Hierarchy
Classloaders in the Application Server runtime follow a hierarchy that is
illustrated in the following figure and fully described in Table 3–3.
Figure 3–5 Classloader runtime hierarchy
Table 3–3 Sun Java System Application Server Classloaders
Classloader
|
Description
|
Bootstrap
|
The Bootstrap Classloader loads all the JDK classes. It is parent to
the System Classloader.
|
System
|
The System Classloader
loads most of the core Application Server classes. It is parent to the Common Classloader.
It is created based on the classpath-prefix, as-install/lib, server-classpath, and classpath-suffix attributes of the java-config element in the domain.xml file. The environment classpath is included if env-classpath-ignored="false" is set in the java-config element.
Add the classes to the classpath-prefix, server-classpath, or classpath-suffix attribute of the domain
administration server (DAS) in addition to the corresponding attribute on
the server instances that use the classes. The default name for the DAS configuration
is server-config.
|
Common
|
The Common Classloader
loads into the system classpath classes in the domain-dir/lib/classes directory,
followed by JAR and ZIP files in the domain-dir/lib directory.
It is parent to the Connector Classloader. No special classpath settings are
required. The existence of these directories is optional; if they don’t
exist, the Common Classloader is not created.
|
Connector
|
The Connector Classloader is a single class loader instance that loads
individually deployed connector modules, which are shared across all applications.
It is parent to the LifeCycleModule Classloader and the EJB Classloader.
|
LifeCycleModule
|
The LifeCycleModule Classloader is the parent class loader for lifecycle
modules. Each lifecycle module’s classpath is used to construct its
own class loader.
|
EJB
|
The EJB Classloader loads the enabled EJB classes in a specific enabled
EJB module or J2EE application. One instance of this class loader is present
in each class loader universe. The EJB Classloader is created with a list
of URLs that point to the locations of the classes it needs to load. It is
parent to the Web Classloader.
|
Web
|
The Web Classloader loads the servlets and other classes in a specific
enabled web module or J2EE application. One instance of this class loader
is present in each class loader universe. The Web Classloader is created with
a list of URLs that point to the locations of the classes it needs to load.
It is parent to the JSP Engine Classloader.
|
JSP
Engine
|
The JSP Engine Classloader loads compiled JSP classes of enabled JSP
files. One instance of this class loader is present in each class loader universe.
The JSP Engine Classloader is created with a list of URLs that point to the
locations of the classes it needs to load.
|
Note that this is not a Java inheritance hierarchy, but a delegation
hierarchy. In the delegation design, a class loader delegates classloading
to its parent before attempting to load a class itself. A class loader parent
can be either the System Classloader or another custom class loader. If the
parent class loader can’t load a class, the findClass() method
is called on the class loader subclass. In effect, a class loader is responsible
for loading only the classes not available to the parent.
The Servlet specification recommends that the Web
Classloader look in the local class loader before delegating to its parent.
You can make the Web Classloader follow the delegation model in the Servlet
specification by setting delegate="false" in the class-loader element of the sun-web.xml file.
It’s safe to do this only for a web module that does not interact with
any other modules.
The default value is delegate="true", which causes
the Web Classloader to delegate in the same manner as the other classloaders.
You must use delegate="true" for a web application that
accesses EJB components or that acts as a web service client or endpoint.
For details about sun-web.xml, see The sun-web.xml File.