WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

Chapter 22. Understanding class loaders 795

To solve this problem, you can break out just the few lines of Java code that load the native

code into a class on its own and place this file on WebSphere’s application class loader (in a

utility JAR file). However, if you deploy multiple such applications (EAR files) to the same

application server, you have to place the class file on the WebSphere extensions class loader

instead to ensure that the native code is loaded only once per JVM.

If the native code is placed on a reloadable class loader (such as the application class loader

or the WAR class loader), it is important that the native code can unload itself properly if the

Java code needs to reload. WebSphere has no control over the native code, and if the native

code does not unload and load properly, the application might fail.

If one native library depends on another library, the handling of JNI code can become even

more complicated. For more details and troubleshooting, go to the following website:

http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-ba

se-dist&topic=trun_classload

22.3 Configuring class loaders for Java EE applications

We provided an overview of WebSphere class loaders and how they work together to load

classes. WebSphere Application Server includes settings that allow you to influence the class

loader behavior. We provide information about these options in this section.

22.3.1 Application server class loader policies

For each application server in the system, you can set the class loader policy to either Single

or

Multiple. From the administrative console, click Servers  Server Types  WebSphere

application servers  server_name. Next, on the Configuration tab under the

Server-specific Application Settings section, select the appropriate class loader policy.

When the application server class loader policy is set to Single, a single application class

loader is used to load all EJB, utility JAR files, and shared libraries within the application

server (JVM). If the WAR class loader policy is set to use the Single class loader for

application option, the web module contents for this particular application are also loaded by

this single class loader.

When the application server class loader policy is set to Multiple, which is the default, each

application receives its own class loader for loading EJB, utility JAR files, and shared libraries.

Depending on whether the WAR class loader policy is set to use the Class loader for each

WAR file in application option or the Single class loader for application option, the web

module might or might not receive its own class loader.

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 file, 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 use the Class

loader for each WAR file in application option, the result is as shown in Figure 22-5 on

page 796.

796 WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

Figure 22-5 Class loader policies - Example 1

Each application is completely separated from the other application, and each web module is

completely separated from the other web module in the same application. WebSphere’s

default class loader policies results in total isolation between the applications and the

modules.

Now, if we change the class loader policy for the WAR2-2 module to use the Single class

loader for application option, the result is shown in Figure 22-6.

Figure 22-6 Class loader policies - Example 2

Web module WAR2-2 is loaded by Application2’s class loader and classes, and for example,

classes in the Util2.jar file can 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 use the Single class loader for application

option, the result is as shown in Figure 22-7 on page 797.

WAR1-1

class loader

WAR1-2

class loader

WAR2-1

class loader

WAR2-2

class loader

Application1 class loader

EJB1.jar

Util1.jar

Application2 class loader

EJB2.jar

Util2.jar

WebSphere Extensions class loader

WAR1-1

class loader

WAR1-2

class loader

WAR2-1

class loader

Application1 class loader

EJB1.jar

Util1.jar

Application2 class loader

EJB2.jar

Util2.jar

WAR2-2.war

WebSphere Extensions class loader