Class loaders
The WAS runtime environment uses the following class loaders in the following order:
- JVM bootstrap, extensions, and CLASSPATH class loaders
The bootstrap class loader uses the boot class path (jre/lib). The extensions class loader uses the system property java.ext.dirs (jre/lib/ext). The CLASSPATH class loader uses the CLASSPATH environment variable.
- WebSphere extensions class loader
Loads the application servers run time classes. Provided as a set of OSGi bundles. Each bundle is loaded by a separate class loader within a network of OSGi class loaders. The extensions class loader delegates to a gateway class loader to load classes from this OSGi class loader network. Packages exported from the OSGi class loader network are visible to applications through the gateway. For details, see OSGi class loader model.
- 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 adapter archives (RAR files), and dependency JAR files. Application class loaders follow Java EE class-loading rules to load classes and JAR files from an enterprise application. The product enables us to associate shared libraries with an application.
- Zero or more web module class loaders
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. We can specify 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 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 extensions class loader is requested to find a class in a Java EE 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-loader isolation policies
| 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. 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 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. Tip: 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: WAS 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 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 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
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.
| Class-loader mode | Description |
|---|---|
| Parent first | Delegate the loading of classes to the parent class loader before attempting to load the class from its local class path. Default for the class-loader policy and for standard JVM class loaders. |
| Parent last | Load classes from the 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. Also known as Classes loaded with local class loader first or Application first. |
The following settings determine the mode of a class loader:
- If the application class-loader policy of an application server is Single, the server-level mode value defines the mode for an application class loader.
- If the application class-loader policy of an application server 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.
OSGi class loader model
Java EE APIs provided in the javax.j2ee.*.jar bundles.
Loaded within the OSGi class loader network and made visible to applications through the gateway. Because classes deployed within OSGi bundles are not visible to the Java virtual machine class loaders, do not use the CLASSPATH environment variable or the java.ext.dirs and java.lang.classpath system properties to specify paths to libraries that depend on the Java EE APIs. Also, do not use CLASSPATH, java.ext.dirs, and java.lang.classpath to specify paths to application libraries because these libraries might cause linkage errors or unexpected server behaviors. The WebSphere extensions class loader uses a ws.ext.dirs system property to determine the path used to load classes and resources beyond those provided in OSGi bundles. 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 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 associated with the provider and if the provider specifies the directory name of the resource drivers.
OSGi uses metadata in the manifest file as its class loader mode. There is no global class path in OSGi. When bundles are installed into the OSGi Framework, their metadata is processed by the module layer and their declared external dependencies are reconciled against the versioned exports declared by other installed modules. The OSGi Framework works out all the dependencies, and calculates the independent required class path for each bundle. This approach resolves the shortcomings of plain Java class loading by ensuring that the following requirements are met:
- Each bundle provides visibility only to Java packages that it explicitly exports.
- Each bundle declares its package dependencies explicitly.
- Packages can be exported at specific versions, and imported at specific versions or from a specific range of versions.
- Multiple versions of a package can be available concurrently to different clients.
Related: