27 Packaging an EJB Application

This section describes:

• Sharing Classes Between EJB Applications

For more information, see:

• Oracle Application Server Enterprise Deployment Guide

• "Understanding Packaging"

Packaging an Application with Both EJB 3.0 and EJB 2.1 EJBs

You can combine both EJB 3.0 and EJB 2.1 beans in your application. For example, you could have an application that contains three annotated EJB 3.0 entities without ejb-jar.xml, two EJB 2.1 entity beans with ejb-jar.xml, and three EJB 3.0 session beans with ebj-jar.xml, annotations, or both (in which case, the ejb-jar.xml overrides the annotations).

Sharing Classes Between EJB Applications

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

• If two EJBs use the same classes, include all classes and the EJBs in the same JAR file. After deployment, both EJBs 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 EJBs 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.

If you receive a ClassCastException, 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.

Handling Out of Memory Exceptions at Runtime

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 Runtime

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.