When is the @Initialized(ApplicationScoped.class) event sent in CDI?

Question

I'm trying to understand the lifecycle/flow of the @Initialized() events within the context of the CDI Container's events thrown that are observable in an extension.

As per the WELD 2 docs, the Container lifecycle events are:

• BeforeBeanDiscovery
• ProcessAnnotatedType and ProcessSyntheticAnnotatedType
• AfterTypeDiscovery
• ProcessInjectionTarget and ProcessProducer
• ProcessInjectionPoint
• ProcessBeanAttributes
• ProcessBean, ProcessManagedBean, ProcessSessionBean, ProcessProducerMethod and ProcessProducerField
• ProcessObserverMethod
• AfterBeanDiscovery
• AfterDeploymentValidation
• BeforeShutdown

What I'm having trouble finding out is where during this container lifecycle would the @Initialized event be triggered. I suspect that it is done AfterDeploymentValidation, but I cannot find any documentation to support that fact. Additionally, I can't seem to find anything in the CDI 1.1 spec which dictates when/where the @Initalized event is thrown.

For instance, is the event thrown before or after all the @PostConstruct methods of discovered beans is executed? Is the event thrown before or after an EJB @Startup is initialized? Is there any documentation that clearly lists the order/sequence of these events in CDI?

Answer 1

Q1: What I'm having trouble finding out is where during this container lifecycle would the @Initialized event be triggered. I suspect that it is done AfterDeploymentValidation, but I cannot find any documentation to support that fact.

As described in CDI 1.1 spec, section 11.5.4. AfterDeploymentValidation event:

The container must fire an event after it has validated that there are no deployment problems and before creating contexts or processing requests.

A1: As a consequence, events with qualifier @Initialized for any scope will be fired after AfterDeploymentValidation event.

---

Q2: Additionally, I can't seem to find anything in the CDI 1.1 spec which dictates when/where the @Initalized event is thrown.

A2: Section 6.7. Context management for built-in scopes describes behaviour for each built-in scope and provides recommendations for custom scopes implementations:

Portable extensions are encouraged to fire an event with qualifier @Initialized(X.class) when a custom context is initialized ...
An event with qualifier @Initialized(RequestScoped.class) is fired when the request context is initialized ...etc.

---

Q3: For instance, is the event thrown before or after all the @PostConstruct methods of discovered beans is executed?

As described in 6.7. Context management for built-in scopes:

The request scope is active:
- ...
- during @PostConstruct callback of any bean.

The application scope is active:
- ...
- during @PostConstruct callback of any bean.
...etc

A3: For a scope to become active it needs to be initialized first. As a consequence, events with qualifier @Initialized will be fired before @PostConstruct callback of any bean, but only for the scopes which must be active in a callback.

---

Q4: Is the event thrown before or after an EJB @Startup is initialized? Is there any documentation that clearly lists the order/sequence of these events in CDI?

A4: EJBs are covered by a separate specification JSR 345: Enterprise JavaBeans TM ,Version 3.2 EJB Core Contracts and Requirements.

According to section 4.8.1 Singleton Session Bean Initialization there:

By default, the container is responsible for deciding when to initialize a singleton session bean instance. However, the Bean Provider can optionally configure the singleton session bean for eager initialization. If the Startup annotation appears on the singleton session bean class or if the singleton session bean has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the singleton session bean instance during the application startup sequence. The container must initialize all such startup-time singleton session beans before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application.
...
In some cases, explicit initialization ordering dependencies exist between multiple singleton session bean components in an application. The DependsOn annotation is used to express these dependencies. A DependsOn dependency is used in cases where one singleton session bean must initialize before one or more other singleton session beans. The container ensures that all singleton session beans with which a singleton session bean has a DependsOn relationship have been initialized before the PostConstruct method is called.

As a consequence, events with qualifier @Initialized will be fired before @PostConstruct callback of EJB bean as well, but only for the scopes which must be active in a callback.