General WebLogic Server EJB Features

This section discusses some of the important general features of the WebLogic Server EJB container related to all types of EJB components . Subsequent sections will detail WebLogic Server features related to specific EJB types.

EJB Deployment/Redeployment

One important feature of the WebLogic Server EJB container is the ability to deploy and redeploy EJB components easily. Chapter 8 discusses the basic EJB packaging and deployment process, and it compares various options for deploying EJB components in WebLogic Server.

Dynamic EJB Compiling

The normal packaging and deployment technique for EJB components involves the execution of the WebLogic Server EJB compiler utility, weblogic.ejbc , or the new application compiler, weblogic.appc , to create a complete EJB archive file containing all of the container classes required for the EJB components. These container classes include home object and EJB object implementation classes, plus concrete classes for the beans that are subclasses of the bean class provided. The complete EJB archive file is then deployed to WebLogic Server using one of the techniques discussed in Chapter 8.

WebLogic Server also allows the deployment of an intermediate EJB archive file that has not been processed through the weblogic.ejbc or weblogic.appc utility. This intermediate archive file must contain the EJB components and descriptor files required by the weblogic.ejbc or weblogic.appc utility, as in the normal packaging and deployment approach discussed in Chapter 8, but the actual compilation step can be deferred until the archive file is processed by the EJB container during the deployment of the application. Note that this same dynamic compilation approach will be employed by WebLogic Server to deploy EJB archive files created using a different version of the compiler, even if the difference is only a service pack. This makes it less painful for you.

Dynamic execution of the EJB compiler may be forced unconditionally for a given EJB archive during the deployment of the application by setting the Force Generation option. To configure this option, find the desired EJB archive underneath the Deployments folder hierarchy in the WebLogic Console s left-hand navigation bar and look in the Compiler Options Configuration tab.

Referencing Other EJB Components

WebLogic Server supports the standard referencing mechanisms defined in the EJB 2.0 specification, including the ejb-link element in the ejb-jar.xml file. In this section, we will discuss referencing EJBs in the same application and in other applications. We end this section with a discussion of the WebLogic Server pass-by-reference optimization.

Referencing EJB Components in the Same Application

It is very common for EJB components to reference other EJB components contained in the same J2EE application. All EJB components in the same EJB archive file are in the same application, as are all EJB components in different archive files in a single enterprise application ( .ear ) archive file or directory structure.

EJB components typically obtain a reference to other components in the same application using the normal java:comp/env/ejb JNDI lookup syntax:

 Test2SessionHomeLocal homelocal2 =      (Test2SessionHomeLocal)ctx.lookup("  java:comp/env/ejb/Test2  "); 

There are two primary ways to map this generic syntax to the actual home interface: mapping to a global JNDI name in the weblogic-ejb-jar.xml file or using ejb-link elements.

In the first approach, the referencing component includes a ejb-local-ref element in the ejb-jar.xml file declaring the reference:

 <ejb-local-ref>   <  ejb-ref-name  >  ejb/Test2  <  /ejb-ref-name  >   <ejb-ref-type>Session</ejb-ref-type>   <local-home>     mastering.weblogic.ch06.example3.ejb.Test2SessionHomeLocal   </local-home>   <local>     mastering.weblogic.ch06.example3.ejb.Test2SessionLocal   </local> </ejb-local-ref> 

The ejb-local-reference-description elements in the weblogic-ejb-jar.xml file map this reference to a particular JNDI name:

 <ejb-local-reference-description>   <!-- Matches entry in ejb-jar.xml file -->   <  ejb-ref-name  >  ejb/Test2  <  /ejb-ref-name  >   <  jndi-name  >  Test2SessionHomeLocal  <  /jndi-name  > </ejb-local-reference-description> 

In the second approach, the referencing component includes an ejb-link element in the ejb-local-ref element in ejb-jar.xml , specifying the name of the other EJB component:

 <ejb-local-ref>   <  ejb-ref-name  >  ejb/Test2  <  /ejb-ref-name  >   <ejb-ref-type>Session</ejb-ref-type>   <local-home>     mastering.weblogic.ch06.example3.ejb.Test2SessionHomeLocal   </local-home>   <local>     mastering.weblogic.ch06.example3.ejb.Test2SessionLocal   </local>   <  ejb-link  >  Test2SessionEJB  <  /ejb-link  > </ejb-local-ref> 

In this approach there is no need to map the ejb/Test2 name to a specific JNDI name, so no ejb-local-reference-description elements are required in the weblogic-ejb-jar.xml descriptor. WebLogic Server automatically maps the ejb/Test2 reference to the Test2SessionEJB home interface and makes it available for lookup using the java:comp/env syntax shown previously. The name Test2SessionEJB is the logical name assigned to the EJB in its deployment descriptor. The ejb-link element may also specify the name of the EJB archive file hosting the desired component:

 <  ejb-link  >  test2.jar#Test2SessionEJB  <  /ejb-link  > 

This is required only if two EJBs in two different archive files use the same logical name. Components in the same application can, of course, look each other up directly using known global JNDI names :

 Test2SessionHomeLocal homelocal2 =      (Test2SessionHomeLocal) ctx.lookup(Test2SessionHomeLocal); 

This technique increases the coupling between EJB components by requiring that code in all referencing components knows the JNDI name for the desired component, but eliminates the need for all ejb-ref elements in descriptor files. Although the number of ejb-ref elements can grow exponentially in applications with many components requiring references to each other, using tools such as EJBGen, described in the next chapter, to create these ejb-ref and related elements makes this technique more tenable for large applications.

Best Practice  

Use ejb-ref elements, in conjunction with either ejb-link or ejb-reference-description elements, rather than direct lookup using global JNDI names, to reduce coupling between components in most applications.

Referencing EJB External Components

EJB components located in different applications, whether different enterprise application archive ( .ear ) files or just other EJB jar files not part of the current application, whether running in the same WebLogic Server instance or not, are considered external components. These components do not share the same local JNDI tree, so the ejb-link mechanism for referencing other components is not available. Components must use either global JNDI names or include appropriate ejb-ref elements in ejb-jar.xml and ejb-reference-description elements in the weblogic-ejb-jar.xml descriptor to look up external components. Note that external components must be looked up and used by their remote interfaces rather than local interfaces.

Because the components are external to the current application and more likely to change their global JNDI names, we suggest you use ejb-ref and ejb-reference-description elements instead of global JNDI names in referencing bean code.

Best Practice  

Use ejb-ref and ejb-reference-description elements to access EJB components in other applications.

Calling Components by Reference

The J2EE specification requires that EJB components invoked through their remote interfaces must use pass- by-value semantics, meaning that method parameters are copied during the invocation. Changes made to the passed-in object in the bean method are not reflected in the caller s version of the object. Copying method parameters is required in the case of a true remote or external invocation, of course, because the parameters are serialized by the underlying RMI infrastructure before being provided to the bean method. Pass-by-value semantics are also required between components located in different enterprise applications in the same Java virtual machine due to classloader constraints.

EJB components located in the same enterprise-application archive ( .ear ) file are loaded by the same classloader and have the option of using pass-by-reference semantics for all invocations, eliminating the unnecessary copying of parameters passed during the invocation and improving performance. Set the enable-call-by-reference parameter to true in the weblogic-ejb-jar.xml descriptor file to enable this feature for each bean in your application. Local references always use pass-by-reference semantics and are unaffected by the enable-call-by-reference setting.

Warning  

The default value of enable-call-by-reference was true in WebLogic Server 7.0 but is now false in WebLogic Server 8.1 in order to comply with Sun s J2EE licensing policy changes that require all J2EE compatible servers to support the specification with their out-of-the-box configuration. Be sure to set enable-call-by-reference to true for all beans in your application that have remote interfaces to avoid parameter copying unless your application requires copying for functional correctness.