InfoCenter Home >
6: Administer applications >
6.4: Installing applications and setting classpaths >
6.4.1: Setting classpaths
6.4.1: Setting classpaths
The relationship among the classloaders represents the
fact that classes loaded by a particular classloader can
reference other classes as long as these other classes can
be loaded by the same classloader or any of its ancestors (but not
its children).

Runtime classpath patches (RCP)
- Description: Classes and JAR files in the product_installation_root/classes directory
- How to set and view contents: The location is fixed by the System property ws.ext.dirs. You can
view the directory contents to see the contents of this classpath.
- Search order: RCP -> RP -> RE. The runtime classpath patches override any copies
of the same files lower in the classpath tree
- Typical contents: e-Fixes and other APARs to be applied to the application server runtime
Runtime classpath (RP)
- Description: Classes and JAR files in the product_installation_root/lib directory
- How to set and view contents: The location is fixed by the System property ws.ext.dirs. You can
view the directory contents to see the contents of this classpath
- Search order: RCP -> RP -> RE. The runtime classloader checks the RCP, and then the RP
- Typical contents: The core WebSphere Application Server runtime
Runtime extensions (RE)
- Description: Classes and JAR files in the product_installation_root/lib/ext directory
- How to set and view contents: The location is fixed by the System property ws.ext.dirs. You can
view the directory contents to see the contents of this classpath
- Search order: RCP -> RP -> RE. The runtime classloader checks the RCP, then the RP,
then the RE
- Typical contents: Extensions to the core WebSphere Application Server runtime
Application extensions (AEX)
Application classloaders (AC)
If you use the classpath setting in the administrative console
to specify additional entries to be added to the classpath, these entries will be appended
to the classpath. If you specify a System property, ws.ext.dirs, these entries will be
appended to the ws.ext.dirs.
The WebSphere Application Server runtime is loaded by a bootstrap classloader that loads classes
from the directories, JAR files in specified directories, and JAR files specified by the system
property ws.ext.dirs. Because the system classloader is the parent of the WebSphere bootstrap
classloader, it is important to note that the classes put in the system classpath will not
be able to load classes in the WebSphere runtime (including J2EE APIs).
The relationship among the classloaders implies that it is not
usually possible to access the classes of one Web application from another Web
application.
The application server settings include a property
for specifying the module visibility, which determines the level of isolation
among the classpaths for various application components.
Note that the default value of
the module visibility setting impacts whether you can port applications from previous
WebSphere Application Server versions or other editions (from Advanced Single
Server Edition Version 4.0 to Advanced Edition Version 4.0, for example)
without reassembling the applications or resetting the field value.
See the module visibility
field description in the application server property reference for more information.
To update (reload) the classes being used by an application, it is best
to stop that J2EE application and start it again. This ensures that dependent
classes between cooperating modules will be reloaded in unison, eliminating
potential ClassCastExceptions that occur when mismatched versions of classes
are being used.
However:
- EJB JAR files can be reloaded by stopping just the EJB module and starting
it again. Any dependent EJB or WAR modules will need to be restarted as well.
- You can also reload EJB modules by specifying a reload interval in the EAR extension of the EAR file. If
the EJB classes change, then the entire J2EE application (EAR) is restarted, not just
the EJB module.
- WAR modules can be configured to reload automatically when their contents change. This
is accomplished by setting an Web module assembly property
using the Application Assembly Tool.
- The EJB JAR modules and WAR modules comprising an application should be packaged together
in the same EAR module
- When a Web module (WAR) accesses an EJB module, it should not package the
EJB interfaces and stubs in the WAR. Rather, it should express the dependency on
the EJB JAR using a MANIFEST Class-Path entry. When using the Application
Assembly Tool, set the classpath property of the Web module.
- Common classes that need to be shared among Web modules and EJB JAR modules should
be packaged into a separate JAR file. Add the JAR file to the EAR file. Reference the JAR
file in the MANIFEST Class-Paths of both the EJB JAR and Web module (WAR) files.
- Class library JAR files to be used only by WAR modules should be added to the WEB-INF/lib
directory of the Web module
|
Related topics |
|
| Home (Getting started page) |
|
InfoCenter |
|
To launch the full documentation set in a separate browser window, click: |
| Display InfoCenter |
| |
PDF library |
|
To browse the PDF library for this product, containing this article and others, click: |
| PDF versions |
| |
Using this documentation |
|
Become an InfoCenter super user! To find out more about navigation, numbering, search, downloads, and more, click: |
| Using this documentation |
| |
|