Sun Java System Application Server Platform Edition 8.1 2005Q2 Update 2 Developer's Guide

- Previous: Runtime Environments
- Next: Classloader Universes

### 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`, `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.
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.

- Previous: Runtime Environments
- Next: Classloader Universes

- © 2010, Oracle Corporation and/or its affiliates