Class loaders

 

+

Search Tips   |   Advanced Search

 

Class loaders find and load class files. Class loaders enable applications that are deployed on servers to access repositories of available classes and resources. Application developers and deployers must consider the location of class and resource files, and the class loaders used to access those files, to make the files available to deployed applications.

This topic provides the following information about class loaders in WAS:

• Class loaders used and the order of use
• Class-loader isolation policies
• Class-loader modes

 

Class loaders used and the order of use

The runtime environment of WAS uses the following class loaders to find and load new classes for an application in the following order:

1. The bootstrap, extensions, and CLASSPATH class loaders created by the Java virtual machine

   The bootstrap class loader uses the boot class path, typically classes in...

   jre/lib

   ...to find and load classes.

   The extensions class loader uses the system property java.ext.dirs, typically...

   jre/lib/ext

   ...to find and load classes.

   The CLASSPATH class loader uses the CLASSPATH environment variable to find and load classes.

   The CLASSPATH class loader loads the J2EE APIs provided by the WAS product in the j2ee.jar file. Because this class loader loads the J2EE APIs, you can add libraries that depend on the J2EE APIs to the class path system property to extend a server class path. However, a preferred method of extending a server class path is to add a shared library.

2. A WebSphere extensions class loader

   The WebSphere extensions class loader loads the WAS classes that are required at run time. The extensions class loader uses a ws.ext.dirs system property to determine the path that is used to load classes. Each directory in the ws.ext.dirs class path and every JAR file or ZIP file in these directories is added to the class path used by this class loader.

   The WebSphere extensions class loader also loads resource provider classes into a server if an application module installed on the server refers to a resource that is associated with the provider and if the provider specifies the directory name of the resource drivers.

3. One or more application module class loaders that load elements of enterprise applications running in the server

   The application elements can be...

   • Web modules
   • EJB modules
   • RAR files
   • Dependency JAR files

   Application class loaders follow J2EE class-loading rules to load classes and JAR files from an enterprise application. WAS enables you to associate shared libraries with an application.

4. Zero or more Web module class loaders

   By default, Web module class loaders load the contents of...

   • WEB-INF/classes
   • WEB-INF/lib

Application module class loaders are children of the WebSphere extensions class loader, which is a child of the CLASSPATH Java class loader.

loader hierarchy" />

Whenever a class needs to be loaded, the class loader usually delegates the request to its parent class loader. If none of the parent class loaders can find the class, the original class loader attempts to load the class.

Requests can only go to a parent class loader; they cannot go to a child class loader. If the WebSphere extensions class loader is requested to find a class in a J2EE module, it cannot go to the application module class loader to find that class and a

If a class is not found, a ClassNotFoundException error occurs.

 

Class-loader isolation policies

The number and function of the application module class loaders depend on the class-loader policies that are specified in the server configuration. Class loaders provide multiple options for isolating applications and modules to enable different application packaging schemes to run on an appserver.

Two class-loader policies control the isolation of applications and modules:

Class-loader policy	Description
Application	Application class loaders load EJB modules, dependency JAR files, embedded resource adapters, and application-scoped shared libraries. Depending on the application class-loader policy, an application class loader can be shared by multiple applications (Single) or unique for each application (Multiple). The application class-loader policy controls the isolation of applications running in the system. When set to Single, applications are not isolated. When set to Multiple, applications are isolated from each other.
WAR	By default, Web module class loaders load the contents of the WEB-INF/classes and WEB-INF/lib directories. The application class loader is the parent of the Web module class loader. You can change the default behavior by changing the WAR class-loader policy of the application. The WAR class-loader policy controls the isolation of Web modules. If this policy is set to Application, then the Web module contents also are loaded by the application class loader (in addition to the EJB files, RAR files, dependency JAR files, and shared libraries). If the policy is set to Module, then each Web module receives its own class loader whose parent is the application class loader. The console and the underlying deployment.xml file use different names for WAR class-loader policy values. In the console, the WAR class-loader policy values are Application or Module. However, in the underlying deployment.xml file where the policy is set, the WAR class-loader policy values are Single instead of Application, or Multiple instead of Module. Application is the same as Single, and Module is the same as Multiple.

WAS class loaders never load application client modules.

For each appserver in the system, you can set the application class-loader policy to Single or Multiple. When the application class-loader policy is set to Single, then a single application class loader loads all EJB modules, dependency JAR files, and shared libraries in the system. When the application class-loader policy is set to Multiple, then each application receives its own class loader that is used for loading the EJB modules, dependency JAR files, and shared libraries for that application.

An application class loader loads classes from Web modules if the application's WAR class-loader policy is set to Application. If the application's WAR class-loader policy is set to Module, then each WAR module receives its own class loader.

The following example shows that when the application class-loader policy is set to Single, a single application class loader loads all of the EJB modules, dependency JAR files, and shared libraries of all applications on the server. The single application class loader can also load Web modules if an application has its WAR class-loader policy set to Application. Applications that have a WAR class-loader policy set to Module use a separate class loader for Web modules.

Server's application class-loader policy: Single
Application's WAR class-loader policy: Module

Application 1
  Module:   EJB1.jar
  Module:  WAR1.war
     MANIFEST Class-Path: Dependency1.jar
    WAR Classloader Policy = Module
Application 2  
  Module:    EJB2.jar
    MANIFEST Class-Path: Dependency2.jar
  Module:  WAR2.war
    WAR Classloader Policy = Application

The following example shows that when the application class-loader policy of an appserver is set to Multiple, each application on the server has its own class loader. An application class loader also loads its Web modules if the application WAR class-loader policy is set to Application. If the policy is set to Module, then a Web module uses its own class loader.

Server's application class-loader policy: Multiple
Application's WAR class-loader policy: Module

Application 1
  Module:   EJB1.jar
  Module:  WAR1.war   
    MANIFEST Class-Path: Dependency1.jar
    WAR Classloader Policy = Module
Application 2  
  Module:    EJB2.jar
    MANIFEST Class-Path: Dependency2.jar
  Module:  WAR2.war
    WAR Classloader Policy = Application

 

Class-loader modes

The class-loader delegation mode, also known as the class loader order, determines whether a class loader delegates the loading of classes to the parent class loader. The following values for class-loader mode are supported:

Class-loader mode	Description
Parent first Also known as Classes loaded with parent class loader first.	The Parent first class-loader mode causes the class loader to delegate the loading of classes to its parent class loader before attempting to load the class from its local class path. This value is the default for the class-loader policy and for standard JVM class loaders.
Parent last Also known as Classes loaded with application class loader first.	The Parent last class-loader mode causes the class loader to attempt to load classes from its local class path before delegating the class loading to its parent. Using this policy, an application class loader can override and provide its own version of a class that exists in the parent class loader.

The following settings determine the mode of a class loader:

• If the application class-loader policy of an appserver is Single, the server-level mode value defines the mode for an application class loader.

• If the application class-loader policy of an appserver is Multiple, the application-level mode value defines the mode for an application class loader.

• If the WAR class-loader policy of an application is Module, the module-level mode value defines the mode for a WAR class loader.

---

 

Related concepts

Enterprise (J2EE) applications
Jakarta Commons Logging

 

Related tasks

Manage shared libraries
Configure applications to use Jakarta Commons Logging
Troubleshooting class loaders

 

Related Reference

Enterprise application settings
Application server settings
Shared library collection