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:
If you have installed
the Feature Pack for EJB 3.0, it is no longer
necessary to create XML deployment descriptors, although XML descriptors
are supported. Instead of deployment descriptors, you can use annotations
to provide component metadata.
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.0 module with a deployment descriptor, there are
several ways to do it. You can package an EJB 3.0 module with an EJB
3.0 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.0 style beans. The XML deployment descriptor
must be a Version 3.0 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.0 beans must be at the EJB 3.0 specification level when
running on the Feature Pack for EJB 3.0. To
set the EJB module to support EJB 3.0 beans, you can set the ejb-jar.xml
deployment descriptor level to 3.0, 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.0 functions, including
annotation scanning or resource injection is performed at runtime.
For more information about packaging and deployment of EJB 3.0 beans, see the topic EJB 3.0 module packaging overview.
As of WebSphere Application Server Version 6.1.0.33, 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.