WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

Chapter 22. Understanding class loaders 791

If the application class loader needs to load a class, it first delegates to the extensions class

loader, which in turn delegates to the bootstrap class loader. If the parent class loader cannot

load the class, the child class loader tries to find the class in its own repository. In this manner,

a class loader loads only classes that its ancestors cannot load.

22.2 WebSphere Application Server and Java EE application

class loaders

When working with Java Platform, Enterprise Edition (Java EE) applications, two additional

types of class loaders are involved:

 The application server class loaders, which loads all of the classes that are needed for the

application server in which the enterprise applications are running.

 The application class loaders, which loads the application classes as defined in the

web.xml file.

Figure 22-2 shows a typical Java EE class loader.

Figure 22-2 Java EE class loading

WebSphere Application Server provides several custom delegated class loaders, similar to

those class loaders shown in 22.1, “JVM class loaders” on page 790, but it implements the

extensions as OSGi packages, as shown in Figure 22-3 on page 792.

Bootstrap class loader

Extensions class loader

WAR

class loader

WAR

class loader

WAR

class loader

WAR

class loader

Application class loader

Application Server

class loader

Application class loader

(EJB, RAR files, Utility JAR files)

Application class loader

(EJB, RAR files, Utility JAR files)

792 WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

Figure 22-3 WebSphere class loaders hierarchy

The top box represents the Java class loaders (bootstrap, extensions, and application).

WebSphere loads just enough here to get itself bootstrapped and to initialize the WebSphere

extensions class loader.

We provide information about the other components of this hierarchy in the sections that

follow.

22.2.1 WebSphere extensions class loader

The WebSphere extensions class loader is where WebSphere Application Server itself is

loaded. WebSphere is packaged as a set of OSGi bundles with each OSGi bundle loaded

separately by its own class loader. This network of OSGi class loaders is then connected to

the extensions class loader, and the remainder of the class loader hierarchy through an OSGi

gateway class loader.

Beginning with WebSphere V6.1, extensions began using OSGi packaging and the runtime

classes are stored in the install_root/plugins directory.

The class path that is used by the extensions class loader is retrieved from the ws.ext.dirs

system property, which is initially derived from the WAS_EXT_DIRS environment variable set

in the setupCmdLine script file.

Each directory listed in the ws.ext.dirs environment variable is added to the WebSphere

extensions class loaders class path, and every .jar file and .zip file in the directory is added

to the class path.

Although the classes and installedChannels directories no longer exist in the install_root

directory, the setupCmdLine script still adds them to the extensions class path. Thus, if you

added your own JAR files to one of these directories in previous releases, you can create this

directory and add your JAR files to it, and the JAR files are still loaded by the extensions class

loader. However, you must avoid this situation by migrating away from such a setup.

JVM class loaders

vs.

Java class loaders

WAR

class loader

WAR

class loader

WAR

class loader

WAR

class loader

Application class loader

(EJB, RAR files, Utility JAR files)

Application class loader

(EJB, RAR files, Utility JAR files)

WebSphere Application Server

OSGi Runtime

WebSphere Extensions class loader

(Third party code, JDBC drivers,

and so on)