[WAS_7.0_ADMIN_GUIDE] Application server class loader policies [WAS_7.0_ADMIN_GUIDE] Class loading/delegation mode [WAS_7.0_ADMIN_GUIDE] Shared Libraries

Application server class loader policies

For each application server in the system, the class loader policy can be set to Single or Multiple. These settings can be found in the administrative console by selecting Servers > Server Types > WebSphere application servers > server_name.

Figure 3.13. Application server classloader settings

Here is an example to illustrate. Suppose that you have two applications, Application1 and Application2, running in the same application server. Each application has one EJB module, one utility JAR, and two Web modules. If the application server has its class loader policy set to Multiple and the class loader policy for all the Web modules are set to Class loader for each WAR file in application, the result is as shown in figure below:

Figure 3.14. Class loader policies: Example 1

Each application is completely separated from the other and each Web module is also completely separated from the other one in the same application. WebSphere's default class loader policies results in total isolation between the applications and the modules.

If we now change the class loader policy for the WAR2-2 module to Single class loader for application, the result is shown in figure below:

Figure 3.15. Class loader policies: Example 2

Web module WAR2-2 is loaded by Application2's class loader and classes, and for example, classes in Util2.jar are able to see classes in WAR2-2's /WEB-INF/classes and /WEB-INF/lib directories.

As a last example, if we change the class loader policy for the application server to Single and also change the class loader policy for WAR2-1 to Single class loader for application, the result is as shown in figure below:

Figure 3.16. Class loader policies: Example 3

There is now only a single application class loader loading classes for both Application1 and Application2. Classes in Util1.jar can see classes in EJB2.jar, Util2.jar, WAR2-1.war and WAR2-2.war. The classes loaded by the application class loader still cannot, however, see the classes in the WAR1-1 and WAR1-2 modules, because a class loader can only find classes by going up the hierarchy, never down.

Class loading/delegation mode

WebSphere's application class loader and WAR class loader both have a setting called the class loader order.

Figure 3.17. Application server classloader settings

This setting determines whether the class loader order should follow the normal Java class loader delegation mechanism, or override it.

There are two possible options for the class loading mode:

In previous WebSphere releases, these settings were called PARENT_FIRST and PARENT_LAST, respectively.

The default value for class loading mode is Classes loaded with parent class loader first. This 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 class path. This is the default policy for standard Java class loaders.

If the class loading policy is set to Classes loaded with local class loader first (parent last), the class loader attempts to load classes from its local class path 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.

NOTE: The administrative console is a bit confusing at this point. On the settings page for a Web module, the two options for class loader order are Classes loaded with parent class loader first and Classes loaded with local class loader first (parent last). However, in this context, the "local class loader" really refers to the WAR class loader, so the option Classes loaded with local class loader first should really be called Classes loaded with WAR class loader first.

Assume that you have an application, similar to Application1 in the previous examples, and it uses the popular log4j package to perform logging from both the EJB module and the two Web modules. Also assume that each module has its own, unique, log4j.properties file packaged into the module. You could configure log4j as a utility JAR so you would only have a single copy of it in your EAR file.

However, if you do that, you might be surprised to see that all modules, including the Web modules, load the log4j.properties file from the EJB module. The reason is that when a Web module initializes the log4j package, the log4j classes are loaded by the application class loader. Log4j is configured as a utility JAR. Log4j then looks for a log4j.properties file on its class path and finds it in the EJB module.

Even if you do not use log4j for logging from the EJB module and the EJB module does not, therefore, contain a log4j.properties file, log4j does not find the log4j.properties file in any of the Web modules anyway. The reason is that a class loader can only find classes by going up the hierarchy, never down.

To solve this problem, you can use one of the following approaches:

Shared Libraries

Shared libraries are files used by multiple applications. Examples of shared libraries are commonly used frameworks like Apache Struts or log4j. You use shared libraries typically to point to a set of JARs and associate those JARs to an application, a Web module, or the class loader of an application server. Shared libraries are especially useful when you have different versions of the same framework you want to associate to different applications.

Shared libraries are defined using the administration tools. They consist of a symbolic name, a Java class path, and a native path for loading JNI libraries. They can be defined at the cell, node, server, or cluster level. However, simply defining a library does not cause the library to be loaded. You must associate the library to an application, a Web module, or the class loader of an application server for the classes represented by the shared library to be loaded. Associating the library to the class loader of an application server makes the library available to all applications on the server.

NOTE: If you associate a shared library to an application, do not associate the same library to the class loader of an application server.

You can associate the shared library to an application in one of two ways:

Shared files are associated with the class loader of an application server using the administrative tools. The settings are found in the Server Infrastructure section. Expand the Java and Process Management. Select Class loader and then click the New button to define a new class loader. After you have defined a new class loader, you can modify it and, using the Shared library references link, you can associate it to the shared libraries you need.

Isolated Shared Libraries

An Isolated Shared Library is another way to deploy application artifacts into the WebSphere runtime environment. An Isolated Shared Library can be associated or shared with one or many WebSphere application and Web module class loaders. The Isolated Shared Library will provide a mechanism where you can share a common set of classes across a subset of the applications within the WebSphere Application Server. This is similar to the server associated shared library, but an Isolated Shared Library is not typically used across ALL applications.

An Isolated Shared Library associated with the application class loader can be thought of as an application associated shared library that can be shared across a subset of the applications in the WebSphere Application Server. However, unlike application associated shared libraries, Isolated Shared Libraries DO NOT have visibility to application classes loaded by the application class loader.

Types of shared libraries:

Application and Web module associated shared libraries do not default to be Isolated Shared Libraries. Specifying a server associated shared library as an Isolated Shared Library has no effect.

WebSphere Application Server version 7.0 includes a new feature, Isolated Shared Libraries, to provide a way to share a common set of classes across a subset of the applications within the WebSphere Application Server. The major benefit to Isolated Shared Libraries is the ability to reduce the number of class instances that are loaded in a JVM reducing the JVM's memory footprint. To better understand the benefit of Isolated Shared Libraries, look at how a solution deployer can decide to share an application associated shared library across multiple applications. The solution deployer has several possibilities:

Using an Isolated Shared Library, the solution deployer can combine pieces of the prior two solutions. Isolated Shared Libraries each have their own class loader allowing a single instance of the classes to be shared across the applications. Each application can specify which Isolated Shared Libraries it wants to reference and different applications can reference different versions of the Isolated Shared Library resulting in a set of applications sharing an Isolated Shared Library. The advantage here is seen in comparison to the previous example: with Isolated Shared Libraries, you are now sharing a single copy of version XXX and a single copy of version YYY for a total of two instances in memory.

Isolated Shared Libraries do not have visibility to application classes loaded by the application class loader.

The JDK defines the class loader delegation model, which provides a way to establish parent-child relationships between two class loaders. This is necessary for creating multiple class loaders in an hierarchal environment as it defines the algorithm that standardizes loading behavior. Under the delegation model every class loader has an associated parent class loader (except for the JVM's Bootstrap class loader).

The order of searching libraries changes when Isolated Shared Libraries are used. The hierarchy or order of search without the new Isolated Shared Libraries present follows the delegation path from bottom to top. The root is always the JDK bootstrap loader. The only variation is to select either parent first or parent last. In both cases, the child looks to see if it has already loaded the class and uses that instance if found and delegates otherwise. In parent first mode, the child delegates to the parent and then tries to load the class if the parent can not load it. In parent last mode, the child tries to load the class then delegates to the parent if it can't load the class. In all cases, a child will delegate to all Isolated Shared Libraries present before delegating to a parent.

Figure 3.18. Use and behavior of Isolated Shared Libraries

In this picture an Isolated Shared Library is shared between two application servers. When an artifact needs to be loaded for a Web module with parent first delegation, the search order is 1 (Isolated Shared Library), 2 (server class loader), 3 (application class loader) and finally 4 (Web module class loader). If parent last delegation is used on the Web module and application class loaders, the order is 4, 3, 1 and then 2.

Not shown on this figure are several WebSphere loaders and the JDK bootstrap loader. They are all higher in the hierarchy tree. Also note that the server, application, library, and Web module shared loaders are optional and might not be present. Here is a library, server, and application shared loaders, but not a WebSphere Application Server shared loader.

To interactively control Isolated Shared Libraries, the Integrated Solution Console system application provides a new check box. The check box specifies whether this shared library will have a single instance when it is associated with an application or Web module.

Figure 3.19. Isolated Shared Libraries

The default value for this attribute is false (unchecked). If an Isolated Shared Library is used for a shared library associated with an application or Web module class loader, the shared library will have its own class loader. Specifying a server associated shared library as isolated will have no effect.