WAS v8.5 > Develop applications > Class loading

Class loaders

Class loaders find and load class files. Class loaders enable applications 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 theclass loaders used to access those files, to make the files available to deployed applications.

This topic provides the following information aboutclass loaders in WebSphere Application Server:


Class loaders used and the order of use

WAS v8.5 runtime environment uses the followingclass loaders to find and load new classes for an application in the following order:

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

    The bootstrapclass loader uses the boot class path (typically classes in jre/lib) to find and load classes. The extensionsclass loader uses the system property java.ext.dirs (typically jre/lib/ext) to find and load classes. The CLASSPATHclass loader uses the CLASSPATH environment variable to find and load classes.

    The CLASSPATH class loader loads the Java EE APIs provided by the WAS product in the j2ee.jar file. Because thisclass loader loads the Java EE APIs, we can add libraries that depend on the Java EE 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 extensionsclass loader loads the WAS classes required at run time. The extensionsclass loader uses a ws.ext.dirs system property to determine the path used to load classes. Each directory in the ws.ext.dirs class path and every JAR file or compressed file in these directories is added to the class path used by thisclass loader.

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

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

    The application elements can be web modules, EJB modules, resource adapter archives (RAR files), and dependency JAR files. Applicationclass loaders follow Java EE class-loading rules to load classes and JAR files from an enterprise application. WAS v8.5 enables you to associate shared libraries with an application.

  4. Zero or more web moduleclass loaders

    By default, web moduleclass loaders load the contents of the WEB-INF/classes and WEB-INF/lib directories. Web moduleclass loaders are children of applicationclass loaders. We can specify that an applicationclass loader load the contents of a web module rather than the web moduleclass loader.

Eachclass loader is a child of the previousclass loader. That is, the application moduleclass loaders are children of the WebSphere extensionsclass loader, which is a child of the CLASSPATHclass loader.

Whenever a class needs to be loaded, theclass loader usually delegates the request to its parentclass loader. If none of the parentclass loaders can find the class, the originalclass loader attempts to load the class. Requests can only go to a parentclass loader; they cannot go to a childclass loader. If the WebSphere extensionsclass loader is requested to find a class in a Java EE module, it cannot go to the application moduleclass loader to find that class and a ClassNotFoundException error occurs. After a class is loaded by aclass loader, any new classes that it tries to load reuse the sameclass loader or go up the precedence list until the class is found.


Class-loader isolation policies

The number and function of the application moduleclass loaders depend on the class-loader policies 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 application server.

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

Class-loader policy Description
Application Applicationclass loaders load EJB modules, dependency JAR files, embedded resource adapters, and application-scoped shared libraries. Depending on the application class-loader policy, an applicationclass loader can be shared by multiple applications (Single) or unique for each application (Multiple). The application class-loader policy controls the isolation of applications that are 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 moduleclass loaders load the contents of the WEB-INF/classes and WEB-INF/lib directories. The applicationclass loader is the parent of the web moduleclass loader. We can change the default behavior by changing the web application archive (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 applicationclass 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 ownclass loader whose parent is the applicationclass 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.

Restriction:class loaders never load application client modules.

For each application server in the system, we can set the application class-loader policy to Single or Multiple. When the application class-loader policy is set to Single, then a single applicationclass 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 ownclass loader used for loading the EJB modules, dependency JAR files, and shared libraries for that application.

An applicationclass 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 ownclass loader.

The following example shows that when the application class-loader policy is set to Single, a single applicationclass loader loads all of the EJB modules, dependency JAR files, and shared libraries of all applications on the server. The single applicationclass 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 separateclass 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 application server is set to Multiple, each application on the server has its ownclass loader. An applicationclass 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 ownclass 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 aclass loader delegates the loading of classes to the parentclass loader. The following values for class-loader mode are supported:

Class-loader mode Description
Parent first

Also known as Classes loaded with parentclass loader first.

The Parent first class-loader mode causes theclass loader to delegate the loading of classes to its parentclass 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 JVMclass loaders.
Parent last

Also known as Classes loaded with localclass loader first or Application first.

The Parent last class-loader mode causes theclass loader to attempt to load classes from its local class path before delegating the class loading to its parent. Using this policy, an applicationclass loader can override and provide its own version of a class that exists in the parentclass loader.

The following settings determine the mode of aclass loader:


Related concepts:

Enterprise (Java EE) applications


Related


Create shared libraries
Manage shared libraries


Reference:

Enterprise application settings
Application server settings
Shared library page


+

Search Tips   |   Advanced Search