Here is some info pulled from the EJB 1.1 spec, Servlet 2.2 spec and J2EE 1.2
spec concerning deployment of ejb jars, web wars and app ears. In going through
this info, what I get out of it is that the ejb-jars should be included in the
application
classpath, sinc in general, the ejb module can consist soley of the ejb-jar with all
required classes included. Although there is support for factoring shared classes
into separate jars, it is not required.
Now a smart deployer could choose not to include the ejb-jars in the application
classpath if it can determine that client views of the ejbs can be met by including
either
the ejb-client jar or ejb-jar Class-Path jars.
+++ EJB 1.1 spec:
17.2 Deployment descriptor
The ejb-jar file must contain the deployment descriptor in the format
defined in Chapter 16. The deployment descriptor must be stored with
the name META-INF/ejb-jar.xml in the ejb-jar file.
17.3 Class files
For each enterprise bean, the ejb-jar file must include the class files
of the following:
. The enterprise bean class.
. The enterprise bean home and remote interface.
. The primary key class if the bean is an entity bean.
The ejb-jar file must also contain the class files for all the classes and
interfaces that the enterprise bean class, and the remote and home interfaces
depend on. This includes their superclasses and superinter-faces, and the
classes and interfaces used as method parameters, results, and exceptions.
An ejb-jar file does not have to include the class files of the home and
remote interfaces of an enterprise bean that is referenced by an enterprise
bean in the ejb-jar, or other classes needed by the referenced enterprise
bean, if the referenced enterprise bean or needed classes are defined in
another jar file that is named in the Class-Path attribute in the Manifest
file of the referencing ejb-jar file, or the transitive closure of such
Class-Path references. Note that this Class-Path mechanism only works
with JDK 1.2 and later.
17.4 ejb-client JAR file
The ejb-jar file producer can create an ejb-client JAR file for the ejb-jar file.
The client-ejb JAR file contains all the class files that a client program needs
to use the client view of the enterprise beans that are contained in the ejb-jar
file.
The ejb-client JAR file is specified in the deployment descriptor of the ejb-jar
file using the optional ejb-client-jar element. The Deployer should ensure that the
specified ejb-client JAR file is accessible to the client program's class-loader.
If no ejb-client-jar element is specified, the Deployer should make the entire ejb-jar
file accessible to the client's class-loader.
The EJB specification does not specify whether the ejb-jar file should include by
copy or by reference the classes that are in the ejb-client JAR. If the by-copy
approach is used, the producer simply includes all the class files in the ejb-client
JAR file also in the ejb-jar file. If the by-reference approach is used,
the ejb-jar file producer does not duplicate the content of the ejb-client JAR file
in the ejb-jar file, but instead uses a Manifest Class-Path entry in the ejb-jar
file to specify that the ejb-jar file depends on the ejb-client JAR at runtime.
+++ Servlet 2.2 spec
9.7 Replacing a Web Application
Applications evolve and must occasionally be replaced. In a long running server it is
ideal to be able to load a new web application and shut down the old one without
restarting the container.
When an application is replaced, a container should provide a robust approach to
preserving session data within that application.
9.9 Web Application Environment
Java 2 Platform Enterprise Edition, v 1.2 defines a naming environment that allows
applications to easily access resources and external information without the explicit
knowledge of how the external information is named or organized.
As servlets are an integral component type of J2EE, provision has been made in the
web application deployment descriptor for specifying information allowing a servlet
to obtain references to resources and enterprise beans. The deployment elements that
contain this information are:
. env-entry
. ejb-ref
. resource-ref
The env-entry element contains information to set up basic environment entry names
relative to the java:comp/env context, the expected Java type of the environment
entry value (the type of object returned from the JNDI lookup method), and an
optional environment entry value. The ejb-ref element contains the information needed
to allow a servlet to locate the home interfaces of a enterprise bean. The
resource-ref element contains the information needed to set up a resource factory.
The requirements of the J2EE environment with regards to setting up the environment
are described in Chapter 5 of the Java 2 Platform Enterprise Edition v 1.2
specification 1 . Servlet containers that are not part of a J2EE compliant
implementation are encouraged, but not required, to implement the application
environment functionality described in the J2EE specification.
+++ J2EE 1.2 spec
8.1.4 Deployment
During the deployment phase of an application's life cycle, the application is
installed on the J2EE platform and then is configured and integrated into the
existing infrastructure. Each J2EE module listed in the application deployment
descriptor must be deployed according to the requirements of the specification
for the respective J2EE module type. Each module listed must be installed in the
appropriate container type and the environment properties of each module must
be set appropriately in the target container to reflect the values declared by the
deployment descriptor element for each component.
8.2 Application Assembly
This section specifies the sequence of steps that are typically followed when
composing a J2EE application.
Assembling a J2EE Application
1. Select the J2EE modules that will used by the application.
2. Create an application directory structure.
The directory structure of an application is arbitrary. The structure should be
designed around the requirements of the contained components.
3. Reconcile J2EE module deployment parameters.
The deployment descriptors for the J2EE modules must be edited to link
internally satisfied dependencies and eliminate any redundant security role
names. An optional element alt-dd (described in Section 8.4,
"J2EE:application XML DTD") may be used when it is desirable to preserve
the original deployment descriptor. The element alt-dd specifies an alternate
deployment descriptor to use at deployment time. The edited copy of the
deployment descriptor file may be saved in the application directory tree in a
location determined by the Application Assembler. If the alt-dd element is
not present, the Deployer must read the deployment descriptor directly from
the JAR.
a. Link the internally satisfied dependencies of all components in every
module contained in the application. For each component dependency,
there must only be one corresponding component that fulfills that
dependency in the scope of the application.
i. For each ejb-link, there must be only one matching ejb-name in the
scope of the entire application (see Section 5.3, "Enterprise JavaBeansT
(EJB) References").
ii. Dependencies that are not linked to internal components must be
handled by the Deployer as external dependencies that must be met by
resources previously installed on the platform. External dependencies
must be linked to the resources on the platform during deployment.
b. Synchronize security role-names across the application. Rename unique
role-names with redundant meaning to a common name.
4. Create an XML deployment descriptor for the application.
The deployment descriptor must be named "application.xml" and must
reside in the top level of the META-INF directory of the application .ear file.
The deployment descriptor must be a valid XML document according to the
document type definition (DTD) for a J2EE:application XML document. The
deployment descriptor must include an XML document type definition with a
PUBLIC identifier of "-//Sun Microsystems//J2EE Application Deployment 1.0//EN".
5. Package the application.
a. Place the J2EE modules and the deployment descriptor in the appropriate
directories. The deployment descriptor must be located at
META-INF/application.xml.
b. Package the application directory hierarchy in a file using the Java Archive
(JAR) file format. The file should be named with a .ear filename
extension.
Adding and Removing Modules
After the application is created, J2EE modules may be added or removed before
deployment. When adding or removing a module the following steps must be
performed:
1. Decide on a location in the application package for the new module.
Optionally create new directories in the application package hierarchy to
contain any J2EE modules that are being added to the application.
2. Copy the new J2EE modules to the desired location in the application
package. The packaged modules are inserted directly in the desired location;
the modules are not unpackaged.
3. Edit the deployment descriptors for the J2EE modules to link the
dependencies which are internally satisfied by the J2EE modules included in
the application.
4. Edit the J2EE application deployment descriptor to meet the content
requirements of the J2EE platform and the validity requirements of the
J2EE:application XML DTD.
