This section discusses some of the important general features of the WebLogic Server EJB container related to all types of EJB
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
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
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.
WebLogic Server supports the standard referencing mechanisms defined in the EJB 2.0 specification, including the
element in the
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
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
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
Test2SessionHomeLocal homelocal2 = (Test2SessionHomeLocal) ctx.lookup(Test2SessionHomeLocal);
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.
EJB components located in different applications, whether different enterprise application archive (
) files or just other EJB jar files not part of the current application, whether running in the same WebLogic Server instance or not, are
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.
Use ejb-ref and ejb-reference-description elements to access EJB components in other applications.
The J2EE specification requires that EJB components invoked through their remote interfaces must use pass-
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.
The default value of
in WebLogic Server 7.0 but is now
in WebLogic Server 8.1 in order to