]
Romain Manni-Bucau commented on CDI-625:
----------------------------------------
CDI provided literals are not yet mainstream and custom impl are still regularly seens so
the breaking bck compat is a real concern IMO
if interceptor approach is not liked we have to just define what we do I think. Not firing
an event before makes sense since a bean with a @PreDestroy can always replace it
(@Obserse init to init the bean then predestroy will be the before end event)
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.