EJB modules

An Enterprise JavaBeans (EJB) module is used to assemble one or more enterprise beans into a single deployable unit. An EJB module is stored in a standard Java archive (JAR) file.

An EJB module contains the following:

You can deploy an EJB module as a stand-alone application, or combine it with other EJB modules or with web modules to create a Java application. An EJB module is installed and run in an enterprise bean container.

If you want to package an EJB 3.x module with a deployment descriptor, there are several ways to do it. You can package an EJB 3.x module with an EJB 3.x style session and/or message-driven beans exclusively; with an EJB 2.1 style session and/or message-driven beans exclusively, or a combination of 2.1 and 3.x style beans. The XML deployment descriptor must be a Version 3.x deployment descriptor. It is required that 2.1 entity beans are packaged in modules with 2.1 deployment descriptors.

EJB modules that contain EJB 3.x beans must be at the EJB 3.x specification level when running on the product. To set the EJB module to support EJB 3.x beans, you can set the ejb-jar.xml deployment descriptor level to 3.0 or 3.1, or you can make sure that the module does not contain an ejb-jar.xml deployment descriptor. If the module level is EJB 2.1 or earlier, no EJB 3.x functions, including annotation scanning or resource injection is performed at run time.

For more information about packaging and deployment of EJB 3.x beans, see the topic EJB 3.x module packaging overview.

Local client views

The EJB specification only requires local client views to be supported for EJBs packaged within the same application. This includes local homes, local business interfaces, and the no-interface view. WebSphere® Application Server permits access to local client views to EJBs packaged within a separate application with some restrictions:
  • The local interface and all parameter, return, and exception types used by the local interface must be visible to the class loader of both the calling application and the target EJB application. You can ensure this by either using a shared library associated with a server class loader or by using an isolated shared library associated with both applications. Read the Creating shared libraries topic for more information.
  • When the target EJB application is stopped, any cached references to the EJB must be refreshed. You can either:
    • Restart the calling application. The simplest solution is to restart the calling application whenever you restart a target EJB application on which it relies.
    • Obtain a new reference from JNDI. By default, JNDI lookups from the java namespace are cached, and the cache must either be disabled or cleared to obtain a new reference. Read the Developing applications that use JNDI topic for more information.

      EJB method invocations throw com.ibm.websphere.ejbcontainer.EJBStoppedException when the target EJB application has been stopped. If you have cached the EJB reference in an instance variable by using either @EJB injection or JNDI lookup, then you can catch this exception and refresh the EJB reference by performing a non-cached lookup.




Related concepts
EJB 3.x module packaging overview
Enterprise beans
Related tasks
Task overview: Using enterprise beans in applications
Creating shared libraries
Developing applications that use JNDI
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Jan 30, 2014 9:17:32 AM CST
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-nd-iseries&topic=cejbemod
File name: cejb_emod.html