Understand classpath and module dependencies

Specifying dependent JAR files or modules

Use the JAR Dependencies editor to specify JAR files or modules that are required by a module.

In order to select required JAR files or modules, you must specify the enterprise application to which your project is scoped. Usually, the project will be referenced by one EAR project in the workspace. However, it is possible that you will have multiple applications that contain a reference to the same module or utility JAR project. If this is the case, then you should ensure that you give the JAR or module the same URI in each application, so that the classpath will be valid for all applications.

To select JAR files or modules that are required by a module:

  1. Switch to the J2EE perspective.

  2. In the J2EE Hierarchy view, right-click the desired module, and click Open With > JAR Dependency Editor from the context menu.

    JAR Dependency Editor

  3. In the Classpath Scope section on the Dependencies page of the editor, select the enterprise application to use for classpath editing. The JAR dependency editor is designed for classpath editing. Therefore, not all of the attributes or information contained in the manifest file (MANIFEST.MF) will be represented on the this page. The Classpath Scope section lists all enterprise applications that contain a reference to the selected project as a module or utility JAR. Use the Refresh button to update the list if a change is made in a separate editor.

  4. In the Dependencies section, select the JAR files or modules that are required or dependent. You can also move them up and down in the list to specify their order on the MANIFEST class path as well as the Java build path.

    JAR Dependency Editor

  5. Click File > Save to save your changes.

TIP: Referencing run-time JAR files at development time: If you need to compile against JAR files visible to the WebSphere Application Server runtime (for example, rt.jar, xerces.jar, and so on), then as a general rule, you should add those JAR files for the respective runtime installation using the predefined class path variables. For example, you should use the WAS_PLUGINDIR class path variable for the WebSphere Application Server V4.0 server JAR files and the WAS_50_PLUGINDIR class path variable for the WebSphere Application Server V5.0 server JAR files.

Class loaders

Class loaders are part of the Java virtual machine (JVM) code and are responsible for finding and loading class files. Class loaders affect the packaging of applications and the run-time behavior of packaged applications deployed on application servers.

The run-time environment of WebSphere Application Server uses the following class loaders to find and load new classes for an application in the following order:

  1. The bootstrap, extensions, and CLASSPATH class loaders created by the JVM.

    The bootstrap class loader uses the boot classpath (typically classes in jre/lib) to find and load classes. The extensions class loader uses the system property java.ext.dirs (typically jre/lib/ext) to find and load classes. The CLASSPATH class loader uses the CLASSPATH environment variable to find and load classes.

    The CLASSPATH class loader contains the J2EE APIs of the WebSphere Application Server product (inside j2ee.jar). Because the J2EE APIs are in this class loader, you can add libraries that depend on J2EE APIs to the classpath system property to extend a server's classpath. However, a preferred method of extending a server's classpath is to add a shared library.

  2. A WebSphere-specific extensions class loader.

    The WebSphere extensions class loader loads the WebSphere run-time and J2EE classes that are required at run time. The extensions class loader uses a ws.ext.dirs system property to determine the path used to load classes. Each directory in the ws.ext.dirs classpath and every JAR file or ZIP file in these directories is added to the classpath used by this class loader.

    The WebSphere extensions class loader also loads resource provider classes into a server if an application module installed on the server refers to a resource that is associated with the provider and if the provider specifies the directory name of the resource drivers.

  3. One or more application module class loaders that load elements of enterprise applications running in the server.

    The application elements can be Web modules, EJB modules, resource adapters, and dependency JAR files. Application class loaders follow J2EE class-loading rules to load classes and JAR files from an enterprise application. The WebSphere run time enables you to associate a shared library classpath with an application.

Each class loader is a child of the class loader above it. That is, the application module class loaders are children of the WebSphere-specific 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. If the WebSphere class loader is requested to find a class in a J2EE module, it cannot go to the application module class loader to find that class and a ClassNotFoundException occurs. Once 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.

Class-loader isolation policies

The number and function of the application module class loaders depends on the class-loader policies specified in the server configuration. Class loaders provide multiple options for isolating applications and modules to enable different application packaging schemes to run on an application server.

Two class-loader policies control the isolation of applications and modules:

Note: WebSphere server class loaders never load application client modules.

For each application server in the system, you can set the application class-loader policy to SINGLE or MULTIPLE. When the application class-loader policy is set to SINGLE, then a single application class loader loads all EJB modules, dependency JAR files, and shared libraries in the system. When the application class-loader policy is set to MULTIPLE, then each application receives its own class loader used for loading that application's EJB modules, dependency JAR files, and shared libraries.

This application class loader can load each application's Web modules if that WAR module's class-loader policy is also set to APPLICATION. If the WAR module's class-loader policy is set to APPLICATION, then the application's loader loads the WAR module's classes. If the WAR class-loader policy is set to MODULE, then each WAR module receives its own class loader.

The following example shows that when the application class-loader policy is set to SINGLE, a single application class loader loads all EJB modules, dependency JAR files, and shared libraries of all applications on the server. The single application class loader can also load Web modules if an application has its WAR class-loader policy set to APPLICATION. Applications having a WAR class-loader policy set to MODULE use a separate class loader for Web modules.

Application class-loader policy: SINGLE

Application 1
	Module:	EJB1.jar
	Module:	WAR1.war
		MANIFEST Class-Path:	Dependency1.jar
		WAR Classloader Policy = MODULE
		
Application 2  
	Module:	EJB2.jar
		MANIFEST Class-Path:	Dependency2.jar
	Module:	WAR2.war
		WAR Classloader Policy = APPLICATION
					

SINGLE

The following example shows that when the application class-loader policy of an application server is set to MULTIPLE, each application on the server has its own class loader. An application class loader also loads its Web modules if the application's WAR class-loader policy is set to APPLICATION. If the policy is set to MODULE, then a Web module uses its own class loader.

Application class-loader policy: MULTIPLE

Application 1
	Module:	EJB1.jar
	Module:	WAR1.war   
		MANIFEST Class-Path:	Dependency1.jar
		WAR Classloader Policy = MODULE
		
Application 2  
	Module:	EJB2.jar
		MANIFEST Class-Path:	Dependency2.jar
	Module:	WAR2.war
		WAR Classloader Policy = APPLICATION
					

MULTIPLE

Class-loader modes

There are two possible values for a class-loader mode:

The following settings determine a class loader's mode:

Editing a server configuration

WebSphere Studio provides you with editors so that you may change your server configurations. To edit a server configuration, you can do one of the following:

Depending on what run-time environment the server configuration is defined to use, or whether it is defined as a local or remote configuration, the fields that you can change may be different.

If you want to run several WebSphere application servers at the same time, you need to change the port settings by selecting the Ports tab located at the bottom of the WebSphere Configuration Editor. For more information about the various port settings, refer to the WebSphere Application Server documentation.

Setting class loader policy for a server

When editing a WebSphere server, you can specify the class loader isolation mode that you want to use for the application server.

  1. Double-click on the server in the Server Configuration view. The server editor opens.

  2. Click the Configuration tab.

  3. You can specify one of the following in the Application class loader policy field:

    1. SINGLE for J2EE application mode. Only one Enterprise application class loader for all applications deployed in an application server.

    2. MULTIPLE for Compatibility mode. Each enterprise application gets its own application class loader.

    Application class loader policy

  4. Save and close the editor.

Setting class loader policy for an application on a server

You can define class loader policy for a specific application for a WebSphere test environment or server.

  1. In the Server Configuration view or Servers view, double-click the server to open it. The server editor opens.

  2. Click the Applications tab at the bottom of the editor.

  3. In the Applications list box, select the application to modify the class loader settings.

  4. In the Classloader mode field, select the class loading mode for the application:

    • PARENT_FIRST causes the class loader to delegate the loading of classes to its parent class loader before attempting to load the class from its local class path.

    • PARENT_LAST causes the class loader to attempt to load classes from its local class path before delegating the class loading to its parent.

  5. In the WAR classloader policy field, select the isolation level of Web modules.

    • If this policy is set to APPLICATION, then the Web project contents also are loaded by the application class loader (in addition to the EJB files, RAR files, dependency JAR files, and shared libraries).

    • If the policy is set to MODULE, then each Web project receives its own class loader whose parent is the application class loader.

    WAR class loader policy

  6. In the Start weight field, specify the order in which projects in an J2EE application are started. Lower weighted projects are started before higher weighted projects.

  7. Save and close the editor.

Professional hosting     Belorussian informational portal         Free SCWCD 1.4 Study Guide     Free SCBCD 1.3 Study Guide     Free SCDJWS 1.4 Study Guide     SCDJWS 1.4 Quiz     IBM Test 000-287. Enterprise Application Development with IBM WebSphere Studio, V5.0 Study Guide     Free Mock Exam Engine