InfoCenter Home >
6: Administer applications >
6.4: Installing applications and setting classpaths >
6.4.1: Setting classpaths
6.4.1: Setting classpaths
The IBM WebSphere Application Server environment has these classpath components:
-
The Application
Server (JVM) Classpath
-
The EJB JAR Classpath
-
The Web Application Classpath
You can also learn about the:
Application server (JVM)
classpath
Where to set |
There is one application server classpath for each application
server in the IBM WebSphere Application Server environment. Each application
server corresponds to a JVM.
Set the classpath in one of two ways:
-
Use an administrative client to set the Command Line Arguments field of
the application server. Specify the classpath with the flag -classpath.
-
Use an administrative client to set the application server Environment property
to include a CLASSPATH variable and value.
|
Scope |
This classpath is visible to all enterprise beans, servlets,
and JSP files contained by an application server.
|
Behavior |
The classes in this classpath are loaded by the JVM primordial
ClassLoader. Hence, after the application server is started,
any changes to this classpath will not take effect until the application
server is stopped and started again. |
Reloadable? |
Classes loaded from this classpath will not be reloaded if they
are changed while the application server is running. |
Typical contents |
-
Classes referenced from servlets whose objects are added to sessions, such
objects that are serialized and whose classes must not be reloaded.
-
Classes that call Java Native Interface (JNI) methods. Those classes and
any imported classes must be placed in the application server classpath
to prevent loading errors
-
For AS/400, any servlet classes and helper classes on which you are going
to run the AS/400 system debugger or IBM Distributed Debugger.
Note that classes which are put in this classpath should not reference
other classes that cannot be found in this classpath. |
ClassLoader |
JVM primordial ClassLoader |
Trace component |
To see the contents of this classpath, enable the trace component:
com.ibm.ejs.sm.active.ActiveEJBServerProcess=all=enabled
for the WebSphere administrative server.
Note that this trace component
should be enabled for the administrative server because that server
is responsible for constructing the application server command line
before starting the application server process.
Enable the trace before starting the application server. |
EJB JAR classpath
Where to set |
This classpath is automatically constructed by each application server.
The administrator can add EJB JAR files to this classpath by deploying new
EJB JAR files and starting the enterprise beans while the application server
is either running or stopped. EJB JAR files are put in the classpath in
the order in which they are deployed.
The Dependent Classpath for the administration server node is prepended
before each EJB JAR file in this classpath, to provide means of modifying
this classpath's behavior.
To set the node Dependent Classpath, use an administrative client to
access node properties.
|
Scope |
This classpath is visible to all enterprise beans, servlets,
and JSP files contained by an application server. |
Behavior |
This classpath is used to locate EJB JAR classes and their dependent
classes while the application server is running.
The Dependent Classpath of the node contains the dependent classes
and precedes all JAR file in this classpath. It is checked during runtime
to locate any helper classes for a enterprise bean that are not
contained in the EJB JAR file of the enterprise bean.
The Dependent Classpath is also used
during the EJB JAR deployment process for the same purpose. However, it
is important to note that the Dependent Classpath is used by all application
servers in a node, when the application servers are running. Hence, it
should not contain any common classes requiring different implementations
for each application server on the same node. Instead, place these common
classes in the application server (JVM) classpaths. |
Reloadable? |
Classes loaded from this classpath will not be 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. |
Typical contents |
-
EJB JAR files containing EJB classes are automatically put in this classpath.
The node Dependent Classpath is prepended to each EJB JAR file in this
classpath.
-
The Node Dependent classpath should contain JAR files or directories containing
helper classes referenced from EJB classes that are not present in the
EJB JAR files.
Note, if these helper classes need to
have different implementations for each application server on the same
node, then these classes should be kept in the Dependent Classpath only
during the EJB JAR deployment process, and application servers should
be kept stopped.
After deployment of the EJB JAR file, their containing JAR files
or directories (containing the helper classes) should be moved from
the Dependent Classpath to the respective application server
JVM classpath before starting the application servers.
|
ClassLoader |
JARClassLoader. There is one instance of it for each
application server accessible through the EJBJARManager. |
Trace component |
Debug the JARClassLoader by enabling trace for the component:
com.ibm.ejs.util.JAR.*=all=enabled
for the application server.
Enable the trace while the application server
is running, before accessing the EJB class.
|
Keep in mind that the Dependent Classpath
is referenced by all application servers running on the same administrative
server node.
Web application classpath
Where to set |
Use an administrative client
to specify the Classpath setting of a Web application. |
Scope |
The classpath is visible to all servlets and JSP files in the corresponding
Web application. |
Behavior |
This classpath is monitored and all components (JAR or class files)
are reloaded whenever it is automatically detected that a component
has been updated.
A new JAR file is automatically loaded upon detection
in any directory already contained in this classpath. This means that it
is not necessary to explicitly specify a new JAR file in this classpath.
Rather, it suffices to just put the JAR file in a directory that
is already present in the classpath.
Automatic reloading at the Web application level keeps all of the application
components synchronized and conserves system resources compared to the
Version 2.0x reloading scheme.
Version 3.5 does not support remote servlet loading (that is, loading
servlets across a network). All application components must be on the machine
containing the application server hosting the application.
|
Reloadable? |
Yes
|
Typical contents |
-
Directories or JAR files with Servlet classes.
-
Directories or JAR files with helper classes that are not
included in the servlet JAR file and that are expected to be reloadable.
-
Directories or JAR files with Access Bean classes that are referenced
from servlet classes and that refer to enterprise beans.
|
ClassLoader |
PowerClassLoader. There is one for each Web application. |
Trace component |
Trace the Web application classpath by tracing the component
com.ibm.servlet.classloader.*=all=enabled
on a running application server.
Enable the trace before invoking
a servlet or JSP file in the Web application from a Web browser. |
For improved performance, set
the automatic reloading property to false in the properties of
Web applications contained by production application servers.
One last classpath you should be aware of is the WebSphere
administrative server classpath, though it is recommended that
you do not modify the classpath for the use of particular
applications.
The administrative server classpath is set automatically
when you install the product. The default classpath setting
contains all of the IBM WebSphere Application Server APIs.
The administrative server classpath value depends on how you
start the administrative server.
If you use one of these methods to start the administrative server:
- The startupServer.sh script on UNIX platforms
- The Windows NT Services panel
then the administrative classpath is set based on the value of the
property:
com.ibm.ejs.sm.adminserver.classpath
in the file:
product_installation_root/bin/admin.config
If you use the adminserver.[bat|sh] script to start
the administrative server, the classpath is set based on its value
as specified by the adminserver.[bat|sh] script.
By default, the administrative server classpath is appended to each
application server JVM classpath. If you would like to append
a different classpath to each application server JVM classpath,
define the different classpath in the property:
com.ibm.ejs.sm.adminServer.managedServerClassPath
in the file:
product_installation_root/bin/admin.config
The managedServerClassPath will be appended instead of the administrative
server classpath.
|
|