Sharing Classes

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 Oracle9iAS 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 Application Server Containers for J2EE User'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 Application Server Containers for J2EE Servlet Developer's Guide.

Out of Memory During Execution

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 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.

ClassCastException

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.

Static Block in an EJB

During EJB deployment in OC4J, you load the bean class to find out its methods so that you can generate EJB wrappers. Because the code in the static block is executed as the class is being loaded, the JNDI environment context is not yet set up. Even during runtime, the bean is in the "does not exist" stage. In this stage of the life cycle, the JNDI environment context is undefined, and the bean provider cannot rely on it to be available. To work around this problem, set up and cache the context during the construction of the bean, in the ejbCreate() method, or in the setSessionContext() method.

OC4J Instances Terminating Due To ping Timeout

Under some conditions, the OPMN process monitoring software in Oracle Application Server may lose contact with an OC4J process. This can occur because of unexpected delays in the hearbeat protocol used by OPMN and OC4J to verify the proper functioning of the OC4J instance.

If this problem occurs sporadically, you can try increasing the ping timeout parameters as described in the following instructions.

However, if this occurs regularly, due to a consistent resource shortage, then you must increase the available hardware resources to solve the problem.

The following conditions can cause this problem:

An overloaded host processor
One or more computation-intensive applications running in the OC4J instance.
Deployment of applications with large numbers (hundreds) of EJBs. Full garbage collections of large heaps can cause the OC4J process to become less responsive during the garbage collection phase. Although this should not occur during normal usage, deployment of large applications with many EJBs in a memory-constrained environment can trigger this behavior.

You can configure the behavior of the "ping protocol" between OPMN and OC4J in the opmn.xml configuration file.

When OC4J exceeds the timeout intervals specified for the ping protocol, the process monitoring software decides that the OC4J process has stopped responding and, therefore, terminates the OC4J process.

If you suspect this behavior in an Oracle Application Server installation, then use the following steps to troubleshoot and work around:

When OC4J instances are "mysteriously" terminating, first increase diagnostic logging to determine if ping failures are triggering the termination:
1. Increase the OPMN logging level to 5 so that you can see the pings.
  
  In the opmn/conf/opmn.xml file, edit the following line:
```
log-file path="$ORACLE_HOME/opmn/logs/ipm.log" level="5" ...
```
2. Reload the daemon.
```
opmn/bin/opmnctl reload
```

Look in opmn/logs/ipm.log for the following line :

Process Ping Failed:  OC4J~<instance name>~default_island~1 (opmnid)

The line above indicates that the memory and CPU resources of the current host are probably not sufficient to perform the operation within the currently specified ping timeout interval (used by OPMN to determine OC4J "responsiveness").

Change the settings as follows:
1. Increase the timeout and interval. For example:
```
<ping timeout="60" interval="60"/>"
<data id="reverseping-failed-ping-limit" value="5" />
```
2. Reload the daemon.
```
opmn/bin/opmnctl reload
```
3. Restart the appropriate OC4J instance.
Repeat the top-level operation that caused the timeout failure.