Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer's Guide

- Previous: Classloader Universes
- Next: Assembling Modules and Applications

### Circumventing Classloader Isolation

Since each application or individually deployed module class loader universe is isolated, an application or module cannot load classes from another application or module. This prevents two similarly named classes in different applications from interfering with each other.

To circumvent this limitation for libraries, utility classes, or individually deployed modules accessed by more than one application, you can include the relevant path to the required classes in one of these ways:

- Using the System Classloader

- Using the Common Classloader

- Using the Java Optional Package Mechanism

- Packaging the Client JAR for One Application in Another Application

#### Using the System Classloader

To use the System Classloader, do one of the following, then restart the server:

- Use the Administration Console. Select the JVM Settings component under the relevant configuration, select the Path Settings tab, and edit the Classpath Suffix field. For details, see the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Guide.

- Edit the `classpath-suffix` attribute of the `java-config` element in the `domain.xml` file. For details about `domain.xml`, see the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Reference.

Using the System Classloader makes an application or module accessible to any other application or module across the domain.

#### Using the Common Classloader

To use the Common Classloader, copy the JAR and ZIP files into the domain-dir`/lib` directory or copy the `.class` files into the domain-dir`/lib/classes` directory, then restart the server.

Using the Common Classloader makes an application or module accessible to any other application or module across the domain.

#### Using the Java Optional Package Mechanism

To use the Java optional package mechanism, copy the JAR and ZIP files into the domain-dir`/lib/ext` directory, then restart the server.

Using the Java optional package mechanism makes an application or module accessible to any other application or module across the domain.

For example, this is the recommended way of adding JDBC drivers to the Application Server. For a list of the JDBC drivers currently supported by the Application Server, see the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Release Notes. For configurations of supported and other drivers, see Configurations for Specific JDBC Drivers.

#### Packaging the Client JAR for One Application in Another Application

By packaging the client JAR for one application in a second application, you allow an EJB or web component in the second application to call an EJB component in the first (dependent) application, without making either of them accessible to any other application or module.

As an alternative for a production environment, you can have the Common Classloader load client JAR of the dependent application as described in Using the Common Classloader restart the server to make the dependent application accessible, and it is accessible across the domain.

#### To package the client JAR for one application in another application

1. Deploy the dependent application.

2. Add the dependent application’s client JAR file to the calling application.

   - For a calling EJB component, add the client JAR file at the same level as the EJB component. Then add a `Class-Path` entry to the `MANIFEST.MF` file of the calling EJB component. The `Class-Path` entry has this syntax:

         Class-Path: filepath1.jar filepath2.jar ...

     Each filepath is relative to the directory or JAR file containing the `MANIFEST.MF` file. For details, see the J2EE specification, section 8.1.1.2, “Dependencies.”

   - For a calling web component, add the client JAR file under the `WEB-INF/``lib` directory.

3. If you need to package the client JAR with both the EJB and web components, set `delegate="true"` in the `class-loader` element of the `sun-web.xml` file.

   This changes the Web Classloader so it follows the standard class loader delegation model and delegates to its parent before attempting to load a class itself.

   For most applications, packaging the client JAR file with the calling EJB component is sufficient. You do not need to package the client JAR file with both the EJB and web components unless the web component is directly calling the EJB component in the dependent application.

4. Deploy the calling application.

   The calling EJB or web component must specify in its `sun-ejb-jar.xml` or `sun-web.xml` file the JNDI name of the EJB component in the dependent application. Using an `ejb-link` mapping does not work when the EJB component being called resides in another application.

- Previous: Classloader Universes
- Next: Assembling Modules and Applications

- © 2010, Oracle Corporation and/or its affiliates