Chapter 12. Packaging and deployment

When an application is started, the container must perform bean discovery, detect definition errors and deployment problems and raise events that allow portable extensions to integrate with the deployment lifecycle.

Bean discovery is the process of determining:

Additional beans may be registered programmatically with the container by the application or a portable extension after the automatic bean discovery completes. Portable extensions may even integrate with the process of building the Bean object for a bean, to enhance the container's built-in functionality.

12.1. Bean archives

Bean classes of enabled beans must be deployed in bean archives.

  • A library jar, EJB jar, application client jar or rar archive is a bean archive if it has a file named beans.xml in the META-INF directory.

  • The WEB-INF/classes directory of a war is a bean archive if there is a file named beans.xml in the WEB-INF directory of the war.

  • A directory in the JVM classpath is a bean archive if it has a file named beans.xml in the META-INF directory.

The container is not required to support application client jar bean archives.

A Java EE container is required by the Java EE specification to support Java EE modules. Other containers may or may not provide support for war, EJB jar or rar bean archives.

The container searches for beans in all bean archives in the application classpath:

  • In an application deployed as an ear, the container searches every bean archive bundled with or referenced by the ear, including bean archives bundled with or referenced by wars and EJB jars contained in the ear. The bean archives might be library jars, EJB jars, rars or war WEB-INF/classes directories.

  • In an application deployed as a war, the container searches every bean archive bundled with or referenced by the war. The bean archives might be library jars or the WEB-INF/classes directory.

  • In an application deployed as an EJB jar, the container searches the EJB jar, if it is a bean archive, and every bean archive referenced by the EJB jar.

  • An embeddable EJB container searches each bean archive in the JVM classpath that is listed in the value of the embeddable container initialization property javax.ejb.embeddable.modules, or every bean archive in the JVM classpath if the property is not specified. The bean archives might be directories, library jars or EJB jars.

When searching for beans, the container considers:

  • any Java class in any bean archive,

  • any ejb-jar.xml file in the metadata directory of any EJB bean archive,

  • any Java class referenced by the @New qualifier of an injection point of another bean, and

  • any interceptor or decorator class declared in the beans.xml file of any bean archive.

If a bean class is deployed in two different bean archives, non-portable behavior results. Portable applications must deploy each bean class in no more than one bean archive.

If an enum declaring injection points is defined in installed library jars, non-portable behavior results.

Bean archives may contain classes which are not deployed as beans. For example a bean archive might contain message driven beans.

An extension may be deployed in any archive, including those that are not bean archives.

12.2. Application initialization lifecycle

When an application is started, the container performs the following steps:

12.3. Application shutdown lifecycle

When an application is stopped, the container performs the following steps:

  • First, the container must destroy all contexts.

  • Next, the container must destroy dependent objects injected into enums.

  • Finally, the container must fire an event of type BeforeShutdown, as defined in Section 11.5.4, “BeforeShutdown event”.

12.4. Bean discovery

The container automatically discovers managed beans (according to the rules of Section 3.1.1, “Which Java classes are managed beans?”) and session beans in bean archives and searches the bean classes for producer methods, producer fields, disposer methods and observer methods.

For each Java class or interface deployed in a bean archive, the container must:

For each enabled bean, the container must search the class for producer methods and fields, including resources, and for each producer method or field:

For each enabled bean, the container must search the class for observer methods, and for each observer method:

The container determines which alternatives, interceptors and decorators are enabled, according to the rules defined in Section 5.1.2, “Enabled and disabled beans”, Section 9.4, “Interceptor enablement and ordering” and Section 8.2, “Decorator enablement and ordering”, taking into account any <alternatives>, <interceptors> and <decorators> declarations in the beans.xml files, and registers the Bean and ObserverMethod objects:

12.5. Integration with Unified EL

The container must provide a Unified EL ELResolver to the servlet engine and JSF implementation that resolves bean EL names using the rules of name resolution defined in Section 5.3, “EL name resolution” and resolving ambiguities according to Section 5.3.1, “Ambiguous EL names”.

  • If a name used in an EL expression does not resolve to any bean, the ELResolver must return a null value.

  • Otherwise, if a name used in an EL expression resolves to exactly one bean, the ELResolver must return a contextual instance of the bean, as defined in Section 6.5.2, “Contextual instance of a bean”.