|
Oracle® Containers for J2EE Deployment Guide
10g Release 3 (10.1.3) Part No. B14431-01 |
|
 Previous |
 Next |
|
Oracle® Containers for J2EE Deployment Guide
10g Release 3 (10.1.3) Part No. B14431-01 |
|
|
Previous |
Next |
The following topics discuss deployment/redeployment of Enterprise JavaBean modules into an application running in an OC4J instance.
The EJB deployment process is highly automated. When an application containing one or more EJB JAR files is deployed, OC4J executes as follows:
OC4J generates a wrapper class for each of the home interfaces (EJBHome and EJBLocalHome implementations) and component interfaces (EJBObject and EJBLocalObject implementations) packaged within each EJB JAR file.
OC4J invokes the Java compiler that it is configured to use to compile the generated EJB wrapper classes. The compiled classes are output to an archive named deployment-cache.jar in a new subdirectory with the same name as the deployed EJB JAR in ORACLE_HOME/j2ee/instance/app_name/application-deployments/.
For example, suppose you deployed mystore.ear, which contains inventory-ejb.jar. The compiled wrapper classes will be generated in ORACLE_HOME/j2ee/instance/mystore/application-deployments/inventory-ejb/deployment-cache.jar.
OC4J optionally generates client-side IIOP stubs for each home and component interface if configured to do so.
See "Example of a Deployed Application Directory Structure" for an example of the directory structure created for an application by OC4J.
Note that because of the amount of processing performed by OC4J and the Java compiler, deploying an EJB JAR file containing a large number (~100) of EJBs may significantly increase the amount of time required to deploy an application. See Chapter 3, "Deploying Large Applications" for guidelines on tuning OC4J and the Java compiler for large application deployment.
OC4J optionally generates client-side IIOP stubs for each home and component interface if configured to do so when deploying with Application Server Control Console, admin_client.jar or the OC4J Ant tasks.
See "Deploying/Redeploying an Application" for instructions on deploying applications with Application Server Control Console.
Before deploying the EJBs, configure OC4J to generate client-side IIOP stubs in Application Server Control Console.
Click the Administration tab.
Check the Generate IIOP Client Stubs when Compiling EJBs box under Compile Time Parameters.
Next, enable stub generation at deployment time:
In the third panel (Deployment Settings) of the deployment wizard, click Edit Deployment Plan.
Set enableIIOP to true.
The application-level stubs generated for all EJB modules are output to an archive named _iiopClient.jar in the ORACLE_HOME/j2ee/home/application-deployments/app_name directory.
In addition, stubs for each individual EJB module are generated in an archive with the same name in the ORACLE_HOME/j2ee/home/application-deployments/app_name/ejbModuleName/ directory.
The -deploy command on admin_client.jar provides two options for generating IIOP stubs: One for generating stubs on the server, the other for generating stubs on the server and copying the new stubs to another location.
Before deploying the EJBs, set the -DGenerateIIOP system property, which configures OC4J to generate client-side IIOP stubs at startup.
In standalone OC4J, specify this system property on the OC4J command line:
java -DGenerateIIOP=true -Dhttp.session.debug=true -jar oc4j.jar
In an OPMN-managed OC4J instance, set the property in opmn.xml:
<ias-component id="OC4J">
<process-type id="home" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="java-options" value="-DGenerateIIOP=true
-Dhttp.session.debug=true"/>
</category>
...
</module-data>
</process-type>
</ias-component>
Next, deploy the application with the admin_client.jar -deploy command. See "Deploying an Archive" for details on using this command.
Include -enableIIOP to generate IIOP client stubs on the OC4J server.
The application-level stubs generated for all EJB modules are output to an archive named _iiopClient.jar in the ORACLE_HOME/j2ee/home/application-deployments/appName directory. In addition, stubs for each individual EJB module are generated in an archive with the same name in the ORACLE_HOME/j2ee/home/application-deployments/appName/ejbModuleName/ directory.
Include -iiopClientJar path to generate stubs in the same locations specified above, as well as to the path specified with the switch.
The deploy Ant task also provides two options for generating IIOP stubs: One for generating stubs on the server, the other for generating stubs on the server and copying the new stubs to another location.
Before deploying the EJBs, set the -DGenerateIIOP system property, which configures OC4J to generate client-side IIOP stubs at startup. See "Generating Stubs with admin_client.jar" above for details.
Next, deploy the application with the deploy task. See "Deploying an EAR File" for details on using this task.
Include enableIIOP to generate IIOP client stubs on the OC4J server.
The application-level stubs generated for all EJB modules are output to an archive named _iiopClient.jar in the ORACLE_HOME/j2ee/home/application-deployments/appName directory. In addition, stubs for each individual EJB module are generated in an archive with the same name in the ORACLE_HOME/j2ee/home/application-deployments/appName/ejbModuleName/ directory.
Include iiopClientJarPath to generate stubs in the same locations specified above, as well as to the path specified with the switch.
OC4J supports incremental or partial redeployment of EJB modules that are part of a deployed application. This feature makes it possible to redeploy only those beans within an EJB JAR that have changed to be deployed, without requiring the entire module to be redeployed. Previously deployed beans that have not been changed will continue to be used.
This functionality represents a significant enhancement over previous releases of OC4J, which treated an EJB module as a single unit, requiring that the module first be undeployed, then redeployed with any updates.
The -updateEBJModule command in both the admin.jar and admin_client.jar utilities can be used to incrementally update a deployed application with one or more EJBs contained within an EJB JAR file.
A restart of OC4J is required only if changes are made to the EJB configuration data during the redeployment process. If no changes are made, a Òhot deploymentÓ can be performed without re-starting OC4J.
The incremental redeployment operation will automatically stop the application containing the EJB(s) to be updated, then automatically restart the application when finished.
|
Note: During redeployment, any client connections to the EJB being updated will be lost. It is strongly recommended that the application be stopped before redeploying the EJB. All existing requests will be allowed to complete, but no new requests will be allowed until the application is restarted. |
This section discusses the impact of EJB redeployment on existing clients, which differs depending on the type of EJBs used in the application. It includes the following topics:
The following describe issues related to redeploying session beans.
For applications that include stateless session EJBs, the redeployment appears seamless to users, with no interruption in service. Existing requests will be served by current bean instances, while new requests will be served with new instances.
For an application or Web service that utilizes active stateful session EJB instances, you must explicitly specify a "persistence directory" where client state data will be persisted through serialization during the undeployment and redeployment processes. If this directory is not specified, all serialized state data will be lost during undeployment.
The persistence directory is defined in the <persistence> element within the orion-application.xml configuration file. This directory can also be set as the value of the persistencePath property through the deployment plan editor at the time the EJB archive is deployed. See "Setting Web Module Configuration Properties" for information.
Also note that for existing clients, a serialization-related exception will occur if there are any changes in the structure of the session beans deployed with the module.
