[V5.1.1 and later]Class loaders

Class loaders are part of the JVM code and are responsible for finding and loading class files. Class loaders affect the packaging of applications and the run-time behavior of packaged applications deployed on appservers.

The run-time environment of WebSphere Application Server 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 JVM.

    The bootstrap class loader uses the boot classpath (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 contains the J2EE APIs of the WebSphere Application Server product (inside j2ee.jar). Because the J2EE APIs are in this class loader, you can add libraries that depend on J2EE APIs to the classpath system property to extend a server's classpath. However, a preferred method of extending a server's classpath is to add a shared library.

  2. A WebSphere-specific extensions class loader

    The WebSphere extensions class loader loads the WebSphere run-time and J2EE classes that are required at run time. The extensions class loader uses a ws.ext.dirs system property to determine the path used to load classes. Each directory in the ws.ext.dirs classpath and every JAR file or ZIP file in these directories is added to the classpath 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, resource adapters, and dependency JAR files. Application class loaders follow J2EE class-loading rules to load classes and JAR files from an enterprise application. The WebSphere run time enables you to associate a shared library classpath with an application.

Each class loader is a child of the class loader above it. That is, the application module class loaders are children of the WebSphere-specific extensions class loader, which is a child of the CLASSPATH Java class loader. 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 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 ClassNotFoundException occurs. Once a class is loaded by a class loader, any new classes that it tries to load reuse the same class loader or go up the precedence list until the class is found.

 

Class preloading

[V5.1.1 and later]The first time a WAS process starts up, the name of each run-time class loaded and the name of the JAR file containing the class are written to a preload file. The names of non-runtime classes such as custom services, resource classes such as db2java.zip, classes on the JVM classpath, and application classes are not written to the preload file. Subsequent startups of the process use the preload file to start the process more quickly.

[V5.1.1 and later]Preload files have the extension .preload. WAS processes that have preload files include the following:

Process Preload file name
Application server cell_name.node_name.server_name.preload
startserver WsServerLauncher.preload
launchClient launchClient.preload

[V5.1.1 and later]Running the command startserver server1 causes the startserver command to use a WsServerLauncher.preload file and the server to use a cell_name.node_name.server1.preload file. Later running a command such as startserver server1 -script, where the -script option creates a new script, uses the cell_name.node_name.server1.preload file only.

[V5.1.1 and later]Preload files, by default, reside in the %was.install.root%/logs/preload directory. If the WAS process does not have write authority to this directory, the process tries writing to the %user.install.root%/logs/preload directory. If the file cannot be written at that location, a preload file is not created.

[V5.1.1 and later]New classes required during startup of a process are added to the preload file. Any classes removed from a process are ignored during subsequent startups. Although it is not necessary, an administrator can delete the preload file and force a refresh that removes the ignored classes from the file.

 

Class-loader isolation policies

The number and function of the application module class loaders depends 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 appserver.

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

Application class-loader policy

Application class loaders consist of EJB modules, dependency JAR files, resource adapters, and 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 class-loader policy

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 application's WAR class-loader policy.

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.

Note: WebSphere server 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 used for loading that application's EJB modules, dependency JAR files, and shared libraries.

This application class loader can load each application's Web modules if that WAR module's class-loader policy is also set to APPLICATION. If the WAR module's class-loader policy is set to APPLICATION, then the application's loader loads the WAR module's classes. If the 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 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 having a WAR class-loader policy set to MODULE use a separate class loader for Web modules.

Application class-loader policy: SINGLE

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
SINGLE class-loader policy

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's WAR class-loader policy is set to APPLICATION. If the policy is set to MODULE, then a Web module uses its own class loader.

Application class-loader policy: MULTIPLE

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
MULTIPLE class-loader policy

 

Class-loader modes

There are two possible values for a class-loader mode:

PARENT_FIRST

The PARENT_FIRST class-loader mode causes the class loader to first delegate the loading of classes to its parent class loader before attempting to load the class from its local classpath. This is the default for class-loader policy and for standard JVM class loaders.

PARENT_LAST

The PARENT_LAST class-loader mode causes the class loader to first attempt to load classes from its local classpath before delegating the class loading to its parent. This policy allows an application class loader to override and provide its own version of a class that exists in the parent class loader.

The following settings determine a class loader's mode:


Related concepts
Enterprise applications
Related tasks
Managing shared libraries
Class loading
Related reference
Enterprise application settings
Application server settings
Shared library collection