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.
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:
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 Java 2 Platform, Enterprise Edition (J2EE) application programming interfaces (APIs) provided by the WebSphere Application Server 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.
The WebSphere Application Server extensions class loader loads the WebSphere Application Server 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 Java archive (JAR) file or ZIP file in these directories is added to the class path used by this class loader.
The WebSphere Application Server 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.
The application elements can be Web modules, enterprise bean (EJB) modules, resource adapters archives (RAR files), and dependency JAR files. Application class loaders follow J2EE class-loading rules to load classes and JAR files from an enterprise application. WebSphere Application Server enables you to associate shared libraries with an application.
By default, Web module class loaders load the contents of the WEB-INF/classes and WEB-INF/lib directories.
Web module class loaders are children of application class loaders. You can specify that an application class loader load the contents of a Web module rather than the Web module class loader.
Each class loader is a child of the previous class loader. 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 WebSphere Application Server 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 error occurs. After 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
The first time that a WebSphere Application Server process starts, the name of each run-time class that is loaded and the name of the JAR file that contains 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 class path, 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. Preload files have the .preload extension. WebSphere Application Server processes that have preload files include the following:
| Process | Preload file name |
| Application server | cell_name.node.server_name.preload |
| startserver | WsServerLauncher.preload |
| launchClient | launchClient.preload |
Running the startserver server1 command causes the startserver command to use a WsServerLauncher.preload file and the server to use a cell_name.node.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.server1.preload file only.
Preload files, by default, are installed in the install_root directory.
New classes required during the startup of a process are added to the preload file. Any classes that are 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 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 application server.
Two class-loader policies control the isolation of applications and modules:
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 Application Server class loaders never load application client modules.
For each application server 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 application server 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
Two values for a class-loader mode are supported:
The following settings determine the mode of a class loader:
Related concepts
Enterprise (J2EE) applications
Related tasks
Managing shared libraries
Configuring class preloading
Related reference
Enterprise application settings
Application server settings
Shared library collection