[cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired

Romain Manni-Bucau (JIRA) issues at jboss.org
Mon Sep 12 03:26:00 EDT 2016

    [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291593#comment-13291593 ] 

Romain Manni-Bucau commented on CDI-625:

You can always remove @PreDestroy in an extension and call it in Bean3 but was more thinking this way: since the user hits this issue the workaround is to not use @PreDestroy when it is an issue or order is important (which is not that common compared to @PreDestroy cases).

Right about BeforeShutdown, know early OWB versions needed to move it before the actual destruction in some cases (could check the details and current state if needed) cause BeforeShutdown extensions are often accessing app scoped beans which was not possible in the mentionned order, maybe no more an issue with this new @BeforeDestroyed.

About the semantic if we introduce @BeforeDestroyed we should likely introduce @AfterDestroyed for the consistency and do the same for @Initialized which would let us with two events doing the same in term or API (but easily collapsable in the implementation so no perf issue, just an API issue). Is that possible to deprecate not prefixed events? Or maybe @AfterXX should be a @Stereotype which would auto document the new API?

> 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 {{@Initialized(X.class)}} is fired when a context is initialized and {{@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:
> * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
> * {{@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 {{@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 {{@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

More information about the cdi-dev mailing list