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:
- 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,
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.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. 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. 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 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 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.
- 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.
You can
enable indirect local proxies using, for example, an administrative
console. Click . Specify a name of com.ibm.websphere.ejbcontainer.indirectLocalProxies and
a value of true for the custom property, then apply
and save the changes.