Programming WebLogic Enterprise JavaBeans
The following sections contain EJB-specific deployment guidelines. For deployment topics that are common to all deployable application units, you will see cross-references to topics in Deploying Applications to WebLogic Server, a comprehensive guide to deploying WebLogic Server applications and modules.
For an overview of the steps required to create and package an EJB, see Overview of the EJB Development Process.
weblogic-ejb-jar.xml, and, for entity EJBs that use container-managed persistence,
To create EJB deployment descriptors, see Edit Deployment Descriptors.
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.
Deploying and Packaging from a Split Development Directory in Developing Applications with WebLogic Server.
Overview of Deployment Tools in Understanding WebLogic Server Deployment
Preparing Applications and Modules for Deployment in Deploying Applications to WebLogic Server.
EJBs in Developing Applications with WebLogic Server.
Controlling Deployment File Copying with Staging Modes in Deploying Applications and Modules.
Overview of the Deployment Process in Understanding WebLogic Server Deployment.
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 Adapters 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 Overview of the Split Development Directory Environment in Developing Applications with WebLogic Server.
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
True. (By default,
If your 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 server). 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.
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
ejbc before deploying it, to ensure that the generated classes are copied to all server instances available to all nodes in the cluster.
For more information on pinned deployments, see Deploying to a Single Server Instance (Pinned Deployment) in Using WebLogic Server Clusters.
When you make changes to a deployed EJB's classes, you must redeploy the EJB. If you use automatic deployment, deployment occurs automatically when you restart WebLogic Server. Otherwise, you must explicitly redeploy the EJB.
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.
You can redeploy an EJB that is standalone or part of an application, using the
weblogic.Deployer tool or the Administration Console. For instructions, see Updating Applications in a Production Environment in Deploying Applications to WebLogic Server.
For more information on production redeployment limitations, see Requirements and Restrictions for Using Production Redeployment in Deploying Applications to WebLogic Server.
In this release of WebLogic Server, you can redeploy an individual implementation class. For information about this feature, see Individual EJB Classloader for Implementation Classes in Developing Applications with WebLogic Server.
To enable this feature, set the
enable-bean-class-redeploy element to
weblogic-ejb-jar.xml. This feature is not recommended for use in production environments. For considerations and limitations related to deploying an individual implementation class, feature, see enable-bean-class-redeploy.
You can use the
disable-warning element 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.