| Oracle® Containers for J2EE Deployment Guide 10g (10.1.3.1.0) Part Number B28951-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Deployment Guide 10g (10.1.3.1.0) Part Number B28951-01 |
|
|
View PDF |
The following topics discuss deployment or 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 4, "Deploying Large Applications" for guidelines on tuning OC4J and the Java compiler for large-application deployment.
|
Note: If you are using the Application Server Control Console, EJB 3.0 entities deployed with session beans are not visible in the Application Server Control view of the EJB JAR module. After you deploy EJB 3.0 entities to OC4J, you cannot manage them through the Application Server Control Console. If you use Application Server Control to view your EJB module, the Entity Beans area will display "No entity beans found".You can manage all other EJB 3.0 beans such as session beans. For example, if you deploy an EJB module that contains both EJB 3.0 entities and EJB 3.0 session beans, your session beans will be visible through Application Server Control. For more information about managing EJBs, see the Oracle Containers for J2EE Enterprise JavaBeans Developer's Guide. |
OC4J optionally generates client-side IIOP stubs for each home and component interface if configured to do so when you deploy with Application Server Control Console, admin_client.jar, or the OC4J Ant tasks.
See "Deploying or 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 the Application Server Control Console.
Click the Administration tab for an OC4J instance.
Under Properties, select EJB Compiler Settings.
Under Compile Time Parameters, select Generate IIOP Client Stubs when Compiling EJBs .
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/instance/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/instance/application-deployments/app_name/ejbModuleName/ directory.
The -deploy command on the admin_client.jar command line 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="default_group">
<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/instance/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/instance/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.
Include -removeArchive to delete the deployment archive from the server's file system after deployment.
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 a J2EE Application (EAR)" 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/instance/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/instance/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 deploy only those beans within an EJB JAR that have changed, 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.
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 restarting OC4J.
The incremental redeployment operation will automatically stop the application containing the EJB or EJBs to be updated and 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. |
For CMP or BMP entity beans, OC4J uses code generation to generate the server implementation of the EJB interfaces (wrappers). In this case, incrementally redeploying only changed beans is most likely to be more efficient than redeploying the entire application.
For session beans, message-driven beans, and EJB 3.0 JPA entities, OC4J uses byte code generation to generate wrappers. Because this approach reduces deployment time so much, it may be just as efficient to redeploy the entire application as to redeploy only changed beans. In this case, incremental redeployment is optional.
The general procedure for using incremental deployment is as follows:
Deploy an application with a large number of enterprise beans.
Change a bean-related class file in an EJB module and rebuild the EJB JAR file (for
example, myBeans-ejb.jar).
Submit the updated EJB JAR to OC4J using any of the following tools:
JDeveloper
Application Server Control Console
See Chapter 9, "Using the Application Server Control Console for Deployment".
The updateEJBModule Ant task
The -updateEBJModule command of the admin_client.jar or admin.jar command-line utility
See "Updating Modified Classes in a Deployed EJB Module" for information about using admin_client.jar or "Updating an EJB Module Within a Deployed Application" for information about using admin.jar.
The following example shows how to use admin_client.jar for incremental deployment:
java -jar admin_client.jar deployer:oc4j:rmis://localhost:23791 admin welcome -updateEJBModule -appName petstore -ejbModuleName myBeans-ejb.jar -file build/myBeans-ejb.jar
Repeat steps 2 and 3.
For more information, see the Oracle Containers for J2EE Enterprise JavaBeans Developer's Guide.
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.
