Introduction

The WebSphere® Application Server static system classpath structure is designed for stable packages that the application server uses frequently. The static system classpaths are searched first, followed by the dynamic classpaths. There are two different types of dynamic classpaths: Web Application classpath and Node Dependent classpath. The dynamic classpaths are structured to reflect packages that are subject to change. Classes that are stable and do not frequently change should be placed in the static classpath, whereas classes that are frequently changed should be placed in the dynamic classpath.

This best practice applies to the following product, version, and platform:

• WebSphere Application Server Base, all platforms, V3.5

Back to top

Recommendation

There is one application server (static) classpath for each application server in the IBM WebSphere Application Server environment. This classpath is visible to all enterprise beans, servlets, and JSP files contained by an application server. After the application server has started, any changes to this classpath will not take effect until the application server is restarted. Therefore, you should place the following types of classes in the application classpath: classes referenced from servlets whose objects are added to sessions; common classes; classes that call Java Native Interface (JNI) methods; and EJB client JAR files. All of the class types noted have the common characteristic of changing infrequently. If a change is made to any of these classes, the application server has to be stopped and restarted to reflect those changes.

Dynamic classpaths are made up of the Node Dependent and Web Application classpaths. The Node Dependent classpath is visible to all enterprise beans, servlets, and JSP files contained by an application server. The Node Dependent classpath is used to locate EJB JAR classes and their dependent classes while the application server is running. It is checked during run time to locate any helper classes for an enterprise bean that are not contained in the EJB JAR file of the enterprise bean. The Node Dependent classpath is also used during the EJB JAR deployment process for the same purpose.

Additionally, it is important to note that the dependent classpath is used by all application servers in a node. Therefore, it should not contain any common classes requiring different implementations for each application server on the same node. These common classes should be placed in the application server (static) classpath. Classes are not reloaded if they are changed while the application server is running. However, new JAR files or directories can be added to this classpath by using the EJB JAR deployment process even while the application server is running. EJB dependent classes, or classes that are referenced by EJBs in their interfaces, are really the only classes that should be placed on the node dependent classpath.

The second component to the dynamic classpaths are the Web Application classpaths. This classpath is visible to all servlets and JSP files in the Web application. The classpath is monitored and all components (classes or JAR files) are reloaded whenever an update has been automatically detected. All application components must be on the machine containing the application server hosting the application. The Web Application classpath has the following contents: directories or JAR files with servlet classes; directories of JAR files with helper classes that are not included in the servlet JAR file that are expected to be reloadable; and directories or JAR files with Access Bean classes that are referenced from servlet classes and that refer to enterprise beans. A new JAR file is automatically loaded upon detection in any directory already contained in this classpath.

System Classpath additional information

The static classpath is made up of three elements:

• System (Application) classpath.
• List of JDBC drivers installed on the node.
• Classpath, which is formed by the administrative server process.

To set the system classpath for an application server:

1. In the administrative client, select the Topology View and click the application server name.
2. Select the General tab, select command line arguments, and enter the classpath identifier, -classpath, followed by the classpath entries.
3. Click the Apply button to save the classpath.

Dynamic classpath additional information

The node classpath applies to all application servers on the same node. This classpath is useful when you want the same packages,for example a third-party application, to be available on any server on the node.

1. In the administrative client, go to the Topology View and select the node name.
2. In the General tab, enter the classpath information in the Dependent classpath: field.

The Web Application classpath is limited in scope to the servlets and JSPs within a single Web application. This isolates the individual Web application so that changes impact it alone.

To set the Web application classpath:

1. In the administrative client, go to the Topology View and select the application server name.
2. Expand the server.
3. Expand the Servlet Engine.
4. Select the Web application by name and verify on the General tab that you are working with the correct Web application.
5. Select the Advanced tab and examine the Document Root field. It should contain the path to the HTML and JSPs for this Web application. The classpath field should contain the directory to where the Servlets and Class/Jar files are located.

After changes are made, click Apply to save them.

Back to top

Alternative

You could place all of your classes or JAR files in the static application classpath and experience no class reloading when a class is updated. Likewise, you could place all of your classes in one of the dynamic classpaths and incur the overhead of monitoring for updates to the static classes.

Resources

• Chapter 14 Application Deployment of the WebSphere Version 3.5 Handbook
  
  
• System Administrator InfoCenter - see Setting Classpaths Chapter
  
  
• Understanding WebSphere ClassLoaders Whitepaper
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Recommendation
• Alternative
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers