Class loaders find and load class files. For a deployed application
to run properly, the class loaders that affect the application and its modules
must be configured so that the application can find the files and resources
that it needs. Diagnosing problems with class loaders can be complicated and
time-consuming. To diagnose and fix the problems more quickly, use the administrative
console Class Loader Viewer to examine class loaders and the classes loaded
by each class loader.
Before you begin
This topic assumes that you have installed an application on a server
supported by WebSphere® Application Server and you
want to examine class loaders used by the application or its modules. The
modules can be Web modules (.war files) or enterprise
bean (EJB) modules (.jar files). The Class Loader Viewer
enables you to examine class loaders in a runtime environment.
About this task
The runtime 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, extensions, and CLASSPATH class loaders created by the
Java virtual machine
- A WebSphere extensions class loader
- One or more application module class loaders that load elements of enterprise
applications running in the server
- Zero or more Web module class loaders

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.
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.
If the class loaders that load the artifacts of an application
are not configured properly, the JVM might throw a class loading exception
when starting or running that application. Class loading exceptions describes the types
of exceptions caused by improperly configured class loaders and suggests ways
to use the Class Loader Viewer to correct configurations of class loaders.
The types of exceptions include:
The steps that follow describe generally how to use the Class Loader
Viewer to examine class loaders and correct problems with application or class
loader configurations.
Restriction: The
Class Loader Viewer is not available on the J9 Java virtual machine, which
includes the AMD 64-bit platforms.
Procedure
- Examine a tree view that lists all installed applications and their
modules. The modules can be Web modules (.war files)
or EJB modules (.jar files).
Click to access the Enterprise
Applications Topology page.
- Examine the class loader delegation hierarchy.
On
the Enterprise Applications Topology page, select a module to access the Class Loader Viewer page.
The page lists the class loaders visible to Web and EJB modules in an installed
enterprise application. This page helps you to determine which class loaders
loaded files of a module and to diagnose problems with class loaders.
The
delegation hierarchy is determined by the class loader mode specified for
an application or Web module. The mode value can be either Parent
First or Parent Last. Refer to the Configure class loaders step
for more information.
- Export information on class loaders.
- On the Class
Loader Viewer page, click Export.
- Select to open a browser or editor on the class loader information
or to save the information to disk in XML format.
- Click OK, and specify any additional
information requested by the system.
- Display information about class loaders visible to the module in
an HTML table format.
On the Class Loader Viewer page, click View.
The View page displays
the following information:
Class loader attribute |
Description |
Delegation |
Indicates whether the class loader delegates the loading
of the module to its parent class loader. A value of true implies
that the class loader of the parent application is being used (Parent
first). A value of false implies that the
module class loader is being used (Parent last). Refer
to the Configure class loaders step
for more information. |
Classpath |
Lists the paths over which the class loader searches
for classes and resources. |
Classes |
Lists the names of classes loaded in the JVM by this
class loader. |
The View option
does not return a value when out-of-memory errors are generated. The out-of-memory
errors might be related to a memory leak. To examine information about class
loaders in a table, resolve the out-of-memory problem, and then click View again.
- Search class loaders.
On the Class Loader Viewer
page, click
Search to access the
Search
page, on which you can search class loaders for the following:
- Specific strings
- Specific .jar files
- The names of files in a specific directory
- The names of files loaded by a specific class loader
The search is case-sensitive.
Class loading exceptions describes several
uses of the Search page.
- Configure class loaders. You can
configure class loaders for the following:
Class loader configuration determines which class loader loads the
classes and resource files for an application or Web module. Application and
WAR module class loader configuration settings include Class loader mode and WAR
class loader policy.
A Class loader mode value
can be either Parent first or Parent last. The default is Parent first. A class loader
with the Parent first mode
delegates loading a class or resource to its immediate parent class loader
before searching its classpath.
When troubleshooting class loading problems,
you might need to override classes visible to a parent class loader. To override
such classes with those specific to an application, set the Class loader mode to Parent last on the class loader
that contains the application classes on its classpath. An application can
override classes visible to a parent class loader, but doing so can result
in a ClassCastException or UnsatisfiedLinkError if there is a mixed use of
overridden classes and non-overridden classes.
For example, under default
class loader policies, a Web module has its own Web module (WAR) class loader
to load its artifacts, which are typically in the WEB-INF/classes and WEB-INF/lib directories.
An application module class loader is the immediate parent of this WAR class
loader. To ensure that the Web module class loader searches these paths for
a particular class or resource first, before delegating the load operation
to the application module class loader, set the Class loader mode of
the Web module to Parent last.
Class
loader policies determine the structure of the application and WAR module
class loaders. Under the default policies, every running application EAR has
its own application module class loader, and every Web module has its own
WAR module class loader. The default policies ensure J2EE compliance regarding
visibility and isolation among application artifacts. Changing the default
policies is not suggested when troubleshooting class loading problems.