]
Antoine Sabot-Durand commented on CDI-625:
------------------------------------------
During EG meeting, decision was taken to introduce {{@BeforeDestroyed}} and keep
{{@Destroyed}} to qualify event after the destruction of the context.
When exactly are events with @Initialized(X.class) and
@Destroyed(X.class) qualifiers fired
-------------------------------------------------------------------------------------------
Key: CDI-625
URL:
https://issues.jboss.org/browse/CDI-625
Project: CDI Specification Issues
Issue Type: Clarification
Components: Events
Reporter: Martin Kouba
Labels: F2F2016
Fix For: 2.0 .Final
The spec states that {{(a)Initialized(X.class)}} is fired when a context is initialized and
{{(a)Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}}
the wording leaves out the context: _"when the application is destroyed"_).
Does it mean that:
* {{(a)Initialized(X.class)}} is fired *after the initialization* of a context is finished,
i.e. the context is ready?
* {{(a)Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e.
after all the beans are destroyed?
I'm asking because for {{(a)Destroyed(X.class)}} it might be useful to perform some
cleanup before the context is actually destroyed - see also CDI-601.
In RI/Weld, the behaivour of {{(a)Destroyed(ApplicationScoped.class)}} is currently a
little bit inconsistent. For webapps and Weld SE, the event is fired before the context is
destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context
is destroyed.
I believe this should be more clear.