Deployment Guidelines for Enterprise Java Beans
The section is a guide to deploying EJBs. It contains EJB-specific deployment guidelines, and for deployment topics that are common to all deployable application units, cross-references to topics in Deploying WebLogic Server Applications, a comprehensive instructions on deploying WebLogic Server applications and modules.
- Before You Deploy an EJB
- Understanding and Performing Deployment Tasks
- Deployment Guidelines for EJBs
Before You Deploy an EJB
Before starting the deployment process you should have:
- Functional, tested bean code, in an exploded directory format or packaged in an archive file - a .jar for a stand-alone EJB or an .ear if the EJB is part of an enterprise application - along with the deployment descriptors.
For an overview of the steps required to create and package an EJB, see EJB Development Task Guide
- Configured the required deployment descriptors - ejb-jar.xml and weblogic-ejb-jar.xml, and, for entity EJBs that use container-managed persistence, weblogic-cmp-jar.xml.
For information on creating EJB deployment descriptors, see Generate Deployment Descriptors and Edit Deployment Descriptors.
Understanding and Performing Deployment Tasks
Table 8-1 is a guide to WebLogic Server documentation topics that help you make decisions about deployment strategies and provide instructions for performing deployment tasks. For EJB-specific deployment topics, see Deployment Guidelines for EJBs.
|
If You Want To.... |
See this Topic |
|---|---|
| Deploy in a development environment | Deployment Topics for Developers" in Deploying WebLogic Server Applications. |
| Select a deployment tool | Deployment Tools" in Deploying WebLogic Server Applications. |
| Determine appropriate packaging for a deployment | Deployment Files" in Deploying WebLogic Server Applications. |
| Select staging mode | Staging Modes" in Deploying WebLogic Server Applications. |
| Perform specific deployment tasks | Performing Common Deployment Tasks", in Deploying WebLogic Server Applications. |
Deployment Guidelines for EJBs
The following sections provide guidelines for deploying EJBs.
Deploy EJBs as Part of an Enterprise Application
BEA recommends that you package and deploy your stand-alone EJB applications as part of an enterprise application. An Enterprise Application is a J2EE deployment unit that bundles together Web Applications, EJBs, and Resource Adaptors into a single deployable unit.
This is a BEA best practice, which allows for easier application migration, additions, and changes. Also, packaging your applications as part of an enterprise application allows you to take advantage of the split development directory structure, which provides a number of benefits over the traditional single directory structure. See Introducing the Split Development Directory Structure" in Developing WebLogic Server Applications.
Deploy EJBs that Call Each Other in the Same Application
When an EJB in one application calls an EJB in another application, WebLogic Server passes method arguments by value, due to classloading requirements. When EJBs are in the same application, WebLogic Server can pass method arguments by reference; this improves the performance of method invocation because parameters are not copied.
For best performance, package components that call each other in the same application, and set enable-call-by-reference in weblogic-ejb-jar.xml to True. (By default, enable-call-by-reference is False).
Deploy Homogeneously to a Cluster
If you EJBs will run on a WebLogic Server cluster, BEA recommends that you deploy them homogeneously - to each Managed Server in the cluster. Alternatively, you can deploy an EJB to only to a single server in the cluster (that is, "pin" a module to a servers). This type of deployment is less common, and should be used only in special circumstances where pinned services are required. For more information, Understanding Cluster Configuration and Application Deployment" in Using WebLogic Server Clusters.
Deploying Pinned EJBs to a Cluster
There is a known issue with deploying or redeploying EJBs to a single server instance in a cluster - referred to as pinned deployment - if the .jar file contains contain uncompiled classes and interfaces.
During deployment, the uncompiled EJB is copied to each server instance in the cluster, but it is compiled only on the server instance to which it has been deployed. As a result, the server instances in the cluster to which the EJB was not targeted lack the classes generated during compilation that are necessary to invoke the EJB. When a client on another server instance tries to invoke the pinned EJB, it fails, and an Assertion error is thrown in the RMI layer.
If you are deploying or redeploying an EJB to a single server instance in a cluster, compile the EJB with appc or ejbc before deploying it, to ensure that the generated classes copied to all server instances available to all nodes in the cluster.
For more information on pinned deployments, see the section Deploying to a Single Server Instance (Pinned Deployment)" in Using WebLogic Server Clusters.
Redeploying an EJB
When you make changes to deployed EJB's classes, redeploy the EJB. If you use automatic deployment, deployment occurs automatically when you restart WebLogic Server. Otherwise, explicitly redeploy the EJB.
Redeploying an EJB deployment enables an EJB provider to make changes to a deployed EJB's classes, recompile, and then "refresh" the classes in a running server.
When you redeploy, the classes currently loaded for the EJB are immediately marked as unavailable in the server, and the EJB's classloader and associated classes are removed. At the same time, a new EJB classloader is created, which loads and maintains the revised EJB classes.
When clients next acquire a reference to the EJB, their EJB method calls use the changed EJB classes.
You can redeploy an EJB that is standalone or part of an application, using weblogic.Deployer tool or the Administration Console. For instructions, see Redeploying or Stopping a Deployment Unit" in Deploying WebLogic Server Applications.
Redeploying an Individual EJB Implementation Class
During iterative development of an EJB application, you make many modifications to EJB implementation class file, typically redeploying an EJB module multiple times during its development.
Prior to WebLogic Server 8.1, you could redeploy EJB implementation classes at the EJB module level, including all implementation and utility classes. Starting in WebLogic Server 8.1, you can redeploy an individual implementation class. For information about this feature, see Individual EJB Classloader for Implementation Classes" in Developing WebLogic Server Applications.
To enable this feature, set the enable-bean-class-redeploy element to True in weblogic-ejb-jar.xml. For considerations and limitations of this feature, see enable-bean-class-redeploy.
Disabling EJB Deployment Warning Messages
You can disable certain WebLogic Server warning messages that occur during deployment. You may find this useful if the messages provide information of which you are already aware.
For example, if the methods in your EJB makes calls by reference rather than by value, WebLogic Server generates this warning during deployment: "Call-by-reference not enabled."
You can use the disable-warningelement in weblogic-ejb-jar.xml to disable certain messages. For a list of messages you can disable, and instructions for disabling the messages, see disable-warning
Understanding Warning Messages
To get more information about the particular warning, use the weblogic.GetMessage tool. For example: java weblogic.GetMessage -detail -id BEA-010202.
|
|
|