8 Deployment Guidelines for Enterprise JavaBeans

Learn about the 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 Oracle WebLogic Server, a comprehensive guide to deploying WebLogic Server applications and modules.

This chapter includes the following sections:

Before You Deploy an EJB

Examine the tasks that need to be completed before you begin with the EJB deployment.

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 production environments, Oracle recommends that you package your application as an EAR.

    For an overview of the steps required to create and package an EJB, see Overview of the EJB Development Process.

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

    To create EJB deployment descriptors, see unresolvable-reference.html.

Understanding and Performing Deployment Tasks

Examine some of the deployment strategies to perform the 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.

Table 8-1 Deployment Tasks and Topics

If You Want To.... See This Topic

Deploy in a development environment

Deploying and Packaging from a Split Development Directory in Developing Applications for Oracle WebLogic Server.

Select a deployment tool

Deployment Tools in Deploying Applications to Oracle WebLogic Server

Determine appropriate packaging for a deployment

Preparing Applications and Modules for Deployment in Deploying Applications to Oracle WebLogic Server.

Organizing EJB components in a split directory structure.

EJBs in Developing Applications for Oracle WebLogic Server.

Select staging mode

Controlling Deployment File Copying with Staging Modes in Deploying Applications to Oracle WebLogic Server.

Perform specific deployment tasks

Overview of the Deployment Process in Deploying Applications to Oracle WebLogic Server.

Deployment Guidelines for EJBs

Understand the guidelines to deploy EJBs on WebLogic Server.

The following sections provide guidelines for deploying EJBs.

Deploy EJBs as Part of an Enterprise Application

Oracle recommends that you package and deploy your stand-alone EJB applications as part of an Enterprise application. An Enterprise application is a Java EE deployment unit that bundles together Web applications, EJBs, and Resource Adapters into a single deployable unit.

This is a Oracle 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 for Oracle WebLogic Server.

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

Switching Protocol Limitation

If an application client request has multiple hops, and QOS is configured differently between servers, then you must switch the protocol.

For example, when a client sends an SSL request to a JMS front-end cluster, the JMS front-end cluster then forwards the request to the JMS back-end cluster using clear text. In this case, you may need to switch from the t3s protocol to the t3 protocol.


You can switch the protocol only in a default channel. Custom channels do not support protocol switching.

Deploying EJBs that Use Dependency Injection

When an EJB uses dependency injection, the resource name defined in the class and the superclass must be unique. For example:

public class ClientServlet extends HttpServlet {
    @EJB(name = 'DateServiceBean', beanInterface = DateService.class)
    private DateService bean; .... } 
public class DerivedClientServlet extends ClientServlet { 
    @EJB(name = MyDateServiceBean', beanInterface = DateService.class)
    private DateService bean; .... }

For more information about dependency injection, see Using Java EE Annotations and Dependency Injection in Developing Applications for Oracle WebLogic Server.

Deploy Homogeneously to a Cluster

If your EJBs will run on a WebLogic Server cluster, Oracle 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. See, Understanding Cluster Configuration in Administering Clusters for Oracle WebLogic Server.

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 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 Administering Clusters for Oracle WebLogic Server.

Redeploying an EJB

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.

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 any of the administration tools listed in Summary of System Administration Tools and APIs in Understanding Oracle WebLogic Server. See Redeploying Applications in a Production Environment in Deploying Applications to Oracle WebLogic Server.

Production redeployment is not supported for:

  • applications that use JTS drivers.

  • applications that include EJB 1.1 container-managed persistence (CMP) EJBs. To use production redeployment with applications that include CMP EJBs, use EJB 2.x CMP instead of EJB 1.1 CMP.

For more information on production redeployment limitations, see Requirements and Restrictions for Production Redeployment in Deploying Applications to Oracle WebLogic Server.

Using FastSwap Deployment to Minimize Deployment

During iterative development of an EJB application, you make many modifications to the EJB implementation class file, typically redeploying an EJB module multiple times during its development.

Java EE 5 introduces the ability to redefine a class at runtime without dropping its ClassLoader or abandoning existing instances. This allows containers to reload altered classes without disturbing running applications, vastly speeding up iterative development cycles and improving the overall development and testing experiences.

With FastSwap, Java classes are redefined in-place without reloading the ClassLoader, thereby having the decided advantage of fast turnaround times. This means that you do not have to wait for an application to redeploy for your changes to take affect. Instead, you can make your changes, auto compile, and then see the effects immediately.

For more information about FastSwap, see Using FastSwap Deployment to Minimize Redeployment in Deploying Applications to Oracle WebLogic Server.

Understanding Warning Messages

To get information about a particular warning, use the weblogic.GetMessage tool. For example:

java weblogic.GetMessage -detail -id BEA-010202

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