|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark
|Sent: Saturday, February 17, 2001 7:09 PM
|To: JBoss-Dev
|Subject: Re: [jBoss-Dev] multiple EJB-jars in one EAR deployment problem
|
|
|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.
|
We have been there before, there is no need to specify the dependencies
explicitely...
Dr Jung stuff doesn't do that cleanly btw...
|+++ 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.
wow, this is strange, since when is the "deployer" or even the packager in
this case aware of the semantics of the calls in the container. we
implement both semantics in the proxies and that SHOULD NOT BE SPECIFIED AT
PACKAGE TIME (!!!!!!)
These are "artificial" problems. The manifest cp entry mechanism is brain
dead... (imho)
where is mark? wtf...
marc
|
|+++ 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.
|
|
|
