Skip to content

Latest commit

 

History

History
114 lines (70 loc) · 5.06 KB

packagingdeployment.asciidoc

File metadata and controls

114 lines (70 loc) · 5.06 KB
Raw

Packaging and deployment

Before an application is started, or during application startup, the container must perform bean discovery, execute build compatible extensions, and detect definition errors and deployment problems.

Bean discovery is the process of determining:

  • Bean archives within application, and any beans contained within them

  • Which alternatives and interceptors are enabled

  • The ordering of enabled interceptors

Additional beans may be registered programmatically via [spi_lite].

Bean archives

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

A bean archive has a bean discovery mode of either annotated or none. This is governed by presence of beans.xml file which can be either empty or it can declare the bean-discovery-mode attribute. Default value for this attribute is annotated.

An archive which:

  • contains a beans.xml file with the bean-discovery-mode of none, or,

  • contains a portable extension or a build compatible extension and no beans.xml file

is not a bean archive.

An implicit bean archive is:

  • an archive which contains a beans.xml file that is empty, or,

  • an archive which contains a beans.xml file that has bean-discovery-mode attribute set to annotated

When determining which archives are bean archives, the container must consider all JAR archives available through implementation-specific means. Implementations are required to document how the candidate JAR archives are found.

The beans.xml file must be named:

  • META-INF/beans.xml.

The container searches for beans in all bean archives discovered as described above.

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.

Implicit bean archives are likely to contain classes which are not deployed as beans.

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

Application initialization lifecycle

Application shutdown lifecycle

When an application is stopped, the container must destroy all contexts.

Type and Bean discovery

The container automatically discovers managed beans (according to the rules of [what_classes_are_beans]) in bean archives and searches the bean classes for producer methods, producer fields, disposer methods and observer methods.

Type discovery

First the container must discover types. The container discovers each Java class with a bean defining annotation in an implicit bean archive.

Bean discovery

For every type in the set of discovered types (as defined in Type discovery), the container must:

  • inspect the type metadata to determine if it is a bean, and then

  • detect definition errors by validating the class and its metadata, and then

  • determine which alternatives and interceptors are enabled, according to the rules defined in [enablement].

For each enabled bean, the container must search the class for producer methods and fields, as defined in [producer_method] and in [producer_field], including resources, and for each producer:

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

Then, the container registers the Bean and ObserverMethod objects:

  • For each enabled bean that is not an interceptor, the container registers an instance of the Bean interface defined in [bean].

  • For each enabled interceptor, the container registers an instance of the Interceptor interface defined in [interceptor].

  • For each observer method of every enabled bean, the container registers an instance of the ObserverMethod interface defined in [observer_method].