Hi,
That somehow relates to the BeforeShutdown lifecycle event which must be fired after the
container has finished processing requests and destroyed all contexts.
IMO, it would make sense / be useful to be able to execute logic on ApplicationScoped
beans from within extensions before they are about to be "destroyed".
In the example from the specification (and consistently with other lifecycle events), one
can retrieve a reference to the bean manager:
void beforeShutdown(@Observes BeforeShutdown event, BeanManager manager) { ... }
While that is not clearly stated in the specification (as opposed to the clarification
done in version 1.2 for events like AfterBeanDiscovery and AfterDeploymentValidation), I
induce that methods like getReference are supposed to systematically throw
ContextNotActiveException.
To still meet the need, that is external control over ApplicationScoped bean destruction
without relying on the @PreDestroy callback nor disposer method, an intermediate lifecycle
event may be introduced, similarly to @Initializing /
@Destroying(ApplicationScoped.class). Interestingly enough, the specification states that
the application scope is active [...] when the disposer method or @PreDestroy callback of
any bean with any normal scope other than @ApplicationScoped is called, which tends to
validate John's "lower scopes" hypothesis.
For the information, calling BeanManager.getReference in BeforeShutdown actually works in
Weld 2.x (I haven't tested that use case in OWB).
Antonin
________________________________
From: cdi-dev-bounces(a)lists.jboss.org <cdi-dev-bounces(a)lists.jboss.org> on behalf of
Romain Manni-Bucau <rmannibucau(a)gmail.com>
Sent: Tuesday, April 28, 2015 10:14 PM
To: John D. Ament
Cc: cdi-dev(a)lists.jboss.org
Subject: Re: [cdi-dev] @Destroyed(ApplicationScoped.class)
Tcks check this event is "accessible" which is important otherwise it is just
useless
What is not well defined is integration with other parts of ee.
Le 28 avr. 2015 21:00, "John D. Ament"
<john.d.ament@gmail.com<mailto:john.d.ament@gmail.com>> a écrit :
Your understanding matches my understanding, and matches what I typically tell people to
do (use @PreDestroy).
I think this is more of a use case for lower scopes, or for a dependent bean (which I
would imagine would receive this event, though I can't say I've tried).
John
On Tue, Apr 28, 2015 at 2:56 PM Mark Struberg
<struberg@yahoo.de<mailto:struberg@yahoo.de>> wrote:
Hi!
The CDI-1.2 spec says in 6.7.3:
„An event with qualifier @Initialized(ApplicationScoped.class) is fired when the
application context is initialized and an event with qualifier
@Destroyed(ApplicationScoped.class) is fired when the application is destroyed. "
Now from the pure wording („IS initialized“, „IS destroyed“) I’d say that both events must
be fired _after_ the state is reached. Means _after_ the context got initialized and
_after_ the context got destroyed.
Means an observer like
@ApplicationScoped
public class MyBean {
public void endIt(@Observes @Destroyed(ApplicationScoped.class) endObject) {
doSomething()
}
}
will _never_ get invoked.
Because the bean (and the whole context) will be already killed…
You can observe this event in a @Singleton scoped bean, but not in an @ApplicationScoped
bean.
If you like to do _that_, then simply use a @PreDestroy.
Do others share this interpretation? Do we need to clarify anything?
LieGrue,
strub
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.