]
Romain Manni-Bucau commented on CDI-625:
----------------------------------------
bq. Not legal and should not work.
Well CDI doesn't solve it so we have to provide a real life solution to solve your
@PreDestroy issue in an extension but should be solve by this jira so let's skip this
one since it was a pre-solution case ;)
bq. I don't think it's needed.
Agree before doesnt make sense but weird to not be symmetric there from a user
perspective. I would at least enhance the After behavior
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 (proposed)
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.