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:
The bean archives that exist in the application, and the beans they contain
Which alternatives, interceptors and decorators are enabled for each bean archive
The ordering of enabled interceptors and decorators
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.
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.
When an application is started, the container performs the following steps:
First, the container must search for service providers for the service javax.enterprise.inject.spi.Extension defined in Section 11.5, “Container lifecycle events”, instantiate a single instance of each service provider, and search the service provider class for observer methods of initialization events.
Next, the container must fire an event of type BeforeBeanDiscovery, as defined in Section 11.5.1, “BeforeBeanDiscovery event”.
Next, the container must perform bean discovery, and abort initialization of the application if any definition errors exist, as defined in Section 2.8, “Problems detected automatically by the container”. Additionally, for every Java EE component class supporting injection that may be instantiated by the container at runtime, the container must create an InjectionTarget for the class, as defined in Section 11.2, “The Producer and InjectionTarget interfaces”, and fire an event of type ProcessInjectionTarget, as defined in Section 11.5.6, “ProcessInjectionTarget event”.
Next, the container must fire an event of type AfterBeanDiscovery, as defined in Section 11.5.2, “AfterBeanDiscovery event”, and abort initialization of the application if any observer registers a definition error.
Next, the container must detect deployment problems by validating bean dependencies and specialization and abort initialization of the application if any deployment problems exist, as defined in Section 2.8, “Problems detected automatically by the container”.
Next, the container must fire an event of type AfterDeploymentValidation, as defined in Section 11.5.3, “AfterDeploymentValidation event”, and abort initialization of the application if any observer registers a deployment problem.
Finally, the container begins directing requests to the application.
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:
create an AnnotatedType representing the type and fire an event of type ProcessAnnotatedType, as defined in Section 11.5.5, “ProcessAnnotatedType event”, and then
inspect the type metadata to determine if it is a bean or other Java EE component class supporting injection, and then
detect definition errors by validating the class and its metadata, and then
if the class is a managed bean, session bean, or other Java EE component class supporting injection, create an InjectionTarget for the class, as defined in Section 11.2, “The Producer and InjectionTarget interfaces”, and fire an event of type ProcessInjectionTarget, as defined in Section 11.5.6, “ProcessInjectionTarget event”, and then
if the class is an enabled bean, interceptor or decorator, create a Bean object that implements the rules defined in Section 7.3.1, “Lifecycle of managed beans”, Section 7.3.2, “Lifecycle of stateful session beans” or Section 7.3.3, “Lifecycle of stateless session and singleton beans”, and fire an event which is a subtype of ProcessBean, as defined in Section 11.5.8, “ProcessBean event”.
For each enabled bean, the container must search the class for producer methods and fields, including resources, and for each producer method or field:
create a Producer, as defined in Section 11.2, “The Producer and InjectionTarget interfaces”, and fire an event of type ProcessProducer, as defined in Section 11.5.7, “ProcessProducer event”, and then
if the producer method or field is enabled, create a Bean object that implements the rules defined in Section 7.3.4, “Lifecycle of producer methods”, Section 7.3.5, “Lifecycle of producer fields” or Section 7.3.6, “Lifecycle of resources”, and fire an event which is a subtype of ProcessBean, as defined in Section 11.5.8, “ProcessBean event”.
For each enabled bean, the container must search the class for observer methods, and for each observer method:
create an ObserverMethod object, as defined in Section 11.1.3, “The ObserverMethod interface” and fire an event of type ProcessObserverMethod, as defined in Section 11.5.9, “ProcessObserverMethod event”.
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 <enable>, <interceptors> and <decorators> declarations in the beans.xml files, and registers the Bean and ObserverMethod objects:
For each enabled bean that is not an interceptor or decorator, the container registers an instance of the Bean interface defined in Section 11.1, “The Bean interface”.
For each enabled interceptor, the container registers an instance of the Interceptor interface defined in Section 11.1.2, “The Interceptor interface”.
For each enabled decorator, the container registers an instance of the Decorator interface defined in Section 11.1.1, “The Decorator interface”.
For each observer method of every enabled bean, the container registers an instance of the ObserverMethod interface defined in Section 11.1.3, “The ObserverMethod interface”.
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”.