![]() | |
|
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.
When the application server class loader policy is set to Single, a single application class loader is used to load all EJBs, utility JARs, and shared libraries within the application server (JVM). If the WAR class loader policy then has been set to Single class loader for application, 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, the default, each application will receive its own class loader for loading EJBs, utility JARs, and shared libraries. Depending on whether the WAR class loader policy is set to Class loader for each WAR file in application or Single class loader for application, 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, 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:
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:
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:
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.
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:
Classes loaded with parent class loader first
Classes loaded with local class loader first (parent last)
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:
Create a separate file, for example, Resource.jar
, configure it as a utility JAR,
move all log4j.properties
files from the modules into this file, and make their
names unique (like war1-1_log4j.properties
, war1-2_log4j.properties
, and
ejb1_log4j.properties
). When initializing log4j from each module, tell it to load
the proper configuration file for the module instead of the default (log4j.properties
).
Keep the log4j.properties
for the Web modules in their original place
(/WEB-INF/classes
), add log4j.jar
to both Web modules
(/WEB-INF/lib
) and set the class loading mode for the Web modules to
Classes loaded with local class loader first (parent last). When
initializing log4j from a Web module, it loads the log4j.jar
from the module
itself and log4j would find the log4j.properties
on its local classpath, the Web
module itself. When the EJB module initializes log4j, it loads from the application class loader
and it finds the log4j.properties
file on the same class path, the one in the
EJB1.jar
file.
If possible, merge all log4j.properties
files into one and place it on
Application class loader, in a Resource.jar
file, for example).
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:
You can use the administrative console. The library is added using the Shared libraries references link under the References section for the enterprise application.
You can use the manifest file of the application and the shared library. The shared library contains a manifest file that identifies it as an extension. The dependency to the library is declared in the application’s manifest file by listing the library extension name in an extension list.
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 associated shared libraries have their classpath added to the application's class loader classpath. Each application will have its own instances of the shared libraries classes. This allows one application to specify version XXX while another application can specify version YYY. The draw back with using application shared libraries is that every application using the shared library will have their own class instances. For example if you want six applications to have version XXX and two applications to have version YYY, each will have its own set of class objects resulting in eight instances of an object loaded into memory.
Server associated shared libraries have their own class loader in the WebSphere Application Server Class Loaders hierarchy. This allows a single instance of the classes to be shared by all applications. The drawback with using the server associated shared libraries is they are shared across all applications on that server which prevents version handling of classes. If one shared library contained version X and one contained version Y, the version higher (assuming parent-first) in the class loader hierarchy will win.
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.
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.
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.
![]() ![]() ![]() |