InfoCenter Home >
6: Administer applications >
6.4: Installing applications and setting classpaths >
6.4.1: Setting classpaths

6.4.1: Setting classpaths

The classpaths and their search orders

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).

Classpath behavior in Version 4.0.x

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)

  • Description: Classes and JAR files in the product_installation_root/lib/app
  • How to set and view contents: The location is fixed by the WebSphere Application Server runtime and cannot be configured. You can view the directory contents to see the contents of this classpath
  • Search order: The runtime classloader checks the AEX, then RCP -> RP -> RE.
  • Typical contents: Class libraries that need to be shared among all J2EE applications installed on the server. Because these classes are not visible to the WebSphere Application Server runtime classloaders (RPC, RP, and RE), this classpath can contain updated versions of common libraries (such as JAXP) that are present in the runtime.

    Place dependent JAR files in this directory, too.

Application classloaders (AC)

  • Description: Classpaths as specified for WAR and JAR modules
  • How to set and view contents: The classpath for WAR and EJB JAR files are set using MANIFEST Class-Path entries. You can modify these settings using the Application Assembly Tool.
  • Search order: Depends on the module type.

    • WAR modules follow the search order: module classloader -> AEX -> RCP -> RP -> RE

      Within the module classloader for the WAR file, the search order is:

      1. Root of the WAR file
      2. WEB-INF/classes directory contents
      3. JAR files in the WEB-INF/lib directory

      The module classloader includes the JAR or WAR and its pieces, WEB-INF/classes and WEB-INF/lib, and all of the entries specified by the Modules' class-path entry.

    • EJB JAR modules follow the search order: AE -> RCP -> RP -> RE -> module classloader

    The delegation mode of WAR and EJB JAR files can be changed by defining the following system properties:

    • com.ibm.ws.classloader.warDelegationMode (false by default)
    • com.ibm.ws.classloader.ejbDelegationMode (true by default)

    Set the value of each property to true or false:

    • true: AE -> RCP -> RP -> RE -> module classloader
    • false: module classloader -> AE -> RCP -> RP -> RE
  • Typical contents: Application code, including servlets, enterprise beans, JavaServer Pages (JSP) files, JavaBeans, and supporting class libraries

The system classpath

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).

Module visibility for setting isolation levels

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.

Guidelines for reloading classes

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.

Guidelines for packaging classes

  • 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
Go to previous article: Installing applications and setting classpaths Go to next article: Maintaining and updating applications

 

 
Go to previous article: Installing applications and setting classpaths Go to next article: Maintaining and updating applications