[
https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy...
]
Martin Kouba commented on CDI-625:
----------------------------------
[~rmannibucau] I see, you're right that existing literals would be broken. On the
other hand, CDI API now provides its own literals which could be used instead. Also these
literals are used mostly by CDI container itself. Rarely by extensions firing events for
custom contexts and custom observer methods...
-1 for "interceptor" approach. Looks unnecessarily complex.
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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)