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 the product 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.
This topic also assumes that you have enabled the class loader
viewer service. Click ,
enable the service and restart the server.
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 Java
virtual machine (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:
Use the class loader viewer to examine class loaders and correct
problems with application or class loader configurations.
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 delegation
mode, or class loader order, specified for an application or
Web module. The value can be either Classes loaded with
parent class loader first or Classes loaded
with local class loader first (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 Table View. The Table View
page displays the following information:
Table 1. Table View page. Information available on class
loader attributes.
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 (Classes loaded with parent class loader
first). A value of false implies
that the module class loader is being used (Classes loaded
with local class loader first (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 Table 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 Table 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 order and WAR class loader policy.
A Class loader order value can be
either Classes loaded with parent class loader first or Classes loaded with local class loader first (parent
last). The default is Classes loaded with parent
class loader first. A class loader with the Classes loaded with parent class loader 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 order to Classes
loaded with local class loader first (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 order of the Web
module to Classes loaded with local class loader first
(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 Java EE compliance regarding visibility
and isolation among application artifacts. Changing the default policies
is not suggested when troubleshooting class loading problems.
What to do next
If you continue to have class loader problems, you might
want to run the osgiCfgInit script to clear and recreate the OSGi
cache. The Equinox OSGi framework, which is used to manage class
loading and relationships between server component bundles, maintains
this cache. However, in some cases, the cached bundle data, that
is maintained on a per-profile basis, with a separate cache at the
WAS_HOME level for installation-wide processes, becomes out of sync
with the actual binaries on the server. refer to Class loading exceptions
and to Class loading.
You can also refer to the topic Class loading exceptions for other possible solutions.