EJB modules

An EJB module is used to assemble one or more enterprise beans into a single deployable unit. An EJB module is stored in a standard JAR file.

An EJB module contains the following:

• One or more deployable enterprise beans.
• A deployment descriptor, stored in an Extensible Markup Language (XML) file. This file declares the contents of the module, defines the structure and external dependencies of the beans in the module, and describes how the beans are to be used at run time.

  It is not necessary to use XML deployment descriptors in EJB 3.x modules, although XML descriptors are supported. Instead of deployment descriptors, we can use annotations to provide component metadata.

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

To package an EJB 3.x module with a deployment descriptor, there are several ways to do it. We 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, we can set the ejb-jar.xml deployment descriptor level to 3.0 or 3.1, or we 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. The product 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. We can ensure this by either using a shared library associated with a server class loader or 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. We can complete one of the following actions:
  • 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 we have cached the EJB reference in an instance variable using either @EJB injection or JNDI lookup, then we can catch this exception and refresh the EJB reference by performing a non-cached lookup.

  • Enable indirect local EJB proxies for the target EJB application. This causes the local EJB proxy to be refreshed automatically when the application is restarted. Enabling indirect local proxies causes some additional overhead for each EJB method invocation.

    We can enable indirect local proxies using, for example, an administrative console. Click Applications > Application Types > WebSphere enterprise applications > application_name > Custom properties > New. Specify a name of com.ibm.websphere.ejbcontainer.indirectLocalProxies and a value of true for the custom property, then apply and save the changes.

Related:

EJB 3.x module packaging overview

Enterprise beans

Task overview: Using enterprise beans in applications

Create shared libraries

Developing applications that use JNDI