[JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-601:
----------------------------------
Yes, sounds better. Maybe even {{ApplicationStopped}}?
bq. My original notion was for @ApplicationScoped beans not to be destroyed while other beans still hold contextual references to them...
This might be pretty complext, if even possible for non-inject cases ({{BeanManager.getReference()}}, {{Instance.get()}}) and unmanaged contextual instances.
What I had in mind when creating this ticket was that it might be useful to introduce some generic event fired *when an application is stopped before all contexts are destroyed* and which would allow a bean to perform cleanup using the dependencies, i.e. fired before {{@PreDestroy}} and {{(a)Destroyed(X.class)}}. [~chrisjr] WRT your use case - your "@Dependent worker bean" would just observe {{ApplicationStopped}} and do all the cleanup ({{@ApplicationScoped}} beans would not be destroyed yet).
{code:java}
@Dependent
class Worker {
@Inject
Service service;
void shutdown(@Observes ApplicationStopped event) {
// At this point Service is not destroyed yet, nor is its @PreDestroy called
service.doSomeStuff();
}
}
@ApplicationScoped
class Service {
@PreDestroy
void destroy() {
// Perform local cleanup
}
void doSomeStuff() {
}
}
{code}
> Add container lifecycle event fired before container destroys all contexts
> --------------------------------------------------------------------------
>
> Key: CDI-601
> URL: https://issues.jboss.org/browse/CDI-601
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-596?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-596 started by Antoine Sabot-Durand.
------------------------------------------------
> ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-596
> URL: https://issues.jboss.org/browse/CDI-596
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0-EDR2
>
>
> Right now, it's not clear what happens if:
> * a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed)
> * a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}}
> We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone.
> This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-596?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-596:
----------------------------------------
Assignee: Antoine Sabot-Durand
> ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-596
> URL: https://issues.jboss.org/browse/CDI-596
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0-EDR2
>
>
> Right now, it's not clear what happens if:
> * a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed)
> * a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}}
> We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone.
> This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-596?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-596:
-------------------------------------
Fix Version/s: 2.0-EDR2
(was: 2.0 (discussion))
> ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-596
> URL: https://issues.jboss.org/browse/CDI-596
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Fix For: 2.0-EDR2
>
>
> Right now, it's not clear what happens if:
> * a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed)
> * a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}}
> We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone.
> This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
F2F at JavaOne?
by Werner Keil
Hi,
I know for those in Europe, especially France or Czech Republic a F2F seems
planned even in the same month (Sep) which is why I cannot travel aside
from nearly 2 full work weeks that'll cost me and my clients.
Antoine and some of his colleagues have a few sessions related to CDI as
such and "somewhat related topics" including Docker, Microservices, etc.
Are enough others (I know Anatole has a talk, Otavio also does, at least
the one related to JSR 363 I plan to join) from the EG there who have time
to meet? Hopefully the JCP gets a room in the Hilton again, otherwise I'm
sure we could meet somewhere else.
WDYT?
Werner
On Wed, Jul 27, 2016 at 7:56 AM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Invitation mise ? jour: CDI weekly meeting - Toutes les
> semaines entre 18:00 et 19:00 le mardi (CET) (ASD Perso)
> (antoine(a)sabot-durand.net)
> 2. Re: Enabling programmatic/synthetic decorators added by
> extension (Martin Kouba)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 Jul 2016 15:35:55 +0000
> From: antoine(a)sabot-durand.net
> Subject: [cdi-dev] Invitation mise ? jour: CDI weekly meeting - Toutes
> les semaines entre 18:00 et 19:00 le mardi (CET) (ASD Perso)
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <001a11c2832c2272ef05388ba8d0(a)google.com>
> Content-Type: text/plain; charset="utf-8"
>
> Cet ?v?nement a ?t? modifi?.
>
> Titre : CDI weekly meeting
> Weekly meeting of the CDI EG and other community members discussing CDI 2.0
> specification.
> Date?: Toutes les semaines entre 18:00 et 19:00 le mardi Paris (modifi?)
> Lieu : IRC #cdi-dev channel on freenode
> Agenda?: ASD Perso
> Participants?:
> * Antoine Sabot-Durand- organisateur
> * cdi-dev
>
> D?tails de l'?v?nement :
>
> https://www.google.com/calendar/event?action=VIEW&eid=XzcxMGpnZ3BrNjEwaml...
>
> Invitation de Google?Agenda?: https://www.google.com/calendar/
>
> Vous recevez ce message ? l'adresse cdi-dev(a)lists.jboss.org, car vous
> participez ? cet ?v?nement.
>
> Refusez cet ?v?nement pour ne plus recevoir de notifications le concernant.
> Vous avez ?galement la possibilit? de cr?er un compte Google ? l'adresse
> https://www.google.com/calendar/ et de d?finir vous-m?me les param?tres de
> notification pour l'int?gralit? de votre agenda.
>
> En transf?rant cette invitation, vous risquez d'autoriser tous les
> destinataires ? modifier votre r?ponse ? l'invitation. Pour en savoir plus,
> consultez la page suivante?:
> https://support.google.com/calendar/answer/37135#forwarding
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/6dc7ad8c/at...
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: text/calendar
> Size: 2031 bytes
> Desc: not available
> Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/6dc7ad8c/at...
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: invite.ics
> Type: application/ics
> Size: 2091 bytes
> Desc: not available
> Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/6dc7ad8c/at...
>
> ------------------------------
>
> Message: 2
> Date: Wed, 27 Jul 2016 07:56:48 +0200
> From: Martin Kouba <mkouba(a)redhat.com>
> Subject: Re: [cdi-dev] Enabling programmatic/synthetic decorators
> added by extension
> To: cdi-dev(a)lists.jboss.org
> Message-ID: <10bcc54a-777a-5931-1738-cdaeb5a7a593(a)redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> For the record - in CDI 2.0 we have
> javax.enterprise.inject.spi.Prioritized interface (currently used for
> ObserverMethod).
>
> But since Weld 3.0.0.Alpha13 prioritized custom beans, interceptors and
> decorators are also supported, i.e. Weld treats them as if annotated
> with @Priority (see also WELD-2000 [1]). I think this approach is also
> worth standardizing.
>
> Martin
>
> [1]
> https://issues.jboss.org/browse/WELD-2000
>
> Dne 26.7.2016 v 11:59 arjan tijms napsal(a):
> > Hi,
> >
> > Just wondering, has there been any progress made for this topic?
> >
> > Having the ability to dynamically add interceptors and/or add them when
> > building a Bean<T> using the programmatic APIs would still be incredibly
> > useful.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> > On Fri, Mar 4, 2016 at 5:18 PM, arjan tijms <arjan.tijms(a)gmail.com
> > <mailto:arjan.tijms@gmail.com>> wrote:
> >
> > ProxyFactory sounds like a perfect solution indeed.
> >
> > I now got something working, more or less, emphasis on less.
> >
> > I first make a "normal" (but effectively dummy) decorator with
> > @Priority available:
> >
> > @Decorator
> > @Priority(PLATFORM_BEFORE + 200)
> > public abstract class HttpAuthenticationBaseDecorator implements
> > HttpAuthenticationMechanism, Serializable {
> >
> > private static final long serialVersionUID = 1L;
> >
> > @Inject
> > @Delegate
> > HttpAuthenticationMechanism delegateMechanism;
> >
> > @Override
> > public AuthStatus validateRequest(HttpServletRequest request,
> > HttpServletResponse response, HttpMessageContext httpMessageContext)
> > throws AuthException {
> > return delegateMechanism.validateRequest(request, response,
> > httpMessageContext);
> > }
> > // ...
> > }
> >
> >
> > Then I create a "dynamic/programmatic" decorator:
> >
> >
> > public class DynamicHttpAuthenticationDecorator implements
> > Decorator<HttpAuthenticationBaseDecorator> {
> >
> > private final Set<Type> types = new
> > HashSet<Type>(asList(HttpAuthenticationBaseDecorator.class,
> > Object.class));
> > private final Set<Type> decoratedTypes =
> > singleton(HttpAuthenticationMechanism.class);
> >
> > private final BeanManager beanManager;
> > private final InjectionPoint decoratorInjectionPoint;
> > private final Set<InjectionPoint> injectionPoints;
> >
> > public DynamicHttpAuthenticationDecorator(BeanManager
> beanManager) {
> >
> > decoratorInjectionPoint = new DecoratorInjectionPoint(
> > HttpAuthenticationMechanism.class,
> >
> >
> beanManager.createAnnotatedType(HttpAuthenticationBaseDecorator.class).getFields().iterator().next(),
> > this);
> >
> > injectionPoints = singleton(decoratorInjectionPoint);
> >
> > this.beanManager = beanManager;
> > }
> >
> > public HttpAuthenticationBaseDecorator
> > create(CreationalContext<HttpAuthenticationBaseDecorator>
> > creationalContext) {
> > return new AutoApplySessionDecorator(
> > (HttpAuthenticationMechanism)
> > beanManager.getInjectableReference(decoratorInjectionPoint,
> > creationalContext));
> > }
> >
> > public void destroy(HttpAuthenticationBaseDecorator instance,
> > CreationalContext<HttpAuthenticationBaseDecorator>
> creationalContext) {
> > creationalContext.release();
> > }
> >
> > public Set<Type> getTypes() {
> > return types;
> > }
> >
> > public Set<Type> getDecoratedTypes() {
> > return decoratedTypes;
> > }
> >
> > public Class<?> getBeanClass() {
> > return HttpAuthenticationBaseDecorator.class;
> > }
> >
> > public Type getDelegateType() {
> > return HttpAuthenticationMechanism.class;
> > }
> >
> > public Set<InjectionPoint> getInjectionPoints() {
> > return injectionPoints;
> > }
> > }
> >
> > This Decorator<T> "pretends" that it's for the dummy decorator, via
> > the getTypes(), but in create() it returns another actual Decorator.
> > Then I create the delegate injection point of that decorator by
> > grabbing the @Delegate annotated field from the real decorator,
> > wrapping that basically in an InjectionPoint and then using that
> > later with beanManager#getInjectableReference.
> >
> > Now after adding this via afterBeanDiscovery.addBean(new
> > DynamicHttpAuthenticationDecorator(beanManager)), and it actually
> > gets called at runtime (tested on Weld).
> >
> > Disadvantages are a fixed priority and the fact that the dummy
> > decorator is called as well.
> >
> > Have to say that implementing
> > the javax.enterprise.inject.spi.Decorator interface, especially the
> > part for grabbing the @Delegate is quite non-obvious.
> >
> > What do you think, is this guaranteed to work, or did I abuse the
> > CDI APIs too much here?
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Mar 2, 2016 at 11:14 PM, Thomas Andraschko
> > <andraschko.thomas(a)gmail.com <mailto:andraschko.thomas@gmail.com>>
> > wrote:
> >
> > +1
> >
> > in DeltaSpike we implemented an own mechanism + proxy to invoke
> > interceptors for partial beans.
> > We will probably enhance this for such usecases or even
> > producers: https://issues.apache.org/jira/browse/DELTASPIKE-1069
> >
> >
> > 2016-03-02 22:51 GMT+01:00 Romain Manni-Bucau
> > <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>>:
> >
> > +1, seems it is the way to fix several issues without
> > introducing a lot of new concepts/API and in term of
> > technical stack it is just standardizing what is there.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
> > 2016-03-02 22:48 GMT+01:00 Mark Struberg <struberg(a)yahoo.de
> > <mailto:struberg@yahoo.de>>:
> >
> > ProxyFactory?
> >
> > I?m really thinking about introducing something like
> > javax.proxy, maybe as own sub-spec PDF?
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 02.03.2016 um 16:31 schrieb arjan tijms
> > <arjan.tijms(a)gmail.com <mailto:arjan.tijms@gmail.com>>:
> > >
> > > Hi,
> > >
> > > I'm trying to add decorators and/or interceptors to a
> > Bean<T> that's added via an extension. There doesn't
> > seem to be any way to add interceptors, but decorators
> > seem almost possible.
> > >
> > > I've added a decorator in the following way:
> > >
> > >
> > > AnnotatedType<AutoApplySessionDecorator> annotatedType
> > =
> >
> beanManager.createAnnotatedType(AutoApplySessionDecorator.class);
> > >
> > > BeanAttributes<AutoApplySessionDecorator>
> > beanAttributes =
> > beanManager.createBeanAttributes(annotatedType);
> > >
> > > Bean<AutoApplySessionDecorator> bean =
> > beanManager.createBean(beanAttributes,
> > AutoApplySessionDecorator.class,
> > beanManager.getInjectionTargetFactory(annotatedType));
> > >
> > > afterBeanDiscovery.addBean(bean);
> > >
> > > Where the "AutoApplySessionDecorator" is an existing
> > (non-scanned) decorator just used as an example.
> > >
> > >
> > > While this seems to work, the problem is with the
> > enablement. @Priority is not processed in this way,
> > since it's only read from an AnnotatedType that's been
> > added to the deployment (see e.g. in Weld
> >
> org.jboss.weld.bootstrap.BeanDeployer.processPriority(AnnotatedType<?>)).
> > >
> > > beans.xml is not really an option here due to the
> > static nature of that and the fact that the decorator
> > needs to be enabled dynamically here, plus that the
> > implementation class of the decorator is a detail I
> > would not like to expose to the application.
> > >
> > >
> > > Is there any other way to either enable a (synthetic)
> > decorator programmatically, or to add Interceptors to a
> > programmatically added Bean<T>?
> > >
> > > Kind regards,
> > > Arjan Tijms
> > >
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev(a)lists.jboss.org <mailto:
> cdi-dev(a)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(a)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(a)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(a)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(a)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.
> >
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
>
> End of cdi-dev Digest, Vol 68, Issue 17
> ***************************************
>
8 years, 5 months
Enabling programmatic/synthetic decorators added by extension
by arjan tijms
Hi,
I'm trying to add decorators and/or interceptors to a Bean<T> that's added
via an extension. There doesn't seem to be any way to add interceptors, but
decorators seem almost possible.
I've added a decorator in the following way:
AnnotatedType<AutoApplySessionDecorator> annotatedType =
beanManager.createAnnotatedType(AutoApplySessionDecorator.class);
BeanAttributes<AutoApplySessionDecorator> beanAttributes =
beanManager.createBeanAttributes(annotatedType);
Bean<AutoApplySessionDecorator> bean =
beanManager.createBean(beanAttributes, AutoApplySessionDecorator.class,
beanManager.getInjectionTargetFactory(annotatedType));
afterBeanDiscovery.addBean(bean);
Where the "AutoApplySessionDecorator" is an existing (non-scanned)
decorator just used as an example.
While this seems to work, the problem is with the enablement. @Priority is
not processed in this way, since it's only read from an AnnotatedType
that's been added to the deployment (see e.g. in
Weld org.jboss.weld.bootstrap.BeanDeployer.processPriority(AnnotatedType<?>)).
beans.xml is not really an option here due to the static nature of that and
the fact that the decorator needs to be enabled dynamically here, plus that
the implementation class of the decorator is a detail I would not like to
expose to the application.
Is there any other way to either enable a (synthetic) decorator
programmatically, or to add Interceptors to a programmatically added
Bean<T>?
Kind regards,
Arjan Tijms
8 years, 5 months
