Sharing Classes Between EJB Applications

If you want to share classes between enterprise beans, you can do one of the following:

If two enterprise beans use the same classes, include all classes and the enterprise beans in the same JAR file. After deployment, both enterprise beans can use the common classes.
Place the shared classes in its own JAR file in the application. Reference the shared JAR file in the class-path of the EJB JAR manifest.mf file, as follows:
```
Class-Path:shared_classes.jar
```
The location of the shared_classes.jar is relative to where the JAR that references is located in the EAR file. In this example, the shared_classes.jar file is at the same level as the EJB JAR.
If all applications reference these classes, archive the shared classes in a JAR file and place this JAR file in the shared library directory of the default application. The home/lib is a default shared library. However, you can set shared library directories using Enterprise Manager in the General Properties page of the "default" application.
If you want only certain applications to reference these classes, archive the shared classes in its own application, deploy the EAR for the application, and have the applications that reference the shared classes declare the shared classes application as its parent. The default parent in OracleAS is the "default" application.

The children see the namespace of its parent application. This is used in order to share services such as enterprise beans among multiple applications. See the Oracle Containers for J2EE Developer's Guide for directions on how to specify a parent application.

If you want to share classes between EJB and Web applications, you should place the referenced classes in a shared JAR.

When sharing classes between EJB applications, be aware of the following issues:

Handling Out of Memory Exceptions at Run Time
Handling Class Cast Exceptions at Run Time

Handling Out of Memory Exceptions at Run Time

If you see that the OC4J memory is growing consistently while executing, then you may have invalid symbolic links in your application.xml file. OC4J loads all resources using the links in the application.xml file. If these links are invalid, then the C heap continues to grow causing OC4J to run out of memory. Ensure that all symbolic links are valid and restart OC4J.

In addition, keep the number of JAR files to a minimum in the directories where the symbolic links point. Eliminate all unused JARs from these directories. OC4J searches all JARs for classes and resources; thus, taking time and memory consumption by the file cache, as well as being mapped into the address space.

Handling Class Cast Exceptions at Run Time

If you receive a ClassCastException at run time, then you probably have the following situation:

You copied EJB interfaces into the WAR where the servlet resides for ease in development and forgot to delete them before creating the WAR file AND
You turned on the search_local_classes_first attribute of the <web-app-class-loader> element in the orion-web.xml file.

To solve this problem, either eliminate the copied classes out of the WAR file, or turn off the search_local_classes_first attribute. This attribute tells the class loader to load in the classes in the WAR file before loading in any other classes, including the classes within the EJB JAR file. For more information on this attribute, see the "Loading WAR File Classes Before System Classes in OC4J" section in the "Servlet Development" chapter of the Oracle Containers for J2EE Servlet Developer's Guide.

When you have an EJB or Web application that references other shared EJB classes, you should place the referenced classes in a shared JAR. In certain situations, if you copy the shared EJB classes into WAR file or another application that references them, you may receive a ClassCastException because of a class loader issue. To be completely safe, never copy referenced EJB classes into the WAR file of its application or into another application.