From issues at jboss.org Tue Mar 1 13:23:00 2016 From: issues at jboss.org (arjan tijms (JIRA)) Date: Tue, 1 Mar 2016 13:23:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170405#comment-13170405 ] arjan tijms commented on CDI-580: --------------------------------- What about extensions adding {{Bean}} instances via {{AfterBeanDiscovery.addBean}}? The above proposal looks like it could work for them, but not sure. Is there any existing way really to add interceptors to manually created {{Bean}} instances? > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From arjan.tijms at gmail.com Wed Mar 2 10:31:56 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 2 Mar 2016 16:31:56 +0100 Subject: [cdi-dev] Enabling programmatic/synthetic decorators added by extension Message-ID: Hi, I'm trying to add decorators and/or interceptors to a Bean 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 annotatedType = beanManager.createAnnotatedType(AutoApplySessionDecorator.class); BeanAttributes beanAttributes = beanManager.createBeanAttributes(annotatedType); Bean 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? Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160302/5d9e4b83/attachment.html From struberg at yahoo.de Wed Mar 2 16:48:02 2016 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 2 Mar 2016 22:48:02 +0100 Subject: [cdi-dev] Enabling programmatic/synthetic decorators added by extension In-Reply-To: References: Message-ID: 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 : > > Hi, > > I'm trying to add decorators and/or interceptors to a Bean 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 annotatedType = beanManager.createAnnotatedType(AutoApplySessionDecorator.class); > > BeanAttributes beanAttributes = beanManager.createBeanAttributes(annotatedType); > > Bean 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? > > Kind regards, > Arjan Tijms > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. From rmannibucau at gmail.com Wed Mar 2 16:51:46 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 2 Mar 2016 22:51:46 +0100 Subject: [cdi-dev] Enabling programmatic/synthetic decorators added by extension In-Reply-To: References: Message-ID: +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 | Blog | Github | LinkedIn | Tomitriber 2016-03-02 22:48 GMT+01:00 Mark Struberg : > 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 : > > > > Hi, > > > > I'm trying to add decorators and/or interceptors to a Bean 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 annotatedType = > beanManager.createAnnotatedType(AutoApplySessionDecorator.class); > > > > BeanAttributes beanAttributes = > beanManager.createBeanAttributes(annotatedType); > > > > Bean 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? > > > > Kind regards, > > Arjan Tijms > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160302/f001f288/attachment.html From andraschko.thomas at gmail.com Wed Mar 2 17:14:30 2016 From: andraschko.thomas at gmail.com (Thomas Andraschko) Date: Wed, 2 Mar 2016 23:14:30 +0100 Subject: [cdi-dev] Enabling programmatic/synthetic decorators added by extension In-Reply-To: References: Message-ID: +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 : > +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 | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-02 22:48 GMT+01:00 Mark Struberg : > >> 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 : >> > >> > Hi, >> > >> > I'm trying to add decorators and/or interceptors to a Bean 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 annotatedType = >> beanManager.createAnnotatedType(AutoApplySessionDecorator.class); >> > >> > BeanAttributes beanAttributes = >> beanManager.createBeanAttributes(annotatedType); >> > >> > Bean 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? >> > >> > Kind regards, >> > Arjan Tijms >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160302/61b6ae08/attachment-0001.html From arjan.tijms at gmail.com Fri Mar 4 11:18:40 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 4 Mar 2016 17:18:40 +0100 Subject: [cdi-dev] Enabling programmatic/synthetic decorators added by extension In-Reply-To: References: Message-ID: 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 { private final Set types = new HashSet(asList(HttpAuthenticationBaseDecorator.class, Object.class)); private final Set decoratedTypes = singleton(HttpAuthenticationMechanism.class); private final BeanManager beanManager; private final InjectionPoint decoratorInjectionPoint; private final Set 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 creationalContext) { return new AutoApplySessionDecorator( (HttpAuthenticationMechanism) beanManager.getInjectableReference(decoratorInjectionPoint, creationalContext)); } public void destroy(HttpAuthenticationBaseDecorator instance, CreationalContext creationalContext) { creationalContext.release(); } public Set getTypes() { return types; } public Set getDecoratedTypes() { return decoratedTypes; } public Class getBeanClass() { return HttpAuthenticationBaseDecorator.class; } public Type getDelegateType() { return HttpAuthenticationMechanism.class; } public Set getInjectionPoints() { return injectionPoints; } } This Decorator "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 at 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 : > >> +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 | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-03-02 22:48 GMT+01:00 Mark Struberg : >> >>> 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 : >>> > >>> > Hi, >>> > >>> > I'm trying to add decorators and/or interceptors to a Bean 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 annotatedType = >>> beanManager.createAnnotatedType(AutoApplySessionDecorator.class); >>> > >>> > BeanAttributes beanAttributes = >>> beanManager.createBeanAttributes(annotatedType); >>> > >>> > Bean 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? >>> > >>> > Kind regards, >>> > Arjan Tijms >>> > >>> > _______________________________________________ >>> > cdi-dev mailing list >>> > cdi-dev at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160304/04901f05/attachment.html From rmannibucau at gmail.com Sun Mar 6 09:31:35 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 6 Mar 2016 15:31:35 +0100 Subject: [cdi-dev] inheritance of cdi scopes Message-ID: Hi guys, spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. Sample: In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. Bonus: One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. Question: Would CDI handle it in 2.0? Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/9d7810f1/attachment-0001.html From rmannibucau at gmail.com Sun Mar 6 09:39:01 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 6 Mar 2016 15:39:01 +0100 Subject: [cdi-dev] async: back to completion future? Message-ID: Hi guys, as a user having a ComlpetionStage makes me loose some JDK utilities, can we move back to CompletionFuture? It would allow for instance: // doesn't work with CompletionStage CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) .then(...) Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/84530a94/attachment.html From reza_rahman at lycos.com Sun Mar 6 10:37:15 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 10:37:15 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: How much end user feedback has there been on this? I have to be honest that it surprises me to find this out now. This to me stands out as an obvious usability problem. CompletableFuture is the obvious top level end user API, not CompletionStage. Not going with CompletableFuture is very likely to confuse most people. The last thing we need is more potential usability problems in Java EE APIs. > On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau wrote: > > Hi guys, > > as a user having a ComlpetionStage makes me loose some JDK utilities, can we move back to CompletionFuture? > > It would allow for instance: > > // doesn't work with CompletionStage > CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) > .then(...) > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/01f28196/attachment.html From reza_rahman at lycos.com Sun Mar 6 10:40:53 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 10:40:53 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: Message-ID: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? > On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: > > Hi guys, > > spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. > > Sample: > In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. > > Bonus: > One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. > > Question: > Would CDI handle it in 2.0? > > Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/0303ae6a/attachment.html From john.d.ament at gmail.com Sun Mar 6 12:02:57 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 06 Mar 2016 17:02:57 +0000 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: What I think would be even better is to see this implemented in the impls (Weld & OWB) and see how users use it, in a release that's not plastered with Alpha or Experimental all over it. While I think we were all wary about it, we need real end user input from the impl standpoint to figure out what makes sense to standardize on. John On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman wrote: > How much end user feedback has there been on this? I have to be honest > that it surprises me to find this out now. > > This to me stands out as an obvious usability problem. CompletableFuture > is the obvious top level end user API, not CompletionStage. Not going with > CompletableFuture is very likely to confuse most people. The last thing we > need is more potential usability problems in Java EE APIs. > > On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau > wrote: > > Hi guys, > > as a user having a ComlpetionStage makes me loose some JDK utilities, can > we move back to CompletionFuture? > > It would allow for instance: > > // doesn't work with CompletionStage > CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) > .then(...) > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/707bf1d7/attachment-0001.html From rmannibucau at gmail.com Sun Mar 6 12:24:51 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 6 Mar 2016 18:24:51 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: 2016-03-06 18:02 GMT+01:00 John D. Ament : > What I think would be even better is to see this implemented in the impls > (Weld & OWB) and see how users use it, in a release that's not plastered > with Alpha or Experimental all over it. While I think we were all wary > about it, we need real end user input from the impl standpoint to figure > out what makes sense to standardize on. > > Or just do the opposite and *standardize* it. We can use Rx* feedbacks but it doesnt' match event case at all which is a real small subset of the reactive programming so I guess easiness should be what drives us there and integration at least with the JVM so CFuture version sounds more natural than CStage one. Difference is very small at method level but at utility level it is. Side note: a Weld or OWB release without experimental/alpha sounds worse if the spec changes later. A compromise can be an extension doing it already you can drop in any of these containers. > John > > > On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman wrote: > >> How much end user feedback has there been on this? I have to be honest >> that it surprises me to find this out now. >> >> This to me stands out as an obvious usability problem. CompletableFuture >> is the obvious top level end user API, not CompletionStage. Not going with >> CompletableFuture is very likely to confuse most people. The last thing we >> need is more potential usability problems in Java EE APIs. >> >> On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau >> wrote: >> >> Hi guys, >> >> as a user having a ComlpetionStage makes me loose some JDK utilities, can >> we move back to CompletionFuture? >> >> It would allow for instance: >> >> // doesn't work with CompletionStage >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >> .then(...) >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/e887522a/attachment.html From rmannibucau at gmail.com Sun Mar 6 12:35:33 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 6 Mar 2016 18:35:33 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> Message-ID: does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? Idea is to give an API to make: public void complete() { try { asyncContext.complete(); } finally { auditContext.end(); } } working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-06 16:40 GMT+01:00 Reza Rahman : > Can you kindly share an annotated code example of the proposed solution so > we can all follow and discuss this? > > On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau > wroteshar: > > Hi guys, > > spoke on concurrency utilities about the ability to inherit a cdi scope. > Idea is to follow request scope more than cdi spec allows. First thought it > was a concurrency utilities thing but Reza mentionned can be a CDI one so > here it is. > > Sample: > In a servlet i get MyBean which is @RequestScoped, I do some set on it. > The i go async (AsyncContext) and trigger a task in another thread. It > would be neat - and mandatory in some case by the loose coupling nature of > CDI - to get the *same* MyBean *instance* in this thread. With a direct > dependency you can easily use message passing pattern - but you loose the > loose coupling cause you need to know until which level you unwrap, think t > principal case which has 2-3 proxies!. However in practice you have a lot > of undirect dependencies, in particular with enterprise concerns (auditing, > security...) so you can't really do it easily/naturally. > > Bonus: > One very verbose way is to be able to kind of push/pop an existing context > in a thread - wrappers doing it on a Runnable/Consumer/Function/... would > be neat. > > Question: > Would CDI handle it in 2.0? > > Side note: this is really about the fact to reuse a "context context" (its > current instances map) in another thread the more transparently possible > and match the user vision more than a technical question for now. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/3fa6f617/attachment-0001.html From john.d.ament at gmail.com Sun Mar 6 12:41:12 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 06 Mar 2016 17:41:12 +0000 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: On Sun, Mar 6, 2016 at 12:25 PM Romain Manni-Bucau wrote: > 2016-03-06 18:02 GMT+01:00 John D. Ament : > >> What I think would be even better is to see this implemented in the impls >> (Weld & OWB) and see how users use it, in a release that's not plastered >> with Alpha or Experimental all over it. While I think we were all wary >> about it, we need real end user input from the impl standpoint to figure >> out what makes sense to standardize on. >> >> > Or just do the opposite and *standardize* it. We can use Rx* feedbacks but > it doesnt' match event case at all which is a real small subset of the > reactive programming so I guess easiness should be what drives us there and > integration at least with the JVM so CFuture version sounds more natural > than CStage one. Difference is very small at method level but at utility > level it is. > > Side note: a Weld or OWB release without experimental/alpha sounds worse > if the spec changes later. A compromise can be an extension doing it > already you can drop in any of these containers. > There seems to be a general misunderstanding about how the specs are intended to work. You standardize on things that as a group everyone has agreed would work in a specific way. Right now, the CDI EG is innovating and standardizing on those innovations instead of standardizing on the features already available in the various impls. Lets take a few examples of where impls deviate from the specs. - Bean Validation: Hibernate Validator has a suite of built in validations https://github.com/hibernate/hibernate-validator/tree/master/engine/src/main/java/org/hibernate/validator/constraints - these constraints can in theory work in any pluggable environment, but come with their core engine built in, for people to leverage. These are good targets to leverage in the core spec when its seen as being very useful. - JAX-RS : All of the implementations had client impls paired up with their 1.1 compliant releases, even though it wasn't required. Why? Because it made a ton of sense. Then see what happened afterwards, the EG came together and standardized on a Client API that took a lot of the great features in each impl and made them consistent. - EJB: Lets not forget that the removal of home/remote/local interfaces came from a combination of xdoclet and spring. The EG came together, saw that what was in use and figured out how to standardize on it once the language features were available. - Singleton EJBs: An extension of EJB 3, most vendors supported a form of singleton in their EJBs, and the EJB EG agreed upon it in addition to some concurrency issues that had to be addressed. - CDI: Lets not forget about the hard work people like strub have put into making CDI work well. Scoped Beans only? Awesome idea. https://github.com/apache/openwebbeans/commit/3b3640e17c88e7c095563337194ba23c6f9e1689 He didn't wait for the EG to standardize on anything before implementing. - JPA: Lets not forget that HIbernate supports in dual hierarchies the EntityManager and Session interfaces concurrently. Want to use HQL in your @NamedQuery? Sure, it works fine. Bottom line, we need to get these features out into the wild, let people play and come back with input on the various impls. There's nothing stopping the weld team from introducing org.jboss.weld.events.api.AsyncEvent that supports CompletableFuture and CompletionStage, allowing app developers to consume this via an injection point just like Event works today, @Inject AsyncEvent. Even if thats not the spec compliant way to do it long term, it makes it clear that you're using a provider specific API. In addition, there would be nothing stopping either team from introducing support for @Priority on observer methods. There's no API change, no spec change required. The spec doesn't mandate that it works, but there's nothing stopping your impl from allowing it. The spec doesn't say you absolutely cannot leverage it. John > > >> John >> >> >> On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman >> wrote: >> >>> How much end user feedback has there been on this? I have to be honest >>> that it surprises me to find this out now. >>> >>> This to me stands out as an obvious usability problem. CompletableFuture >>> is the obvious top level end user API, not CompletionStage. Not going with >>> CompletableFuture is very likely to confuse most people. The last thing we >>> need is more potential usability problems in Java EE APIs. >>> >>> On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau >>> wrote: >>> >>> Hi guys, >>> >>> as a user having a ComlpetionStage makes me loose some JDK utilities, >>> can we move back to CompletionFuture? >>> >>> It would allow for instance: >>> >>> // doesn't work with CompletionStage >>> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>> .then(...) >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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 at 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. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/1082af7b/attachment.html From reza_rahman at lycos.com Sun Mar 6 12:51:36 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 12:51:36 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: Personally I think this is overdue for standardization, it's just that it's a rather strange API choice I'd like to at least understand a bit better. What was the thinking behind this? > On Mar 6, 2016, at 12:24 PM, Romain Manni-Bucau wrote: > > > 2016-03-06 18:02 GMT+01:00 John D. Ament : >> What I think would be even better is to see this implemented in the impls (Weld & OWB) and see how users use it, in a release that's not plastered with Alpha or Experimental all over it. While I think we were all wary about it, we need real end user input from the impl standpoint to figure out what makes sense to standardize on. >> > > Or just do the opposite and *standardize* it. We can use Rx* feedbacks but it doesnt' match event case at all which is a real small subset of the reactive programming so I guess easiness should be what drives us there and integration at least with the JVM so CFuture version sounds more natural than CStage one. Difference is very small at method level but at utility level it is. > > Side note: a Weld or OWB release without experimental/alpha sounds worse if the spec changes later. A compromise can be an extension doing it already you can drop in any of these containers. > >> John >> >> >>> On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman wrote: >>> How much end user feedback has there been on this? I have to be honest that it surprises me to find this out now. >>> >>> This to me stands out as an obvious usability problem. CompletableFuture is the obvious top level end user API, not CompletionStage. Not going with CompletableFuture is very likely to confuse most people. The last thing we need is more potential usability problems in Java EE APIs. >>> >>>> On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau wrote: >>>> >>>> Hi guys, >>>> >>>> as a user having a ComlpetionStage makes me loose some JDK utilities, can we move back to CompletionFuture? >>>> >>>> It would allow for instance: >>>> >>>> // doesn't work with CompletionStage >>>> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>> .then(...) >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/3f537bc3/attachment-0001.html From reza_rahman at lycos.com Sun Mar 6 13:20:00 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 13:20:00 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> Message-ID: Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? > On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: > > does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? > > Idea is to give an API to make: > > public void complete() { > try { > asyncContext.complete(); > } finally { > auditContext.end(); > } > } > > working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). > > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2016-03-06 16:40 GMT+01:00 Reza Rahman : >> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >> >> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >> >>> Hi guys, >>> >>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>> >>> Sample: >>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>> >>> Bonus: >>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>> >>> Question: >>> Would CDI handle it in 2.0? >>> >>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/b6dbeacf/attachment.html From rmannibucau at gmail.com Sun Mar 6 13:30:20 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 6 Mar 2016 19:30:20 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> Message-ID: 2016-03-06 19:20 GMT+01:00 Reza Rahman : > Can you kindly try to make the example a bit simpler? It's important to > make the case for how likely this is supposed to occur in most business > applications. > > Also, other than making sure that the executor service is propagating > thread local request contexts correctly what other solution are you > proposing? Did you check the specification? How sure are you that this > isn't simply an implementation bug? > > As far as I know the executor service is supposed to be preserving all > relevant parts of the EE context? > > Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. > On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau > wrote: > > does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? > > Idea is to give an API to make: > > public void complete() { > try { > asyncContext.complete(); > } finally { > auditContext.end(); > } > } > > working without hacky and almost impossible context pushing (cause of > injections nature you are not supposed to know what to push in the context > when going async). > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-06 16:40 GMT+01:00 Reza Rahman : > >> Can you kindly share an annotated code example of the proposed solution >> so we can all follow and discuss this? >> >> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau >> wroteshar: >> >> Hi guys, >> >> spoke on concurrency utilities about the ability to inherit a cdi scope. >> Idea is to follow request scope more than cdi spec allows. First thought it >> was a concurrency utilities thing but Reza mentionned can be a CDI one so >> here it is. >> >> Sample: >> In a servlet i get MyBean which is @RequestScoped, I do some set on it. >> The i go async (AsyncContext) and trigger a task in another thread. It >> would be neat - and mandatory in some case by the loose coupling nature of >> CDI - to get the *same* MyBean *instance* in this thread. With a direct >> dependency you can easily use message passing pattern - but you loose the >> loose coupling cause you need to know until which level you unwrap, think t >> principal case which has 2-3 proxies!. However in practice you have a lot >> of undirect dependencies, in particular with enterprise concerns (auditing, >> security...) so you can't really do it easily/naturally. >> >> Bonus: >> One very verbose way is to be able to kind of push/pop an existing >> context in a thread - wrappers doing it on a Runnable/Consumer/Function/... >> would be neat. >> >> Question: >> Would CDI handle it in 2.0? >> >> Side note: this is really about the fact to reuse a "context context" >> (its current instances map) in another thread the more transparently >> possible and match the user vision more than a technical question for now. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/97c05a92/attachment-0001.html From john.d.ament at gmail.com Sun Mar 6 13:39:14 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 6 Mar 2016 13:39:14 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: I agree that it's a sorely missing feature. Jumping in to how to standardize it is how we got into this problem. From what I remember it was agreed to use the lowest entry point. On Mar 6, 2016 12:51, "Reza Rahman" wrote: > Personally I think this is overdue for standardization, it's just that > it's a rather strange API choice I'd like to at least understand a bit > better. What was the thinking behind this? > > On Mar 6, 2016, at 12:24 PM, Romain Manni-Bucau > wrote: > > > 2016-03-06 18:02 GMT+01:00 John D. Ament : > >> What I think would be even better is to see this implemented in the impls >> (Weld & OWB) and see how users use it, in a release that's not plastered >> with Alpha or Experimental all over it. While I think we were all wary >> about it, we need real end user input from the impl standpoint to figure >> out what makes sense to standardize on. >> >> > Or just do the opposite and *standardize* it. We can use Rx* feedbacks but > it doesnt' match event case at all which is a real small subset of the > reactive programming so I guess easiness should be what drives us there and > integration at least with the JVM so CFuture version sounds more natural > than CStage one. Difference is very small at method level but at utility > level it is. > > Side note: a Weld or OWB release without experimental/alpha sounds worse > if the spec changes later. A compromise can be an extension doing it > already you can drop in any of these containers. > > >> John >> >> >> On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman >> wrote: >> >>> How much end user feedback has there been on this? I have to be honest >>> that it surprises me to find this out now. >>> >>> This to me stands out as an obvious usability problem. CompletableFuture >>> is the obvious top level end user API, not CompletionStage. Not going with >>> CompletableFuture is very likely to confuse most people. The last thing we >>> need is more potential usability problems in Java EE APIs. >>> >>> On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau >>> wrote: >>> >>> Hi guys, >>> >>> as a user having a ComlpetionStage makes me loose some JDK utilities, >>> can we move back to CompletionFuture? >>> >>> It would allow for instance: >>> >>> // doesn't work with CompletionStage >>> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>> .then(...) >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/53446e31/attachment.html From reza_rahman at lycos.com Sun Mar 6 13:42:10 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 13:42:10 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> Message-ID: <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? > On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: > > 2016-03-06 19:20 GMT+01:00 Reza Rahman : >> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >> >> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >> >> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? > > Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. > >>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>> >>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>> >>> Idea is to give an API to make: >>> >>> public void complete() { >>> try { >>> asyncContext.complete(); >>> } finally { >>> auditContext.end(); >>> } >>> } >>> >>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>> >>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>> >>>>> Hi guys, >>>>> >>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>> >>>>> Sample: >>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>> >>>>> Bonus: >>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>> >>>>> Question: >>>>> Would CDI handle it in 2.0? >>>>> >>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/854705e5/attachment-0001.html From reza_rahman at lycos.com Sun Mar 6 13:48:34 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 13:48:34 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: <828C6074-AE7C-47A9-A0FE-62FF99F7873C@lycos.com> Using the lowest level API possible on principal seems to be the only justification that I can see. Almost by definition that's causing a usability hazard in this case. This is easily avoided by using the more likely familiar higher level API. It introduces no complexities for implementation or standardization. > On Mar 6, 2016, at 1:39 PM, John D. Ament wrote: > > I agree that it's a sorely missing feature. Jumping in to how to standardize it is how we got into this problem. From what I remember it was agreed to use the lowest entry point. > >> On Mar 6, 2016 12:51, "Reza Rahman" wrote: >> Personally I think this is overdue for standardization, it's just that it's a rather strange API choice I'd like to at least understand a bit better. What was the thinking behind this? >> >>> On Mar 6, 2016, at 12:24 PM, Romain Manni-Bucau wrote: >>> >>> >>> 2016-03-06 18:02 GMT+01:00 John D. Ament : >>>> What I think would be even better is to see this implemented in the impls (Weld & OWB) and see how users use it, in a release that's not plastered with Alpha or Experimental all over it. While I think we were all wary about it, we need real end user input from the impl standpoint to figure out what makes sense to standardize on. >>>> >>> >>> Or just do the opposite and *standardize* it. We can use Rx* feedbacks but it doesnt' match event case at all which is a real small subset of the reactive programming so I guess easiness should be what drives us there and integration at least with the JVM so CFuture version sounds more natural than CStage one. Difference is very small at method level but at utility level it is. >>> >>> Side note: a Weld or OWB release without experimental/alpha sounds worse if the spec changes later. A compromise can be an extension doing it already you can drop in any of these containers. >>> >>>> John >>>> >>>> >>>>> On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman wrote: >>>>> How much end user feedback has there been on this? I have to be honest that it surprises me to find this out now. >>>>> >>>>> This to me stands out as an obvious usability problem. CompletableFuture is the obvious top level end user API, not CompletionStage. Not going with CompletableFuture is very likely to confuse most people. The last thing we need is more potential usability problems in Java EE APIs. >>>>> >>>>>> On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau wrote: >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> as a user having a ComlpetionStage makes me loose some JDK utilities, can we move back to CompletionFuture? >>>>>> >>>>>> It would allow for instance: >>>>>> >>>>>> // doesn't work with CompletionStage >>>>>> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>>>> .then(...) >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/503e3b54/attachment.html From rmannibucau at gmail.com Sun Mar 6 14:15:58 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 6 Mar 2016 20:15:58 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: 2016-03-06 19:42 GMT+01:00 Reza Rahman : > This frankly surprises me. I'll check the specification text. This might > indeed just be an implementation bug. The EE concurrency utilities are > supposed to be copying all relevant context. If this is an issue than it > has to be that it is not copying enough of the HTTP request context for CDI > to work. > > The issue is not technical since I got it working but needed to reverse. >From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. > Surely the Red Hat folks can quickly shed some light here since they > implement essentially this whole stack? > > On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau > wrote: > > 2016-03-06 19:20 GMT+01:00 Reza Rahman : > >> Can you kindly try to make the example a bit simpler? It's important to >> make the case for how likely this is supposed to occur in most business >> applications. >> >> Also, other than making sure that the executor service is propagating >> thread local request contexts correctly what other solution are you >> proposing? Did you check the specification? How sure are you that this >> isn't simply an implementation bug? >> >> As far as I know the executor service is supposed to be preserving all >> relevant parts of the EE context? >> >> > Not in concurrency-utilities for EE at least. That was the first impl I > did then Mark pointed out it was violating CDI spec and request scope > definition. There is a kind of contracdiction there cause > concurrency-utilities doesn't integrate with CDI at all but we can also see > it the opposite way: CDI doesn't provide any way to propagate a context in > another thread. Both point of view are valid so we need to see where we > tackle it. > > >> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau >> wrote: >> >> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >> >> Idea is to give an API to make: >> >> public void complete() { >> try { >> asyncContext.complete(); >> } finally { >> auditContext.end(); >> } >> } >> >> working without hacky and almost impossible context pushing (cause of >> injections nature you are not supposed to know what to push in the context >> when going async). >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >> >>> Can you kindly share an annotated code example of the proposed solution >>> so we can all follow and discuss this? >>> >>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau >>> wroteshar: >>> >>> Hi guys, >>> >>> spoke on concurrency utilities about the ability to inherit a cdi scope. >>> Idea is to follow request scope more than cdi spec allows. First thought it >>> was a concurrency utilities thing but Reza mentionned can be a CDI one so >>> here it is. >>> >>> Sample: >>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. >>> The i go async (AsyncContext) and trigger a task in another thread. It >>> would be neat - and mandatory in some case by the loose coupling nature of >>> CDI - to get the *same* MyBean *instance* in this thread. With a direct >>> dependency you can easily use message passing pattern - but you loose the >>> loose coupling cause you need to know until which level you unwrap, think t >>> principal case which has 2-3 proxies!. However in practice you have a lot >>> of undirect dependencies, in particular with enterprise concerns (auditing, >>> security...) so you can't really do it easily/naturally. >>> >>> Bonus: >>> One very verbose way is to be able to kind of push/pop an existing >>> context in a thread - wrappers doing it on a Runnable/Consumer/Function/... >>> would be neat. >>> >>> Question: >>> Would CDI handle it in 2.0? >>> >>> Side note: this is really about the fact to reuse a "context context" >>> (its current instances map) in another thread the more transparently >>> possible and match the user vision more than a technical question for now. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/2f81cea4/attachment-0001.html From reza_rahman at lycos.com Sun Mar 6 14:25:54 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 14:25:54 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. > On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: > > > 2016-03-06 19:42 GMT+01:00 Reza Rahman : >> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >> > > The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. > >> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >> >>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>> >>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>> >>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>> >>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>> >>> >>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>> >>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>> >>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>> >>>>> Idea is to give an API to make: >>>>> >>>>> public void complete() { >>>>> try { >>>>> asyncContext.complete(); >>>>> } finally { >>>>> auditContext.end(); >>>>> } >>>>> } >>>>> >>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>> >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>> >>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>> >>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>> >>>>>>> Sample: >>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>> >>>>>>> Bonus: >>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>> >>>>>>> Question: >>>>>>> Would CDI handle it in 2.0? >>>>>>> >>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/c0290db3/attachment.html From rmannibucau at gmail.com Sun Mar 6 14:36:59 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 6 Mar 2016 20:36:59 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: 2016-03-06 20:25 GMT+01:00 Reza Rahman : > Let's see. I suspect the specification text for EE concurrency is generic > enough for implementations to also be able to cover CDI scopes or any other > Java EE API context propagation needs. This means the issue needs to be > solved at the individual implementation level. Changing anything in the > spec is probably just unnecessary ceremony in this case. > > Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread ( http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). > On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau > wrote: > > > 2016-03-06 19:42 GMT+01:00 Reza Rahman : > >> This frankly surprises me. I'll check the specification text. This might >> indeed just be an implementation bug. The EE concurrency utilities are >> supposed to be copying all relevant context. If this is an issue than it >> has to be that it is not copying enough of the HTTP request context for CDI >> to work. >> >> > The issue is not technical since I got it working but needed to reverse. > From my understanding ee concurrency utilities was done in a time CDI was > not there so it just ignored it somehow and it hasnt been updated when > integrated to the spec. Now with the wording of the CDI - and TCK - it is > impossible to make it working since request scope is bound the thre request > thread - and not the request. Side note: same applies to session scope and > conversation. > > >> Surely the Red Hat folks can quickly shed some light here since they >> implement essentially this whole stack? >> >> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau >> wrote: >> >> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >> >>> Can you kindly try to make the example a bit simpler? It's important to >>> make the case for how likely this is supposed to occur in most business >>> applications. >>> >>> Also, other than making sure that the executor service is propagating >>> thread local request contexts correctly what other solution are you >>> proposing? Did you check the specification? How sure are you that this >>> isn't simply an implementation bug? >>> >>> As far as I know the executor service is supposed to be preserving all >>> relevant parts of the EE context? >>> >>> >> Not in concurrency-utilities for EE at least. That was the first impl I >> did then Mark pointed out it was violating CDI spec and request scope >> definition. There is a kind of contracdiction there cause >> concurrency-utilities doesn't integrate with CDI at all but we can also see >> it the opposite way: CDI doesn't provide any way to propagate a context in >> another thread. Both point of view are valid so we need to see where we >> tackle it. >> >> >>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau >>> wrote: >>> >>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>> >>> Idea is to give an API to make: >>> >>> public void complete() { >>> try { >>> asyncContext.complete(); >>> } finally { >>> auditContext.end(); >>> } >>> } >>> >>> working without hacky and almost impossible context pushing (cause of >>> injections nature you are not supposed to know what to push in the context >>> when going async). >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>> >>>> Can you kindly share an annotated code example of the proposed solution >>>> so we can all follow and discuss this? >>>> >>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau >>>> wroteshar: >>>> >>>> Hi guys, >>>> >>>> spoke on concurrency utilities about the ability to inherit a cdi >>>> scope. Idea is to follow request scope more than cdi spec allows. First >>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>> CDI one so here it is. >>>> >>>> Sample: >>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. >>>> The i go async (AsyncContext) and trigger a task in another thread. It >>>> would be neat - and mandatory in some case by the loose coupling nature of >>>> CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>> dependency you can easily use message passing pattern - but you loose the >>>> loose coupling cause you need to know until which level you unwrap, think t >>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>> security...) so you can't really do it easily/naturally. >>>> >>>> Bonus: >>>> One very verbose way is to be able to kind of push/pop an existing >>>> context in a thread - wrappers doing it on a Runnable/Consumer/Function/... >>>> would be neat. >>>> >>>> Question: >>>> Would CDI handle it in 2.0? >>>> >>>> Side note: this is really about the fact to reuse a "context context" >>>> (its current instances map) in another thread the more transparently >>>> possible and match the user vision more than a technical question for now. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/7c116348/attachment-0001.html From john.d.ament at gmail.com Sun Mar 6 14:45:15 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 06 Mar 2016 19:45:15 +0000 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. This is another requested feature, but looks more like a bug or gap in the spec. John On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: > 2016-03-06 20:25 GMT+01:00 Reza Rahman : > >> Let's see. I suspect the specification text for EE concurrency is generic >> enough for implementations to also be able to cover CDI scopes or any other >> Java EE API context propagation needs. This means the issue needs to be >> solved at the individual implementation level. Changing anything in the >> spec is probably just unnecessary ceremony in this case. >> >> > Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI > still prevent it to work since it would violate the spec to propagate it > while request scope is bound to another thread ( > http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles > async listener but not the main AsyncContext part). > > >> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau >> wrote: >> >> >> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >> >>> This frankly surprises me. I'll check the specification text. This might >>> indeed just be an implementation bug. The EE concurrency utilities are >>> supposed to be copying all relevant context. If this is an issue than it >>> has to be that it is not copying enough of the HTTP request context for CDI >>> to work. >>> >>> >> The issue is not technical since I got it working but needed to reverse. >> From my understanding ee concurrency utilities was done in a time CDI was >> not there so it just ignored it somehow and it hasnt been updated when >> integrated to the spec. Now with the wording of the CDI - and TCK - it is >> impossible to make it working since request scope is bound the thre request >> thread - and not the request. Side note: same applies to session scope and >> conversation. >> >> >>> Surely the Red Hat folks can quickly shed some light here since they >>> implement essentially this whole stack? >>> >>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau >>> wrote: >>> >>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>> >>>> Can you kindly try to make the example a bit simpler? It's important to >>>> make the case for how likely this is supposed to occur in most business >>>> applications. >>>> >>>> Also, other than making sure that the executor service is propagating >>>> thread local request contexts correctly what other solution are you >>>> proposing? Did you check the specification? How sure are you that this >>>> isn't simply an implementation bug? >>>> >>>> As far as I know the executor service is supposed to be preserving all >>>> relevant parts of the EE context? >>>> >>>> >>> Not in concurrency-utilities for EE at least. That was the first impl I >>> did then Mark pointed out it was violating CDI spec and request scope >>> definition. There is a kind of contracdiction there cause >>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>> it the opposite way: CDI doesn't provide any way to propagate a context in >>> another thread. Both point of view are valid so we need to see where we >>> tackle it. >>> >>> >>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau >>>> wrote: >>>> >>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>> >>>> Idea is to give an API to make: >>>> >>>> public void complete() { >>>> try { >>>> asyncContext.complete(); >>>> } finally { >>>> auditContext.end(); >>>> } >>>> } >>>> >>>> working without hacky and almost impossible context pushing (cause of >>>> injections nature you are not supposed to know what to push in the context >>>> when going async). >>>> >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>> >>>>> Can you kindly share an annotated code example of the proposed >>>>> solution so we can all follow and discuss this? >>>>> >>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau >>>>> wroteshar: >>>>> >>>>> Hi guys, >>>>> >>>>> spoke on concurrency utilities about the ability to inherit a cdi >>>>> scope. Idea is to follow request scope more than cdi spec allows. First >>>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>>> CDI one so here it is. >>>>> >>>>> Sample: >>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on >>>>> it. The i go async (AsyncContext) and trigger a task in another thread. It >>>>> would be neat - and mandatory in some case by the loose coupling nature of >>>>> CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>>> dependency you can easily use message passing pattern - but you loose the >>>>> loose coupling cause you need to know until which level you unwrap, think t >>>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>>> security...) so you can't really do it easily/naturally. >>>>> >>>>> Bonus: >>>>> One very verbose way is to be able to kind of push/pop an existing >>>>> context in a thread - wrappers doing it on a Runnable/Consumer/Function/... >>>>> would be neat. >>>>> >>>>> Question: >>>>> Would CDI handle it in 2.0? >>>>> >>>>> Side note: this is really about the fact to reuse a "context context" >>>>> (its current instances map) in another thread the more transparently >>>>> possible and match the user vision more than a technical question for now. >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog >>>>> | Github >>>>> | LinkedIn >>>>> | Tomitriber >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/b6cb3430/attachment-0001.html From stephan at knitelius.com Sun Mar 6 14:45:24 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Sun, 06 Mar 2016 19:45:24 +0000 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: So what's stopping us from allowing request scope propagation? Alternatively we could introduce a new scope sharing state for all asynchronous threads that where spawned within a request, @AsynchronousScoped? Thereby request scope could remain bound to the thread. On So., 6. M?rz 2016 at 20:26, Reza Rahman wrote: > Let's see. I suspect the specification text for EE concurrency is generic > enough for implementations to also be able to cover CDI scopes or any other > Java EE API context propagation needs. This means the issue needs to be > solved at the individual implementation level. Changing anything in the > spec is probably just unnecessary ceremony in this case. > > On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau > wrote: > > > 2016-03-06 19:42 GMT+01:00 Reza Rahman : > >> This frankly surprises me. I'll check the specification text. This might >> indeed just be an implementation bug. The EE concurrency utilities are >> supposed to be copying all relevant context. If this is an issue than it >> has to be that it is not copying enough of the HTTP request context for CDI >> to work. >> >> > The issue is not technical since I got it working but needed to reverse. > From my understanding ee concurrency utilities was done in a time CDI was > not there so it just ignored it somehow and it hasnt been updated when > integrated to the spec. Now with the wording of the CDI - and TCK - it is > impossible to make it working since request scope is bound the thre request > thread - and not the request. Side note: same applies to session scope and > conversation. > > >> Surely the Red Hat folks can quickly shed some light here since they >> implement essentially this whole stack? >> >> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau >> wrote: >> >> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >> >>> Can you kindly try to make the example a bit simpler? It's important to >>> make the case for how likely this is supposed to occur in most business >>> applications. >>> >>> Also, other than making sure that the executor service is propagating >>> thread local request contexts correctly what other solution are you >>> proposing? Did you check the specification? How sure are you that this >>> isn't simply an implementation bug? >>> >>> As far as I know the executor service is supposed to be preserving all >>> relevant parts of the EE context? >>> >>> >> Not in concurrency-utilities for EE at least. That was the first impl I >> did then Mark pointed out it was violating CDI spec and request scope >> definition. There is a kind of contracdiction there cause >> concurrency-utilities doesn't integrate with CDI at all but we can also see >> it the opposite way: CDI doesn't provide any way to propagate a context in >> another thread. Both point of view are valid so we need to see where we >> tackle it. >> >> >>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau >>> wrote: >>> >>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>> >>> Idea is to give an API to make: >>> >>> public void complete() { >>> try { >>> asyncContext.complete(); >>> } finally { >>> auditContext.end(); >>> } >>> } >>> >>> working without hacky and almost impossible context pushing (cause of >>> injections nature you are not supposed to know what to push in the context >>> when going async). >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>> >>>> Can you kindly share an annotated code example of the proposed solution >>>> so we can all follow and discuss this? >>>> >>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau >>>> wroteshar: >>>> >>>> Hi guys, >>>> >>>> spoke on concurrency utilities about the ability to inherit a cdi >>>> scope. Idea is to follow request scope more than cdi spec allows. First >>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>> CDI one so here it is. >>>> >>>> Sample: >>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. >>>> The i go async (AsyncContext) and trigger a task in another thread. It >>>> would be neat - and mandatory in some case by the loose coupling nature of >>>> CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>> dependency you can easily use message passing pattern - but you loose the >>>> loose coupling cause you need to know until which level you unwrap, think t >>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>> security...) so you can't really do it easily/naturally. >>>> >>>> Bonus: >>>> One very verbose way is to be able to kind of push/pop an existing >>>> context in a thread - wrappers doing it on a Runnable/Consumer/Function/... >>>> would be neat. >>>> >>>> Question: >>>> Would CDI handle it in 2.0? >>>> >>>> Side note: this is really about the fact to reuse a "context context" >>>> (its current instances map) in another thread the more transparently >>>> possible and match the user vision more than a technical question for now. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/d3c49db3/attachment.html From john.d.ament at gmail.com Sun Mar 6 14:55:03 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 06 Mar 2016 19:55:03 +0000 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <828C6074-AE7C-47A9-A0FE-62FF99F7873C@lycos.com> References: <828C6074-AE7C-47A9-A0FE-62FF99F7873C@lycos.com> Message-ID: On the flip side, it seems like CompletionStage isn't quite a complete API, and if external callers can only leverage a specific impl then its more of a case where the interface does not enough. John On Sun, Mar 6, 2016 at 1:48 PM Reza Rahman wrote: > Using the lowest level API possible on principal seems to be the only > justification that I can see. Almost by definition that's causing a > usability hazard in this case. This is easily avoided by using the more > likely familiar higher level API. It introduces no complexities for > implementation or standardization. > > On Mar 6, 2016, at 1:39 PM, John D. Ament wrote: > > I agree that it's a sorely missing feature. Jumping in to how to > standardize it is how we got into this problem. From what I remember it > was agreed to use the lowest entry point. > On Mar 6, 2016 12:51, "Reza Rahman" wrote: > >> Personally I think this is overdue for standardization, it's just that >> it's a rather strange API choice I'd like to at least understand a bit >> better. What was the thinking behind this? >> >> On Mar 6, 2016, at 12:24 PM, Romain Manni-Bucau >> wrote: >> >> >> 2016-03-06 18:02 GMT+01:00 John D. Ament : >> >>> What I think would be even better is to see this implemented in the >>> impls (Weld & OWB) and see how users use it, in a release that's not >>> plastered with Alpha or Experimental all over it. While I think we were >>> all wary about it, we need real end user input from the impl standpoint to >>> figure out what makes sense to standardize on. >>> >>> >> Or just do the opposite and *standardize* it. We can use Rx* feedbacks >> but it doesnt' match event case at all which is a real small subset of the >> reactive programming so I guess easiness should be what drives us there and >> integration at least with the JVM so CFuture version sounds more natural >> than CStage one. Difference is very small at method level but at utility >> level it is. >> >> Side note: a Weld or OWB release without experimental/alpha sounds worse >> if the spec changes later. A compromise can be an extension doing it >> already you can drop in any of these containers. >> >> >>> John >>> >>> >>> On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman >>> wrote: >>> >>>> How much end user feedback has there been on this? I have to be honest >>>> that it surprises me to find this out now. >>>> >>>> This to me stands out as an obvious usability problem. >>>> CompletableFuture is the obvious top level end user API, not >>>> CompletionStage. Not going with CompletableFuture is very likely to confuse >>>> most people. The last thing we need is more potential usability problems in >>>> Java EE APIs. >>>> >>>> On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau >>>> wrote: >>>> >>>> Hi guys, >>>> >>>> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>> can we move back to CompletionFuture? >>>> >>>> It would allow for instance: >>>> >>>> // doesn't work with CompletionStage >>>> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>> .then(...) >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/a529b1a4/attachment-0001.html From reza_rahman at lycos.com Sun Mar 6 14:59:26 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 14:59:26 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. > On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: > > The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. > > I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. > > This is another requested feature, but looks more like a bug or gap in the spec. > > John > >> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>> >> >> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >> >>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>> >>>> >>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>> >>>> >>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>> >>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>> >>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>> >>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>> >>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>> >>>>>> >>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>> >>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>> >>>>>>>> Idea is to give an API to make: >>>>>>>> >>>>>>>> public void complete() { >>>>>>>> try { >>>>>>>> asyncContext.complete(); >>>>>>>> } finally { >>>>>>>> auditContext.end(); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>> >>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>> >>>>>>>>>> Sample: >>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>> >>>>>>>>>> Bonus: >>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>> >>>>>>>>>> Question: >>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>> >>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>> _______________________________________________ >>>>>>>>>> cdi-dev mailing list >>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/f20e5458/attachment-0001.html From rmannibucau at gmail.com Sun Mar 6 15:06:59 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 6 Mar 2016 21:06:59 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: 2016-03-06 20:59 GMT+01:00 Reza Rahman : > As far as I know this is precisely the sort of thing that the EE > concurrency spec is intended for. It is supposed to copy over everything > from the underlying thread local context into the new thread for all EE > managed components to function. Since CDI beans are also EE container > managed, it also applies to CDI beans as well. The EE vendor is supposed to > make sure this works properly. > > I don't think the concurrency utilities specifically lists APIs for which > thread context propagation should work. If this doesn't work in a specific > implementation it's most likely because they didn't take CDI into account > in their own EE concurrency implementation. > > That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). > On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: > > The section of the spec you link to makes no references to threads. 6.3 > makes some notes about normal scopes and threads, and specifically says > that a context is bound to one or more threads. > > I think what's happened is that over the years, people have simply bound > HTTP Request == single thread, but when async processing was introduced no > one thought to clarify that the spawning of a child thread from the > original HTTP request retains the parent's context. > > This is another requested feature, but looks more like a bug or gap in the > spec. > > John > > On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau > wrote: > >> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >> >>> Let's see. I suspect the specification text for EE concurrency is >>> generic enough for implementations to also be able to cover CDI scopes or >>> any other Java EE API context propagation needs. This means the issue needs >>> to be solved at the individual implementation level. Changing anything in >>> the spec is probably just unnecessary ceremony in this case. >>> >>> >> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI >> still prevent it to work since it would violate the spec to propagate it >> while request scope is bound to another thread ( >> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles >> async listener but not the main AsyncContext part). >> >> >>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau >>> wrote: >>> >>> >>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>> >>>> This frankly surprises me. I'll check the specification text. This >>>> might indeed just be an implementation bug. The EE concurrency utilities >>>> are supposed to be copying all relevant context. If this is an issue than >>>> it has to be that it is not copying enough of the HTTP request context for >>>> CDI to work. >>>> >>>> >>> The issue is not technical since I got it working but needed to reverse. >>> From my understanding ee concurrency utilities was done in a time CDI was >>> not there so it just ignored it somehow and it hasnt been updated when >>> integrated to the spec. Now with the wording of the CDI - and TCK - it is >>> impossible to make it working since request scope is bound the thre request >>> thread - and not the request. Side note: same applies to session scope and >>> conversation. >>> >>> >>>> Surely the Red Hat folks can quickly shed some light here since they >>>> implement essentially this whole stack? >>>> >>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau >>>> wrote: >>>> >>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>> >>>>> Can you kindly try to make the example a bit simpler? It's important >>>>> to make the case for how likely this is supposed to occur in most business >>>>> applications. >>>>> >>>>> Also, other than making sure that the executor service is propagating >>>>> thread local request contexts correctly what other solution are you >>>>> proposing? Did you check the specification? How sure are you that this >>>>> isn't simply an implementation bug? >>>>> >>>>> As far as I know the executor service is supposed to be preserving all >>>>> relevant parts of the EE context? >>>>> >>>>> >>>> Not in concurrency-utilities for EE at least. That was the first impl I >>>> did then Mark pointed out it was violating CDI spec and request scope >>>> definition. There is a kind of contracdiction there cause >>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>> another thread. Both point of view are valid so we need to see where we >>>> tackle it. >>>> >>>> >>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau >>>>> wrote: >>>>> >>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>> >>>>> Idea is to give an API to make: >>>>> >>>>> public void complete() { >>>>> try { >>>>> asyncContext.complete(); >>>>> } finally { >>>>> auditContext.end(); >>>>> } >>>>> } >>>>> >>>>> working without hacky and almost impossible context pushing (cause of >>>>> injections nature you are not supposed to know what to push in the context >>>>> when going async). >>>>> >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog >>>>> | Github >>>>> | LinkedIn >>>>> | Tomitriber >>>>> >>>>> >>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>> >>>>>> Can you kindly share an annotated code example of the proposed >>>>>> solution so we can all follow and discuss this? >>>>>> >>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau >>>>>> wroteshar: >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> spoke on concurrency utilities about the ability to inherit a cdi >>>>>> scope. Idea is to follow request scope more than cdi spec allows. First >>>>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>>>> CDI one so here it is. >>>>>> >>>>>> Sample: >>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on >>>>>> it. The i go async (AsyncContext) and trigger a task in another thread. It >>>>>> would be neat - and mandatory in some case by the loose coupling nature of >>>>>> CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>>>> dependency you can easily use message passing pattern - but you loose the >>>>>> loose coupling cause you need to know until which level you unwrap, think t >>>>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>>>> security...) so you can't really do it easily/naturally. >>>>>> >>>>>> Bonus: >>>>>> One very verbose way is to be able to kind of push/pop an existing >>>>>> context in a thread - wrappers doing it on a Runnable/Consumer/Function/... >>>>>> would be neat. >>>>>> >>>>>> Question: >>>>>> Would CDI handle it in 2.0? >>>>>> >>>>>> Side note: this is really about the fact to reuse a "context context" >>>>>> (its current instances map) in another thread the more transparently >>>>>> possible and match the user vision more than a technical question for now. >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog >>>>>> | Github >>>>>> | LinkedIn >>>>>> | Tomitriber >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/99a1122f/attachment-0001.html From reza_rahman at lycos.com Sun Mar 6 15:30:30 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 15:30:30 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. > On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: > > > 2016-03-06 20:59 GMT+01:00 Reza Rahman : >> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >> >> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. > > That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). > >>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>> >>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>> >>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>> >>> This is another requested feature, but looks more like a bug or gap in the spec. >>> >>> John >>> >>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>> >>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>> >>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>> >>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>> >>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>> >>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>> >>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>> >>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>> >>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>> >>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>> >>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>> >>>>>>>>>> Idea is to give an API to make: >>>>>>>>>> >>>>>>>>>> public void complete() { >>>>>>>>>> try { >>>>>>>>>> asyncContext.complete(); >>>>>>>>>> } finally { >>>>>>>>>> auditContext.end(); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>> >>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>> >>>>>>>>>>>> Hi guys, >>>>>>>>>>>> >>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>> >>>>>>>>>>>> Sample: >>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>> >>>>>>>>>>>> Bonus: >>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>> >>>>>>>>>>>> Question: >>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>> >>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/7b24ce17/attachment-0001.html From john.d.ament at gmail.com Sun Mar 6 16:23:35 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 06 Mar 2016 21:23:35 +0000 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: Reza, I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html If that's the case, then basically this should work OOTB right? Task task = new MyTask(); task = contextService.createContextualProxy(task, Task.class); executor.submit(task); // now magically the context should be prop'd? Is that about right? John On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: > Have you actually looked at the EE concurrency spec text in detail? What > does it say about managed component context propagation? > > Without actually doing that further discussing this is just taking shots > in the dark. As an implementer it should not surprise you that this might > simply be a bug because the person implementing the concurrency utilities > for the EE runtime was not told about what to copy over into the new thread > for CDI to work correctly. > > On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau > wrote: > > > 2016-03-06 20:59 GMT+01:00 Reza Rahman : > >> As far as I know this is precisely the sort of thing that the EE >> concurrency spec is intended for. It is supposed to copy over everything >> from the underlying thread local context into the new thread for all EE >> managed components to function. Since CDI beans are also EE container >> managed, it also applies to CDI beans as well. The EE vendor is supposed to >> make sure this works properly. >> >> I don't think the concurrency utilities specifically lists APIs for which >> thread context propagation should work. If this doesn't work in a specific >> implementation it's most likely because they didn't take CDI into account >> in their own EE concurrency implementation. >> >> > That's what I wanted/would like. CDI TCK breaks it quite easily and > @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly > named. So to solve it we would need another scope as I mentionned several > times on this list 100% matching servlet instances lifecycles (on a pure > CDI side we have the same issue for sessions which are recycled during a > request, the session scope is corrupted *by spec* in term of user behavior). > > >> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >> >> The section of the spec you link to makes no references to threads. 6.3 >> makes some notes about normal scopes and threads, and specifically says >> that a context is bound to one or more threads. >> >> I think what's happened is that over the years, people have simply bound >> HTTP Request == single thread, but when async processing was introduced no >> one thought to clarify that the spawning of a child thread from the >> original HTTP request retains the parent's context. >> >> This is another requested feature, but looks more like a bug or gap in >> the spec. >> >> John >> >> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau >> wrote: >> >>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>> >>>> Let's see. I suspect the specification text for EE concurrency is >>>> generic enough for implementations to also be able to cover CDI scopes or >>>> any other Java EE API context propagation needs. This means the issue needs >>>> to be solved at the individual implementation level. Changing anything in >>>> the spec is probably just unnecessary ceremony in this case. >>>> >>>> >>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI >>> still prevent it to work since it would violate the spec to propagate it >>> while request scope is bound to another thread ( >>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>> handles async listener but not the main AsyncContext part). >>> >>> >>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau >>>> wrote: >>>> >>>> >>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>> >>>>> This frankly surprises me. I'll check the specification text. This >>>>> might indeed just be an implementation bug. The EE concurrency utilities >>>>> are supposed to be copying all relevant context. If this is an issue than >>>>> it has to be that it is not copying enough of the HTTP request context for >>>>> CDI to work. >>>>> >>>>> >>>> The issue is not technical since I got it working but needed to >>>> reverse. From my understanding ee concurrency utilities was done in a time >>>> CDI was not there so it just ignored it somehow and it hasnt been updated >>>> when integrated to the spec. Now with the wording of the CDI - and TCK - it >>>> is impossible to make it working since request scope is bound the thre >>>> request thread - and not the request. Side note: same applies to session >>>> scope and conversation. >>>> >>>> >>>>> Surely the Red Hat folks can quickly shed some light here since they >>>>> implement essentially this whole stack? >>>>> >>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau >>>>> wrote: >>>>> >>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>> >>>>>> Can you kindly try to make the example a bit simpler? It's important >>>>>> to make the case for how likely this is supposed to occur in most business >>>>>> applications. >>>>>> >>>>>> Also, other than making sure that the executor service is propagating >>>>>> thread local request contexts correctly what other solution are you >>>>>> proposing? Did you check the specification? How sure are you that this >>>>>> isn't simply an implementation bug? >>>>>> >>>>>> As far as I know the executor service is supposed to be preserving >>>>>> all relevant parts of the EE context? >>>>>> >>>>>> >>>>> Not in concurrency-utilities for EE at least. That was the first impl >>>>> I did then Mark pointed out it was violating CDI spec and request scope >>>>> definition. There is a kind of contracdiction there cause >>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>> another thread. Both point of view are valid so we need to see where we >>>>> tackle it. >>>>> >>>>> >>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wrote: >>>>>> >>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>> >>>>>> Idea is to give an API to make: >>>>>> >>>>>> public void complete() { >>>>>> try { >>>>>> asyncContext.complete(); >>>>>> } finally { >>>>>> auditContext.end(); >>>>>> } >>>>>> } >>>>>> >>>>>> working without hacky and almost impossible context pushing (cause of >>>>>> injections nature you are not supposed to know what to push in the context >>>>>> when going async). >>>>>> >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog >>>>>> | Github >>>>>> | LinkedIn >>>>>> | Tomitriber >>>>>> >>>>>> >>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>> >>>>>>> Can you kindly share an annotated code example of the proposed >>>>>>> solution so we can all follow and discuss this? >>>>>>> >>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> spoke on concurrency utilities about the ability to inherit a cdi >>>>>>> scope. Idea is to follow request scope more than cdi spec allows. First >>>>>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>>>>> CDI one so here it is. >>>>>>> >>>>>>> Sample: >>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on >>>>>>> it. The i go async (AsyncContext) and trigger a task in another thread. It >>>>>>> would be neat - and mandatory in some case by the loose coupling nature of >>>>>>> CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>>>>> dependency you can easily use message passing pattern - but you loose the >>>>>>> loose coupling cause you need to know until which level you unwrap, think t >>>>>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>>>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>>>>> security...) so you can't really do it easily/naturally. >>>>>>> >>>>>>> Bonus: >>>>>>> One very verbose way is to be able to kind of push/pop an existing >>>>>>> context in a thread - wrappers doing it on a Runnable/Consumer/Function/... >>>>>>> would be neat. >>>>>>> >>>>>>> Question: >>>>>>> Would CDI handle it in 2.0? >>>>>>> >>>>>>> Side note: this is really about the fact to reuse a "context >>>>>>> context" (its current instances map) in another thread the more >>>>>>> transparently possible and match the user vision more than a technical >>>>>>> question for now. >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau | Blog >>>>>>> | Github >>>>>>> | LinkedIn >>>>>>> | Tomitriber >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/79a34729/attachment-0001.html From reza_rahman at lycos.com Sun Mar 6 16:50:26 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 16:50:26 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. > On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: > > Reza, > > I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. > > I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html > > If that's the case, then basically this should work OOTB right? > > Task task = new MyTask(); > task = contextService.createContextualProxy(task, Task.class); > executor.submit(task); > > // now magically the context should be prop'd? > > Is that about right? > > John > >> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >> >> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >> >>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>> >>> >>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>> >>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>> >>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>> >>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>> >>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>> >>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>> >>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>> >>>>> John >>>>> >>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>> >>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>> >>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>> >>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>> >>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>>>> >>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>> >>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>> >>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>>>>>> try { >>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>>> } finally { >>>>>>>>>>>> auditContext.end(); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>>>> >>>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>> >>>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sample: >>>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bonus: >>>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Question: >>>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/4bc7985a/attachment-0001.html From john.d.ament at gmail.com Sun Mar 6 17:03:22 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 06 Mar 2016 22:03:22 +0000 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> Message-ID: I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. John On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: > I am re-reading the spec end to end again right now. So far it seems I > have remembered everything correctly. > > You should read over section 2.3. What it is saying is that a container > implementing the Java EE concurrency utilities should ensure whatever > contextual information is needed for managed components to work correctly > should be propagated automatically. For the correct implementation of CDI > scopes, this should also mean any currently active scopes. The section you > are referring to is basically implying that thinking that it is possible to > use these scoped beans in tasks (albeit not reliably since beans could go > out of scope before the thread finishes - for example if the request ends). > > This does not have anything to do with the context service per se. The > context service is an SPI of sorts to allow end user developers to do for > their own applications what the container does behind the scenes for > managed component context propagation. > > I'll read over the entire spec to see if there is anything to contradict > this. If that's not the case what Romain is describing is most likely an > implementation specific bug that did not take into account CDI scope > propagation. > > On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: > > Reza, > > I read through the concurrency utils spec. Was there a specific section > you had in mind? The only references to CDI were near the beginning > warning users to not use Request/Session scoped beans as tasks since the > outer most context may be destroyed before the work is done. > > I have a feeling what you're referring to is the context service: > http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html > > If that's the case, then basically this should work OOTB right? > > Task task = new MyTask(); > task = contextService.createContextualProxy(task, Task.class); > executor.submit(task); > > // now magically the context should be prop'd? > > Is that about right? > > John > > On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: > >> Have you actually looked at the EE concurrency spec text in detail? What >> does it say about managed component context propagation? >> >> Without actually doing that further discussing this is just taking shots >> in the dark. As an implementer it should not surprise you that this might >> simply be a bug because the person implementing the concurrency utilities >> for the EE runtime was not told about what to copy over into the new thread >> for CDI to work correctly. >> >> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau >> wrote: >> >> >> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >> >>> As far as I know this is precisely the sort of thing that the EE >>> concurrency spec is intended for. It is supposed to copy over everything >>> from the underlying thread local context into the new thread for all EE >>> managed components to function. Since CDI beans are also EE container >>> managed, it also applies to CDI beans as well. The EE vendor is supposed to >>> make sure this works properly. >>> >>> I don't think the concurrency utilities specifically lists APIs for >>> which thread context propagation should work. If this doesn't work in a >>> specific implementation it's most likely because they didn't take CDI into >>> account in their own EE concurrency implementation. >>> >>> >> That's what I wanted/would like. CDI TCK breaks it quite easily and >> @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly >> named. So to solve it we would need another scope as I mentionned several >> times on this list 100% matching servlet instances lifecycles (on a pure >> CDI side we have the same issue for sessions which are recycled during a >> request, the session scope is corrupted *by spec* in term of user behavior). >> >> >>> On Mar 6, 2016, at 2:45 PM, John D. Ament >>> wrote: >>> >>> The section of the spec you link to makes no references to threads. 6.3 >>> makes some notes about normal scopes and threads, and specifically says >>> that a context is bound to one or more threads. >>> >>> I think what's happened is that over the years, people have simply bound >>> HTTP Request == single thread, but when async processing was introduced no >>> one thought to clarify that the spawning of a child thread from the >>> original HTTP request retains the parent's context. >>> >>> This is another requested feature, but looks more like a bug or gap in >>> the spec. >>> >>> John >>> >>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau >>> wrote: >>> >>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>> >>>>> Let's see. I suspect the specification text for EE concurrency is >>>>> generic enough for implementations to also be able to cover CDI scopes or >>>>> any other Java EE API context propagation needs. This means the issue needs >>>>> to be solved at the individual implementation level. Changing anything in >>>>> the spec is probably just unnecessary ceremony in this case. >>>>> >>>>> >>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI >>>> still prevent it to work since it would violate the spec to propagate it >>>> while request scope is bound to another thread ( >>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>> handles async listener but not the main AsyncContext part). >>>> >>>> >>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau >>>>> wrote: >>>>> >>>>> >>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>> >>>>>> This frankly surprises me. I'll check the specification text. This >>>>>> might indeed just be an implementation bug. The EE concurrency utilities >>>>>> are supposed to be copying all relevant context. If this is an issue than >>>>>> it has to be that it is not copying enough of the HTTP request context for >>>>>> CDI to work. >>>>>> >>>>>> >>>>> The issue is not technical since I got it working but needed to >>>>> reverse. From my understanding ee concurrency utilities was done in a time >>>>> CDI was not there so it just ignored it somehow and it hasnt been updated >>>>> when integrated to the spec. Now with the wording of the CDI - and TCK - it >>>>> is impossible to make it working since request scope is bound the thre >>>>> request thread - and not the request. Side note: same applies to session >>>>> scope and conversation. >>>>> >>>>> >>>>>> Surely the Red Hat folks can quickly shed some light here since they >>>>>> implement essentially this whole stack? >>>>>> >>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau >>>>>> wrote: >>>>>> >>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>> >>>>>>> Can you kindly try to make the example a bit simpler? It's important >>>>>>> to make the case for how likely this is supposed to occur in most business >>>>>>> applications. >>>>>>> >>>>>>> Also, other than making sure that the executor service is >>>>>>> propagating thread local request contexts correctly what other solution are >>>>>>> you proposing? Did you check the specification? How sure are you that this >>>>>>> isn't simply an implementation bug? >>>>>>> >>>>>>> As far as I know the executor service is supposed to be preserving >>>>>>> all relevant parts of the EE context? >>>>>>> >>>>>>> >>>>>> Not in concurrency-utilities for EE at least. That was the first impl >>>>>> I did then Mark pointed out it was violating CDI spec and request scope >>>>>> definition. There is a kind of contracdiction there cause >>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>> another thread. Both point of view are valid so we need to see where we >>>>>> tackle it. >>>>>> >>>>>> >>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>> >>>>>>> Idea is to give an API to make: >>>>>>> >>>>>>> public void complete() { >>>>>>> try { >>>>>>> asyncContext.complete(); >>>>>>> } finally { >>>>>>> auditContext.end(); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> working without hacky and almost impossible context pushing (cause >>>>>>> of injections nature you are not supposed to know what to push in the >>>>>>> context when going async). >>>>>>> >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau | Blog >>>>>>> | Github >>>>>>> | LinkedIn >>>>>>> | Tomitriber >>>>>>> >>>>>>> >>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>> >>>>>>>> Can you kindly share an annotated code example of the proposed >>>>>>>> solution so we can all follow and discuss this? >>>>>>>> >>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi >>>>>>>> scope. Idea is to follow request scope more than cdi spec allows. First >>>>>>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>>>>>> CDI one so here it is. >>>>>>>> >>>>>>>> Sample: >>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on >>>>>>>> it. The i go async (AsyncContext) and trigger a task in another thread. It >>>>>>>> would be neat - and mandatory in some case by the loose coupling nature of >>>>>>>> CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>>>>>> dependency you can easily use message passing pattern - but you loose the >>>>>>>> loose coupling cause you need to know until which level you unwrap, think t >>>>>>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>>>>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>>>>>> security...) so you can't really do it easily/naturally. >>>>>>>> >>>>>>>> Bonus: >>>>>>>> One very verbose way is to be able to kind of push/pop an existing >>>>>>>> context in a thread - wrappers doing it on a Runnable/Consumer/Function/... >>>>>>>> would be neat. >>>>>>>> >>>>>>>> Question: >>>>>>>> Would CDI handle it in 2.0? >>>>>>>> >>>>>>>> Side note: this is really about the fact to reuse a "context >>>>>>>> context" (its current instances map) in another thread the more >>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>> question for now. >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog >>>>>>>> | Github >>>>>>>> | LinkedIn >>>>>>>> | Tomitriber >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/2536f1d0/attachment-0001.html From reza_rahman at lycos.com Sun Mar 6 17:14:08 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 17:14:08 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> Message-ID: <4A9B7235-9B82-4348-B58D-193739424949@lycos.com> That does not surprise me too much. They probably did the bare minimum, which means even the security or JNDI context does not work correctly although the text says it should. I even sort of doubt injected stateful session beans work correctly (basically the same mechanics as CDI beans). Beyond the section on CDI let me see if there is other text that makes it obvious this is an implementation bug that should be fixed. > On Mar 6, 2016, at 5:03 PM, John D. Ament wrote: > > I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. > > If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. > > I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. > > John > >> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >> >> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >> >> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >> >> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >> >> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >> >>> Reza, >>> >>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>> >>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>> >>> If that's the case, then basically this should work OOTB right? >>> >>> Task task = new MyTask(); >>> task = contextService.createContextualProxy(task, Task.class); >>> executor.submit(task); >>> >>> // now magically the context should be prop'd? >>> >>> Is that about right? >>> >>> John >>> >>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>> >>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>> >>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>> >>>>> >>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>> >>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>> >>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>> >>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>>> >>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>>> >>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>>> >>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>>>> >>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>>>> >>>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>> >>>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>>>>> >>>>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>>>>> >>>>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>>>> >>>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>>>>> >>>>>>>>>>>>>> public void complete() { >>>>>>>>>>>>>> try { >>>>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>>>>> } finally { >>>>>>>>>>>>>> auditContext.end(); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sample: >>>>>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bonus: >>>>>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Question: >>>>>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/2b1e6266/attachment-0001.html From struberg at yahoo.de Sun Mar 6 17:23:47 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 6 Mar 2016 23:23:47 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: Also keep in mind that the request scoped instances are mostly not thread safe. Lg, Strub > Am 06.03.2016 um 20:15 schrieb Romain Manni-Bucau : > > > 2016-03-06 19:42 GMT+01:00 Reza Rahman : >> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. > > The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. > >> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >> >>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>> >>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>> >>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>> >>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>> >>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>> >>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>> >>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>> >>>>> Idea is to give an API to make: >>>>> >>>>> public void complete() { >>>>> try { >>>>> asyncContext.complete(); >>>>> } finally { >>>>> auditContext.end(); >>>>> } >>>>> } >>>>> >>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>> >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>> >>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>> >>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>> >>>>>>> Sample: >>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>> >>>>>>> Bonus: >>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>> >>>>>>> Question: >>>>>>> Would CDI handle it in 2.0? >>>>>>> >>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/82574649/attachment.html From reza_rahman at lycos.com Sun Mar 6 17:33:02 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 17:33:02 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: <059B2519-92FB-4993-B28D-C8020436182E@lycos.com> This is fair, although probably rare in practice. The utilities I do think mostly assume a read-only context that does not change from thread to thread. > On Mar 6, 2016, at 5:23 PM, Mark Struberg wrote: > > Also keep in mind that the request scoped instances are mostly not thread safe. > Lg, > Strub > >> Am 06.03.2016 um 20:15 schrieb Romain Manni-Bucau : >> >> >> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >> >> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >> >>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>> >>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>> >>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>> >>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>> >>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>> >>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>> >>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>> >>>>>> Idea is to give an API to make: >>>>>> >>>>>> public void complete() { >>>>>> try { >>>>>> asyncContext.complete(); >>>>>> } finally { >>>>>> auditContext.end(); >>>>>> } >>>>>> } >>>>>> >>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>> >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>> >>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>> >>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>> >>>>>>>> Sample: >>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>> >>>>>>>> Bonus: >>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>> >>>>>>>> Question: >>>>>>>> Would CDI handle it in 2.0? >>>>>>>> >>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/9a4c0da4/attachment-0001.html From stephan at knitelius.com Sun Mar 6 17:33:15 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Sun, 06 Mar 2016 22:33:15 +0000 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: Just as with any other scope, outside of conversation, developers would have to deal with these issues when using request scoped beans in asynchronous contexts. All the more reason to introduce configurable @Singleton style concurrent access control. Knitti On So., 6. M?rz 2016 at 23:24, Mark Struberg wrote: > Also keep in mind that the request scoped instances are mostly not thread > safe. > Lg, > Strub > > Am 06.03.2016 um 20:15 schrieb Romain Manni-Bucau : > > > 2016-03-06 19:42 GMT+01:00 Reza Rahman : > >> This frankly surprises me. I'll check the specification text. This might >> indeed just be an implementation bug. The EE concurrency utilities are >> supposed to be copying all relevant context. If this is an issue than it >> has to be that it is not copying enough of the HTTP request context for CDI >> to work. >> >> > The issue is not technical since I got it working but needed to reverse. > From my understanding ee concurrency utilities was done in a time CDI was > not there so it just ignored it somehow and it hasnt been updated when > integrated to the spec. Now with the wording of the CDI - and TCK - it is > impossible to make it working since request scope is bound the thre request > thread - and not the request. Side note: same applies to session scope and > conversation. > > >> Surely the Red Hat folks can quickly shed some light here since they >> implement essentially this whole stack? >> >> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau >> wrote: >> >> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >> >>> Can you kindly try to make the example a bit simpler? It's important to >>> make the case for how likely this is supposed to occur in most business >>> applications. >>> >>> Also, other than making sure that the executor service is propagating >>> thread local request contexts correctly what other solution are you >>> proposing? Did you check the specification? How sure are you that this >>> isn't simply an implementation bug? >>> >>> As far as I know the executor service is supposed to be preserving all >>> relevant parts of the EE context? >>> >>> >> Not in concurrency-utilities for EE at least. That was the first impl I >> did then Mark pointed out it was violating CDI spec and request scope >> definition. There is a kind of contracdiction there cause >> concurrency-utilities doesn't integrate with CDI at all but we can also see >> it the opposite way: CDI doesn't provide any way to propagate a context in >> another thread. Both point of view are valid so we need to see where we >> tackle it. >> >> >>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau >>> wrote: >>> >>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>> >>> Idea is to give an API to make: >>> >>> public void complete() { >>> try { >>> asyncContext.complete(); >>> } finally { >>> auditContext.end(); >>> } >>> } >>> >>> working without hacky and almost impossible context pushing (cause of >>> injections nature you are not supposed to know what to push in the context >>> when going async). >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>> >>>> Can you kindly share an annotated code example of the proposed solution >>>> so we can all follow and discuss this? >>>> >>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau >>>> wroteshar: >>>> >>>> Hi guys, >>>> >>>> spoke on concurrency utilities about the ability to inherit a cdi >>>> scope. Idea is to follow request scope more than cdi spec allows. First >>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>> CDI one so here it is. >>>> >>>> Sample: >>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. >>>> The i go async (AsyncContext) and trigger a task in another thread. It >>>> would be neat - and mandatory in some case by the loose coupling nature of >>>> CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>> dependency you can easily use message passing pattern - but you loose the >>>> loose coupling cause you need to know until which level you unwrap, think t >>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>> security...) so you can't really do it easily/naturally. >>>> >>>> Bonus: >>>> One very verbose way is to be able to kind of push/pop an existing >>>> context in a thread - wrappers doing it on a Runnable/Consumer/Function/... >>>> would be neat. >>>> >>>> Question: >>>> Would CDI handle it in 2.0? >>>> >>>> Side note: this is really about the fact to reuse a "context context" >>>> (its current instances map) in another thread the more transparently >>>> possible and match the user vision more than a technical question for now. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/dac8cd7b/attachment.html From arjan.tijms at gmail.com Sun Mar 6 17:34:35 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Sun, 6 Mar 2016 23:34:35 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> Message-ID: On Sun, Mar 6, 2016 at 11:03 PM, John D. Ament wrote: > The worst part is that right now, outside of the ASF, all other EE7 impls > seem to be using the RI for concurrency. > I'm pretty sure that JEUS (from TMaxSoft) uses its own independent implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/3dceb81b/attachment-0001.html From stephan at knitelius.com Sun Mar 6 17:40:34 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Sun, 06 Mar 2016 22:40:34 +0000 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: <059B2519-92FB-4993-B28D-C8020436182E@lycos.com> References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <059B2519-92FB-4993-B28D-C8020436182E@lycos.com> Message-ID: Agree on should be mostly read-only thread safe operations. In practice I have seen fair number of projects misuse request scope as a replacement for stateless session bean. Knitti On So., 6. M?rz 2016 at 23:33, Reza Rahman wrote: > This is fair, although probably rare in practice. The utilities I do think > mostly assume a read-only context that does not change from thread to > thread. > > On Mar 6, 2016, at 5:23 PM, Mark Struberg wrote: > > Also keep in mind that the request scoped instances are mostly not thread > safe. > Lg, > Strub > > Am 06.03.2016 um 20:15 schrieb Romain Manni-Bucau : > > > 2016-03-06 19:42 GMT+01:00 Reza Rahman : > >> This frankly surprises me. I'll check the specification text. This might >> indeed just be an implementation bug. The EE concurrency utilities are >> supposed to be copying all relevant context. If this is an issue than it >> has to be that it is not copying enough of the HTTP request context for CDI >> to work. >> >> > The issue is not technical since I got it working but needed to reverse. > From my understanding ee concurrency utilities was done in a time CDI was > not there so it just ignored it somehow and it hasnt been updated when > integrated to the spec. Now with the wording of the CDI - and TCK - it is > impossible to make it working since request scope is bound the thre request > thread - and not the request. Side note: same applies to session scope and > conversation. > > >> Surely the Red Hat folks can quickly shed some light here since they >> implement essentially this whole stack? >> >> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau >> wrote: >> >> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >> >>> Can you kindly try to make the example a bit simpler? It's important to >>> make the case for how likely this is supposed to occur in most business >>> applications. >>> >>> Also, other than making sure that the executor service is propagating >>> thread local request contexts correctly what other solution are you >>> proposing? Did you check the specification? How sure are you that this >>> isn't simply an implementation bug? >>> >>> As far as I know the executor service is supposed to be preserving all >>> relevant parts of the EE context? >>> >>> >> Not in concurrency-utilities for EE at least. That was the first impl I >> did then Mark pointed out it was violating CDI spec and request scope >> definition. There is a kind of contracdiction there cause >> concurrency-utilities doesn't integrate with CDI at all but we can also see >> it the opposite way: CDI doesn't provide any way to propagate a context in >> another thread. Both point of view are valid so we need to see where we >> tackle it. >> >> >>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau >>> wrote: >>> >>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>> >>> Idea is to give an API to make: >>> >>> public void complete() { >>> try { >>> asyncContext.complete(); >>> } finally { >>> auditContext.end(); >>> } >>> } >>> >>> working without hacky and almost impossible context pushing (cause of >>> injections nature you are not supposed to know what to push in the context >>> when going async). >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>> >>>> Can you kindly share an annotated code example of the proposed solution >>>> so we can all follow and discuss this? >>>> >>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau >>>> wroteshar: >>>> >>>> Hi guys, >>>> >>>> spoke on concurrency utilities about the ability to inherit a cdi >>>> scope. Idea is to follow request scope more than cdi spec allows. First >>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>> CDI one so here it is. >>>> >>>> Sample: >>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. >>>> The i go async (AsyncContext) and trigger a task in another thread. It >>>> would be neat - and mandatory in some case by the loose coupling nature of >>>> CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>> dependency you can easily use message passing pattern - but you loose the >>>> loose coupling cause you need to know until which level you unwrap, think t >>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>> security...) so you can't really do it easily/naturally. >>>> >>>> Bonus: >>>> One very verbose way is to be able to kind of push/pop an existing >>>> context in a thread - wrappers doing it on a Runnable/Consumer/Function/... >>>> would be neat. >>>> >>>> Question: >>>> Would CDI handle it in 2.0? >>>> >>>> Side note: this is really about the fact to reuse a "context context" >>>> (its current instances map) in another thread the more transparently >>>> possible and match the user vision more than a technical question for now. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/ceb50369/attachment-0001.html From rmannibucau at gmail.com Sun Mar 6 17:50:45 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 6 Mar 2016 23:50:45 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: Le 6 mars 2016 21:30, "Reza Rahman" a ?crit : > > Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? > Yep > Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. > Not sure where you go with that. Even if you want ro read - which is more than ambiguous and up to impl so not portable in any case - that request context is correctly handled, same use case is broken if you keep the servlet synchronous and trigger an async task from there using CU. There CDI clearly states the request scope is destroyed and in practise likely before the async task ends so the issue is real. > On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: > >> >> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>> >>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>> >>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>> >> >> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >> >>> >>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>> >>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>> >>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>> >>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>> >>>> John >>>> >>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < rmannibucau at gmail.com> wrote: >>>>> >>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>> >>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>> >>>>> >>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread ( http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>> >>>>>> >>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>>> >>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>> >>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>> >>>>>>> >>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>> >>>>>>>> >>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>> >>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>> >>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>> >>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>> >>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>> >>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>> >>>>>>>>>>> public void complete() { >>>>>>>>>>> try { >>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>> } finally { >>>>>>>>>>> auditContext.end(); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>> >>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < rmannibucau at gmail.com> wroteshar: >>>>>>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/bba61c6a/attachment-0001.html From reza_rahman at lycos.com Sun Mar 6 18:07:17 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 18:07:17 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: <6DB5F278-31B3-4CA9-885C-180197AD832E@lycos.com> I've read through the spec page to page yet one more time. I don't see anything that suggests this is anything more than a bug in a likely poorly implemented RI and TCK. I'll test this case along with other things that should also work like the security, JNDI and EJB contexts. I'll file bugs accordingly and see if I can get them fixed. I am unlikely to use this in a justification for a revision of EE concurrency. Frankly other than fixing the bugs and maybe adding a few more associated TCK tests I see no reason to change the spec text any further. It already states or implies that these things should be working. If we end up launching a revision I'll consider adding clarifying text as a low priority task. For me, this is the end of the line on this one for now. > On Mar 6, 2016, at 5:50 PM, Romain Manni-Bucau wrote: > > > Le 6 mars 2016 21:30, "Reza Rahman" a ?crit : > > > > Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? > > > > Yep > > > Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. > > > > Not sure where you go with that. Even if you want ro read - which is more than ambiguous and up to impl so not portable in any case - that request context is correctly handled, same use case is broken if you keep the servlet synchronous and trigger an async task from there using CU. There CDI clearly states the request scope is destroyed and in practise likely before the async task ends so the issue is real. > > > On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: > > > >> > >> 2016-03-06 20:59 GMT+01:00 Reza Rahman : > >>> > >>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. > >>> > >>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. > >>> > >> > >> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). > >> > >>> > >>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: > >>> > >>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. > >>>> > >>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. > >>>> > >>>> This is another requested feature, but looks more like a bug or gap in the spec. > >>>> > >>>> John > >>>> > >>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: > >>>>> > >>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : > >>>>>> > >>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. > >>>>>> > >>>>> > >>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). > >>>>> > >>>>>> > >>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: > >>>>>> > >>>>>>> > >>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : > >>>>>>>> > >>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. > >>>>>>>> > >>>>>>> > >>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. > >>>>>>> > >>>>>>>> > >>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? > >>>>>>>> > >>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: > >>>>>>>> > >>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : > >>>>>>>>>> > >>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. > >>>>>>>>>> > >>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? > >>>>>>>>>> > >>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: > >>>>>>>>>> > >>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? > >>>>>>>>>>> > >>>>>>>>>>> Idea is to give an API to make: > >>>>>>>>>>> > >>>>>>>>>>> public void complete() { > >>>>>>>>>>> try { > >>>>>>>>>>> asyncContext.complete(); > >>>>>>>>>>> } finally { > >>>>>>>>>>> auditContext.end(); > >>>>>>>>>>> } > >>>>>>>>>>> } > >>>>>>>>>>> > >>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Romain Manni-Bucau > >>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>>>>>>>>>> > >>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : > >>>>>>>>>>>> > >>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? > >>>>>>>>>>>> > >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi guys, > >>>>>>>>>>>>> > >>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Sample: > >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Bonus: > >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Question: > >>>>>>>>>>>>> Would CDI handle it in 2.0? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Romain Manni-Bucau > >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> cdi-dev mailing list > >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/fb4b7bf0/attachment-0001.html From struberg at yahoo.de Sun Mar 6 23:46:05 2016 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 7 Mar 2016 05:46:05 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> Message-ID: <94FC1E64-45A2-428D-9231-B7D30AF07B7E@yahoo.de> SAP is using owb afaik. Lg, Strub > Am 06.03.2016 um 23:34 schrieb arjan tijms : > >> On Sun, Mar 6, 2016 at 11:03 PM, John D. Ament wrote: >> The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. > > I'm pretty sure that JEUS (from TMaxSoft) uses its own independent implementation. > > > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/4b13ca0b/attachment.html From struberg at yahoo.de Sun Mar 6 23:49:14 2016 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 7 Mar 2016 05:49:14 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <059B2519-92FB-4993-B28D-C8020436182E@lycos.com> Message-ID: <45A51208-0699-4344-AAE0-940A861906C2@yahoo.de> Nope, @RequestScoped beans are in practice almost never thread safe. Think about request scoped EntityManagers etc. Lg, Strub > Am 06.03.2016 um 23:40 schrieb Stephan Knitelius : > > Agree on should be mostly read-only thread safe operations. > > In practice I have seen fair number of projects misuse request scope as a replacement for stateless session bean. > > Knitti >> On So., 6. M?rz 2016 at 23:33, Reza Rahman wrote: >> This is fair, although probably rare in practice. The utilities I do think mostly assume a read-only context that does not change from thread to thread. >> >>> On Mar 6, 2016, at 5:23 PM, Mark Struberg wrote: >>> >>> Also keep in mind that the request scoped instances are mostly not thread safe. >>> Lg, >>> Strub >>> >>>> Am 06.03.2016 um 20:15 schrieb Romain Manni-Bucau : >>>> >>>> >>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>> >>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>> >>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>> >>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>> >>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>> >>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>> >>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>> >>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>> >>>>>>>> Idea is to give an API to make: >>>>>>>> >>>>>>>> public void complete() { >>>>>>>> try { >>>>>>>> asyncContext.complete(); >>>>>>>> } finally { >>>>>>>> auditContext.end(); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>> >>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>> >>>>>>>>>> Sample: >>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>> >>>>>>>>>> Bonus: >>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>> >>>>>>>>>> Question: >>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>> >>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>> _______________________________________________ >>>>>>>>>> cdi-dev mailing list >>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/d297bb98/attachment-0001.html From struberg at yahoo.de Sun Mar 6 23:53:37 2016 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 7 Mar 2016 05:53:37 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> Message-ID: <2C765CDD-E086-4D24-9BDB-38A37C27CF1B@yahoo.de> The containers mimic ejb for propagation for a good reason! No session e.g. , new TX, etc Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). LieGrue, Strub > Am 06.03.2016 um 23:03 schrieb John D. Ament : > > I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. > > If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. > > I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. > > John > >> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >> >> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >> >> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >> >> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >> >> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >> >>> Reza, >>> >>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>> >>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>> >>> If that's the case, then basically this should work OOTB right? >>> >>> Task task = new MyTask(); >>> task = contextService.createContextualProxy(task, Task.class); >>> executor.submit(task); >>> >>> // now magically the context should be prop'd? >>> >>> Is that about right? >>> >>> John >>> >>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>> >>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>> >>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>> >>>>> >>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>> >>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>> >>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>> >>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>>> >>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>>> >>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>>> >>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>>>> >>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>>>> >>>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>> >>>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>>>>> >>>>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>>>>> >>>>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>>>> >>>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>>>>> >>>>>>>>>>>>>> public void complete() { >>>>>>>>>>>>>> try { >>>>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>>>>> } finally { >>>>>>>>>>>>>> auditContext.end(); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sample: >>>>>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bonus: >>>>>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Question: >>>>>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/ef853b99/attachment-0001.html From reza_rahman at lycos.com Sun Mar 6 23:57:51 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 6 Mar 2016 23:57:51 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: <2C765CDD-E086-4D24-9BDB-38A37C27CF1B@yahoo.de> References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> <2C765CDD-E086-4D24-9B DB-38A37C27CF1B@yahoo.de> Message-ID: The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. > On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: > Specifically > The containers mimic ejb for propagation for a good reason! > No session e.g. , new TX, etc > > Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). > > LieGrue, > Strub > >> Am 06.03.2016 um 23:03 schrieb John D. Ament : >> >> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >> >> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >> >> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >> >> John >> >>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >>> >>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >>> >>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >>> >>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >>> >>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >>> >>>> Reza, >>>> >>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>>> >>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>> >>>> If that's the case, then basically this should work OOTB right? >>>> >>>> Task task = new MyTask(); >>>> task = contextService.createContextualProxy(task, Task.class); >>>> executor.submit(task); >>>> >>>> // now magically the context should be prop'd? >>>> >>>> Is that about right? >>>> >>>> John >>>> >>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>>> >>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>>> >>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>> >>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>>> >>>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>>> >>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>>> >>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>>>> >>>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>>>> >>>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>>>> >>>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>>>>> >>>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>>>>> >>>>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>>>>>> >>>>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>>>>>> >>>>>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>>>>> >>>>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> public void complete() { >>>>>>>>>>>>>>> try { >>>>>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>>>>>> } finally { >>>>>>>>>>>>>>> auditContext.end(); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sample: >>>>>>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Bonus: >>>>>>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Question: >>>>>>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/e72a988c/attachment-0001.html From mkouba at redhat.com Mon Mar 7 02:35:37 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 7 Mar 2016 08:35:37 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: <56DD2F49.3010900@redhat.com> Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): > Hi guys, > > as a user having a ComlpetionStage makes me loose some JDK utilities, > can we move back to CompletionFuture? > > It would allow for instance: > > // doesn't work with CompletionStage > CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) > .then(...) Well, this should work if the underlying CompletionStage impl supports toCompletableFuture(), i.e. in Weld 3: CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), event2.fireAsync(...).toCompletableFuture()) AFAIK the default async execution facility of CompletableFuture is ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the CompletionStage interface allows us to wrap the async calls without the specified executor (e.g. CompletionStage.thenApplyAsync(Function)) and supply a default one provided by the impl. > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 From mkouba at redhat.com Mon Mar 7 02:42:06 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 7 Mar 2016 08:42:06 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: <56DD30CE.6070101@redhat.com> Dne 6.3.2016 v 16:37 Reza Rahman napsal(a): > How much end user feedback has there been on this? I have to be honest > that it surprises me to find this out now. Well, this was discussed many times (ML, EG mtgs, F2F, etc.). > > This to me stands out as an obvious usability problem. CompletableFuture > is the obvious top level end user API, not CompletionStage. Is it obvious? For me the CompletionStage looks more appropriate. But I'm open for discussions. > Not going > with CompletableFuture is very likely to confuse most people. The last > thing we need is more potential usability problems in Java EE APIs. > > On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau > wrote: > >> Hi guys, >> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >> can we move back to CompletionFuture? >> >> It would allow for instance: >> >> // doesn't work with CompletionStage >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >> .then(...) >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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 From rmannibucau at gmail.com Mon Mar 7 03:03:11 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 09:03:11 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <56DD2F49.3010900@redhat.com> References: <56DD2F49.3010900@redhat.com> Message-ID: Le 7 mars 2016 08:35, "Martin Kouba" a ?crit : > > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): > >> Hi guys, >> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >> can we move back to CompletionFuture? >> >> It would allow for instance: >> >> // doesn't work with CompletionStage >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >> .then(...) > > > Well, this should work if the underlying CompletionStage impl supports toCompletableFuture(), i.e. in Weld 3: > Yes but it is not natural to convert it IMO = we can do better > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), event2.fireAsync(...).toCompletableFuture()) > > AFAIK the default async execution facility of CompletableFuture is ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the CompletionStage interface allows us to wrap the async calls without the specified executor (e.g. CompletionStage.thenApplyAsync(Function)) and supply a default one provided by the impl. > Should use the pool in which the evznt is fired then "then step" is synchronous is my sample so all is decided at fire time > >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/fa71a4ae/attachment.html From mkouba at redhat.com Mon Mar 7 03:03:19 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 7 Mar 2016 09:03:19 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: <56DD35C7.9040505@redhat.com> Dne 6.3.2016 v 18:41 John D. Ament napsal(a): > > > On Sun, Mar 6, 2016 at 12:25 PM Romain Manni-Bucau > > wrote: > > 2016-03-06 18:02 GMT+01:00 John D. Ament >: > > What I think would be even better is to see this implemented in > the impls (Weld & OWB) and see how users use it, in a release > that's not plastered with Alpha or Experimental all over it. > While I think we were all wary about it, we need real end user > input from the impl standpoint to figure out what makes sense to > standardize on. > > > Or just do the opposite and *standardize* it. We can use Rx* > feedbacks but it doesnt' match event case at all which is a real > small subset of the reactive programming so I guess easiness should > be what drives us there and integration at least with the JVM so > CFuture version sounds more natural than CStage one. Difference is > very small at method level but at utility level it is. > > Side note: a Weld or OWB release without experimental/alpha sounds > worse if the spec changes later. A compromise can be an extension > doing it already you can drop in any of these containers. > > > There seems to be a general misunderstanding about how the specs are > intended to work. You standardize on things that as a group everyone > has agreed would work in a specific way. Right now, the CDI EG is > innovating and standardizing on those innovations instead of > standardizing on the features already available in the various impls. > Lets take a few examples of where impls deviate from the specs. > > - Bean Validation: Hibernate Validator has a suite of built in > validations > https://github.com/hibernate/hibernate-validator/tree/master/engine/src/main/java/org/hibernate/validator/constraints - > these constraints can in theory work in any pluggable environment, but > come with their core engine built in, for people to leverage. These are > good targets to leverage in the core spec when its seen as being very > useful. I think you cannot compare custom BV constraints and things which require core API changes. > > - JAX-RS : All of the implementations had client impls paired up with > their 1.1 compliant releases, even though it wasn't required. Why? > Because it made a ton of sense. Then see what happened afterwards, the > EG came together and standardized on a Client API that took a lot of the > great features in each impl and made them consistent. > > - EJB: Lets not forget that the removal of home/remote/local interfaces > came from a combination of xdoclet and spring. The EG came together, > saw that what was in use and figured out how to standardize on it once > the language features were available. > > - Singleton EJBs: An extension of EJB 3, most vendors supported a form > of singleton in their EJBs, and the EJB EG agreed upon it in addition to > some concurrency issues that had to be addressed. > > - CDI: Lets not forget about the hard work people like strub have put > into making CDI work well. Scoped Beans only? Awesome idea. > https://github.com/apache/openwebbeans/commit/3b3640e17c88e7c095563337194ba23c6f9e1689 > He didn't wait for the EG to standardize on anything before implementing. You call it "awesome idea", I agree that this feature makes sense, but I call it "manipulative approach". It was implemented before the EG was able to decide. The same for CDI-527 - OWB has a config property "javax.enterprise.inject.allowProxying.classes" but the proposed PR was not merged. Sure, EG is slow but it doesn't mean it should be ignored. > > - JPA: Lets not forget that HIbernate supports in dual hierarchies the > EntityManager and Session interfaces concurrently. Want to use HQL in > your @NamedQuery? Sure, it works fine. > > Bottom line, we need to get these features out into the wild, let people > play and come back with input on the various impls. There's nothing > stopping the weld team from introducing > org.jboss.weld.events.api.AsyncEvent that supports CompletableFuture and > CompletionStage, allowing app developers to consume this via an > injection point just like Event works today, @Inject AsyncEvent. But this would require the users to depend on Weld API! And that's only acceptable in SE and servlet containers where the users need impl-specific stuff anyway. > Even if thats not the spec compliant way to do it long term, it makes it > clear that you're using a provider specific API. > > In addition, there would be nothing stopping either team from > introducing support for @Priority on observer methods. There's no API > change, no spec change required. The spec doesn't mandate that it > works, but there's nothing stopping your impl from allowing it. The > spec doesn't say you absolutely cannot leverage it. I agree that the impls should innovate where the spec allows it. On the hand, it's not always an easy task, esp. if you need backward compatibility. > > John > > John > > > On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman > > wrote: > > How much end user feedback has there been on this? I have to > be honest that it surprises me to find this out now. > > This to me stands out as an obvious usability problem. > CompletableFuture is the obvious top level end user API, not > CompletionStage. Not going with CompletableFuture is very > likely to confuse most people. The last thing we need is > more potential usability problems in Java EE APIs. > > On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau > > wrote: > >> Hi guys, >> >> as a user having a ComlpetionStage makes me loose some JDK >> utilities, can we move back to CompletionFuture? >> >> It would allow for instance: >> >> // doesn't work with CompletionStage >> CompletionFuture.allOf(event1.fireAsync(...), >> event2.fireAsync(...)) >> .then(...) >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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 at 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 at 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 From mkouba at redhat.com Mon Mar 7 03:07:07 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 7 Mar 2016 09:07:07 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> Message-ID: <56DD36AB.5040205@redhat.com> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): > > Le 7 mars 2016 08:35, "Martin Kouba" > a ?crit : > > > > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): > > > >> Hi guys, > >> > >> as a user having a ComlpetionStage makes me loose some JDK utilities, > >> can we move back to CompletionFuture? > >> > >> It would allow for instance: > >> > >> // doesn't work with CompletionStage > >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) > >> .then(...) > > > > > > Well, this should work if the underlying CompletionStage impl > supports toCompletableFuture(), i.e. in Weld 3: > > > > Yes but it is not natural to convert it IMO = we can do better > > > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), > event2.fireAsync(...).toCompletableFuture()) > > > > AFAIK the default async execution facility of CompletableFuture is > ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the > CompletionStage interface allows us to wrap the async calls without the > specified executor (e.g. CompletionStage.thenApplyAsync(Function T, ? extends U>)) and supply a default one provided by the impl. > > > > Should use the pool in which the evznt is fired then "then step" is > synchronous is my sample so all is decided at fire time I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). > > > > >> > >> Romain Manni-Bucau > >> @rmannibucau | Blog > >> | Github > >> | LinkedIn > >> | Tomitriber > >> > >> > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at 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 > -- Martin Kouba Software Engineer Red Hat, Czech Republic From rmannibucau at gmail.com Mon Mar 7 03:45:07 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 09:45:07 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <56DD36AB.5040205@redhat.com> References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> Message-ID: 2016-03-07 9:07 GMT+01:00 Martin Kouba : > > Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): > >> >> Le 7 mars 2016 08:35, "Martin Kouba" > > a ?crit : >> > >> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >> > >> >> Hi guys, >> >> >> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >> >> can we move back to CompletionFuture? >> >> >> >> It would allow for instance: >> >> >> >> // doesn't work with CompletionStage >> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >> >> .then(...) >> > >> > >> > Well, this should work if the underlying CompletionStage impl >> supports toCompletableFuture(), i.e. in Weld 3: >> > >> >> Yes but it is not natural to convert it IMO = we can do better >> >> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >> event2.fireAsync(...).toCompletableFuture()) >> > >> > AFAIK the default async execution facility of CompletableFuture is >> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >> CompletionStage interface allows us to wrap the async calls without the >> specified executor (e.g. CompletionStage.thenApplyAsync(Function> T, ? extends U>)) and supply a default one provided by the impl. >> > >> >> Should use the pool in which the evznt is fired then "then step" is >> synchronous is my sample so all is decided at fire time >> > > I don't talk about your particular example - I understand that it's not > using async exec (although the "then()" method does not exist). > > was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). That said I agree on the state switching the pool is better but with these 2 notes: - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) > >> > >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau | Blog >> >> | Github >> >> | LinkedIn >> >> | Tomitriber >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at 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 >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/35a6e6e7/attachment.html From rmannibucau at gmail.com Mon Mar 7 03:49:23 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 09:49:23 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> <2C765CDD-E086-4D24-9BDB-38A37C27CF1B@yahoo.de> Message-ID: " Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. " States that the context is not inherited, is that what you mean? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-07 5:57 GMT+01:00 Reza Rahman : > The specification currently references pretty much all the major CDI > scopes specifically with the issue of propagation and lifecycle in mind. > Please see section 2.3. > > On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: > Specifically > > The containers mimic ejb for propagation for a good reason! > No session e.g. , new TX, etc > > Sadly the concurrency utilis only mention @ApplicationScoped, so the > Request Context not only doesn't get propagated (which is good), but also > doesn't get set up (which is crap). > > LieGrue, > Strub > > Am 06.03.2016 um 23:03 schrieb John D. Ament : > > I agree, in a sense, with what you're saying. There's nothing in this > spec that says it wouldn't be propagated. However, there's nothing in this > spec that states clearly that CDI contexts are propagated. > > If you look at the RI, the RI only seems to propagate transaction state. > Considering the age of the spec, I'm not surprised to see that. The worst > part is that right now, outside of the ASF, all other EE7 impls seem to be > using the RI for concurrency. > > I'm fairly certain that from this spec's standpoint, the only thing that's > actually propagated is the transaction. > > John > > On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: > >> I am re-reading the spec end to end again right now. So far it seems I >> have remembered everything correctly. >> >> You should read over section 2.3. What it is saying is that a container >> implementing the Java EE concurrency utilities should ensure whatever >> contextual information is needed for managed components to work correctly >> should be propagated automatically. For the correct implementation of CDI >> scopes, this should also mean any currently active scopes. The section you >> are referring to is basically implying that thinking that it is possible to >> use these scoped beans in tasks (albeit not reliably since beans could go >> out of scope before the thread finishes - for example if the request ends). >> >> This does not have anything to do with the context service per se. The >> context service is an SPI of sorts to allow end user developers to do for >> their own applications what the container does behind the scenes for >> managed component context propagation. >> >> I'll read over the entire spec to see if there is anything to contradict >> this. If that's not the case what Romain is describing is most likely an >> implementation specific bug that did not take into account CDI scope >> propagation. >> >> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >> >> Reza, >> >> I read through the concurrency utils spec. Was there a specific section >> you had in mind? The only references to CDI were near the beginning >> warning users to not use Request/Session scoped beans as tasks since the >> outer most context may be destroyed before the work is done. >> >> I have a feeling what you're referring to is the context service: >> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >> >> If that's the case, then basically this should work OOTB right? >> >> Task task = new MyTask(); >> task = contextService.createContextualProxy(task, Task.class); >> executor.submit(task); >> >> // now magically the context should be prop'd? >> >> Is that about right? >> >> John >> >> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >> >>> Have you actually looked at the EE concurrency spec text in detail? What >>> does it say about managed component context propagation? >>> >>> Without actually doing that further discussing this is just taking shots >>> in the dark. As an implementer it should not surprise you that this might >>> simply be a bug because the person implementing the concurrency utilities >>> for the EE runtime was not told about what to copy over into the new thread >>> for CDI to work correctly. >>> >>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau >>> wrote: >>> >>> >>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>> >>>> As far as I know this is precisely the sort of thing that the EE >>>> concurrency spec is intended for. It is supposed to copy over everything >>>> from the underlying thread local context into the new thread for all EE >>>> managed components to function. Since CDI beans are also EE container >>>> managed, it also applies to CDI beans as well. The EE vendor is supposed to >>>> make sure this works properly. >>>> >>>> I don't think the concurrency utilities specifically lists APIs for >>>> which thread context propagation should work. If this doesn't work in a >>>> specific implementation it's most likely because they didn't take CDI into >>>> account in their own EE concurrency implementation. >>>> >>>> >>> That's what I wanted/would like. CDI TCK breaks it quite easily and >>> @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly >>> named. So to solve it we would need another scope as I mentionned several >>> times on this list 100% matching servlet instances lifecycles (on a pure >>> CDI side we have the same issue for sessions which are recycled during a >>> request, the session scope is corrupted *by spec* in term of user behavior). >>> >>> >>>> On Mar 6, 2016, at 2:45 PM, John D. Ament >>>> wrote: >>>> >>>> The section of the spec you link to makes no references to threads. >>>> 6.3 makes some notes about normal scopes and threads, and specifically >>>> says that a context is bound to one or more threads. >>>> >>>> I think what's happened is that over the years, people have simply >>>> bound HTTP Request == single thread, but when async processing was >>>> introduced no one thought to clarify that the spawning of a child thread >>>> from the original HTTP request retains the parent's context. >>>> >>>> This is another requested feature, but looks more like a bug or gap in >>>> the spec. >>>> >>>> John >>>> >>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>> >>>>>> Let's see. I suspect the specification text for EE concurrency is >>>>>> generic enough for implementations to also be able to cover CDI scopes or >>>>>> any other Java EE API context propagation needs. This means the issue needs >>>>>> to be solved at the individual implementation level. Changing anything in >>>>>> the spec is probably just unnecessary ceremony in this case. >>>>>> >>>>>> >>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI >>>>> still prevent it to work since it would violate the spec to propagate it >>>>> while request scope is bound to another thread ( >>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>> handles async listener but not the main AsyncContext part). >>>>> >>>>> >>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau >>>>>> wrote: >>>>>> >>>>>> >>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>> >>>>>>> This frankly surprises me. I'll check the specification text. This >>>>>>> might indeed just be an implementation bug. The EE concurrency utilities >>>>>>> are supposed to be copying all relevant context. If this is an issue than >>>>>>> it has to be that it is not copying enough of the HTTP request context for >>>>>>> CDI to work. >>>>>>> >>>>>>> >>>>>> The issue is not technical since I got it working but needed to >>>>>> reverse. From my understanding ee concurrency utilities was done in a time >>>>>> CDI was not there so it just ignored it somehow and it hasnt been updated >>>>>> when integrated to the spec. Now with the wording of the CDI - and TCK - it >>>>>> is impossible to make it working since request scope is bound the thre >>>>>> request thread - and not the request. Side note: same applies to session >>>>>> scope and conversation. >>>>>> >>>>>> >>>>>>> Surely the Red Hat folks can quickly shed some light here since they >>>>>>> implement essentially this whole stack? >>>>>>> >>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>> >>>>>>>> Can you kindly try to make the example a bit simpler? It's >>>>>>>> important to make the case for how likely this is supposed to occur in most >>>>>>>> business applications. >>>>>>>> >>>>>>>> Also, other than making sure that the executor service is >>>>>>>> propagating thread local request contexts correctly what other solution are >>>>>>>> you proposing? Did you check the specification? How sure are you that this >>>>>>>> isn't simply an implementation bug? >>>>>>>> >>>>>>>> As far as I know the executor service is supposed to be preserving >>>>>>>> all relevant parts of the EE context? >>>>>>>> >>>>>>>> >>>>>>> Not in concurrency-utilities for EE at least. That was the first >>>>>>> impl I did then Mark pointed out it was violating CDI spec and request >>>>>>> scope definition. There is a kind of contracdiction there cause >>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>> tackle it. >>>>>>> >>>>>>> >>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>> >>>>>>>> Idea is to give an API to make: >>>>>>>> >>>>>>>> public void complete() { >>>>>>>> try { >>>>>>>> asyncContext.complete(); >>>>>>>> } finally { >>>>>>>> auditContext.end(); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> working without hacky and almost impossible context pushing (cause >>>>>>>> of injections nature you are not supposed to know what to push in the >>>>>>>> context when going async). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog >>>>>>>> | Github >>>>>>>> | LinkedIn >>>>>>>> | Tomitriber >>>>>>>> >>>>>>>> >>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>> >>>>>>>>> Can you kindly share an annotated code example of the proposed >>>>>>>>> solution so we can all follow and discuss this? >>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>>> >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi >>>>>>>>> scope. Idea is to follow request scope more than cdi spec allows. First >>>>>>>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>>>>>>> CDI one so here it is. >>>>>>>>> >>>>>>>>> Sample: >>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set >>>>>>>>> on it. The i go async (AsyncContext) and trigger a task in another thread. >>>>>>>>> It would be neat - and mandatory in some case by the loose coupling nature >>>>>>>>> of CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>>>>>>> dependency you can easily use message passing pattern - but you loose the >>>>>>>>> loose coupling cause you need to know until which level you unwrap, think t >>>>>>>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>>>>>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>>>>>>> security...) so you can't really do it easily/naturally. >>>>>>>>> >>>>>>>>> Bonus: >>>>>>>>> One very verbose way is to be able to kind of push/pop an existing >>>>>>>>> context in a thread - wrappers doing it on a Runnable/Consumer/Function/... >>>>>>>>> would be neat. >>>>>>>>> >>>>>>>>> Question: >>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>> >>>>>>>>> Side note: this is really about the fact to reuse a "context >>>>>>>>> context" (its current instances map) in another thread the more >>>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>>> question for now. >>>>>>>>> >>>>>>>>> >>>>>>>>> Romain Manni-Bucau >>>>>>>>> @rmannibucau | Blog >>>>>>>>> | Github >>>>>>>>> | LinkedIn >>>>>>>>> | Tomitriber >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> cdi-dev mailing list >>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/e93640e1/attachment-0001.html From issues at jboss.org Mon Mar 7 04:23:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 7 Mar 2016 04:23:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172610#comment-13172610 ] Martin Kouba commented on CDI-494: ---------------------------------- http://lists.jboss.org/pipermail/cdi-dev/2016-February/007789.html > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 04:38:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 7 Mar 2016 04:38:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172622#comment-13172622 ] Matej Novotny commented on CDI-494: ----------------------------------- After quite a discussion we had on this topic, I am fairly convinced we should clarify, that wildcards do not belong to unresolvable types - e.g. +1 for the PR. This will clear up, among other things, that it is valid to perform one {{Event.select(List)}} and multiple {{event.fire(new ArrayList)}}. > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Mon Mar 7 04:57:13 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 7 Mar 2016 10:57:13 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> Message-ID: <56DD5079.40801@redhat.com> Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a): > 2016-03-07 9:07 GMT+01:00 Martin Kouba >: > > > Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): > > > Le 7 mars 2016 08:35, "Martin Kouba" > >> a ?crit : > > > > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): > > > >> Hi guys, > >> > >> as a user having a ComlpetionStage makes me loose some JDK > utilities, > >> can we move back to CompletionFuture? > >> > >> It would allow for instance: > >> > >> // doesn't work with CompletionStage > >> CompletionFuture.allOf(event1.fireAsync(...), > event2.fireAsync(...)) > >> .then(...) > > > > > > Well, this should work if the underlying CompletionStage impl > supports toCompletableFuture(), i.e. in Weld 3: > > > > Yes but it is not natural to convert it IMO = we can do better > > > > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), > event2.fireAsync(...).toCompletableFuture()) > > > > AFAIK the default async execution facility of > CompletableFuture is > ForkJoinPool.commonPool() which is not a good fit for Java EE. > Using the > CompletionStage interface allows us to wrap the async calls > without the > specified executor (e.g. > CompletionStage.thenApplyAsync(Function T, ? extends U>)) and supply a default one provided by the impl. > > > > Should use the pool in which the evznt is fired then "then step" is > synchronous is my sample so all is decided at fire time > > > I don't talk about your particular example - I understand that it's > not using async exec (although the "then()" method does not exist). > > > was supposed to represent the different flavours (thenRun, thenCompose, > ...) ;). > > That said I agree on the state switching the pool is better but with > these 2 notes: > > - could be better to hide these poorly designed methods then -> don't > use CompletionXXX but a CDI API with a bridge to CompletionX to let the > user go back on SE tools Yep, this is one of the possible solutions. On the other hand, I don't think it's poorly designed. CompletionStage defines the "default asynchronous execution facility" and CDI spec states that the CompletionStage returned by fireAsync methods is container-specific. The impl may choose to clarify this "default asynchronous execution facility", i.e. there's place for innovation... > - we still don't have a *standard* config for the pool(s) underlying CDI > features so it sounds as poor as SE solution IMO (at least a > core/max/ttl config in beans.xml) I don't think this should be standardized... > > > > > >> > >> Romain Manni-Bucau > >> @rmannibucau | Blog > >> | Github > >> | LinkedIn > >> | Tomitriber > >> > >> > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at 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 > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > > -- Martin Kouba Software Engineer Red Hat, Czech Republic From rmannibucau at gmail.com Mon Mar 7 05:10:13 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 11:10:13 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <56DD5079.40801@redhat.com> References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <56DD5079.40801@redhat.com> Message-ID: 2016-03-07 10:57 GMT+01:00 Martin Kouba : > Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a): > >> 2016-03-07 9:07 GMT+01:00 Martin Kouba > >: >> >> >> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >> >> >> Le 7 mars 2016 08:35, "Martin Kouba" > >> >> a ?crit : >> >> > >> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >> > >> >> Hi guys, >> >> >> >> as a user having a ComlpetionStage makes me loose some JDK >> utilities, >> >> can we move back to CompletionFuture? >> >> >> >> It would allow for instance: >> >> >> >> // doesn't work with CompletionStage >> >> CompletionFuture.allOf(event1.fireAsync(...), >> event2.fireAsync(...)) >> >> .then(...) >> > >> > >> > Well, this should work if the underlying CompletionStage impl >> supports toCompletableFuture(), i.e. in Weld 3: >> > >> >> Yes but it is not natural to convert it IMO = we can do better >> >> > >> >> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >> event2.fireAsync(...).toCompletableFuture()) >> > >> > AFAIK the default async execution facility of >> CompletableFuture is >> ForkJoinPool.commonPool() which is not a good fit for Java EE. >> Using the >> CompletionStage interface allows us to wrap the async calls >> without the >> specified executor (e.g. >> CompletionStage.thenApplyAsync(Function> T, ? extends U>)) and supply a default one provided by the impl. >> > >> >> Should use the pool in which the evznt is fired then "then step" >> is >> synchronous is my sample so all is decided at fire time >> >> >> I don't talk about your particular example - I understand that it's >> not using async exec (although the "then()" method does not exist). >> >> >> was supposed to represent the different flavours (thenRun, thenCompose, >> ...) ;). >> >> That said I agree on the state switching the pool is better but with >> these 2 notes: >> >> - could be better to hide these poorly designed methods then -> don't >> use CompletionXXX but a CDI API with a bridge to CompletionX to let the >> user go back on SE tools >> > > Yep, this is one of the possible solutions. On the other hand, I don't > think it's poorly designed. CompletionStage defines the "default > asynchronous execution facility" and CDI spec states that the > CompletionStage returned by fireAsync methods is container-specific. The > impl may choose to clarify this "default asynchronous execution facility", > i.e. there's place for innovation... > > - we still don't have a *standard* config for the pool(s) underlying CDI >> features so it sounds as poor as SE solution IMO (at least a >> core/max/ttl config in beans.xml) >> > > I don't think this should be standardized... > > Why? Typically if you take @Asynchronous (EJB spec) you have already this issue and this is often avoided when portability matters for that particular reason you don't know how you will behave. Or do you think concurrency-utilities solves it? > >> >> > >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau | Blog >> >> | Github >> >> | LinkedIn >> >> | Tomitriber >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at 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 >> >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/2ab7ac99/attachment-0001.html From antoine at sabot-durand.net Mon Mar 7 05:12:40 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 07 Mar 2016 10:12:40 +0000 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <56DD30CE.6070101@redhat.com> References: <56DD30CE.6070101@redhat.com> Message-ID: Hi guys, Back from vacation, I'm "happy" to see that we go back on Async event feature (which took us 6 months). @Reza and @Romain sorry but I don't get it. the good practice is to develop for interface (that's why CDI uses Set and not HashSet for instance). I'm ok it's the theory, but if you want to make an exception to this practice you need to have a good reason. So if you want to rely on JDK classes like CompletableFuture instead of interface, you'll probably have to go a step further than that. CompletionStage has a toCompletableFuture() method. To go back to the big picture, as some people around don't seem to be happy with what we designed, we still have the solution to move async event can in specification annexe. It's a solution to test a feature without definitely specifying it. Antoine Le lun. 7 mars 2016 ? 08:42, Martin Kouba a ?crit : > Dne 6.3.2016 v 16:37 Reza Rahman napsal(a): > > How much end user feedback has there been on this? I have to be honest > > that it surprises me to find this out now. > > Well, this was discussed many times (ML, EG mtgs, F2F, etc.). > > > > > This to me stands out as an obvious usability problem. CompletableFuture > > is the obvious top level end user API, not CompletionStage. > > Is it obvious? For me the CompletionStage looks more appropriate. But > I'm open for discussions. > > > Not going > > with CompletableFuture is very likely to confuse most people. The last > > thing we need is more potential usability problems in Java EE APIs. > > > > On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau > > wrote: > > > >> Hi guys, > >> > >> as a user having a ComlpetionStage makes me loose some JDK utilities, > >> can we move back to CompletionFuture? > >> > >> It would allow for instance: > >> > >> // doesn't work with CompletionStage > >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) > >> .then(...) > >> > >> Romain Manni-Bucau > >> @rmannibucau | Blog > >> | Github > >> | LinkedIn > >> | Tomitriber > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/c822e952/attachment.html From rmannibucau at gmail.com Mon Mar 7 05:16:30 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 11:16:30 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD30CE.6070101@redhat.com> Message-ID: 2016-03-07 11:12 GMT+01:00 Antoine Sabot-Durand : > Hi guys, > > Back from vacation, I'm "happy" to see that we go back on Async event > feature (which took us 6 months). > > @Reza and @Romain sorry but I don't get it. the good practice is to > develop for interface (that's why CDI uses Set and not HashSet for > instance). I'm ok it's the theory, but if you want to make an exception to > this practice you need to have a good reason. So if you want to rely on > JDK classes like CompletableFuture instead of interface, you'll probably > have to go a step further than that. CompletionStage has a > toCompletableFuture() method. > > It is all about being "fluent" by default. If not java 8 provides enough alternatives to not use the feature IMO (even CompletionFuture itself does it wrapping your fire() call). > To go back to the big picture, as some people around don't seem to be > happy with what we designed, we still have the solution to move async > event can in specification annexe. It's a solution to test a feature > without definitely specifying it. > > +1 > Antoine > > Le lun. 7 mars 2016 ? 08:42, Martin Kouba a ?crit : > >> Dne 6.3.2016 v 16:37 Reza Rahman napsal(a): >> > How much end user feedback has there been on this? I have to be honest >> > that it surprises me to find this out now. >> >> Well, this was discussed many times (ML, EG mtgs, F2F, etc.). >> >> > >> > This to me stands out as an obvious usability problem. CompletableFuture >> > is the obvious top level end user API, not CompletionStage. >> >> Is it obvious? For me the CompletionStage looks more appropriate. But >> I'm open for discussions. >> >> > Not going >> > with CompletableFuture is very likely to confuse most people. The last >> > thing we need is more potential usability problems in Java EE APIs. >> > >> > On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau > > > wrote: >> > >> >> Hi guys, >> >> >> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >> >> can we move back to CompletionFuture? >> >> >> >> It would allow for instance: >> >> >> >> // doesn't work with CompletionStage >> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >> >> .then(...) >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau | Blog >> >> | Github >> >> | LinkedIn >> >> | Tomitriber >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/4a23c8e0/attachment-0001.html From mkouba at redhat.com Mon Mar 7 05:17:27 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 7 Mar 2016 11:17:27 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <56DD5079.40801@redhat.com> Message-ID: <56DD5537.8070003@redhat.com> Dne 7.3.2016 v 11:10 Romain Manni-Bucau napsal(a): > > 2016-03-07 10:57 GMT+01:00 Martin Kouba >: > > Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a): > > 2016-03-07 9:07 GMT+01:00 Martin Kouba > >>: > > > Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): > > > Le 7 mars 2016 08:35, "Martin Kouba" > > > > >>> a ?crit : > > > > > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): > > > >> Hi guys, > >> > >> as a user having a ComlpetionStage makes me loose > some JDK > utilities, > >> can we move back to CompletionFuture? > >> > >> It would allow for instance: > >> > >> // doesn't work with CompletionStage > >> CompletionFuture.allOf(event1.fireAsync(...), > event2.fireAsync(...)) > >> .then(...) > > > > > > Well, this should work if the underlying > CompletionStage impl > supports toCompletableFuture(), i.e. in Weld 3: > > > > Yes but it is not natural to convert it IMO = we can do > better > > > > > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), > event2.fireAsync(...).toCompletableFuture()) > > > > AFAIK the default async execution facility of > CompletableFuture is > ForkJoinPool.commonPool() which is not a good fit for > Java EE. > Using the > CompletionStage interface allows us to wrap the async calls > without the > specified executor (e.g. > CompletionStage.thenApplyAsync(Function T, ? extends U>)) and supply a default one provided by > the impl. > > > > Should use the pool in which the evznt is fired then > "then step" is > synchronous is my sample so all is decided at fire time > > > I don't talk about your particular example - I understand > that it's > not using async exec (although the "then()" method does not > exist). > > > was supposed to represent the different flavours (thenRun, > thenCompose, > ...) ;). > > That said I agree on the state switching the pool is better but with > these 2 notes: > > - could be better to hide these poorly designed methods then -> > don't > use CompletionXXX but a CDI API with a bridge to CompletionX to > let the > user go back on SE tools > > > Yep, this is one of the possible solutions. On the other hand, I > don't think it's poorly designed. CompletionStage defines the > "default asynchronous execution facility" and CDI spec states that > the CompletionStage returned by fireAsync methods is > container-specific. The impl may choose to clarify this "default > asynchronous execution facility", i.e. there's place for innovation... > > - we still don't have a *standard* config for the pool(s) > underlying CDI > features so it sounds as poor as SE solution IMO (at least a > core/max/ttl config in beans.xml) > > > I don't think this should be standardized... > > > Why? Typically if you take @Asynchronous (EJB spec) you have already > this issue and this is often avoided when portability matters for that > particular reason you don't know how you will behave. Or do you think > concurrency-utilities solves it? No, it doesn't. I think it should remain impl-specific. You know how it will behave - it will be async. And if needed you could tune up the config, depending on the container. If you specify core/max/ttl the container will not be able to optimize. > > > > > > >> > >> Romain Manni-Bucau > >> @rmannibucau | Blog > >> | Github > >> | LinkedIn > >> | Tomitriber > >> > >> > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at 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 > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > > -- Martin Kouba Software Engineer Red Hat, Czech Republic From rmannibucau at gmail.com Mon Mar 7 05:20:55 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 11:20:55 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <56DD5537.8070003@redhat.com> References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <56DD5079.40801@redhat.com> <56DD5537.8070003@redhat.com> Message-ID: 2016-03-07 11:17 GMT+01:00 Martin Kouba : > > > Dne 7.3.2016 v 11:10 Romain Manni-Bucau napsal(a): > >> >> 2016-03-07 10:57 GMT+01:00 Martin Kouba > >: >> >> Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a): >> >> 2016-03-07 9:07 GMT+01:00 Martin Kouba > >> >>: >> >> >> >> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >> >> >> Le 7 mars 2016 08:35, "Martin Kouba" > >> > >> >> >>> a ?crit : >> >> > >> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >> > >> >> Hi guys, >> >> >> >> as a user having a ComlpetionStage makes me loose >> some JDK >> utilities, >> >> can we move back to CompletionFuture? >> >> >> >> It would allow for instance: >> >> >> >> // doesn't work with CompletionStage >> >> CompletionFuture.allOf(event1.fireAsync(...), >> event2.fireAsync(...)) >> >> .then(...) >> > >> > >> > Well, this should work if the underlying >> CompletionStage impl >> supports toCompletableFuture(), i.e. in Weld 3: >> > >> >> Yes but it is not natural to convert it IMO = we can do >> better >> >> > >> >> >> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >> event2.fireAsync(...).toCompletableFuture()) >> > >> > AFAIK the default async execution facility of >> CompletableFuture is >> ForkJoinPool.commonPool() which is not a good fit for >> Java EE. >> Using the >> CompletionStage interface allows us to wrap the async >> calls >> without the >> specified executor (e.g. >> CompletionStage.thenApplyAsync(Function> T, ? extends U>)) and supply a default one provided by >> the impl. >> > >> >> Should use the pool in which the evznt is fired then >> "then step" is >> synchronous is my sample so all is decided at fire time >> >> >> I don't talk about your particular example - I understand >> that it's >> not using async exec (although the "then()" method does not >> exist). >> >> >> was supposed to represent the different flavours (thenRun, >> thenCompose, >> ...) ;). >> >> That said I agree on the state switching the pool is better but >> with >> these 2 notes: >> >> - could be better to hide these poorly designed methods then -> >> don't >> use CompletionXXX but a CDI API with a bridge to CompletionX to >> let the >> user go back on SE tools >> >> >> Yep, this is one of the possible solutions. On the other hand, I >> don't think it's poorly designed. CompletionStage defines the >> "default asynchronous execution facility" and CDI spec states that >> the CompletionStage returned by fireAsync methods is >> container-specific. The impl may choose to clarify this "default >> asynchronous execution facility", i.e. there's place for innovation... >> >> - we still don't have a *standard* config for the pool(s) >> underlying CDI >> features so it sounds as poor as SE solution IMO (at least a >> core/max/ttl config in beans.xml) >> >> >> I don't think this should be standardized... >> >> >> Why? Typically if you take @Asynchronous (EJB spec) you have already >> this issue and this is often avoided when portability matters for that >> particular reason you don't know how you will behave. Or do you think >> concurrency-utilities solves it? >> > > No, it doesn't. I think it should remain impl-specific. You know how it > will behave - it will be async. And if needed you could tune up the config, > depending on the container. If you specify core/max/ttl the container will > not be able to optimize. > > "it will be async" <- then container is free to have a single thread (would make a js impl possible :)) which would totally break you app which is supposed to be scalable. Also if the config is container dependent you can just not be able to configure it - I know the container would be bad but you don't always choose it. In any case not having a config means the feature is not reliable and depending on the container specific features means you are aside the EE goals of reliability in the time IMHO. Also the container opitmizations can have side effects so if not behaving as expected it needs to be spec-ed. Threading model is something central when it starts to be used for a bit mroe than fire and forget once a day, ignoring it is killing before the birth the API you can add on top of it IMO. > > >> >> >> > >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau | >> Blog >> >> | Github >> >> | LinkedIn >> >> | >> Tomitriber >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at 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 >> >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> >> >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/130e7584/attachment-0001.html From stephan at knitelius.com Mon Mar 7 05:27:20 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Mon, 07 Mar 2016 10:27:20 +0000 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> <2C765CDD-E086-4D24-9BDB-38A37C27CF1B@yahoo.de> Message-ID: >>" >>Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting >>component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not >>recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. >>" > >States that the context is not inherited, is that what you mean? Sounds more like a warning that the CDI context may be destroyed prior to completion of the asynchronous task. Therefor we might be able to clear this up on the CDI side, by keeping contexts alive as long as they are associated with > 1 executing threads. On Mon, 7 Mar 2016 at 09:50 Romain Manni-Bucau wrote: > " > Tasks that are submitted to a managed instance of ExecutorService may > still be running after the lifecycle of the submitting component. > Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or > @ConversationScoped are not recommended to use as tasks as it cannot be > guaranteed that the tasks will complete before the CDI context is > destroyed. > " > > States that the context is not inherited, is that what you mean? > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-07 5:57 GMT+01:00 Reza Rahman : > >> The specification currently references pretty much all the major CDI >> scopes specifically with the issue of propagation and lifecycle in mind. >> Please see section 2.3. >> >> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >> Specifically >> >> The containers mimic ejb for propagation for a good reason! >> No session e.g. , new TX, etc >> >> Sadly the concurrency utilis only mention @ApplicationScoped, so the >> Request Context not only doesn't get propagated (which is good), but also >> doesn't get set up (which is crap). >> >> LieGrue, >> Strub >> >> Am 06.03.2016 um 23:03 schrieb John D. Ament : >> >> I agree, in a sense, with what you're saying. There's nothing in this >> spec that says it wouldn't be propagated. However, there's nothing in this >> spec that states clearly that CDI contexts are propagated. >> >> If you look at the RI, the RI only seems to propagate transaction state. >> Considering the age of the spec, I'm not surprised to see that. The worst >> part is that right now, outside of the ASF, all other EE7 impls seem to be >> using the RI for concurrency. >> >> I'm fairly certain that from this spec's standpoint, the only thing >> that's actually propagated is the transaction. >> >> John >> >> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >> >>> I am re-reading the spec end to end again right now. So far it seems I >>> have remembered everything correctly. >>> >>> You should read over section 2.3. What it is saying is that a container >>> implementing the Java EE concurrency utilities should ensure whatever >>> contextual information is needed for managed components to work correctly >>> should be propagated automatically. For the correct implementation of CDI >>> scopes, this should also mean any currently active scopes. The section you >>> are referring to is basically implying that thinking that it is possible to >>> use these scoped beans in tasks (albeit not reliably since beans could go >>> out of scope before the thread finishes - for example if the request ends). >>> >>> This does not have anything to do with the context service per se. The >>> context service is an SPI of sorts to allow end user developers to do for >>> their own applications what the container does behind the scenes for >>> managed component context propagation. >>> >>> I'll read over the entire spec to see if there is anything to contradict >>> this. If that's not the case what Romain is describing is most likely an >>> implementation specific bug that did not take into account CDI scope >>> propagation. >>> >>> On Mar 6, 2016, at 4:23 PM, John D. Ament >>> wrote: >>> >>> Reza, >>> >>> I read through the concurrency utils spec. Was there a specific section >>> you had in mind? The only references to CDI were near the beginning >>> warning users to not use Request/Session scoped beans as tasks since the >>> outer most context may be destroyed before the work is done. >>> >>> I have a feeling what you're referring to is the context service: >>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>> >>> If that's the case, then basically this should work OOTB right? >>> >>> Task task = new MyTask(); >>> task = contextService.createContextualProxy(task, Task.class); >>> executor.submit(task); >>> >>> // now magically the context should be prop'd? >>> >>> Is that about right? >>> >>> John >>> >>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman >>> wrote: >>> >>>> Have you actually looked at the EE concurrency spec text in detail? >>>> What does it say about managed component context propagation? >>>> >>>> Without actually doing that further discussing this is just taking >>>> shots in the dark. As an implementer it should not surprise you that this >>>> might simply be a bug because the person implementing the concurrency >>>> utilities for the EE runtime was not told about what to copy over into the >>>> new thread for CDI to work correctly. >>>> >>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau >>>> wrote: >>>> >>>> >>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>> >>>>> As far as I know this is precisely the sort of thing that the EE >>>>> concurrency spec is intended for. It is supposed to copy over everything >>>>> from the underlying thread local context into the new thread for all EE >>>>> managed components to function. Since CDI beans are also EE container >>>>> managed, it also applies to CDI beans as well. The EE vendor is supposed to >>>>> make sure this works properly. >>>>> >>>>> I don't think the concurrency utilities specifically lists APIs for >>>>> which thread context propagation should work. If this doesn't work in a >>>>> specific implementation it's most likely because they didn't take CDI into >>>>> account in their own EE concurrency implementation. >>>>> >>>>> >>>> That's what I wanted/would like. CDI TCK breaks it quite easily and >>>> @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly >>>> named. So to solve it we would need another scope as I mentionned several >>>> times on this list 100% matching servlet instances lifecycles (on a pure >>>> CDI side we have the same issue for sessions which are recycled during a >>>> request, the session scope is corrupted *by spec* in term of user behavior). >>>> >>>> >>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament >>>>> wrote: >>>>> >>>>> The section of the spec you link to makes no references to threads. >>>>> 6.3 makes some notes about normal scopes and threads, and specifically >>>>> says that a context is bound to one or more threads. >>>>> >>>>> I think what's happened is that over the years, people have simply >>>>> bound HTTP Request == single thread, but when async processing was >>>>> introduced no one thought to clarify that the spawning of a child thread >>>>> from the original HTTP request retains the parent's context. >>>>> >>>>> This is another requested feature, but looks more like a bug or gap in >>>>> the spec. >>>>> >>>>> John >>>>> >>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>> >>>>>>> Let's see. I suspect the specification text for EE concurrency is >>>>>>> generic enough for implementations to also be able to cover CDI scopes or >>>>>>> any other Java EE API context propagation needs. This means the issue needs >>>>>>> to be solved at the individual implementation level. Changing anything in >>>>>>> the spec is probably just unnecessary ceremony in this case. >>>>>>> >>>>>>> >>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI >>>>>> still prevent it to work since it would violate the spec to propagate it >>>>>> while request scope is bound to another thread ( >>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>> handles async listener but not the main AsyncContext part). >>>>>> >>>>>> >>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>> >>>>>>>> This frankly surprises me. I'll check the specification text. This >>>>>>>> might indeed just be an implementation bug. The EE concurrency utilities >>>>>>>> are supposed to be copying all relevant context. If this is an issue than >>>>>>>> it has to be that it is not copying enough of the HTTP request context for >>>>>>>> CDI to work. >>>>>>>> >>>>>>>> >>>>>>> The issue is not technical since I got it working but needed to >>>>>>> reverse. From my understanding ee concurrency utilities was done in a time >>>>>>> CDI was not there so it just ignored it somehow and it hasnt been updated >>>>>>> when integrated to the spec. Now with the wording of the CDI - and TCK - it >>>>>>> is impossible to make it working since request scope is bound the thre >>>>>>> request thread - and not the request. Side note: same applies to session >>>>>>> scope and conversation. >>>>>>> >>>>>>> >>>>>>>> Surely the Red Hat folks can quickly shed some light here since >>>>>>>> they implement essentially this whole stack? >>>>>>>> >>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>> >>>>>>>>> Can you kindly try to make the example a bit simpler? It's >>>>>>>>> important to make the case for how likely this is supposed to occur in most >>>>>>>>> business applications. >>>>>>>>> >>>>>>>>> Also, other than making sure that the executor service is >>>>>>>>> propagating thread local request contexts correctly what other solution are >>>>>>>>> you proposing? Did you check the specification? How sure are you that this >>>>>>>>> isn't simply an implementation bug? >>>>>>>>> >>>>>>>>> As far as I know the executor service is supposed to be preserving >>>>>>>>> all relevant parts of the EE context? >>>>>>>>> >>>>>>>>> >>>>>>>> Not in concurrency-utilities for EE at least. That was the first >>>>>>>> impl I did then Mark pointed out it was violating CDI spec and request >>>>>>>> scope definition. There is a kind of contracdiction there cause >>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>>> tackle it. >>>>>>>> >>>>>>>> >>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e >>>>>>>>> help? >>>>>>>>> >>>>>>>>> Idea is to give an API to make: >>>>>>>>> >>>>>>>>> public void complete() { >>>>>>>>> try { >>>>>>>>> asyncContext.complete(); >>>>>>>>> } finally { >>>>>>>>> auditContext.end(); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> working without hacky and almost impossible context pushing (cause >>>>>>>>> of injections nature you are not supposed to know what to push in the >>>>>>>>> context when going async). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Romain Manni-Bucau >>>>>>>>> @rmannibucau | Blog >>>>>>>>> | Github >>>>>>>>> | LinkedIn >>>>>>>>> | Tomitriber >>>>>>>>> >>>>>>>>> >>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>> >>>>>>>>>> Can you kindly share an annotated code example of the proposed >>>>>>>>>> solution so we can all follow and discuss this? >>>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>>>> >>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi >>>>>>>>>> scope. Idea is to follow request scope more than cdi spec allows. First >>>>>>>>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>>>>>>>> CDI one so here it is. >>>>>>>>>> >>>>>>>>>> Sample: >>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set >>>>>>>>>> on it. The i go async (AsyncContext) and trigger a task in another thread. >>>>>>>>>> It would be neat - and mandatory in some case by the loose coupling nature >>>>>>>>>> of CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>>>>>>>> dependency you can easily use message passing pattern - but you loose the >>>>>>>>>> loose coupling cause you need to know until which level you unwrap, think t >>>>>>>>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>>>>>>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>>>>>>>> security...) so you can't really do it easily/naturally. >>>>>>>>>> >>>>>>>>>> Bonus: >>>>>>>>>> One very verbose way is to be able to kind of push/pop an >>>>>>>>>> existing context in a thread - wrappers doing it on a >>>>>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>>>>> >>>>>>>>>> Question: >>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>> >>>>>>>>>> Side note: this is really about the fact to reuse a "context >>>>>>>>>> context" (its current instances map) in another thread the more >>>>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>>>> question for now. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau | Blog >>>>>>>>>> | Github >>>>>>>>>> | LinkedIn >>>>>>>>>> | Tomitriber >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> cdi-dev mailing list >>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/f5a8a7b6/attachment-0001.html From rmannibucau at gmail.com Mon Mar 7 05:30:29 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 11:30:29 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> <2C765CDD-E086-4D24-9BDB-38A37C27CF1B@yahoo.de> Message-ID: 2016-03-07 11:27 GMT+01:00 Stephan Knitelius : > >>" > >>Tasks that are submitted to a managed instance of ExecutorService may > still be running after the lifecycle of the submitting >>component. > Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or > @ConversationScoped are not >>recommended to use as tasks as it cannot be > guaranteed that the tasks will complete before the CDI context is > destroyed. > >>" > > > >States that the context is not inherited, is that what you mean? > > Sounds more like a warning that the CDI context may be destroyed prior to > completion of the asynchronous task. Therefor we might be able to clear > this up on the CDI side, by keeping contexts alive as long as they are > associated with > 1 executing threads. > > means the context is not bound to (controlled by) this thread so the behavior is undefined. Also this *only* converns submitted tasks and not injections used inside the task so: es.submit(() -> { reqScopedInstance.doSomeWork(); }); is not under this statement at all. > > On Mon, 7 Mar 2016 at 09:50 Romain Manni-Bucau > wrote: > >> " >> Tasks that are submitted to a managed instance of ExecutorService may >> still be running after the lifecycle of the submitting component. >> Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or >> @ConversationScoped are not recommended to use as tasks as it cannot be >> guaranteed that the tasks will complete before the CDI context is >> destroyed. >> " >> >> States that the context is not inherited, is that what you mean? >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >> >>> The specification currently references pretty much all the major CDI >>> scopes specifically with the issue of propagation and lifecycle in mind. >>> Please see section 2.3. >>> >>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >>> Specifically >>> >>> The containers mimic ejb for propagation for a good reason! >>> No session e.g. , new TX, etc >>> >>> Sadly the concurrency utilis only mention @ApplicationScoped, so the >>> Request Context not only doesn't get propagated (which is good), but also >>> doesn't get set up (which is crap). >>> >>> LieGrue, >>> Strub >>> >>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>> >>> I agree, in a sense, with what you're saying. There's nothing in this >>> spec that says it wouldn't be propagated. However, there's nothing in this >>> spec that states clearly that CDI contexts are propagated. >>> >>> If you look at the RI, the RI only seems to propagate transaction >>> state. Considering the age of the spec, I'm not surprised to see that. >>> The worst part is that right now, outside of the ASF, all other EE7 impls >>> seem to be using the RI for concurrency. >>> >>> I'm fairly certain that from this spec's standpoint, the only thing >>> that's actually propagated is the transaction. >>> >>> John >>> >>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman >>> wrote: >>> >>>> I am re-reading the spec end to end again right now. So far it seems I >>>> have remembered everything correctly. >>>> >>>> You should read over section 2.3. What it is saying is that a container >>>> implementing the Java EE concurrency utilities should ensure whatever >>>> contextual information is needed for managed components to work correctly >>>> should be propagated automatically. For the correct implementation of CDI >>>> scopes, this should also mean any currently active scopes. The section you >>>> are referring to is basically implying that thinking that it is possible to >>>> use these scoped beans in tasks (albeit not reliably since beans could go >>>> out of scope before the thread finishes - for example if the request ends). >>>> >>>> This does not have anything to do with the context service per se. The >>>> context service is an SPI of sorts to allow end user developers to do for >>>> their own applications what the container does behind the scenes for >>>> managed component context propagation. >>>> >>>> I'll read over the entire spec to see if there is anything to >>>> contradict this. If that's not the case what Romain is describing is most >>>> likely an implementation specific bug that did not take into account CDI >>>> scope propagation. >>>> >>>> On Mar 6, 2016, at 4:23 PM, John D. Ament >>>> wrote: >>>> >>>> Reza, >>>> >>>> I read through the concurrency utils spec. Was there a specific >>>> section you had in mind? The only references to CDI were near the >>>> beginning warning users to not use Request/Session scoped beans as tasks >>>> since the outer most context may be destroyed before the work is done. >>>> >>>> I have a feeling what you're referring to is the context service: >>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>> >>>> If that's the case, then basically this should work OOTB right? >>>> >>>> Task task = new MyTask(); >>>> task = contextService.createContextualProxy(task, Task.class); >>>> executor.submit(task); >>>> >>>> // now magically the context should be prop'd? >>>> >>>> Is that about right? >>>> >>>> John >>>> >>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman >>>> wrote: >>>> >>>>> Have you actually looked at the EE concurrency spec text in detail? >>>>> What does it say about managed component context propagation? >>>>> >>>>> Without actually doing that further discussing this is just taking >>>>> shots in the dark. As an implementer it should not surprise you that this >>>>> might simply be a bug because the person implementing the concurrency >>>>> utilities for the EE runtime was not told about what to copy over into the >>>>> new thread for CDI to work correctly. >>>>> >>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau >>>>> wrote: >>>>> >>>>> >>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>> >>>>>> As far as I know this is precisely the sort of thing that the EE >>>>>> concurrency spec is intended for. It is supposed to copy over everything >>>>>> from the underlying thread local context into the new thread for all EE >>>>>> managed components to function. Since CDI beans are also EE container >>>>>> managed, it also applies to CDI beans as well. The EE vendor is supposed to >>>>>> make sure this works properly. >>>>>> >>>>>> I don't think the concurrency utilities specifically lists APIs for >>>>>> which thread context propagation should work. If this doesn't work in a >>>>>> specific implementation it's most likely because they didn't take CDI into >>>>>> account in their own EE concurrency implementation. >>>>>> >>>>>> >>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and >>>>> @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly >>>>> named. So to solve it we would need another scope as I mentionned several >>>>> times on this list 100% matching servlet instances lifecycles (on a pure >>>>> CDI side we have the same issue for sessions which are recycled during a >>>>> request, the session scope is corrupted *by spec* in term of user behavior). >>>>> >>>>> >>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament >>>>>> wrote: >>>>>> >>>>>> The section of the spec you link to makes no references to threads. >>>>>> 6.3 makes some notes about normal scopes and threads, and specifically >>>>>> says that a context is bound to one or more threads. >>>>>> >>>>>> I think what's happened is that over the years, people have simply >>>>>> bound HTTP Request == single thread, but when async processing was >>>>>> introduced no one thought to clarify that the spawning of a child thread >>>>>> from the original HTTP request retains the parent's context. >>>>>> >>>>>> This is another requested feature, but looks more like a bug or gap >>>>>> in the spec. >>>>>> >>>>>> John >>>>>> >>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wrote: >>>>>> >>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>> >>>>>>>> Let's see. I suspect the specification text for EE concurrency is >>>>>>>> generic enough for implementations to also be able to cover CDI scopes or >>>>>>>> any other Java EE API context propagation needs. This means the issue needs >>>>>>>> to be solved at the individual implementation level. Changing anything in >>>>>>>> the spec is probably just unnecessary ceremony in this case. >>>>>>>> >>>>>>>> >>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. >>>>>>> CDI still prevent it to work since it would violate the spec to propagate >>>>>>> it while request scope is bound to another thread ( >>>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>>> handles async listener but not the main AsyncContext part). >>>>>>> >>>>>>> >>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>> >>>>>>>>> This frankly surprises me. I'll check the specification text. This >>>>>>>>> might indeed just be an implementation bug. The EE concurrency utilities >>>>>>>>> are supposed to be copying all relevant context. If this is an issue than >>>>>>>>> it has to be that it is not copying enough of the HTTP request context for >>>>>>>>> CDI to work. >>>>>>>>> >>>>>>>>> >>>>>>>> The issue is not technical since I got it working but needed to >>>>>>>> reverse. From my understanding ee concurrency utilities was done in a time >>>>>>>> CDI was not there so it just ignored it somehow and it hasnt been updated >>>>>>>> when integrated to the spec. Now with the wording of the CDI - and TCK - it >>>>>>>> is impossible to make it working since request scope is bound the thre >>>>>>>> request thread - and not the request. Side note: same applies to session >>>>>>>> scope and conversation. >>>>>>>> >>>>>>>> >>>>>>>>> Surely the Red Hat folks can quickly shed some light here since >>>>>>>>> they implement essentially this whole stack? >>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>> >>>>>>>>>> Can you kindly try to make the example a bit simpler? It's >>>>>>>>>> important to make the case for how likely this is supposed to occur in most >>>>>>>>>> business applications. >>>>>>>>>> >>>>>>>>>> Also, other than making sure that the executor service is >>>>>>>>>> propagating thread local request contexts correctly what other solution are >>>>>>>>>> you proposing? Did you check the specification? How sure are you that this >>>>>>>>>> isn't simply an implementation bug? >>>>>>>>>> >>>>>>>>>> As far as I know the executor service is supposed to be >>>>>>>>>> preserving all relevant parts of the EE context? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Not in concurrency-utilities for EE at least. That was the first >>>>>>>>> impl I did then Mark pointed out it was violating CDI spec and request >>>>>>>>> scope definition. There is a kind of contracdiction there cause >>>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>>>> tackle it. >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e >>>>>>>>>> help? >>>>>>>>>> >>>>>>>>>> Idea is to give an API to make: >>>>>>>>>> >>>>>>>>>> public void complete() { >>>>>>>>>> try { >>>>>>>>>> asyncContext.complete(); >>>>>>>>>> } finally { >>>>>>>>>> auditContext.end(); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> working without hacky and almost impossible context pushing >>>>>>>>>> (cause of injections nature you are not supposed to know what to push in >>>>>>>>>> the context when going async). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau | Blog >>>>>>>>>> | Github >>>>>>>>>> | LinkedIn >>>>>>>>>> | Tomitriber >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>> >>>>>>>>>>> Can you kindly share an annotated code example of the proposed >>>>>>>>>>> solution so we can all follow and discuss this? >>>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>>>>> >>>>>>>>>>> Hi guys, >>>>>>>>>>> >>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a >>>>>>>>>>> cdi scope. Idea is to follow request scope more than cdi spec allows. First >>>>>>>>>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>>>>>>>>> CDI one so here it is. >>>>>>>>>>> >>>>>>>>>>> Sample: >>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set >>>>>>>>>>> on it. The i go async (AsyncContext) and trigger a task in another thread. >>>>>>>>>>> It would be neat - and mandatory in some case by the loose coupling nature >>>>>>>>>>> of CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>>>>>>>>> dependency you can easily use message passing pattern - but you loose the >>>>>>>>>>> loose coupling cause you need to know until which level you unwrap, think t >>>>>>>>>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>>>>>>>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>>>>>>>>> security...) so you can't really do it easily/naturally. >>>>>>>>>>> >>>>>>>>>>> Bonus: >>>>>>>>>>> One very verbose way is to be able to kind of push/pop an >>>>>>>>>>> existing context in a thread - wrappers doing it on a >>>>>>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>>>>>> >>>>>>>>>>> Question: >>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>> >>>>>>>>>>> Side note: this is really about the fact to reuse a "context >>>>>>>>>>> context" (its current instances map) in another thread the more >>>>>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>>>>> question for now. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>> @rmannibucau | Blog >>>>>>>>>>> | Github >>>>>>>>>>> | LinkedIn >>>>>>>>>>> | Tomitriber >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/850fb65a/attachment-0001.html From antoine at sabot-durand.net Mon Mar 7 05:33:15 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 07 Mar 2016 10:33:15 +0000 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: John, I partially disagree with you here. CDI innovated from the beginning. When the project started in 2007 there wasn't any strong typed DI framework around. No spec proposed a SPI like CDI and eventing system in DI framework were inexistant or nearly unused (Who eared of event bus in Spring ?). Following your definition of what is a specification CDI wouldn't be here today. The challenge is to find a real balance between innovating (but not to much and without breaking backward compatibility) and take working ideas around in impl or other framework (like builders from DeltaSpike or Weld bootstrap API that we are about to propose to complete SE API) The problem with CDI, is that it's still limited to Java EE so you'll only have very few user giving you feedback on impl specific features. It will probably change when we'll add SE support but in the meantime we should try to deliver something useful for our users and something they asked (like async events). As I said in my previous mail, Spec annexe can be used to put features that didn't gather enough truct from the EG to be specified. It's a step between spec and impl. Bean validation already done that in 1.0 with method validation http://beanvalidation.org/1.0/spec/#appendix-methodlevelvalidation And standardize it in 1.1 after having gathered users feedback: http://beanvalidation.org/1.1/spec/#d0e267 Antoine Le dim. 6 mars 2016 ? 18:41, John D. Ament a ?crit : > On Sun, Mar 6, 2016 at 12:25 PM Romain Manni-Bucau > wrote: > >> 2016-03-06 18:02 GMT+01:00 John D. Ament : >> >>> What I think would be even better is to see this implemented in the >>> impls (Weld & OWB) and see how users use it, in a release that's not >>> plastered with Alpha or Experimental all over it. While I think we were >>> all wary about it, we need real end user input from the impl standpoint to >>> figure out what makes sense to standardize on. >>> >>> >> Or just do the opposite and *standardize* it. We can use Rx* feedbacks >> but it doesnt' match event case at all which is a real small subset of the >> reactive programming so I guess easiness should be what drives us there and >> integration at least with the JVM so CFuture version sounds more natural >> than CStage one. Difference is very small at method level but at utility >> level it is. >> >> Side note: a Weld or OWB release without experimental/alpha sounds worse >> if the spec changes later. A compromise can be an extension doing it >> already you can drop in any of these containers. >> > > There seems to be a general misunderstanding about how the specs are > intended to work. You standardize on things that as a group everyone has > agreed would work in a specific way. Right now, the CDI EG is innovating > and standardizing on those innovations instead of standardizing on the > features already available in the various impls. Lets take a few examples > of where impls deviate from the specs. > > - Bean Validation: Hibernate Validator has a suite of built in validations > https://github.com/hibernate/hibernate-validator/tree/master/engine/src/main/java/org/hibernate/validator/constraints - > these constraints can in theory work in any pluggable environment, but come > with their core engine built in, for people to leverage. These are good > targets to leverage in the core spec when its seen as being very useful. > > - JAX-RS : All of the implementations had client impls paired up with > their 1.1 compliant releases, even though it wasn't required. Why? Because > it made a ton of sense. Then see what happened afterwards, the EG came > together and standardized on a Client API that took a lot of the great > features in each impl and made them consistent. > > - EJB: Lets not forget that the removal of home/remote/local interfaces > came from a combination of xdoclet and spring. The EG came together, saw > that what was in use and figured out how to standardize on it once the > language features were available. > > - Singleton EJBs: An extension of EJB 3, most vendors supported a form of > singleton in their EJBs, and the EJB EG agreed upon it in addition to some > concurrency issues that had to be addressed. > > - CDI: Lets not forget about the hard work people like strub have put into > making CDI work well. Scoped Beans only? Awesome idea. > https://github.com/apache/openwebbeans/commit/3b3640e17c88e7c095563337194ba23c6f9e1689 > He didn't wait for the EG to standardize on anything before implementing. > > - JPA: Lets not forget that HIbernate supports in dual hierarchies the > EntityManager and Session interfaces concurrently. Want to use HQL in your > @NamedQuery? Sure, it works fine. > > Bottom line, we need to get these features out into the wild, let people > play and come back with input on the various impls. There's nothing > stopping the weld team from introducing > org.jboss.weld.events.api.AsyncEvent that supports CompletableFuture and > CompletionStage, allowing app developers to consume this via an injection > point just like Event works today, @Inject AsyncEvent. Even if thats > not the spec compliant way to do it long term, it makes it clear that > you're using a provider specific API. > > In addition, there would be nothing stopping either team from introducing > support for @Priority on observer methods. There's no API change, no spec > change required. The spec doesn't mandate that it works, but there's > nothing stopping your impl from allowing it. The spec doesn't say you > absolutely cannot leverage it. > > John > > >> >> >>> John >>> >>> >>> On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman >>> wrote: >>> >>>> How much end user feedback has there been on this? I have to be honest >>>> that it surprises me to find this out now. >>>> >>>> This to me stands out as an obvious usability problem. >>>> CompletableFuture is the obvious top level end user API, not >>>> CompletionStage. Not going with CompletableFuture is very likely to confuse >>>> most people. The last thing we need is more potential usability problems in >>>> Java EE APIs. >>>> >>>> On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau >>>> wrote: >>>> >>>> Hi guys, >>>> >>>> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>> can we move back to CompletionFuture? >>>> >>>> It would allow for instance: >>>> >>>> // doesn't work with CompletionStage >>>> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>> .then(...) >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/5520e122/attachment.html From reza_rahman at lycos.com Mon Mar 7 07:56:22 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 07:56:22 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <56DD30CE.6070101@redhat.com> References: <56DD30CE.6070101@redhat.com> Message-ID: Already explained what the issue is. This is a usability hazard. > On Mar 7, 2016, at 2:42 AM, Martin Kouba wrote: > > Dne 6.3.2016 v 16:37 Reza Rahman napsal(a): >> How much end user feedback has there been on this? I have to be honest >> that it surprises me to find this out now. > > Well, this was discussed many times (ML, EG mtgs, F2F, etc.). > >> >> This to me stands out as an obvious usability problem. CompletableFuture >> is the obvious top level end user API, not CompletionStage. > > Is it obvious? For me the CompletionStage looks more appropriate. But I'm open for discussions. > >> Not going >> with CompletableFuture is very likely to confuse most people. The last >> thing we need is more potential usability problems in Java EE APIs. >> >> On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau > > wrote: >> >>> Hi guys, >>> >>> as a user having a ComlpetionStage makes me loose some JDK utilities, >>> can we move back to CompletionFuture? >>> >>> It would allow for instance: >>> >>> // doesn't work with CompletionStage >>> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>> .then(...) >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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 From john.d.ament at gmail.com Mon Mar 7 07:57:40 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 07 Mar 2016 12:57:40 +0000 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: Antoine, I don't think we have vastly differing opinions here. My main concern is that the CDI Impls wait for the spec to say something should be done before implementing. There is very little innovation that happens within the implementations, as a result its very hard for the EG to decide how something should work - you have anywhere from 0 to 1 capabilities existing in the wild to see how it should behave. And actually I'll disagree pretty heavily about how CDI came to be. Most of what was Seam 2 went into WebBeans. The CDI behaviors were adapted from Seam 2 from a DI stand point, with some clean up with where there were gaps, things that didn't make sense, and things that just didn't belong. John On Mon, Mar 7, 2016 at 5:33 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > John, I partially disagree with you here. > > CDI innovated from the beginning. When the project started in 2007 there > wasn't any strong typed DI framework around. No spec proposed a SPI like > CDI and eventing system in DI framework were inexistant or nearly unused > (Who eared of event bus in Spring ?). Following your definition of what is > a specification CDI wouldn't be here today. > > The challenge is to find a real balance between innovating (but not to > much and without breaking backward compatibility) and take working ideas > around in impl or other framework (like builders from DeltaSpike or Weld > bootstrap API that we are about to propose to complete SE API) > > The problem with CDI, is that it's still limited to Java EE so you'll only > have very few user giving you feedback on impl specific features. It will > probably change when we'll add SE support but in the meantime we should try > to deliver something useful for our users and something they asked (like > async events). > > As I said in my previous mail, Spec annexe can be used to put features > that didn't gather enough truct from the EG to be specified. It's a step > between spec and impl. Bean validation already done that in 1.0 with method > validation > > http://beanvalidation.org/1.0/spec/#appendix-methodlevelvalidation > > And standardize it in 1.1 after having gathered users feedback: > > http://beanvalidation.org/1.1/spec/#d0e267 > > > Antoine > Le dim. 6 mars 2016 ? 18:41, John D. Ament a > ?crit : > >> On Sun, Mar 6, 2016 at 12:25 PM Romain Manni-Bucau >> wrote: >> >>> 2016-03-06 18:02 GMT+01:00 John D. Ament : >>> >>>> What I think would be even better is to see this implemented in the >>>> impls (Weld & OWB) and see how users use it, in a release that's not >>>> plastered with Alpha or Experimental all over it. While I think we were >>>> all wary about it, we need real end user input from the impl standpoint to >>>> figure out what makes sense to standardize on. >>>> >>>> >>> Or just do the opposite and *standardize* it. We can use Rx* feedbacks >>> but it doesnt' match event case at all which is a real small subset of the >>> reactive programming so I guess easiness should be what drives us there and >>> integration at least with the JVM so CFuture version sounds more natural >>> than CStage one. Difference is very small at method level but at utility >>> level it is. >>> >>> Side note: a Weld or OWB release without experimental/alpha sounds worse >>> if the spec changes later. A compromise can be an extension doing it >>> already you can drop in any of these containers. >>> >> >> There seems to be a general misunderstanding about how the specs are >> intended to work. You standardize on things that as a group everyone has >> agreed would work in a specific way. Right now, the CDI EG is innovating >> and standardizing on those innovations instead of standardizing on the >> features already available in the various impls. Lets take a few examples >> of where impls deviate from the specs. >> >> - Bean Validation: Hibernate Validator has a suite of built in >> validations >> https://github.com/hibernate/hibernate-validator/tree/master/engine/src/main/java/org/hibernate/validator/constraints - >> these constraints can in theory work in any pluggable environment, but come >> with their core engine built in, for people to leverage. These are good >> targets to leverage in the core spec when its seen as being very useful. >> >> - JAX-RS : All of the implementations had client impls paired up with >> their 1.1 compliant releases, even though it wasn't required. Why? Because >> it made a ton of sense. Then see what happened afterwards, the EG came >> together and standardized on a Client API that took a lot of the great >> features in each impl and made them consistent. >> >> - EJB: Lets not forget that the removal of home/remote/local interfaces >> came from a combination of xdoclet and spring. The EG came together, saw >> that what was in use and figured out how to standardize on it once the >> language features were available. >> >> - Singleton EJBs: An extension of EJB 3, most vendors supported a form of >> singleton in their EJBs, and the EJB EG agreed upon it in addition to some >> concurrency issues that had to be addressed. >> >> - CDI: Lets not forget about the hard work people like strub have put >> into making CDI work well. Scoped Beans only? Awesome idea. >> https://github.com/apache/openwebbeans/commit/3b3640e17c88e7c095563337194ba23c6f9e1689 >> He didn't wait for the EG to standardize on anything before implementing. >> >> - JPA: Lets not forget that HIbernate supports in dual hierarchies the >> EntityManager and Session interfaces concurrently. Want to use HQL in your >> @NamedQuery? Sure, it works fine. >> >> Bottom line, we need to get these features out into the wild, let people >> play and come back with input on the various impls. There's nothing >> stopping the weld team from introducing >> org.jboss.weld.events.api.AsyncEvent that supports CompletableFuture and >> CompletionStage, allowing app developers to consume this via an injection >> point just like Event works today, @Inject AsyncEvent. Even if thats >> not the spec compliant way to do it long term, it makes it clear that >> you're using a provider specific API. >> >> In addition, there would be nothing stopping either team from introducing >> support for @Priority on observer methods. There's no API change, no spec >> change required. The spec doesn't mandate that it works, but there's >> nothing stopping your impl from allowing it. The spec doesn't say you >> absolutely cannot leverage it. >> >> John >> >> >>> >>> >>>> John >>>> >>>> >>>> On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman >>>> wrote: >>>> >>>>> How much end user feedback has there been on this? I have to be honest >>>>> that it surprises me to find this out now. >>>>> >>>>> This to me stands out as an obvious usability problem. >>>>> CompletableFuture is the obvious top level end user API, not >>>>> CompletionStage. Not going with CompletableFuture is very likely to confuse >>>>> most people. The last thing we need is more potential usability problems in >>>>> Java EE APIs. >>>>> >>>>> On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau >>>>> wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>>> can we move back to CompletionFuture? >>>>> >>>>> It would allow for instance: >>>>> >>>>> // doesn't work with CompletionStage >>>>> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>>> .then(...) >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog >>>>> | Github >>>>> | LinkedIn >>>>> | Tomitriber >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at 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 at 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 at 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 at 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/efd24dea/attachment.html From reza_rahman at lycos.com Mon Mar 7 08:01:53 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 08:01:53 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <56DD2F49.3010900@redhat.com> References: <56DD2F49.3010900@redhat.com> Message-ID: <1DA48EEB-E066-433A-B92F-1C40BDE9A482@lycos.com> I think in this case it is worth exploring to see if there is another way of accomplishing this goal. This is an issue generally for Java EE, not CDI alone. I don't think we can afford to avoid the CompletableFuture API for this reason. Simply too many people will expect that API. > On Mar 7, 2016, at 2:3AM, Martin Kouba wrote: > > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >> Hi guys, >> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >> can we move back to CompletionFuture? >> >> It would allow for instance: >> >> // doesn't work with CompletionStage >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >> .then(...) > > Well, this should work if the underlying CompletionStage impl supports > toCompletableFuture(), i.e. in Weld 3: > > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), > event2.fireAsync(...).toCompletableFuture()) > > AFAIK the default async execution facility of CompletableFuture is > ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the > CompletionStage interface allows us to wrap the async calls without the > specified executor (e.g. CompletionStage.thenApplyAsync(Function T, ? extends U>)) and supply a default one provided by the impl. > > >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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. From rmannibucau at gmail.com Mon Mar 7 08:02:56 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 14:02:56 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: Message-ID: 2016-03-07 13:57 GMT+01:00 John D. Ament : > Antoine, > > I don't think we have vastly differing opinions here. My main concern is > that the CDI Impls wait for the spec to say something should be done before > implementing. There is very little innovation that happens within the > implementations, as a result its very hard for the EG to decide how > something should work - you have anywhere from 0 to 1 capabilities existing > in the wild to see how it should behave. > > Sadly it is like that and guess will stay cause spec are used for standards and any innovation doesn't make users happy if at programming level (it is on ops side) - and believe me I say it after having tried very hard the other way around. > And actually I'll disagree pretty heavily about how CDI came to be. Most > of what was Seam 2 went into WebBeans. The CDI behaviors were adapted from > Seam 2 from a DI stand point, with some clean up with where there were > gaps, things that didn't make sense, and things that just didn't belong. > > That's the way which works the best: you do something outside spec umbrella (including "official implementations") then you standardize it. DeltaSpike is a good example of it: no impl shadow but new proposals which could be standardized as Seam has been. > John > > > On Mon, Mar 7, 2016 at 5:33 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> John, I partially disagree with you here. >> >> CDI innovated from the beginning. When the project started in 2007 there >> wasn't any strong typed DI framework around. No spec proposed a SPI like >> CDI and eventing system in DI framework were inexistant or nearly unused >> (Who eared of event bus in Spring ?). Following your definition of what is >> a specification CDI wouldn't be here today. >> >> The challenge is to find a real balance between innovating (but not to >> much and without breaking backward compatibility) and take working ideas >> around in impl or other framework (like builders from DeltaSpike or Weld >> bootstrap API that we are about to propose to complete SE API) >> >> The problem with CDI, is that it's still limited to Java EE so you'll >> only have very few user giving you feedback on impl specific features. It >> will probably change when we'll add SE support but in the meantime we >> should try to deliver something useful for our users and something they >> asked (like async events). >> >> As I said in my previous mail, Spec annexe can be used to put features >> that didn't gather enough truct from the EG to be specified. It's a step >> between spec and impl. Bean validation already done that in 1.0 with method >> validation >> >> http://beanvalidation.org/1.0/spec/#appendix-methodlevelvalidation >> >> And standardize it in 1.1 after having gathered users feedback: >> >> http://beanvalidation.org/1.1/spec/#d0e267 >> >> >> Antoine >> Le dim. 6 mars 2016 ? 18:41, John D. Ament a >> ?crit : >> >>> On Sun, Mar 6, 2016 at 12:25 PM Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> 2016-03-06 18:02 GMT+01:00 John D. Ament : >>>> >>>>> What I think would be even better is to see this implemented in the >>>>> impls (Weld & OWB) and see how users use it, in a release that's not >>>>> plastered with Alpha or Experimental all over it. While I think we were >>>>> all wary about it, we need real end user input from the impl standpoint to >>>>> figure out what makes sense to standardize on. >>>>> >>>>> >>>> Or just do the opposite and *standardize* it. We can use Rx* feedbacks >>>> but it doesnt' match event case at all which is a real small subset of the >>>> reactive programming so I guess easiness should be what drives us there and >>>> integration at least with the JVM so CFuture version sounds more natural >>>> than CStage one. Difference is very small at method level but at utility >>>> level it is. >>>> >>>> Side note: a Weld or OWB release without experimental/alpha sounds >>>> worse if the spec changes later. A compromise can be an extension doing it >>>> already you can drop in any of these containers. >>>> >>> >>> There seems to be a general misunderstanding about how the specs are >>> intended to work. You standardize on things that as a group everyone has >>> agreed would work in a specific way. Right now, the CDI EG is innovating >>> and standardizing on those innovations instead of standardizing on the >>> features already available in the various impls. Lets take a few examples >>> of where impls deviate from the specs. >>> >>> - Bean Validation: Hibernate Validator has a suite of built in >>> validations >>> https://github.com/hibernate/hibernate-validator/tree/master/engine/src/main/java/org/hibernate/validator/constraints - >>> these constraints can in theory work in any pluggable environment, but come >>> with their core engine built in, for people to leverage. These are good >>> targets to leverage in the core spec when its seen as being very useful. >>> >>> - JAX-RS : All of the implementations had client impls paired up with >>> their 1.1 compliant releases, even though it wasn't required. Why? Because >>> it made a ton of sense. Then see what happened afterwards, the EG came >>> together and standardized on a Client API that took a lot of the great >>> features in each impl and made them consistent. >>> >>> - EJB: Lets not forget that the removal of home/remote/local interfaces >>> came from a combination of xdoclet and spring. The EG came together, saw >>> that what was in use and figured out how to standardize on it once the >>> language features were available. >>> >>> - Singleton EJBs: An extension of EJB 3, most vendors supported a form >>> of singleton in their EJBs, and the EJB EG agreed upon it in addition to >>> some concurrency issues that had to be addressed. >>> >>> - CDI: Lets not forget about the hard work people like strub have put >>> into making CDI work well. Scoped Beans only? Awesome idea. >>> https://github.com/apache/openwebbeans/commit/3b3640e17c88e7c095563337194ba23c6f9e1689 >>> He didn't wait for the EG to standardize on anything before implementing. >>> >>> - JPA: Lets not forget that HIbernate supports in dual hierarchies the >>> EntityManager and Session interfaces concurrently. Want to use HQL in your >>> @NamedQuery? Sure, it works fine. >>> >>> Bottom line, we need to get these features out into the wild, let people >>> play and come back with input on the various impls. There's nothing >>> stopping the weld team from introducing >>> org.jboss.weld.events.api.AsyncEvent that supports CompletableFuture and >>> CompletionStage, allowing app developers to consume this via an injection >>> point just like Event works today, @Inject AsyncEvent. Even if thats >>> not the spec compliant way to do it long term, it makes it clear that >>> you're using a provider specific API. >>> >>> In addition, there would be nothing stopping either team from >>> introducing support for @Priority on observer methods. There's no API >>> change, no spec change required. The spec doesn't mandate that it works, >>> but there's nothing stopping your impl from allowing it. The spec doesn't >>> say you absolutely cannot leverage it. >>> >>> John >>> >>> >>>> >>>> >>>>> John >>>>> >>>>> >>>>> On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman >>>>> wrote: >>>>> >>>>>> How much end user feedback has there been on this? I have to be >>>>>> honest that it surprises me to find this out now. >>>>>> >>>>>> This to me stands out as an obvious usability problem. >>>>>> CompletableFuture is the obvious top level end user API, not >>>>>> CompletionStage. Not going with CompletableFuture is very likely to confuse >>>>>> most people. The last thing we need is more potential usability problems in >>>>>> Java EE APIs. >>>>>> >>>>>> On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau >>>>>> wrote: >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>>>> can we move back to CompletionFuture? >>>>>> >>>>>> It would allow for instance: >>>>>> >>>>>> // doesn't work with CompletionStage >>>>>> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>>>> .then(...) >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog >>>>>> | Github >>>>>> | LinkedIn >>>>>> | Tomitriber >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at 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 at 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 at 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 at 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. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/7767e59c/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 08:06:41 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 08:06:41 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> <2C765CDD-E086-4D24-9B DB-38A37C27CF1B@yahoo.de> Message-ID: What this is saying is that it is not recommended to use them because of the possible life-cycle mismatch. If they are not supposed to work at all, the specification would have simply stated it won't work. Anyway personally I have no reason to further discuss this. I'm going to try to find a way to get this done for developers sooner rather than later. If TomEE does not want to do it, too bad for developers. > On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau wrote: > > " > Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. > " > > States that the context is not inherited, is that what you mean? > > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2016-03-07 5:57 GMT+01:00 Reza Rahman : >> The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. >> >>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >>> Specifically >> >>> The containers mimic ejb for propagation for a good reason! >>> No session e.g. , new TX, etc >>> >>> Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). >>> >>> LieGrue, >>> Strub >>> >>>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>>> >>>> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >>>> >>>> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >>>> >>>> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >>>> >>>> John >>>> >>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >>>>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >>>>> >>>>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >>>>> >>>>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >>>>> >>>>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >>>>> >>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >>>>> >>>>>> Reza, >>>>>> >>>>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>>>>> >>>>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>> >>>>>> If that's the case, then basically this should work OOTB right? >>>>>> >>>>>> Task task = new MyTask(); >>>>>> task = contextService.createContextualProxy(task, Task.class); >>>>>> executor.submit(task); >>>>>> >>>>>> // now magically the context should be prop'd? >>>>>> >>>>>> Is that about right? >>>>>> >>>>>> John >>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>>>>> >>>>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>>>>> >>>>>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>>>>>> >>>>>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>>>>>> >>>>>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>>>>>> >>>>>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>>>>>>> >>>>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>>>>>>> >>>>>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>>>>>>> >>>>>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>>>>>>> >>>>>>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> public void complete() { >>>>>>>>>>>>>>>>> try { >>>>>>>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>>>>>>>> } finally { >>>>>>>>>>>>>>>>> auditContext.end(); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Sample: >>>>>>>>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Bonus: >>>>>>>>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Question: >>>>>>>>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/aca995e4/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 08:11:57 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 08:11:57 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> Message-ID: <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. > On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau wrote: > > 2016-03-07 9:07 GMT+01:00 Martin Kouba : >> >> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>> >>> Le 7 mars 2016 08:35, "Martin Kouba" >> > a ?crit : >>> > >>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>> > >>> >> Hi guys, >>> >> >>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>> >> can we move back to CompletionFuture? >>> >> >>> >> It would allow for instance: >>> >> >>> >> // doesn't work with CompletionStage >>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>> >> .then(...) >>> > >>> > >>> > Well, this should work if the underlying CompletionStage impl >>> supports toCompletableFuture(), i.e. in Weld 3: >>> > >>> >>> Yes but it is not natural to convert it IMO = we can do better >>> >>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>> event2.fireAsync(...).toCompletableFuture()) >>> > >>> > AFAIK the default async execution facility of CompletableFuture is >>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>> CompletionStage interface allows us to wrap the async calls without the >>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>> T, ? extends U>)) and supply a default one provided by the impl. >>> > >>> >>> Should use the pool in which the evznt is fired then "then step" is >>> synchronous is my sample so all is decided at fire time >> >> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >> > > was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). > > That said I agree on the state switching the pool is better but with these 2 notes: > > - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools > - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) > >>> >>> > >>> >> >>> >> Romain Manni-Bucau >>> >> @rmannibucau | Blog >>> >> | Github >>> >> | LinkedIn >>> >> | Tomitriber >>> >> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> cdi-dev mailing list >>> >> cdi-dev at 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 >>> >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/db1b3110/attachment.html From rmannibucau at gmail.com Mon Mar 7 08:12:23 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 14:12:23 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> Message-ID: 2016-03-07 14:06 GMT+01:00 Reza Rahman : > What this is saying is that it is not recommended to use them because of > the possible life-cycle mismatch. If they are not supposed to work at all, > the specification would have simply stated it won't work. > > It is not stated so not supported, that's the way EE works whatever you think (if you doubt just use any of the SHOULD features in 2 servers ;)). > Anyway personally I have no reason to further discuss this. I'm going to > try to find a way to get this done for developers sooner rather than later. > If TomEE does not want to do it, too bad for developers. > > This is not the point. I'm for getting it done but the spec states the opposite since it ignores not submitting instances completely and it states that submitting ones are not expected to work very clearly in the previous quote (not being deterministic means it doesn't work). However the issue is wider than concurrency-utilities so even if you manage to get it done for this spec users can still face this issue. If I follow a context start/stop API is possible for 2.0 so question is really: should this API get inheritance or not. > On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau > wrote: > > " > Tasks that are submitted to a managed instance of ExecutorService may > still be running after the lifecycle of the submitting component. > Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or > @ConversationScoped are not recommended to use as tasks as it cannot be > guaranteed that the tasks will complete before the CDI context is > destroyed. > " > > States that the context is not inherited, is that what you mean? > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-07 5:57 GMT+01:00 Reza Rahman : > >> The specification currently references pretty much all the major CDI >> scopes specifically with the issue of propagation and lifecycle in mind. >> Please see section 2.3. >> >> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >> Specifically >> >> The containers mimic ejb for propagation for a good reason! >> No session e.g. , new TX, etc >> >> Sadly the concurrency utilis only mention @ApplicationScoped, so the >> Request Context not only doesn't get propagated (which is good), but also >> doesn't get set up (which is crap). >> >> LieGrue, >> Strub >> >> Am 06.03.2016 um 23:03 schrieb John D. Ament : >> >> I agree, in a sense, with what you're saying. There's nothing in this >> spec that says it wouldn't be propagated. However, there's nothing in this >> spec that states clearly that CDI contexts are propagated. >> >> If you look at the RI, the RI only seems to propagate transaction state. >> Considering the age of the spec, I'm not surprised to see that. The worst >> part is that right now, outside of the ASF, all other EE7 impls seem to be >> using the RI for concurrency. >> >> I'm fairly certain that from this spec's standpoint, the only thing >> that's actually propagated is the transaction. >> >> John >> >> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >> >>> I am re-reading the spec end to end again right now. So far it seems I >>> have remembered everything correctly. >>> >>> You should read over section 2.3. What it is saying is that a container >>> implementing the Java EE concurrency utilities should ensure whatever >>> contextual information is needed for managed components to work correctly >>> should be propagated automatically. For the correct implementation of CDI >>> scopes, this should also mean any currently active scopes. The section you >>> are referring to is basically implying that thinking that it is possible to >>> use these scoped beans in tasks (albeit not reliably since beans could go >>> out of scope before the thread finishes - for example if the request ends). >>> >>> This does not have anything to do with the context service per se. The >>> context service is an SPI of sorts to allow end user developers to do for >>> their own applications what the container does behind the scenes for >>> managed component context propagation. >>> >>> I'll read over the entire spec to see if there is anything to contradict >>> this. If that's not the case what Romain is describing is most likely an >>> implementation specific bug that did not take into account CDI scope >>> propagation. >>> >>> On Mar 6, 2016, at 4:23 PM, John D. Ament >>> wrote: >>> >>> Reza, >>> >>> I read through the concurrency utils spec. Was there a specific section >>> you had in mind? The only references to CDI were near the beginning >>> warning users to not use Request/Session scoped beans as tasks since the >>> outer most context may be destroyed before the work is done. >>> >>> I have a feeling what you're referring to is the context service: >>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>> >>> If that's the case, then basically this should work OOTB right? >>> >>> Task task = new MyTask(); >>> task = contextService.createContextualProxy(task, Task.class); >>> executor.submit(task); >>> >>> // now magically the context should be prop'd? >>> >>> Is that about right? >>> >>> John >>> >>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman >>> wrote: >>> >>>> Have you actually looked at the EE concurrency spec text in detail? >>>> What does it say about managed component context propagation? >>>> >>>> Without actually doing that further discussing this is just taking >>>> shots in the dark. As an implementer it should not surprise you that this >>>> might simply be a bug because the person implementing the concurrency >>>> utilities for the EE runtime was not told about what to copy over into the >>>> new thread for CDI to work correctly. >>>> >>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau >>>> wrote: >>>> >>>> >>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>> >>>>> As far as I know this is precisely the sort of thing that the EE >>>>> concurrency spec is intended for. It is supposed to copy over everything >>>>> from the underlying thread local context into the new thread for all EE >>>>> managed components to function. Since CDI beans are also EE container >>>>> managed, it also applies to CDI beans as well. The EE vendor is supposed to >>>>> make sure this works properly. >>>>> >>>>> I don't think the concurrency utilities specifically lists APIs for >>>>> which thread context propagation should work. If this doesn't work in a >>>>> specific implementation it's most likely because they didn't take CDI into >>>>> account in their own EE concurrency implementation. >>>>> >>>>> >>>> That's what I wanted/would like. CDI TCK breaks it quite easily and >>>> @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly >>>> named. So to solve it we would need another scope as I mentionned several >>>> times on this list 100% matching servlet instances lifecycles (on a pure >>>> CDI side we have the same issue for sessions which are recycled during a >>>> request, the session scope is corrupted *by spec* in term of user behavior). >>>> >>>> >>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament >>>>> wrote: >>>>> >>>>> The section of the spec you link to makes no references to threads. >>>>> 6.3 makes some notes about normal scopes and threads, and specifically >>>>> says that a context is bound to one or more threads. >>>>> >>>>> I think what's happened is that over the years, people have simply >>>>> bound HTTP Request == single thread, but when async processing was >>>>> introduced no one thought to clarify that the spawning of a child thread >>>>> from the original HTTP request retains the parent's context. >>>>> >>>>> This is another requested feature, but looks more like a bug or gap in >>>>> the spec. >>>>> >>>>> John >>>>> >>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>> >>>>>>> Let's see. I suspect the specification text for EE concurrency is >>>>>>> generic enough for implementations to also be able to cover CDI scopes or >>>>>>> any other Java EE API context propagation needs. This means the issue needs >>>>>>> to be solved at the individual implementation level. Changing anything in >>>>>>> the spec is probably just unnecessary ceremony in this case. >>>>>>> >>>>>>> >>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI >>>>>> still prevent it to work since it would violate the spec to propagate it >>>>>> while request scope is bound to another thread ( >>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>> handles async listener but not the main AsyncContext part). >>>>>> >>>>>> >>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>> >>>>>>>> This frankly surprises me. I'll check the specification text. This >>>>>>>> might indeed just be an implementation bug. The EE concurrency utilities >>>>>>>> are supposed to be copying all relevant context. If this is an issue than >>>>>>>> it has to be that it is not copying enough of the HTTP request context for >>>>>>>> CDI to work. >>>>>>>> >>>>>>>> >>>>>>> The issue is not technical since I got it working but needed to >>>>>>> reverse. From my understanding ee concurrency utilities was done in a time >>>>>>> CDI was not there so it just ignored it somehow and it hasnt been updated >>>>>>> when integrated to the spec. Now with the wording of the CDI - and TCK - it >>>>>>> is impossible to make it working since request scope is bound the thre >>>>>>> request thread - and not the request. Side note: same applies to session >>>>>>> scope and conversation. >>>>>>> >>>>>>> >>>>>>>> Surely the Red Hat folks can quickly shed some light here since >>>>>>>> they implement essentially this whole stack? >>>>>>>> >>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>> >>>>>>>>> Can you kindly try to make the example a bit simpler? It's >>>>>>>>> important to make the case for how likely this is supposed to occur in most >>>>>>>>> business applications. >>>>>>>>> >>>>>>>>> Also, other than making sure that the executor service is >>>>>>>>> propagating thread local request contexts correctly what other solution are >>>>>>>>> you proposing? Did you check the specification? How sure are you that this >>>>>>>>> isn't simply an implementation bug? >>>>>>>>> >>>>>>>>> As far as I know the executor service is supposed to be preserving >>>>>>>>> all relevant parts of the EE context? >>>>>>>>> >>>>>>>>> >>>>>>>> Not in concurrency-utilities for EE at least. That was the first >>>>>>>> impl I did then Mark pointed out it was violating CDI spec and request >>>>>>>> scope definition. There is a kind of contracdiction there cause >>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>>> tackle it. >>>>>>>> >>>>>>>> >>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e >>>>>>>>> help? >>>>>>>>> >>>>>>>>> Idea is to give an API to make: >>>>>>>>> >>>>>>>>> public void complete() { >>>>>>>>> try { >>>>>>>>> asyncContext.complete(); >>>>>>>>> } finally { >>>>>>>>> auditContext.end(); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> working without hacky and almost impossible context pushing (cause >>>>>>>>> of injections nature you are not supposed to know what to push in the >>>>>>>>> context when going async). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Romain Manni-Bucau >>>>>>>>> @rmannibucau | Blog >>>>>>>>> | Github >>>>>>>>> | LinkedIn >>>>>>>>> | Tomitriber >>>>>>>>> >>>>>>>>> >>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>> >>>>>>>>>> Can you kindly share an annotated code example of the proposed >>>>>>>>>> solution so we can all follow and discuss this? >>>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>>>> >>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi >>>>>>>>>> scope. Idea is to follow request scope more than cdi spec allows. First >>>>>>>>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>>>>>>>> CDI one so here it is. >>>>>>>>>> >>>>>>>>>> Sample: >>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set >>>>>>>>>> on it. The i go async (AsyncContext) and trigger a task in another thread. >>>>>>>>>> It would be neat - and mandatory in some case by the loose coupling nature >>>>>>>>>> of CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>>>>>>>> dependency you can easily use message passing pattern - but you loose the >>>>>>>>>> loose coupling cause you need to know until which level you unwrap, think t >>>>>>>>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>>>>>>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>>>>>>>> security...) so you can't really do it easily/naturally. >>>>>>>>>> >>>>>>>>>> Bonus: >>>>>>>>>> One very verbose way is to be able to kind of push/pop an >>>>>>>>>> existing context in a thread - wrappers doing it on a >>>>>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>>>>> >>>>>>>>>> Question: >>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>> >>>>>>>>>> Side note: this is really about the fact to reuse a "context >>>>>>>>>> context" (its current instances map) in another thread the more >>>>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>>>> question for now. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau | Blog >>>>>>>>>> | Github >>>>>>>>>> | LinkedIn >>>>>>>>>> | Tomitriber >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> cdi-dev mailing list >>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/ff565a7a/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 08:15:24 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 08:15:24 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <56DD5079.40801@redhat.com> Message-ID: <9532B290-4F8C-4358-B8CD-36EE36A595E9@lycos.com> I am really confused now. Why shouldn't Java EE concurrency not be able to define a standard way to configure custom executors? You can do that today, just in vendor specific ways... > On Mar 7, 2016, at 5:10 AM, Romain Manni-Bucau wrote: > > > 2016-03-07 10:57 GMT+01:00 Martin Kouba : >> Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a): >>> 2016-03-07 9:07 GMT+01:00 Martin Kouba >> >: >>> >>> >>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>> >>> >>> Le 7 mars 2016 08:35, "Martin Kouba" >> >>> >> a ?crit : >>> >>> > >>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>> > >>> >> Hi guys, >>> >> >>> >> as a user having a ComlpetionStage makes me loose some JDK >>> utilities, >>> >> can we move back to CompletionFuture? >>> >> >>> >> It would allow for instance: >>> >> >>> >> // doesn't work with CompletionStage >>> >> CompletionFuture.allOf(event1.fireAsync(...), >>> event2.fireAsync(...)) >>> >> .then(...) >>> > >>> > >>> > Well, this should work if the underlying CompletionStage impl >>> supports toCompletableFuture(), i.e. in Weld 3: >>> > >>> >>> Yes but it is not natural to convert it IMO = we can do better >>> >>> > >>> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>> event2.fireAsync(...).toCompletableFuture()) >>> > >>> > AFAIK the default async execution facility of >>> CompletableFuture is >>> ForkJoinPool.commonPool() which is not a good fit for Java EE. >>> Using the >>> CompletionStage interface allows us to wrap the async calls >>> without the >>> specified executor (e.g. >>> CompletionStage.thenApplyAsync(Function>> T, ? extends U>)) and supply a default one provided by the impl. >>> > >>> >>> Should use the pool in which the evznt is fired then "then step" is >>> synchronous is my sample so all is decided at fire time >>> >>> >>> I don't talk about your particular example - I understand that it's >>> not using async exec (although the "then()" method does not exist). >>> >>> >>> was supposed to represent the different flavours (thenRun, thenCompose, >>> ...) ;). >>> >>> That said I agree on the state switching the pool is better but with >>> these 2 notes: >>> >>> - could be better to hide these poorly designed methods then -> don't >>> use CompletionXXX but a CDI API with a bridge to CompletionX to let the >>> user go back on SE tools >> >> Yep, this is one of the possible solutions. On the other hand, I don't think it's poorly designed. CompletionStage defines the "default asynchronous execution facility" and CDI spec states that the CompletionStage returned by fireAsync methods is container-specific. The impl may choose to clarify this "default asynchronous execution facility", i.e. there's place for innovation... >> >>> - we still don't have a *standard* config for the pool(s) underlying CDI >>> features so it sounds as poor as SE solution IMO (at least a >>> core/max/ttl config in beans.xml) >> >> I don't think this should be standardized... >> > > Why? Typically if you take @Asynchronous (EJB spec) you have already this issue and this is often avoided when portability matters for that particular reason you don't know how you will behave. Or do you think concurrency-utilities solves it? > >>> >>> >>> > >>> >> >>> >> Romain Manni-Bucau >>> >> @rmannibucau | Blog >>> >> | Github >>> >> | LinkedIn >>> >> | Tomitriber >>> >> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> cdi-dev mailing list >>> >> cdi-dev at 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 >>> >>> >>> -- >>> Martin Kouba >>> Software Engineer >>> Red Hat, Czech Republic >>> >>> >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/a898869a/attachment.html From reza_rahman at lycos.com Mon Mar 7 08:16:16 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 08:16:16 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD30CE.6070101@redhat.com> Message-ID: Sent from my iPhone > On Mar 7, 2016, at 5:12 AM, Antoine Sabot-Durand wrote: > > Hi guys, > > Back from vacation, I'm "happy" to see that we go back on Async event feature (which took us 6 months). > > @Reza and @Romain sorry but I don't get it. the good practice is to develop for interface (that's why CDI uses Set and not HashSet for instance). I'm ok it's the theory, but if you want to make an exception to this practice you need to have a good reason. So if you want to rely on JDK classes like CompletableFuture instead of interface, you'll probably have to go a step further than that. CompletionStage has a toCompletableFuture() method. > > To go back to the big picture, as some people around don't seem to be happy with what we designed, we still have the solution to move async event can in specification annexe. It's a solution to test a feature without definitely specifying it. > > Antoine > >> Le lun. 7 mars 2016 ? 08:42, Martin Kouba a ?crit : >> Dne 6.3.2016 v 16:37 Reza Rahman napsal(a): >> > How much end user feedback has there been on this? I have to be honest >> > that it surprises me to find this out now. >> >> Well, this was discussed many times (ML, EG mtgs, F2F, etc.). >> >> > >> > This to me stands out as an obvious usability problem. CompletableFuture >> > is the obvious top level end user API, not CompletionStage. >> >> Is it obvious? For me the CompletionStage looks more appropriate. But >> I'm open for discussions. >> >> > Not going >> > with CompletableFuture is very likely to confuse most people. The last >> > thing we need is more potential usability problems in Java EE APIs. >> > >> > On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau > > > wrote: >> > >> >> Hi guys, >> >> >> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >> >> can we move back to CompletionFuture? >> >> >> >> It would allow for instance: >> >> >> >> // doesn't work with CompletionStage >> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >> >> .then(...) >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau | Blog >> >> | Github >> >> | LinkedIn >> >> | Tomitriber >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/69a6e157/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 08:16:22 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 08:16:22 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD30CE.6070101@redhat.com> Message-ID: <65DB1949-9147-49FB-AB01-1D46C56408FE@lycos.com> Sent from my iPhone > On Mar 7, 2016, at 5:12 AM, Antoine Sabot-Durand wrote: > > Hi guys, > > Back from vacation, I'm "happy" to see that we go back on Async event feature (which took us 6 months). > > @Reza and @Romain sorry but I don't get it. the good practice is to develop for interface (that's why CDI uses Set and not HashSet for instance). I'm ok it's the theory, but if you want to make an exception to this practice you need to have a good reason. So if you want to rely on JDK classes like CompletableFuture instead of interface, you'll probably have to go a step further than that. CompletionStage has a toCompletableFuture() method. > > To go back to the big picture, as some people around don't seem to be happy with what we designed, we still have the solution to move async event can in specification annexe. It's a solution to test a feature without definitely specifying it. > > Antoine > >> Le lun. 7 mars 2016 ? 08:42, Martin Kouba a ?crit : >> Dne 6.3.2016 v 16:37 Reza Rahman napsal(a): >> > How much end user feedback has there been on this? I have to be honest >> > that it surprises me to find this out now. >> >> Well, this was discussed many times (ML, EG mtgs, F2F, etc.). >> >> > >> > This to me stands out as an obvious usability problem. CompletableFuture >> > is the obvious top level end user API, not CompletionStage. >> >> Is it obvious? For me the CompletionStage looks more appropriate. But >> I'm open for discussions. >> >> > Not going >> > with CompletableFuture is very likely to confuse most people. The last >> > thing we need is more potential usability problems in Java EE APIs. >> > >> > On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau > > > wrote: >> > >> >> Hi guys, >> >> >> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >> >> can we move back to CompletionFuture? >> >> >> >> It would allow for instance: >> >> >> >> // doesn't work with CompletionStage >> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >> >> .then(...) >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau | Blog >> >> | Github >> >> | LinkedIn >> >> | Tomitriber >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/d2f98308/attachment.html From rmannibucau at gmail.com Mon Mar 7 08:19:34 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 14:19:34 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <9532B290-4F8C-4358-B8CD-36EE36A595E9@lycos.com> References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <56DD5079.40801@redhat.com> <9532B290-4F8C-4358-B8CD-36EE36A595E9@lycos.com> Message-ID: 2016-03-07 14:15 GMT+01:00 Reza Rahman : > I am really confused now. Why shouldn't Java EE concurrency not be able to > define a standard way to configure custom executors? You can do that today, > just in vendor specific ways... > > Cause there are several libs where you don't control the pool and the best you can do is to wrap the task (Runnable) on your side. Also you can hit it in background threads you can't enforce to use concurrency spec and finally you can hit it in fully synchronous way if you execute after the CDI chain - which is allowed by CDI and TCK-ed so you can need a way to stack the context to reuse some part after. Last "?": JTA integration: you can also hit it to save data after @TransactionScoped for audit purposes. > On Mar 7, 2016, at 5:10 AM, Romain Manni-Bucau > wrote: > > > 2016-03-07 10:57 GMT+01:00 Martin Kouba : > >> Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a): >> >>> 2016-03-07 9:07 GMT+01:00 Martin Kouba >> >: >>> >>> >>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>> >>> >>> Le 7 mars 2016 08:35, "Martin Kouba" >> >>> >> a ?crit : >>> >>> > >>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>> > >>> >> Hi guys, >>> >> >>> >> as a user having a ComlpetionStage makes me loose some JDK >>> utilities, >>> >> can we move back to CompletionFuture? >>> >> >>> >> It would allow for instance: >>> >> >>> >> // doesn't work with CompletionStage >>> >> CompletionFuture.allOf(event1.fireAsync(...), >>> event2.fireAsync(...)) >>> >> .then(...) >>> > >>> > >>> > Well, this should work if the underlying CompletionStage impl >>> supports toCompletableFuture(), i.e. in Weld 3: >>> > >>> >>> Yes but it is not natural to convert it IMO = we can do better >>> >>> > >>> >>> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>> event2.fireAsync(...).toCompletableFuture()) >>> > >>> > AFAIK the default async execution facility of >>> CompletableFuture is >>> ForkJoinPool.commonPool() which is not a good fit for Java EE. >>> Using the >>> CompletionStage interface allows us to wrap the async calls >>> without the >>> specified executor (e.g. >>> CompletionStage.thenApplyAsync(Function>> T, ? extends U>)) and supply a default one provided by the impl. >>> > >>> >>> Should use the pool in which the evznt is fired then "then step" >>> is >>> synchronous is my sample so all is decided at fire time >>> >>> >>> I don't talk about your particular example - I understand that it's >>> not using async exec (although the "then()" method does not exist). >>> >>> >>> was supposed to represent the different flavours (thenRun, thenCompose, >>> ...) ;). >>> >>> That said I agree on the state switching the pool is better but with >>> these 2 notes: >>> >>> - could be better to hide these poorly designed methods then -> don't >>> use CompletionXXX but a CDI API with a bridge to CompletionX to let the >>> user go back on SE tools >>> >> >> Yep, this is one of the possible solutions. On the other hand, I don't >> think it's poorly designed. CompletionStage defines the "default >> asynchronous execution facility" and CDI spec states that the >> CompletionStage returned by fireAsync methods is container-specific. The >> impl may choose to clarify this "default asynchronous execution facility", >> i.e. there's place for innovation... >> >> - we still don't have a *standard* config for the pool(s) underlying CDI >>> features so it sounds as poor as SE solution IMO (at least a >>> core/max/ttl config in beans.xml) >>> >> >> I don't think this should be standardized... >> >> > Why? Typically if you take @Asynchronous (EJB spec) you have already this > issue and this is often avoided when portability matters for that > particular reason you don't know how you will behave. Or do you think > concurrency-utilities solves it? > > >> >>> >>> > >>> >> >>> >> Romain Manni-Bucau >>> >> @rmannibucau | Blog >>> >> | Github >>> >> | LinkedIn >>> >> | Tomitriber >>> >> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> cdi-dev mailing list >>> >> cdi-dev at 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 >>> >>> >>> -- >>> Martin Kouba >>> Software Engineer >>> Red Hat, Czech Republic >>> >>> >>> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/177fc787/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 08:22:28 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 08:22:28 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD30CE.6070101@redhat.com> Message-ID: <9ACFA187-9884-496B-96A2-44E52CC164E8@lycos.com> If you don't understand why most developers would simply expect to use CompletableFuture and would immediately be confused if they see something else, I think we are in bigger trouble than I thought. You should really ask a few developers outside your immediate network or do a Google search to see just how much more prominent CompletableFuture is as oppose to CompletionStage. Not finding a way to use that API and choosing an obscure superclass is a sure recipe for problems. > On Mar 7, 2016, at 5:12 AM, Antoine Sabot-Durand wrote: > > Hi guys, > > Back from vacation, I'm "happy" to see that we go back on Async event feature (which took us 6 months). > > @Reza and @Romain sorry but I don't get it. the good practice is to develop for interface (that's why CDI uses Set and not HashSet for instance). I'm ok it's the theory, but if you want to make an exception to this practice you need to have a good reason. So if you want to rely on JDK classes like CompletableFuture instead of interface, you'll probably have to go a step further than that. CompletionStage has a toCompletableFuture() method. > > To go back to the big picture, as some people around don't seem to be happy with what we designed, we still have the solution to move async event can in specification annexe. It's a solution to test a feature without definitely specifying it. > > Antoine > >> Le lun. 7 mars 2016 ? 08:42, Martin Kouba a ?crit : >> Dne 6.3.2016 v 16:37 Reza Rahman napsal(a): >> > How much end user feedback has there been on this? I have to be honest >> > that it surprises me to find this out now. >> >> Well, this was discussed many times (ML, EG mtgs, F2F, etc.). >> >> > >> > This to me stands out as an obvious usability problem. CompletableFuture >> > is the obvious top level end user API, not CompletionStage. >> >> Is it obvious? For me the CompletionStage looks more appropriate. But >> I'm open for discussions. >> >> > Not going >> > with CompletableFuture is very likely to confuse most people. The last >> > thing we need is more potential usability problems in Java EE APIs. >> > >> > On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau > > > wrote: >> > >> >> Hi guys, >> >> >> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >> >> can we move back to CompletionFuture? >> >> >> >> It would allow for instance: >> >> >> >> // doesn't work with CompletionStage >> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >> >> .then(...) >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau | Blog >> >> | Github >> >> | LinkedIn >> >> | Tomitriber >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/e4ad01f1/attachment.html From reza_rahman at lycos.com Mon Mar 7 08:34:45 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 08:34:45 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <56DD5079.40801@redhat.com> <9532B290-4F8C-4358-B8CD-36EE36A595E9@lycos.com> Message-ID: <8CACB9C7-3790-4047-8C20-2B0A41065D1C@lycos.com> You've lost me. Are you talking about configuring what executors the container implementation itself should use or what custom executors an application developer can use? The best I can understand what your saying applies to the container implementation itself. Then again, implementations like WebLogic, WebSphere and GlassFish allow you to configure even the core executor pool of the runtime. It most certainly allows creating custom executors pools. The only difference would be making what is vendor specific today completely standardized. Since when is that a bad thing? > On Mar 7, 2016, at 8:19 AM, Romain Manni-Bucau wrote: > > 2016-03-07 14:15 GMT+01:00 Reza Rahman : >> I am really confused now. Why shouldn't Java EE concurrency not be able to define a standard way to configure custom executors? You can do that today, just in vendor specific ways... >> > > Cause there are several libs where you don't control the pool and the best you can do is to wrap the task (Runnable) on your side. Also you can hit it in background threads you can't enforce to use concurrency spec and finally you can hit it in fully synchronous way if you execute after the CDI chain - which is allowed by CDI and TCK-ed so you can need a way to stack the context to reuse some part after. Last "?": JTA integration: you can also hit it to save data after @TransactionScoped for audit purposes. > >>> On Mar 7, 2016, at 5:10 AM, Romain Manni-Bucau wrote: >>> >>> >>> 2016-03-07 10:57 GMT+01:00 Martin Kouba : >>>> Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a): >>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba >>>> >: >>>>> >>>>> >>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>> >>>>> >>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>> >>>>> >> a ?crit : >>>>> >>>>> > >>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>> > >>>>> >> Hi guys, >>>>> >> >>>>> >> as a user having a ComlpetionStage makes me loose some JDK >>>>> utilities, >>>>> >> can we move back to CompletionFuture? >>>>> >> >>>>> >> It would allow for instance: >>>>> >> >>>>> >> // doesn't work with CompletionStage >>>>> >> CompletionFuture.allOf(event1.fireAsync(...), >>>>> event2.fireAsync(...)) >>>>> >> .then(...) >>>>> > >>>>> > >>>>> > Well, this should work if the underlying CompletionStage impl >>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>> > >>>>> >>>>> Yes but it is not natural to convert it IMO = we can do better >>>>> >>>>> > >>>>> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>> event2.fireAsync(...).toCompletableFuture()) >>>>> > >>>>> > AFAIK the default async execution facility of >>>>> CompletableFuture is >>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. >>>>> Using the >>>>> CompletionStage interface allows us to wrap the async calls >>>>> without the >>>>> specified executor (e.g. >>>>> CompletionStage.thenApplyAsync(Function>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>> > >>>>> >>>>> Should use the pool in which the evznt is fired then "then step" is >>>>> synchronous is my sample so all is decided at fire time >>>>> >>>>> >>>>> I don't talk about your particular example - I understand that it's >>>>> not using async exec (although the "then()" method does not exist). >>>>> >>>>> >>>>> was supposed to represent the different flavours (thenRun, thenCompose, >>>>> ...) ;). >>>>> >>>>> That said I agree on the state switching the pool is better but with >>>>> these 2 notes: >>>>> >>>>> - could be better to hide these poorly designed methods then -> don't >>>>> use CompletionXXX but a CDI API with a bridge to CompletionX to let the >>>>> user go back on SE tools >>>> >>>> Yep, this is one of the possible solutions. On the other hand, I don't think it's poorly designed. CompletionStage defines the "default asynchronous execution facility" and CDI spec states that the CompletionStage returned by fireAsync methods is container-specific. The impl may choose to clarify this "default asynchronous execution facility", i.e. there's place for innovation... >>>> >>>>> - we still don't have a *standard* config for the pool(s) underlying CDI >>>>> features so it sounds as poor as SE solution IMO (at least a >>>>> core/max/ttl config in beans.xml) >>>> >>>> I don't think this should be standardized... >>>> >>> >>> Why? Typically if you take @Asynchronous (EJB spec) you have already this issue and this is often avoided when portability matters for that particular reason you don't know how you will behave. Or do you think concurrency-utilities solves it? >>> >>>>> >>>>> >>>>> > >>>>> >> >>>>> >> Romain Manni-Bucau >>>>> >> @rmannibucau | Blog >>>>> >> | Github >>>>> >> | LinkedIn >>>>> >> | Tomitriber >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> _______________________________________________ >>>>> >> cdi-dev mailing list >>>>> >> cdi-dev at 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 >>>>> >>>>> >>>>> -- >>>>> Martin Kouba >>>>> Software Engineer >>>>> Red Hat, Czech Republic >>>>> >>>>> >>>> >>>> -- >>>> Martin Kouba >>>> Software Engineer >>>> Red Hat, Czech Republic >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/352b1c7f/attachment-0001.html From rmannibucau at gmail.com Mon Mar 7 08:39:10 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 14:39:10 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <8CACB9C7-3790-4047-8C20-2B0A41065D1C@lycos.com> References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <56DD5079.40801@redhat.com> <9532B290-4F8C-4358-B8CD-36EE36A595E9@lycos.com> <8CACB9C7-3790-4047-8C20-2B0A41065D1C@lycos.com> Message-ID: 2016-03-07 14:34 GMT+01:00 Reza Rahman : > You've lost me. > > Are you talking about configuring what executors the container > implementation itself should use or what custom executors an application > developer can use? > > Both cases > The best I can understand what your saying applies to the container > implementation itself. Then again, implementations like WebLogic, WebSphere > and GlassFish allow you to configure even the core executor pool of the > runtime. It most certainly allows creating custom executors pools. > > The only difference would be making what is vendor specific today > completely standardized. Since when is that a bad thing? > > I'm for this standardization - even if just a subset of vendors config but the minimum to ensure an app can scale on all servers. The bad thing is when the feature is central or important for an app. Then you hide a proprietary feature behind a standard API, this is very nasty and can lead to broken usages pretty easily. However my last point is: even if you fix it for the container you still have the app use cases where the pool are sometimes hidden in apps themself and EE concurrency doesn't help there (and just taking few remote libs it is not rare at all). > On Mar 7, 2016, at 8:19 AM, Romain Manni-Bucau > wrote: > > 2016-03-07 14:15 GMT+01:00 Reza Rahman : > >> I am really confused now. Why shouldn't Java EE concurrency not be able >> to define a standard way to configure custom executors? You can do that >> today, just in vendor specific ways... >> >> > Cause there are several libs where you don't control the pool and the best > you can do is to wrap the task (Runnable) on your side. Also you can hit it > in background threads you can't enforce to use concurrency spec and finally > you can hit it in fully synchronous way if you execute after the CDI chain > - which is allowed by CDI and TCK-ed so you can need a way to stack the > context to reuse some part after. Last "?": JTA integration: you can also > hit it to save data after @TransactionScoped for audit purposes. > > >> On Mar 7, 2016, at 5:10 AM, Romain Manni-Bucau >> wrote: >> >> >> 2016-03-07 10:57 GMT+01:00 Martin Kouba : >> >>> Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a): >>> >>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba >>> >: >>>> >>>> >>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>> >>>> >>>> Le 7 mars 2016 08:35, "Martin Kouba" >>> >>>> >> a ?crit >>>> : >>>> >>>> > >>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>> > >>>> >> Hi guys, >>>> >> >>>> >> as a user having a ComlpetionStage makes me loose some JDK >>>> utilities, >>>> >> can we move back to CompletionFuture? >>>> >> >>>> >> It would allow for instance: >>>> >> >>>> >> // doesn't work with CompletionStage >>>> >> CompletionFuture.allOf(event1.fireAsync(...), >>>> event2.fireAsync(...)) >>>> >> .then(...) >>>> > >>>> > >>>> > Well, this should work if the underlying CompletionStage >>>> impl >>>> supports toCompletableFuture(), i.e. in Weld 3: >>>> > >>>> >>>> Yes but it is not natural to convert it IMO = we can do better >>>> >>>> > >>>> >>>> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>> event2.fireAsync(...).toCompletableFuture()) >>>> > >>>> > AFAIK the default async execution facility of >>>> CompletableFuture is >>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. >>>> Using the >>>> CompletionStage interface allows us to wrap the async calls >>>> without the >>>> specified executor (e.g. >>>> CompletionStage.thenApplyAsync(Function>>> T, ? extends U>)) and supply a default one provided by the impl. >>>> > >>>> >>>> Should use the pool in which the evznt is fired then "then >>>> step" is >>>> synchronous is my sample so all is decided at fire time >>>> >>>> >>>> I don't talk about your particular example - I understand that it's >>>> not using async exec (although the "then()" method does not exist). >>>> >>>> >>>> was supposed to represent the different flavours (thenRun, thenCompose, >>>> ...) ;). >>>> >>>> That said I agree on the state switching the pool is better but with >>>> these 2 notes: >>>> >>>> - could be better to hide these poorly designed methods then -> don't >>>> use CompletionXXX but a CDI API with a bridge to CompletionX to let the >>>> user go back on SE tools >>>> >>> >>> Yep, this is one of the possible solutions. On the other hand, I don't >>> think it's poorly designed. CompletionStage defines the "default >>> asynchronous execution facility" and CDI spec states that the >>> CompletionStage returned by fireAsync methods is container-specific. The >>> impl may choose to clarify this "default asynchronous execution facility", >>> i.e. there's place for innovation... >>> >>> - we still don't have a *standard* config for the pool(s) underlying CDI >>>> features so it sounds as poor as SE solution IMO (at least a >>>> core/max/ttl config in beans.xml) >>>> >>> >>> I don't think this should be standardized... >>> >>> >> Why? Typically if you take @Asynchronous (EJB spec) you have already this >> issue and this is often avoided when portability matters for that >> particular reason you don't know how you will behave. Or do you think >> concurrency-utilities solves it? >> >> >>> >>>> >>>> > >>>> >> >>>> >> Romain Manni-Bucau >>>> >> @rmannibucau | Blog >>>> >> | Github >>>> >> | LinkedIn >>>> >> | Tomitriber >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> cdi-dev mailing list >>>> >> cdi-dev at 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 >>>> >>>> >>>> -- >>>> Martin Kouba >>>> Software Engineer >>>> Red Hat, Czech Republic >>>> >>>> >>>> >>> -- >>> Martin Kouba >>> Software Engineer >>> Red Hat, Czech Republic >>> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/aa6d76e3/attachment.html From reza_rahman at lycos.com Mon Mar 7 08:40:45 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 08:40:45 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> Message-ID: <26A370F4-7B3D-4125-88E4-E0FB1BD0F340@lycos.com> There are way too many cases I can cite of the spec saying something is optional but good implementations doing what is actually right. Even in the worst reading of this, that is exactly what is happening here. > On Mar 7, 2016, at 8:12 AM, Romain Manni-Bucau wrote: > > 2016-03-07 14:06 GMT+01:00 Reza Rahman : >> What this is saying is that it is not recommended to use them because of the possible life-cycle mismatch. If they are not supposed to work at all, the specification would have simply stated it won't work. >> > > It is not stated so not supported, that's the way EE works whatever you think (if you doubt just use any of the SHOULD features in 2 servers ;)). > >> Anyway personally I have no reason to further discuss this. I'm going to try to find a way to get this done for developers sooner rather than later. If TomEE does not want to do it, too bad for developers. >> > > This is not the point. I'm for getting it done but the spec states the opposite since it ignores not submitting instances completely and it states that submitting ones are not expected to work very clearly in the previous quote (not being deterministic means it doesn't work). > > However the issue is wider than concurrency-utilities so even if you manage to get it done for this spec users can still face this issue. If I follow a context start/stop API is possible for 2.0 so question is really: should this API get inheritance or not. > >>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau wrote: >>> >>> " >>> Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. >>> " >>> >>> States that the context is not inherited, is that what you mean? >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>> The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. >>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >>>>> Specifically >>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>> No session e.g. , new TX, etc >>>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). >>>>> >>>>> LieGrue, >>>>> Strub >>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>>>>> >>>>>> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >>>>>> >>>>>> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >>>>>> >>>>>> John >>>>>> >>>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >>>>>>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >>>>>>> >>>>>>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >>>>>>> >>>>>>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >>>>>>> >>>>>>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >>>>>>> >>>>>>>> Reza, >>>>>>>> >>>>>>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>>>>>>> >>>>>>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>> >>>>>>>> If that's the case, then basically this should work OOTB right? >>>>>>>> >>>>>>>> Task task = new MyTask(); >>>>>>>> task = contextService.createContextualProxy(task, Task.class); >>>>>>>> executor.submit(task); >>>>>>>> >>>>>>>> // now magically the context should be prop'd? >>>>>>>> >>>>>>>> Is that about right? >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>>>>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>>>>>>> >>>>>>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>>>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>>>>>>> >>>>>>>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>>>>>>>> >>>>>>>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>>>>>>>> >>>>>>>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>>>>>>>> >>>>>>>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>>>>>>>> >>>>>>>>>>>> John >>>>>>>>>>>> >>>>>>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> public void complete() { >>>>>>>>>>>>>>>>>>> try { >>>>>>>>>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>>>>>>>>>> } finally { >>>>>>>>>>>>>>>>>>> auditContext.end(); >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Sample: >>>>>>>>>>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Bonus: >>>>>>>>>>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Question: >>>>>>>>>>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/c133e8a9/attachment-0001.html From rmannibucau at gmail.com Mon Mar 7 08:42:54 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 14:42:54 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: <26A370F4-7B3D-4125-88E4-E0FB1BD0F340@lycos.com> References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> <26A370F4-7B3D-4125-88E4-E0FB1BD0F340@lycos.com> Message-ID: 2016-03-07 14:40 GMT+01:00 Reza Rahman : > There are way too many cases I can cite of the spec saying something is > optional but good implementations doing what is actually right. Even in the > worst reading of this, that is exactly what is happening here. > > Reza take one day and re-read it with a not oriented eye: the spec states it shouldnt work. Let also ignore the concurrency utility for one moment since it covers only 50% of the cases and show me where the spec states it should be covered please. > On Mar 7, 2016, at 8:12 AM, Romain Manni-Bucau > wrote: > > 2016-03-07 14:06 GMT+01:00 Reza Rahman : > >> What this is saying is that it is not recommended to use them because of >> the possible life-cycle mismatch. If they are not supposed to work at all, >> the specification would have simply stated it won't work. >> >> > It is not stated so not supported, that's the way EE works whatever you > think (if you doubt just use any of the SHOULD features in 2 servers ;)). > > >> Anyway personally I have no reason to further discuss this. I'm going to >> try to find a way to get this done for developers sooner rather than later. >> If TomEE does not want to do it, too bad for developers. >> >> > This is not the point. I'm for getting it done but the spec states the > opposite since it ignores not submitting instances completely and it states > that submitting ones are not expected to work very clearly in the previous > quote (not being deterministic means it doesn't work). > > However the issue is wider than concurrency-utilities so even if you > manage to get it done for this spec users can still face this issue. If I > follow a context start/stop API is possible for 2.0 so question is really: > should this API get inheritance or not. > > >> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau >> wrote: >> >> " >> Tasks that are submitted to a managed instance of ExecutorService may >> still be running after the lifecycle of the submitting component. >> Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or >> @ConversationScoped are not recommended to use as tasks as it cannot be >> guaranteed that the tasks will complete before the CDI context is >> destroyed. >> " >> >> States that the context is not inherited, is that what you mean? >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >> >>> The specification currently references pretty much all the major CDI >>> scopes specifically with the issue of propagation and lifecycle in mind. >>> Please see section 2.3. >>> >>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >>> Specifically >>> >>> The containers mimic ejb for propagation for a good reason! >>> No session e.g. , new TX, etc >>> >>> Sadly the concurrency utilis only mention @ApplicationScoped, so the >>> Request Context not only doesn't get propagated (which is good), but also >>> doesn't get set up (which is crap). >>> >>> LieGrue, >>> Strub >>> >>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>> >>> I agree, in a sense, with what you're saying. There's nothing in this >>> spec that says it wouldn't be propagated. However, there's nothing in this >>> spec that states clearly that CDI contexts are propagated. >>> >>> If you look at the RI, the RI only seems to propagate transaction >>> state. Considering the age of the spec, I'm not surprised to see that. >>> The worst part is that right now, outside of the ASF, all other EE7 impls >>> seem to be using the RI for concurrency. >>> >>> I'm fairly certain that from this spec's standpoint, the only thing >>> that's actually propagated is the transaction. >>> >>> John >>> >>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman >>> wrote: >>> >>>> I am re-reading the spec end to end again right now. So far it seems I >>>> have remembered everything correctly. >>>> >>>> You should read over section 2.3. What it is saying is that a container >>>> implementing the Java EE concurrency utilities should ensure whatever >>>> contextual information is needed for managed components to work correctly >>>> should be propagated automatically. For the correct implementation of CDI >>>> scopes, this should also mean any currently active scopes. The section you >>>> are referring to is basically implying that thinking that it is possible to >>>> use these scoped beans in tasks (albeit not reliably since beans could go >>>> out of scope before the thread finishes - for example if the request ends). >>>> >>>> This does not have anything to do with the context service per se. The >>>> context service is an SPI of sorts to allow end user developers to do for >>>> their own applications what the container does behind the scenes for >>>> managed component context propagation. >>>> >>>> I'll read over the entire spec to see if there is anything to >>>> contradict this. If that's not the case what Romain is describing is most >>>> likely an implementation specific bug that did not take into account CDI >>>> scope propagation. >>>> >>>> On Mar 6, 2016, at 4:23 PM, John D. Ament >>>> wrote: >>>> >>>> Reza, >>>> >>>> I read through the concurrency utils spec. Was there a specific >>>> section you had in mind? The only references to CDI were near the >>>> beginning warning users to not use Request/Session scoped beans as tasks >>>> since the outer most context may be destroyed before the work is done. >>>> >>>> I have a feeling what you're referring to is the context service: >>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>> >>>> If that's the case, then basically this should work OOTB right? >>>> >>>> Task task = new MyTask(); >>>> task = contextService.createContextualProxy(task, Task.class); >>>> executor.submit(task); >>>> >>>> // now magically the context should be prop'd? >>>> >>>> Is that about right? >>>> >>>> John >>>> >>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman >>>> wrote: >>>> >>>>> Have you actually looked at the EE concurrency spec text in detail? >>>>> What does it say about managed component context propagation? >>>>> >>>>> Without actually doing that further discussing this is just taking >>>>> shots in the dark. As an implementer it should not surprise you that this >>>>> might simply be a bug because the person implementing the concurrency >>>>> utilities for the EE runtime was not told about what to copy over into the >>>>> new thread for CDI to work correctly. >>>>> >>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau >>>>> wrote: >>>>> >>>>> >>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>> >>>>>> As far as I know this is precisely the sort of thing that the EE >>>>>> concurrency spec is intended for. It is supposed to copy over everything >>>>>> from the underlying thread local context into the new thread for all EE >>>>>> managed components to function. Since CDI beans are also EE container >>>>>> managed, it also applies to CDI beans as well. The EE vendor is supposed to >>>>>> make sure this works properly. >>>>>> >>>>>> I don't think the concurrency utilities specifically lists APIs for >>>>>> which thread context propagation should work. If this doesn't work in a >>>>>> specific implementation it's most likely because they didn't take CDI into >>>>>> account in their own EE concurrency implementation. >>>>>> >>>>>> >>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and >>>>> @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly >>>>> named. So to solve it we would need another scope as I mentionned several >>>>> times on this list 100% matching servlet instances lifecycles (on a pure >>>>> CDI side we have the same issue for sessions which are recycled during a >>>>> request, the session scope is corrupted *by spec* in term of user behavior). >>>>> >>>>> >>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament >>>>>> wrote: >>>>>> >>>>>> The section of the spec you link to makes no references to threads. >>>>>> 6.3 makes some notes about normal scopes and threads, and specifically >>>>>> says that a context is bound to one or more threads. >>>>>> >>>>>> I think what's happened is that over the years, people have simply >>>>>> bound HTTP Request == single thread, but when async processing was >>>>>> introduced no one thought to clarify that the spawning of a child thread >>>>>> from the original HTTP request retains the parent's context. >>>>>> >>>>>> This is another requested feature, but looks more like a bug or gap >>>>>> in the spec. >>>>>> >>>>>> John >>>>>> >>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wrote: >>>>>> >>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>> >>>>>>>> Let's see. I suspect the specification text for EE concurrency is >>>>>>>> generic enough for implementations to also be able to cover CDI scopes or >>>>>>>> any other Java EE API context propagation needs. This means the issue needs >>>>>>>> to be solved at the individual implementation level. Changing anything in >>>>>>>> the spec is probably just unnecessary ceremony in this case. >>>>>>>> >>>>>>>> >>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. >>>>>>> CDI still prevent it to work since it would violate the spec to propagate >>>>>>> it while request scope is bound to another thread ( >>>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>>> handles async listener but not the main AsyncContext part). >>>>>>> >>>>>>> >>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>> >>>>>>>>> This frankly surprises me. I'll check the specification text. This >>>>>>>>> might indeed just be an implementation bug. The EE concurrency utilities >>>>>>>>> are supposed to be copying all relevant context. If this is an issue than >>>>>>>>> it has to be that it is not copying enough of the HTTP request context for >>>>>>>>> CDI to work. >>>>>>>>> >>>>>>>>> >>>>>>>> The issue is not technical since I got it working but needed to >>>>>>>> reverse. From my understanding ee concurrency utilities was done in a time >>>>>>>> CDI was not there so it just ignored it somehow and it hasnt been updated >>>>>>>> when integrated to the spec. Now with the wording of the CDI - and TCK - it >>>>>>>> is impossible to make it working since request scope is bound the thre >>>>>>>> request thread - and not the request. Side note: same applies to session >>>>>>>> scope and conversation. >>>>>>>> >>>>>>>> >>>>>>>>> Surely the Red Hat folks can quickly shed some light here since >>>>>>>>> they implement essentially this whole stack? >>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>> >>>>>>>>>> Can you kindly try to make the example a bit simpler? It's >>>>>>>>>> important to make the case for how likely this is supposed to occur in most >>>>>>>>>> business applications. >>>>>>>>>> >>>>>>>>>> Also, other than making sure that the executor service is >>>>>>>>>> propagating thread local request contexts correctly what other solution are >>>>>>>>>> you proposing? Did you check the specification? How sure are you that this >>>>>>>>>> isn't simply an implementation bug? >>>>>>>>>> >>>>>>>>>> As far as I know the executor service is supposed to be >>>>>>>>>> preserving all relevant parts of the EE context? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Not in concurrency-utilities for EE at least. That was the first >>>>>>>>> impl I did then Mark pointed out it was violating CDI spec and request >>>>>>>>> scope definition. There is a kind of contracdiction there cause >>>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>>>> tackle it. >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e >>>>>>>>>> help? >>>>>>>>>> >>>>>>>>>> Idea is to give an API to make: >>>>>>>>>> >>>>>>>>>> public void complete() { >>>>>>>>>> try { >>>>>>>>>> asyncContext.complete(); >>>>>>>>>> } finally { >>>>>>>>>> auditContext.end(); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> working without hacky and almost impossible context pushing >>>>>>>>>> (cause of injections nature you are not supposed to know what to push in >>>>>>>>>> the context when going async). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau | Blog >>>>>>>>>> | Github >>>>>>>>>> | LinkedIn >>>>>>>>>> | Tomitriber >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>> >>>>>>>>>>> Can you kindly share an annotated code example of the proposed >>>>>>>>>>> solution so we can all follow and discuss this? >>>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>>>>> >>>>>>>>>>> Hi guys, >>>>>>>>>>> >>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a >>>>>>>>>>> cdi scope. Idea is to follow request scope more than cdi spec allows. First >>>>>>>>>>> thought it was a concurrency utilities thing but Reza mentionned can be a >>>>>>>>>>> CDI one so here it is. >>>>>>>>>>> >>>>>>>>>>> Sample: >>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set >>>>>>>>>>> on it. The i go async (AsyncContext) and trigger a task in another thread. >>>>>>>>>>> It would be neat - and mandatory in some case by the loose coupling nature >>>>>>>>>>> of CDI - to get the *same* MyBean *instance* in this thread. With a direct >>>>>>>>>>> dependency you can easily use message passing pattern - but you loose the >>>>>>>>>>> loose coupling cause you need to know until which level you unwrap, think t >>>>>>>>>>> principal case which has 2-3 proxies!. However in practice you have a lot >>>>>>>>>>> of undirect dependencies, in particular with enterprise concerns (auditing, >>>>>>>>>>> security...) so you can't really do it easily/naturally. >>>>>>>>>>> >>>>>>>>>>> Bonus: >>>>>>>>>>> One very verbose way is to be able to kind of push/pop an >>>>>>>>>>> existing context in a thread - wrappers doing it on a >>>>>>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>>>>>> >>>>>>>>>>> Question: >>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>> >>>>>>>>>>> Side note: this is really about the fact to reuse a "context >>>>>>>>>>> context" (its current instances map) in another thread the more >>>>>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>>>>> question for now. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>> @rmannibucau | Blog >>>>>>>>>>> | Github >>>>>>>>>>> | LinkedIn >>>>>>>>>>> | Tomitriber >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/878f8bf3/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 08:47:05 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 08:47:05 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <56DD5079.40801@redhat.com> <9532B290-4F8C-4358-B8CD-36EE36A595E9@lycos.com> <8CACB9C7-3790-4047-8C20-2B0A41065D1C@lycos.com> Message-ID: <96A3F4D9-3076-4D6C-A0FC-3C2072314F5E@lycos.com> I am still confused what the issue is. Let's do this another way. What do you propose as a solution for EE overall? Are you simply saying the current proprietary ways of configuring executors are not good? > On Mar 7, 2016, at 8:39 AM, Romain Manni-Bucau wrote: > > > 2016-03-07 14:34 GMT+01:00 Reza Rahman : >> You've lost me. >> >> Are you talking about configuring what executors the container implementation itself should use or what custom executors an application developer can use? >> > > Both cases > >> The best I can understand what your saying applies to the container implementation itself. Then again, implementations like WebLogic, WebSphere and GlassFish allow you to configure even the core executor pool of the runtime. It most certainly allows creating custom executors pools. >> >> The only difference would be making what is vendor specific today completely standardized. Since when is that a bad thing? >> > > I'm for this standardization - even if just a subset of vendors config but the minimum to ensure an app can scale on all servers. The bad thing is when the feature is central or important for an app. Then you hide a proprietary feature behind a standard API, this is very nasty and can lead to broken usages pretty easily. > > However my last point is: even if you fix it for the container you still have the app use cases where the pool are sometimes hidden in apps themself and EE concurrency doesn't help there (and just taking few remote libs it is not rare at all). > >>> On Mar 7, 2016, at 8:19 AM, Romain Manni-Bucau wrote: >>> >>> 2016-03-07 14:15 GMT+01:00 Reza Rahman : >>>> I am really confused now. Why shouldn't Java EE concurrency not be able to define a standard way to configure custom executors? You can do that today, just in vendor specific ways... >>>> >>> >>> Cause there are several libs where you don't control the pool and the best you can do is to wrap the task (Runnable) on your side. Also you can hit it in background threads you can't enforce to use concurrency spec and finally you can hit it in fully synchronous way if you execute after the CDI chain - which is allowed by CDI and TCK-ed so you can need a way to stack the context to reuse some part after. Last "?": JTA integration: you can also hit it to save data after @TransactionScoped for audit purposes. >>> >>>>> On Mar 7, 2016, at 5:10 AM, Romain Manni-Bucau wrote: >>>>> >>>>> >>>>> 2016-03-07 10:57 GMT+01:00 Martin Kouba : >>>>>> Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a): >>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba >>>>>> >: >>>>>>> >>>>>>> >>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>>>> >>>>>>> >>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>>> >>>>>>> >> a ?crit : >>>>>>> >>>>>>> > >>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>>> > >>>>>>> >> Hi guys, >>>>>>> >> >>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK >>>>>>> utilities, >>>>>>> >> can we move back to CompletionFuture? >>>>>>> >> >>>>>>> >> It would allow for instance: >>>>>>> >> >>>>>>> >> // doesn't work with CompletionStage >>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), >>>>>>> event2.fireAsync(...)) >>>>>>> >> .then(...) >>>>>>> > >>>>>>> > >>>>>>> > Well, this should work if the underlying CompletionStage impl >>>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>>> > >>>>>>> >>>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>>> >>>>>>> > >>>>>>> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>>> > >>>>>>> > AFAIK the default async execution facility of >>>>>>> CompletableFuture is >>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. >>>>>>> Using the >>>>>>> CompletionStage interface allows us to wrap the async calls >>>>>>> without the >>>>>>> specified executor (e.g. >>>>>>> CompletionStage.thenApplyAsync(Function>>>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>>>> > >>>>>>> >>>>>>> Should use the pool in which the evznt is fired then "then step" is >>>>>>> synchronous is my sample so all is decided at fire time >>>>>>> >>>>>>> >>>>>>> I don't talk about your particular example - I understand that it's >>>>>>> not using async exec (although the "then()" method does not exist). >>>>>>> >>>>>>> >>>>>>> was supposed to represent the different flavours (thenRun, thenCompose, >>>>>>> ...) ;). >>>>>>> >>>>>>> That said I agree on the state switching the pool is better but with >>>>>>> these 2 notes: >>>>>>> >>>>>>> - could be better to hide these poorly designed methods then -> don't >>>>>>> use CompletionXXX but a CDI API with a bridge to CompletionX to let the >>>>>>> user go back on SE tools >>>>>> >>>>>> Yep, this is one of the possible solutions. On the other hand, I don't think it's poorly designed. CompletionStage defines the "default asynchronous execution facility" and CDI spec states that the CompletionStage returned by fireAsync methods is container-specific. The impl may choose to clarify this "default asynchronous execution facility", i.e. there's place for innovation... >>>>>> >>>>>>> - we still don't have a *standard* config for the pool(s) underlying CDI >>>>>>> features so it sounds as poor as SE solution IMO (at least a >>>>>>> core/max/ttl config in beans.xml) >>>>>> >>>>>> I don't think this should be standardized... >>>>>> >>>>> >>>>> Why? Typically if you take @Asynchronous (EJB spec) you have already this issue and this is often avoided when portability matters for that particular reason you don't know how you will behave. Or do you think concurrency-utilities solves it? >>>>> >>>>>>> >>>>>>> >>>>>>> > >>>>>>> >> >>>>>>> >> Romain Manni-Bucau >>>>>>> >> @rmannibucau | Blog >>>>>>> >> | Github >>>>>>> >> | LinkedIn >>>>>>> >> | Tomitriber >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> _______________________________________________ >>>>>>> >> cdi-dev mailing list >>>>>>> >> cdi-dev at 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 >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Martin Kouba >>>>>>> Software Engineer >>>>>>> Red Hat, Czech Republic >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Martin Kouba >>>>>> Software Engineer >>>>>> Red Hat, Czech Republic >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/74ff7247/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 08:52:26 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 08:52:26 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> <26A370F4-7B3D-4125-88E4-E0FB1BD0F340@lycos.com> Message-ID: I hate to tell you this, but I would recommend the same. I have read this many, many times over months because I think this is an important API. There is a big difference between pointing out possible issues with incorrect use of a feature and outright forbidding a feature. This is merely a warning on what could happen if a feature is misused. > On Mar 7, 2016, at 8:42 AM, Romain Manni-Bucau wrote: > > > 2016-03-07 14:40 GMT+01:00 Reza Rahman : >> There are way too many cases I can cite of the spec saying something is optional but good implementations doing what is actually right. Even in the worst reading of this, that is exactly what is happening here. >> > > Reza take one day and re-read it with a not oriented eye: the spec states it shouldnt work. Let also ignore the concurrency utility for one moment since it covers only 50% of the cases and show me where the spec states it should be covered please. > >>> On Mar 7, 2016, at 8:12 AM, Romain Manni-Bucau wrote: >>> >>> 2016-03-07 14:06 GMT+01:00 Reza Rahman : >>>> What this is saying is that it is not recommended to use them because of the possible life-cycle mismatch. If they are not supposed to work at all, the specification would have simply stated it won't work. >>>> >>> >>> It is not stated so not supported, that's the way EE works whatever you think (if you doubt just use any of the SHOULD features in 2 servers ;)). >>> >>>> Anyway personally I have no reason to further discuss this. I'm going to try to find a way to get this done for developers sooner rather than later. If TomEE does not want to do it, too bad for developers. >>>> >>> >>> This is not the point. I'm for getting it done but the spec states the opposite since it ignores not submitting instances completely and it states that submitting ones are not expected to work very clearly in the previous quote (not being deterministic means it doesn't work). >>> >>> However the issue is wider than concurrency-utilities so even if you manage to get it done for this spec users can still face this issue. If I follow a context start/stop API is possible for 2.0 so question is really: should this API get inheritance or not. >>> >>>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau wrote: >>>>> >>>>> " >>>>> Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. >>>>> " >>>>> >>>>> States that the context is not inherited, is that what you mean? >>>>> >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>> >>>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>>>> The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. >>>>>> >>>>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >>>>>>> Specifically >>>>>> >>>>>>> The containers mimic ejb for propagation for a good reason! >>>>>>> No session e.g. , new TX, etc >>>>>>> >>>>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). >>>>>>> >>>>>>> LieGrue, >>>>>>> Strub >>>>>>> >>>>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>>>>>>> >>>>>>>> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>>> >>>>>>>> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >>>>>>>> >>>>>>>> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >>>>>>>>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >>>>>>>>> >>>>>>>>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >>>>>>>>> >>>>>>>>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >>>>>>>>> >>>>>>>>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >>>>>>>>> >>>>>>>>>> Reza, >>>>>>>>>> >>>>>>>>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>>>>>>>>> >>>>>>>>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>>>> >>>>>>>>>> If that's the case, then basically this should work OOTB right? >>>>>>>>>> >>>>>>>>>> Task task = new MyTask(); >>>>>>>>>> task = contextService.createContextualProxy(task, Task.class); >>>>>>>>>> executor.submit(task); >>>>>>>>>> >>>>>>>>>> // now magically the context should be prop'd? >>>>>>>>>> >>>>>>>>>> Is that about right? >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>>>>>>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>>>>>>>>> >>>>>>>>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>>>>>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>>>>>>>>> >>>>>>>>>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>>>>>>>>>> >>>>>>>>>>>>>> John >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>>>>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> public void complete() { >>>>>>>>>>>>>>>>>>>>> try { >>>>>>>>>>>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>>>>>>>>>>>> } finally { >>>>>>>>>>>>>>>>>>>>> auditContext.end(); >>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Sample: >>>>>>>>>>>>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Bonus: >>>>>>>>>>>>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Question: >>>>>>>>>>>>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/140a0c16/attachment-0001.html From rmannibucau at gmail.com Mon Mar 7 08:52:12 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 14:52:12 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <96A3F4D9-3076-4D6C-A0FC-3C2072314F5E@lycos.com> References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <56DD5079.40801@redhat.com> <9532B290-4F8C-4358-B8CD-36EE36A595E9@lycos.com> <8CACB9C7-3790-4047-8C20-2B0A41065D1C@lycos.com> <96A3F4D9-3076-4D6C-A0FC-3C2072314F5E@lycos.com> Message-ID: 2016-03-07 14:47 GMT+01:00 Reza Rahman : > I am still confused what the issue is. Let's do this another way. > > What do you propose as a solution for EE overall? Are you simply saying > the current proprietary ways of configuring executors are not good? > > Solutions: 1. standardize the basic pool configs 2. add an API to control the context and its propagation cleanly 3. (i don't know about the tck part so this is a maybe) fix/enhance the integration between concurrency and cdi specs if needed (TCK) + add a way to propagate a context (maybe with concurrency utility proxy factory and a new option in method signature) About proprietary config: yes this is generally bad to rely on it too much for internals of an app. A thread pool is an internal of an app - understand it as opposed to "a MySQL/Oracle datasource". > On Mar 7, 2016, at 8:39 AM, Romain Manni-Bucau > wrote: > > > 2016-03-07 14:34 GMT+01:00 Reza Rahman : > >> You've lost me. >> >> Are you talking about configuring what executors the container >> implementation itself should use or what custom executors an application >> developer can use? >> >> > Both cases > > >> The best I can understand what your saying applies to the container >> implementation itself. Then again, implementations like WebLogic, WebSphere >> and GlassFish allow you to configure even the core executor pool of the >> runtime. It most certainly allows creating custom executors pools. >> >> The only difference would be making what is vendor specific today >> completely standardized. Since when is that a bad thing? >> >> > I'm for this standardization - even if just a subset of vendors config but > the minimum to ensure an app can scale on all servers. The bad thing is > when the feature is central or important for an app. Then you hide a > proprietary feature behind a standard API, this is very nasty and can lead > to broken usages pretty easily. > > However my last point is: even if you fix it for the container you still > have the app use cases where the pool are sometimes hidden in apps themself > and EE concurrency doesn't help there (and just taking few remote libs it > is not rare at all). > > >> On Mar 7, 2016, at 8:19 AM, Romain Manni-Bucau >> wrote: >> >> 2016-03-07 14:15 GMT+01:00 Reza Rahman : >> >>> I am really confused now. Why shouldn't Java EE concurrency not be able >>> to define a standard way to configure custom executors? You can do that >>> today, just in vendor specific ways... >>> >>> >> Cause there are several libs where you don't control the pool and the >> best you can do is to wrap the task (Runnable) on your side. Also you can >> hit it in background threads you can't enforce to use concurrency spec and >> finally you can hit it in fully synchronous way if you execute after the >> CDI chain - which is allowed by CDI and TCK-ed so you can need a way to >> stack the context to reuse some part after. Last "?": JTA integration: you >> can also hit it to save data after @TransactionScoped for audit purposes. >> >> >>> On Mar 7, 2016, at 5:10 AM, Romain Manni-Bucau >>> wrote: >>> >>> >>> 2016-03-07 10:57 GMT+01:00 Martin Kouba : >>> >>>> Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a): >>>> >>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba >>>> >: >>>>> >>>>> >>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>> >>>>> >>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>> >>>>> >> a >>>>> ?crit : >>>>> >>>>> > >>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>> > >>>>> >> Hi guys, >>>>> >> >>>>> >> as a user having a ComlpetionStage makes me loose some JDK >>>>> utilities, >>>>> >> can we move back to CompletionFuture? >>>>> >> >>>>> >> It would allow for instance: >>>>> >> >>>>> >> // doesn't work with CompletionStage >>>>> >> CompletionFuture.allOf(event1.fireAsync(...), >>>>> event2.fireAsync(...)) >>>>> >> .then(...) >>>>> > >>>>> > >>>>> > Well, this should work if the underlying CompletionStage >>>>> impl >>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>> > >>>>> >>>>> Yes but it is not natural to convert it IMO = we can do better >>>>> >>>>> > >>>>> >>>>> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>> event2.fireAsync(...).toCompletableFuture()) >>>>> > >>>>> > AFAIK the default async execution facility of >>>>> CompletableFuture is >>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. >>>>> Using the >>>>> CompletionStage interface allows us to wrap the async calls >>>>> without the >>>>> specified executor (e.g. >>>>> CompletionStage.thenApplyAsync(Function>>>> T, ? extends U>)) and supply a default one provided by the >>>>> impl. >>>>> > >>>>> >>>>> Should use the pool in which the evznt is fired then "then >>>>> step" is >>>>> synchronous is my sample so all is decided at fire time >>>>> >>>>> >>>>> I don't talk about your particular example - I understand that it's >>>>> not using async exec (although the "then()" method does not exist). >>>>> >>>>> >>>>> was supposed to represent the different flavours (thenRun, thenCompose, >>>>> ...) ;). >>>>> >>>>> That said I agree on the state switching the pool is better but with >>>>> these 2 notes: >>>>> >>>>> - could be better to hide these poorly designed methods then -> don't >>>>> use CompletionXXX but a CDI API with a bridge to CompletionX to let the >>>>> user go back on SE tools >>>>> >>>> >>>> Yep, this is one of the possible solutions. On the other hand, I don't >>>> think it's poorly designed. CompletionStage defines the "default >>>> asynchronous execution facility" and CDI spec states that the >>>> CompletionStage returned by fireAsync methods is container-specific. The >>>> impl may choose to clarify this "default asynchronous execution facility", >>>> i.e. there's place for innovation... >>>> >>>> - we still don't have a *standard* config for the pool(s) underlying CDI >>>>> features so it sounds as poor as SE solution IMO (at least a >>>>> core/max/ttl config in beans.xml) >>>>> >>>> >>>> I don't think this should be standardized... >>>> >>>> >>> Why? Typically if you take @Asynchronous (EJB spec) you have already >>> this issue and this is often avoided when portability matters for that >>> particular reason you don't know how you will behave. Or do you think >>> concurrency-utilities solves it? >>> >>> >>>> >>>>> >>>>> > >>>>> >> >>>>> >> Romain Manni-Bucau >>>>> >> @rmannibucau | Blog >>>>> >> | Github >>>>> >> | LinkedIn >>>>> >> | Tomitriber >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> _______________________________________________ >>>>> >> cdi-dev mailing list >>>>> >> cdi-dev at lists.jboss.org >>>>> >>>> cdi-dev at 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 >>>>> >>>>> >>>>> -- >>>>> Martin Kouba >>>>> Software Engineer >>>>> Red Hat, Czech Republic >>>>> >>>>> >>>>> >>>> -- >>>> Martin Kouba >>>> Software Engineer >>>> Red Hat, Czech Republic >>>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/d66a4e8d/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 10:03:43 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 10:03:43 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <56DD5079.40801@redhat.com> <9532B290-4F8C-4358-B8CD-36EE36A595E9@lycos.com> <8CACB9C7-3790-4047-8C20-2B0A41065D1C@lycos.com> <96A3F4D9-3076-4D6C-A0FC-3C2072314F5E@lycos.com> Message-ID: Comments in-line: > On Mar 7, 2016, at 8:52 AM, Romain Manni-Bucau wrote: > > > 2016-03-07 14:47 GMT+01:00 Reza Rahman : >> I am still confused what the issue is. Let's do this another way. >> >> What do you propose as a solution for EE overall? Are you simply saying the current proprietary ways of configuring executors are not good? > > Solutions: > 1. standardize the basic pool configs This is what concerns me the most. I'd like to see this standardized. If there isn't anything that I am missing here, there is not much for me to discuss. > 2. add an API to control the context and its propagation cleanly You mean a CDI API to further control life cycle? I'd like to see a concrete proposal before I comment on this. This sounds to me like there isn't an easy solution to it. > 3. (i don't know about the tck part so this is a maybe) fix/enhance the integration between concurrency and cdi specs if needed (TCK) + add a way to propagate a context (maybe with concurrency utility proxy factory and a new option in method signature) Already discussed my thoughts on this. I don't think there is a need to repeat that here. > > About proprietary config: yes this is generally bad to rely on it too much for internals of an app. A thread pool is an internal of an app - understand it as opposed to "a MySQL/Oracle datasource". This is where you lost me again. Are you arguing for standardizing what is proprietary today or not? > >>> On Mar 7, 2016, at 8:39 AM, Romain Manni-Bucau wrote: >>> >>> >>> 2016-03-07 14:34 GMT+01:00 Reza Rahman : >>>> You've lost me. >>>> >>>> Are you talking about configuring what executors the container implementation itself should use or what custom executors an application developer can use? >>> >>> Both cases >>> >>>> The best I can understand what your saying applies to the container implementation itself. Then again, implementations like WebLogic, WebSphere and GlassFish allow you to configure even the core executor pool of the runtime. It most certainly allows creating custom executors pools. >>>> >>>> The only difference would be making what is vendor specific today completely standardized. Since when is that a bad thing? >>> >>> I'm for this standardization - even if just a subset of vendors config but the minimum to ensure an app can scale on all servers. The bad thing is when the feature is central or important for an app. Then you hide a proprietary feature behind a standard API, this is very nasty and can lead to broken usages pretty easily. >>> >>> However my last point is: even if you fix it for the container you still have the app use cases where the pool are sometimes hidden in apps themself and EE concurrency doesn't help there (and just taking few remote libs it is not rare at all). >>> >>>>> On Mar 7, 2016, at 8:19 AM, Romain Manni-Bucau wrote: >>>>> >>>>> 2016-03-07 14:15 GMT+01:00 Reza Rahman : >>>>>> I am really confused now. Why shouldn't Java EE concurrency not be able to define a standard way to configure custom executors? You can do that today, just in vendor specific ways... >>>>> >>>>> Cause there are several libs where you don't control the pool and the best you can do is to wrap the task (Runnable) on your side. Also you can hit it in background threads you can't enforce to use concurrency spec and finally you can hit it in fully synchronous way if you execute after the CDI chain - which is allowed by CDI and TCK-ed so you can need a way to stack the context to reuse some part after. Last "?": JTA integration: you can also hit it to save data after @TransactionScoped for audit purposes. >>>>> >>>>>>> On Mar 7, 2016, at 5:10 AM, Romain Manni-Bucau wrote: >>>>>>> >>>>>>> >>>>>>> 2016-03-07 10:57 GMT+01:00 Martin Kouba : >>>>>>>> Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a): >>>>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba >>>>>>>> >: >>>>>>>>> >>>>>>>>> >>>>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>>>>> >>>>>>>>> >> a ?crit : >>>>>>>>> >>>>>>>>> > >>>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>>>>> > >>>>>>>>> >> Hi guys, >>>>>>>>> >> >>>>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK >>>>>>>>> utilities, >>>>>>>>> >> can we move back to CompletionFuture? >>>>>>>>> >> >>>>>>>>> >> It would allow for instance: >>>>>>>>> >> >>>>>>>>> >> // doesn't work with CompletionStage >>>>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), >>>>>>>>> event2.fireAsync(...)) >>>>>>>>> >> .then(...) >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Well, this should work if the underlying CompletionStage impl >>>>>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>>>>> > >>>>>>>>> >>>>>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>>>>> >>>>>>>>> > >>>>>>>>> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>>>>> > >>>>>>>>> > AFAIK the default async execution facility of >>>>>>>>> CompletableFuture is >>>>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. >>>>>>>>> Using the >>>>>>>>> CompletionStage interface allows us to wrap the async calls >>>>>>>>> without the >>>>>>>>> specified executor (e.g. >>>>>>>>> CompletionStage.thenApplyAsync(Function>>>>>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>>>>>> > >>>>>>>>> >>>>>>>>> Should use the pool in which the evznt is fired then "then step" is >>>>>>>>> synchronous is my sample so all is decided at fire time >>>>>>>>> >>>>>>>>> >>>>>>>>> I don't talk about your particular example - I understand that it's >>>>>>>>> not using async exec (although the "then()" method does not exist). >>>>>>>>> >>>>>>>>> >>>>>>>>> was supposed to represent the different flavours (thenRun, thenCompose, >>>>>>>>> ...) ;). >>>>>>>>> >>>>>>>>> That said I agree on the state switching the pool is better but with >>>>>>>>> these 2 notes: >>>>>>>>> >>>>>>>>> - could be better to hide these poorly designed methods then -> don't >>>>>>>>> use CompletionXXX but a CDI API with a bridge to CompletionX to let the >>>>>>>>> user go back on SE tools >>>>>>>> >>>>>>>> Yep, this is one of the possible solutions. On the other hand, I don't think it's poorly designed. CompletionStage defines the "default asynchronous execution facility" and CDI spec states that the CompletionStage returned by fireAsync methods is container-specific. The impl may choose to clarify this "default asynchronous execution facility", i.e. there's place for innovation... >>>>>>>> >>>>>>>>> - we still don't have a *standard* config for the pool(s) underlying CDI >>>>>>>>> features so it sounds as poor as SE solution IMO (at least a >>>>>>>>> core/max/ttl config in beans.xml) >>>>>>>> >>>>>>>> I don't think this should be standardized... >>>>>>> >>>>>>> Why? Typically if you take @Asynchronous (EJB spec) you have already this issue and this is often avoided when portability matters for that particular reason you don't know how you will behave. Or do you think concurrency-utilities solves it? >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > >>>>>>>>> >> >>>>>>>>> >> Romain Manni-Bucau >>>>>>>>> >> @rmannibucau | Blog >>>>>>>>> >> | Github >>>>>>>>> >> | LinkedIn >>>>>>>>> >> | Tomitriber >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> _______________________________________________ >>>>>>>>> >> cdi-dev mailing list >>>>>>>>> >> cdi-dev at 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Martin Kouba >>>>>>>>> Software Engineer >>>>>>>>> Red Hat, Czech Republic >>>>>>>> >>>>>>>> -- >>>>>>>> Martin Kouba >>>>>>>> Software Engineer >>>>>>>> Red Hat, Czech Republic >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/3b6180ad/attachment-0001.html From struberg at yahoo.de Mon Mar 7 10:05:32 2016 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 7 Mar 2016 16:05:32 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> <2C765CDD-E086-4D24-9B DB-38A37C27CF1B@yahoo.de> Message-ID: <886FAD60-6E2E-4467-A535-B3272232DD29@yahoo.de> The question is whether the spec does allow us to do it. And if other containers consequently do it as well. If it does then I will implement it in TomEE. LieGrue, strub > Am 07.03.2016 um 14:06 schrieb Reza Rahman : > > What this is saying is that it is not recommended to use them because of the possible life-cycle mismatch. If they are not supposed to work at all, the specification would have simply stated it won't work. > > Anyway personally I have no reason to further discuss this. I'm going to try to find a way to get this done for developers sooner rather than later. If TomEE does not want to do it, too bad for developers. > > On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau wrote: > >> " >> Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. >> " >> >> States that the context is not inherited, is that what you mean? >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >> The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. >> >> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >> Specifically >>> The containers mimic ejb for propagation for a good reason! >>> No session e.g. , new TX, etc >>> >>> Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). >>> >>> LieGrue, >>> Strub >>> >>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>> >>>> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >>>> >>>> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >>>> >>>> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >>>> >>>> John >>>> >>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >>>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >>>> >>>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >>>> >>>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >>>> >>>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >>>> >>>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >>>> >>>>> Reza, >>>>> >>>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>>>> >>>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>> >>>>> If that's the case, then basically this should work OOTB right? >>>>> >>>>> Task task = new MyTask(); >>>>> task = contextService.createContextualProxy(task, Task.class); >>>>> executor.submit(task); >>>>> >>>>> // now magically the context should be prop'd? >>>>> >>>>> Is that about right? >>>>> >>>>> John >>>>> >>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>>> >>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>>> >>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>> >>>>>> >>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>> >>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>>> >>>>>> >>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>>> >>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>> >>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>>> >>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>>> >>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>>> >>>>>>> >>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>>> >>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>> >>>>>>>> >>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>> >>>>>>>> >>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>> >>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>> >>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>> >>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>> >>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>> >>>>>>>>> >>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>> >>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>> >>>>>>>>>> Idea is to give an API to make: >>>>>>>>>> >>>>>>>>>> public void complete() { >>>>>>>>>> try { >>>>>>>>>> asyncContext.complete(); >>>>>>>>>> } finally { >>>>>>>>>> auditContext.end(); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>> >>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>> >>>>>>>>>>> Hi guys, >>>>>>>>>>> >>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>> >>>>>>>>>>> Sample: >>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>> >>>>>>>>>>> Bonus: >>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>> >>>>>>>>>>> Question: >>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>> >>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. From struberg at yahoo.de Mon Mar 7 10:09:02 2016 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 7 Mar 2016 16:09:02 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> Message-ID: <05A2736C-BA0C-4080-89CA-3B66A3A1D58B@yahoo.de> > Am 07.03.2016 um 14:12 schrieb Romain Manni-Bucau : > > This is not the point. I'm for getting it done but the spec states the opposite since it ignores not submitting instances completely and it states that submitting ones are not expected to work very clearly in the previous quote (not being deterministic means it doesn't work). Romain has a point :/ It?s not just left out, it seems to be explicitly marked as non-portable. That should be amended in the concurrency-utils spec. And even better: it should explicitly be defined that @RequestScoped works. Of course I can live with all vendors agree that it should work. Better than nothing. LieGrue, strub From rmannibucau at gmail.com Mon Mar 7 10:12:53 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 16:12:53 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <56DD5079.40801@redhat.com> <9532B290-4F8C-4358-B8CD-36EE36A595E9@lycos.com> <8CACB9C7-3790-4047-8C20-2B0A41065D1C@lycos.com> <96A3F4D9-3076-4D6C-A0FC-3C2072314F5E@lycos.com> Message-ID: 2016-03-07 16:03 GMT+01:00 Reza Rahman : > Comments in-line: > > On Mar 7, 2016, at 8:52 AM, Romain Manni-Bucau > wrote: > > > 2016-03-07 14:47 GMT+01:00 Reza Rahman : > >> I am still confused what the issue is. Let's do this another way. >> >> What do you propose as a solution for EE overall? Are you simply saying >> the current proprietary ways of configuring executors are not good? >> >> > Solutions: > 1. standardize the basic pool configs > > > This is what concerns me the most. I'd like to see this standardized. If > there isn't anything that I am missing here, there is not much for me to > discuss. > > 2. add an API to control the context and its propagation cleanly > > > You mean a CDI API to further control life cycle? I'd like to see a > concrete proposal before I comment on this. This sounds to me like there > isn't an easy solution to it. > > To share the idea: ContextView view= beanManager.createContextView(RequestScoped.class); new Runnable() { public void run() { ContextView old = beanManager.restore(RequestScoped.class, view); try { // work } finally { beanManager.restore(RequestScoped.class, old); } } }; > 3. (i don't know about the tck part so this is a maybe) fix/enhance the > integration between concurrency and cdi specs if needed (TCK) + add a way > to propagate a context (maybe with concurrency utility proxy factory and a > new option in method signature) > > > Already discussed my thoughts on this. I don't think there is a need to > repeat that here. > > > About proprietary config: yes this is generally bad to rely on it too much > for internals of an app. A thread pool is an internal of an app - > understand it as opposed to "a MySQL/Oracle datasource". > > > This is where you lost me again. Are you arguing for standardizing what is > proprietary today or not? > > Yep I'm for. > > >> On Mar 7, 2016, at 8:39 AM, Romain Manni-Bucau >> wrote: >> >> >> 2016-03-07 14:34 GMT+01:00 Reza Rahman : >> >>> You've lost me. >>> >>> Are you talking about configuring what executors the container >>> implementation itself should use or what custom executors an application >>> developer can use? >>> >>> >> Both cases >> >> >>> The best I can understand what your saying applies to the container >>> implementation itself. Then again, implementations like WebLogic, WebSphere >>> and GlassFish allow you to configure even the core executor pool of the >>> runtime. It most certainly allows creating custom executors pools. >>> >>> The only difference would be making what is vendor specific today >>> completely standardized. Since when is that a bad thing? >>> >>> >> I'm for this standardization - even if just a subset of vendors config >> but the minimum to ensure an app can scale on all servers. The bad thing is >> when the feature is central or important for an app. Then you hide a >> proprietary feature behind a standard API, this is very nasty and can lead >> to broken usages pretty easily. >> >> However my last point is: even if you fix it for the container you still >> have the app use cases where the pool are sometimes hidden in apps themself >> and EE concurrency doesn't help there (and just taking few remote libs it >> is not rare at all). >> >> >>> On Mar 7, 2016, at 8:19 AM, Romain Manni-Bucau >>> wrote: >>> >>> 2016-03-07 14:15 GMT+01:00 Reza Rahman : >>> >>>> I am really confused now. Why shouldn't Java EE concurrency not be able >>>> to define a standard way to configure custom executors? You can do that >>>> today, just in vendor specific ways... >>>> >>>> >>> Cause there are several libs where you don't control the pool and the >>> best you can do is to wrap the task (Runnable) on your side. Also you can >>> hit it in background threads you can't enforce to use concurrency spec and >>> finally you can hit it in fully synchronous way if you execute after the >>> CDI chain - which is allowed by CDI and TCK-ed so you can need a way to >>> stack the context to reuse some part after. Last "?": JTA integration: you >>> can also hit it to save data after @TransactionScoped for audit purposes. >>> >>> >>>> On Mar 7, 2016, at 5:10 AM, Romain Manni-Bucau >>>> wrote: >>>> >>>> >>>> 2016-03-07 10:57 GMT+01:00 Martin Kouba : >>>> >>>>> Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a): >>>>> >>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba >>>>> >: >>>>>> >>>>>> >>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>>> >>>>>> >>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>> >>>>>> >> a >>>>>> ?crit : >>>>>> >>>>>> > >>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>> > >>>>>> >> Hi guys, >>>>>> >> >>>>>> >> as a user having a ComlpetionStage makes me loose some >>>>>> JDK >>>>>> utilities, >>>>>> >> can we move back to CompletionFuture? >>>>>> >> >>>>>> >> It would allow for instance: >>>>>> >> >>>>>> >> // doesn't work with CompletionStage >>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), >>>>>> event2.fireAsync(...)) >>>>>> >> .then(...) >>>>>> > >>>>>> > >>>>>> > Well, this should work if the underlying CompletionStage >>>>>> impl >>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>> > >>>>>> >>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>> >>>>>> > >>>>>> >>>>>> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>> > >>>>>> > AFAIK the default async execution facility of >>>>>> CompletableFuture is >>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. >>>>>> Using the >>>>>> CompletionStage interface allows us to wrap the async calls >>>>>> without the >>>>>> specified executor (e.g. >>>>>> CompletionStage.thenApplyAsync(Function>>>>> T, ? extends U>)) and supply a default one provided by the >>>>>> impl. >>>>>> > >>>>>> >>>>>> Should use the pool in which the evznt is fired then "then >>>>>> step" is >>>>>> synchronous is my sample so all is decided at fire time >>>>>> >>>>>> >>>>>> I don't talk about your particular example - I understand that >>>>>> it's >>>>>> not using async exec (although the "then()" method does not >>>>>> exist). >>>>>> >>>>>> >>>>>> was supposed to represent the different flavours (thenRun, >>>>>> thenCompose, >>>>>> ...) ;). >>>>>> >>>>>> That said I agree on the state switching the pool is better but with >>>>>> these 2 notes: >>>>>> >>>>>> - could be better to hide these poorly designed methods then -> don't >>>>>> use CompletionXXX but a CDI API with a bridge to CompletionX to let >>>>>> the >>>>>> user go back on SE tools >>>>>> >>>>> >>>>> Yep, this is one of the possible solutions. On the other hand, I don't >>>>> think it's poorly designed. CompletionStage defines the "default >>>>> asynchronous execution facility" and CDI spec states that the >>>>> CompletionStage returned by fireAsync methods is container-specific. The >>>>> impl may choose to clarify this "default asynchronous execution facility", >>>>> i.e. there's place for innovation... >>>>> >>>>> - we still don't have a *standard* config for the pool(s) underlying >>>>>> CDI >>>>>> features so it sounds as poor as SE solution IMO (at least a >>>>>> core/max/ttl config in beans.xml) >>>>>> >>>>> >>>>> I don't think this should be standardized... >>>>> >>>>> >>>> Why? Typically if you take @Asynchronous (EJB spec) you have already >>>> this issue and this is often avoided when portability matters for that >>>> particular reason you don't know how you will behave. Or do you think >>>> concurrency-utilities solves it? >>>> >>>> >>>>> >>>>>> >>>>>> > >>>>>> >> >>>>>> >> Romain Manni-Bucau >>>>>> >> @rmannibucau | Blog >>>>>> >> | Github >>>>>> >> | LinkedIn >>>>>> >> | Tomitriber >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> _______________________________________________ >>>>>> >> cdi-dev mailing list >>>>>> >> cdi-dev at lists.jboss.org >>>>>> >>>>> cdi-dev at 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 >>>>>> >>>>>> >>>>>> -- >>>>>> Martin Kouba >>>>>> Software Engineer >>>>>> Red Hat, Czech Republic >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Martin Kouba >>>>> Software Engineer >>>>> Red Hat, Czech Republic >>>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/6531e9b1/attachment-0001.html From struberg at yahoo.de Mon Mar 7 10:15:09 2016 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 7 Mar 2016 16:15:09 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <56DD35C7.9040505@redhat.com> References: <56DD35C7.9040505@redhat.com> Message-ID: <0AF6427B-E61D-4BE6-A1EF-677E41D0DCDA@yahoo.de> > Am 07.03.2016 um 09:03 schrieb Martin Kouba : > > You call it "awesome idea", I agree that this feature makes sense, but I > call it "manipulative approach". It was implemented before the EG was > able to decide. The same for CDI-527 - OWB has a config property > "javax.enterprise.inject.allowProxying.classes" Come on Martin, don?t be unfair. How long has this been discussed? Read the original ticket and discussions for bean-discovery-mode where I explained it already. That was almost 4 years ago. But instead the ?annotated? mode got favoured and as it turned out is not that useful in real world because it messes up most Extensions. Can we please do it RIGHT now? What?s the problem? LieGrue, strub From reza_rahman at lycos.com Mon Mar 7 10:24:05 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 10:24:05 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: <05A2736C-BA0C-4080-89CA-3B66A3A1D58B@yahoo.de> References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> <05A2736C-BA0C-4080-89CA-3B66A3A1D58B@yahoo.de> Message-ID: I've already noted this to the JIRA for the issue. If we can we will add it as further clarification. I don't think it's a necessary step to moving forward. > On Mar 7, 2016, at 10:09 AM, Mark Struberg wrote: > > >> Am 07.03.2016 um 14:12 schrieb Romain Manni-Bucau : >> >> This is not the point. I'm for getting it done but the spec states the opposite since it ignores not submitting instances completely and it states that submitting ones are not expected to work very clearly in the previous quote (not being deterministic means it doesn't work). > > > Romain has a point :/ > It?s not just left out, it seems to be explicitly marked as non-portable. > That should be amended in the concurrency-utils spec. > And even better: it should explicitly be defined that @RequestScoped works. > Of course I can live with all vendors agree that it should work. Better than nothing. > > LieGrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. From reza_rahman at lycos.com Mon Mar 7 10:28:54 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 10:28:54 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: <886FAD60-6E2E-4467-A535-B3272232DD29@yahoo.de> References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> <2C765CDD-E086-4D24-9B DB-38A37C27CF1B@yahoo.de> <886FAD60-6E2E-4467-A535-B3272232DD29@yahoo.de> Message-ID: <5B872657-0DBE-469D-99A3-D2076FB70300@lycos.com> Even in the most conservative reading of this, the spec is clearly not disallowing it. > On Mar 7, 2016, at 10:05 AM, Mark Struberg wrote: > > The question is whether the spec does allow us to do it. And if other containers consequently do it as well. > > If it does then I will implement it in TomEE. > > LieGrue, > strub > > >> Am 07.03.2016 um 14:06 schrieb Reza Rahman : >> >> What this is saying is that it is not recommended to use them because of the possible life-cycle mismatch. If they are not supposed to work at all, the specification would have simply stated it won't work. >> >> Anyway personally I have no reason to further discuss this. I'm going to try to find a way to get this done for developers sooner rather than later. If TomEE does not want to do it, too bad for developers. >> >>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau wrote: >>> >>> " >>> Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. >>> " >>> >>> States that the context is not inherited, is that what you mean? >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>> The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. >>> >>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >>>> Specifically >>>> The containers mimic ejb for propagation for a good reason! >>>> No session e.g. , new TX, etc >>>> >>>> Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). >>>> >>>> LieGrue, >>>> Strub >>>> >>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>>>> >>>>> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >>>>> >>>>> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >>>>> >>>>> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >>>>> >>>>> John >>>>> >>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >>>>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >>>>> >>>>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >>>>> >>>>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >>>>> >>>>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >>>>> >>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >>>>>> >>>>>> Reza, >>>>>> >>>>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>>>>> >>>>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>> >>>>>> If that's the case, then basically this should work OOTB right? >>>>>> >>>>>> Task task = new MyTask(); >>>>>> task = contextService.createContextualProxy(task, Task.class); >>>>>> executor.submit(task); >>>>>> >>>>>> // now magically the context should be prop'd? >>>>>> >>>>>> Is that about right? >>>>>> >>>>>> John >>>>>> >>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>>>> >>>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>>>> >>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>>>> >>>>>>> >>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>>> >>>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>>>> >>>>>>> >>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>>>> >>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>>>> >>>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>>>> >>>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>>>> >>>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>>>> >>>>>>>> >>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>>> >>>>>>>>> >>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>>> >>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>>>> >>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>> >>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>> >>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>>> >>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>> >>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>> >>>>>>>>>>> public void complete() { >>>>>>>>>>> try { >>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>> } finally { >>>>>>>>>>> auditContext.end(); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>> >>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>> >>>>>>>>>>>> Hi guys, >>>>>>>>>>>> >>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>> >>>>>>>>>>>> Sample: >>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>> >>>>>>>>>>>> Bonus: >>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>> >>>>>>>>>>>> Question: >>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>> >>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > From mkouba at redhat.com Mon Mar 7 10:36:43 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 7 Mar 2016 16:36:43 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <0AF6427B-E61D-4BE6-A1EF-677E41D0DCDA@yahoo.de> References: <56DD35C7.9040505@redhat.com> <0AF6427B-E61D-4BE6-A1EF-677E41D0DCDA@yahoo.de> Message-ID: <56DDA00B.7060005@redhat.com> Dne 7.3.2016 v 16:15 Mark Struberg napsal(a): > >> Am 07.03.2016 um 09:03 schrieb Martin Kouba : >> >> You call it "awesome idea", I agree that this feature makes sense, but I >> call it "manipulative approach". It was implemented before the EG was >> able to decide. The same for CDI-527 - OWB has a config property >> "javax.enterprise.inject.allowProxying.classes" > > > Come on Martin, don?t be unfair. How long has this been discussed? Read the original ticket and discussions for bean-discovery-mode where I explained it already. That was almost 4 years ago. > But instead the ?annotated? mode got favoured and as it turned out is not that useful in real world because it messes up most Extensions. > Can we please do it RIGHT now? What?s the problem? I'm sorry, I know the issue was created long time ago (05/Feb/14 5:51 PM). Altough it wasn't discussed thorougly - but that's not your fault of course. Again, I don't say it's a bad idea (I like it actually). I just don't like the way you're pushing your opinions (e.g. we did not agreed on the name and bang... OWB acts as if the PR was merged). > > LieGrue, > strub > From reza_rahman at lycos.com Mon Mar 7 10:51:57 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 10:51:57 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <9ACFA187-9884-496B-96A2-44E52CC164E8@lycos.com> References: <56DD30CE.6070101@redhat.com> <9ACFA187-9884-496B-96A2-44E52CC164E8@lycos.com> Message-ID: If still in doubt, a wise move on this is to seek guidance from the JDK team. We shouldn't be doing things contrary to what their API design intent is. Their API design positioning is what folks out there are picking up and running with. > On Mar 7, 2016, at 8:22 AM, Reza Rahman wrote: > > If you don't understand why most developers would simply expect to use CompletableFuture and would immediately be confused if they see something else, I think we are in bigger trouble than I thought. > > You should really ask a few developers outside your immediate network or do a Google search to see just how much more prominent CompletableFuture is as oppose to CompletionStage. Not finding a way to use that API and choosing an obscure superclass is a sure recipe for problems. > >> On Mar 7, 2016, at 5:12 AM, Antoine Sabot-Durand wrote: >> >> Hi guys, >> >> Back from vacation, I'm "happy" to see that we go back on Async event feature (which took us 6 months). >> >> @Reza and @Romain sorry but I don't get it. the good practice is to develop for interface (that's why CDI uses Set and not HashSet for instance). I'm ok it's the theory, but if you want to make an exception to this practice you need to have a good reason. So if you want to rely on JDK classes like CompletableFuture instead of interface, you'll probably have to go a step further than that. CompletionStage has a toCompletableFuture() method. >> >> To go back to the big picture, as some people around don't seem to be happy with what we designed, we still have the solution to move async event can in specification annexe. It's a solution to test a feature without definitely specifying it. >> >> Antoine >> >>> Le lun. 7 mars 2016 ? 08:42, Martin Kouba a ?crit : >>> Dne 6.3.2016 v 16:37 Reza Rahman napsal(a): >>> > How much end user feedback has there been on this? I have to be honest >>> > that it surprises me to find this out now. >>> >>> Well, this was discussed many times (ML, EG mtgs, F2F, etc.). >>> >>> > >>> > This to me stands out as an obvious usability problem. CompletableFuture >>> > is the obvious top level end user API, not CompletionStage. >>> >>> Is it obvious? For me the CompletionStage looks more appropriate. But >>> I'm open for discussions. >>> >>> > Not going >>> > with CompletableFuture is very likely to confuse most people. The last >>> > thing we need is more potential usability problems in Java EE APIs. >>> > >>> > On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau >> > > wrote: >>> > >>> >> Hi guys, >>> >> >>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>> >> can we move back to CompletionFuture? >>> >> >>> >> It would allow for instance: >>> >> >>> >> // doesn't work with CompletionStage >>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>> >> .then(...) >>> >> >>> >> Romain Manni-Bucau >>> >> @rmannibucau | Blog >>> >> | Github >>> >> | LinkedIn >>> >> | Tomitriber >>> >> >>> >> _______________________________________________ >>> >> cdi-dev mailing list >>> >> cdi-dev at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/e25e8d63/attachment.html From antoine at sabot-durand.net Mon Mar 7 11:06:01 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 07 Mar 2016 16:06:01 +0000 Subject: [cdi-dev] About to merge PR 276 (CDI-485 Literals for built-in annotations) Message-ID: Hi Guys, Some of the EG member gave green lite on PR 276 opened 21 days ago: https://github.com/cdi-spec/cdi/pull/276 Please take a few minutes to review it (it's rather simple). Unless negative reaction I'll merge it tomorrow morning (9:00 CET) Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/641f1ef9/attachment.html From reza_rahman at lycos.com Mon Mar 7 14:08:47 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 14:08:47 -0500 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: <5B872657-0DBE-469D-99A3-D2076FB70300@lycos.com> References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> <2C765CDD-E086-4D24-9B DB-38A37C27CF1B@yahoo.de> <886FAD60-6E2E-4467-A535-B3272232DD29@yahoo.de> <5B872657-0DBE-469D-99A3-D2076FB70300@lycos.com> Message-ID: <7F1DB8F2-61DC-459E-8EFC-A93FB6131577@lycos.com> Reading over the CDI spec definition for request scoped beans, I am a tad confused. When are request scoped beans being destroyed right now? Are they just bound to the Servlet request thread and destroyed as soon as the service method returns? In case of asynchronous Servlets, are they kept around until the real HTTP request actually completes the same way the underlying HTTP connection is kept around? Or is that too difficult because it would require integration at a very low level with the Servlet implementation? There's some language around asynchronous completion right now but it's not very clear what actually happens. Does the onComplete, etc asynchronous callback basically create new request scoped instances? > On Mar 7, 2016, at 10:28 AM, Reza Rahman wrote: > > Even in the most conservative reading of this, the spec is clearly not disallowing it. > >> On Mar 7, 2016, at 10:05 AM, Mark Struberg wrote: >> >> The question is whether the spec does allow us to do it. And if other containers consequently do it as well. >> >> If it does then I will implement it in TomEE. >> >> LieGrue, >> strub >> >> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman : >>> >>> What this is saying is that it is not recommended to use them because of the possible life-cycle mismatch. If they are not supposed to work at all, the specification would have simply stated it won't work. >>> >>> Anyway personally I have no reason to further discuss this. I'm going to try to find a way to get this done for developers sooner rather than later. If TomEE does not want to do it, too bad for developers. >>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau wrote: >>>> >>>> " >>>> Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. >>>> " >>>> >>>> States that the context is not inherited, is that what you mean? >>>> >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>> The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. >>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >>>>> Specifically >>>>> The containers mimic ejb for propagation for a good reason! >>>>> No session e.g. , new TX, etc >>>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). >>>>> >>>>> LieGrue, >>>>> Strub >>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>>>>> >>>>>> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >>>>>> >>>>>> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >>>>>> >>>>>> John >>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >>>>>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >>>>>> >>>>>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >>>>>> >>>>>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >>>>>> >>>>>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >>>>>>> >>>>>>> Reza, >>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>>>>>> >>>>>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>> >>>>>>> If that's the case, then basically this should work OOTB right? >>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>> task = contextService.createContextualProxy(task, Task.class); >>>>>>> executor.submit(task); >>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>> >>>>>>> Is that about right? >>>>>>> >>>>>>> John >>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>>>>> >>>>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>>>>> >>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>>>>> >>>>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>>>>> >>>>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>>>>> >>>>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>>>>> >>>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>> >>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>>>>>> try { >>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>>> } finally { >>>>>>>>>>>> auditContext.end(); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. >> From reza_rahman at lycos.com Mon Mar 7 14:35:34 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 14:35:34 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> Message-ID: <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. Basically this means CompletableFutures are already pretty Java EE ready. If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? > On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: > > I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. > >> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau wrote: >> >> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >>> >>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>> >>>> Le 7 mars 2016 08:35, "Martin Kouba" >>> > a ?crit : >>>> > >>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>> > >>>> >> Hi guys, >>>> >> >>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>> >> can we move back to CompletionFuture? >>>> >> >>>> >> It would allow for instance: >>>> >> >>>> >> // doesn't work with CompletionStage >>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>> >> .then(...) >>>> > >>>> > >>>> > Well, this should work if the underlying CompletionStage impl >>>> supports toCompletableFuture(), i.e. in Weld 3: >>>> > >>>> >>>> Yes but it is not natural to convert it IMO = we can do better >>>> >>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>> event2.fireAsync(...).toCompletableFuture()) >>>> > >>>> > AFAIK the default async execution facility of CompletableFuture is >>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>>> CompletionStage interface allows us to wrap the async calls without the >>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>> T, ? extends U>)) and supply a default one provided by the impl. >>>> > >>>> >>>> Should use the pool in which the evznt is fired then "then step" is >>>> synchronous is my sample so all is decided at fire time >>> >>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >> >> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). >> >> That said I agree on the state switching the pool is better but with these 2 notes: >> >> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools >> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >> >>>> >>>> > >>>> >> >>>> >> Romain Manni-Bucau >>>> >> @rmannibucau | Blog >>>> >> | Github >>>> >> | LinkedIn >>>> >> | Tomitriber >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> cdi-dev mailing list >>>> >> cdi-dev at 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 >>> >>> -- >>> Martin Kouba >>> Software Engineer >>> Red Hat, Czech Republic >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/43c07320/attachment.html From rmannibucau at gmail.com Mon Mar 7 14:39:21 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 20:39:21 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> Message-ID: 2016-03-07 20:35 GMT+01:00 Reza Rahman : > Talking with a colleague about this he reminded me of an important fact I > almost forgot. The CompletableFuture API can actually be used with custom > executors. That means users concerned about managed threads in a Java EE > environment can use it with existing EE 7 concurrency executors. > > Basically this means CompletableFutures are already pretty Java EE ready. > > If this is the main cited reason for using CompletionStage, is it really > that valid of an argument to justify yet another custom subclass specific > only to CDI instead of what's likely to be far more familiar and expected? > > Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. > On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: > > I think this is a very bad idea. It's better not to use either API and > wait to sort out how CompletableFuture can be used in EE consistently. > Because of backwards compatibility rules, it is better to have no API than > a bad API. > > On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau > wrote: > > 2016-03-07 9:07 GMT+01:00 Martin Kouba : > >> >> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >> >>> >>> Le 7 mars 2016 08:35, "Martin Kouba" >> > a ?crit : >>> > >>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>> > >>> >> Hi guys, >>> >> >>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>> >> can we move back to CompletionFuture? >>> >> >>> >> It would allow for instance: >>> >> >>> >> // doesn't work with CompletionStage >>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>> >> .then(...) >>> > >>> > >>> > Well, this should work if the underlying CompletionStage impl >>> supports toCompletableFuture(), i.e. in Weld 3: >>> > >>> >>> Yes but it is not natural to convert it IMO = we can do better >>> >>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>> event2.fireAsync(...).toCompletableFuture()) >>> > >>> > AFAIK the default async execution facility of CompletableFuture is >>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>> CompletionStage interface allows us to wrap the async calls without the >>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>> T, ? extends U>)) and supply a default one provided by the impl. >>> > >>> >>> Should use the pool in which the evznt is fired then "then step" is >>> synchronous is my sample so all is decided at fire time >>> >> >> I don't talk about your particular example - I understand that it's not >> using async exec (although the "then()" method does not exist). >> >> > was supposed to represent the different flavours (thenRun, thenCompose, > ...) ;). > > That said I agree on the state switching the pool is better but with these > 2 notes: > > - could be better to hide these poorly designed methods then -> don't use > CompletionXXX but a CDI API with a bridge to CompletionX to let the user go > back on SE tools > - we still don't have a *standard* config for the pool(s) underlying CDI > features so it sounds as poor as SE solution IMO (at least a core/max/ttl > config in beans.xml) > > >> >>> > >>> >> >>> >> Romain Manni-Bucau >>> >> @rmannibucau | Blog >>> >> | Github >>> >> | LinkedIn >>> >> | Tomitriber >>> >> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> cdi-dev mailing list >>> >> cdi-dev at 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 >>> >>> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/e4c16ff6/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 14:53:20 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 14:53:20 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> Message-ID: <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API. > On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau wrote: > > > 2016-03-07 20:35 GMT+01:00 Reza Rahman : >> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. >> >> Basically this means CompletableFutures are already pretty Java EE ready. >> >> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? >> > > Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. > >>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >>> >>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. >>> >>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau wrote: >>>> >>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >>>>> >>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>>> >>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>> > a ?crit : >>>>>> > >>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>> > >>>>>> >> Hi guys, >>>>>> >> >>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>>>> >> can we move back to CompletionFuture? >>>>>> >> >>>>>> >> It would allow for instance: >>>>>> >> >>>>>> >> // doesn't work with CompletionStage >>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>>>> >> .then(...) >>>>>> > >>>>>> > >>>>>> > Well, this should work if the underlying CompletionStage impl >>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>> > >>>>>> >>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>> >>>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>> > >>>>>> > AFAIK the default async execution facility of CompletableFuture is >>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>>>>> CompletionStage interface allows us to wrap the async calls without the >>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>>> > >>>>>> >>>>>> Should use the pool in which the evznt is fired then "then step" is >>>>>> synchronous is my sample so all is decided at fire time >>>>> >>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >>>>> >>>> >>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). >>>> >>>> That said I agree on the state switching the pool is better but with these 2 notes: >>>> >>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools >>>> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >>>> >>>>>> >>>>>> > >>>>>> >> >>>>>> >> Romain Manni-Bucau >>>>>> >> @rmannibucau | Blog >>>>>> >> | Github >>>>>> >> | LinkedIn >>>>>> >> | Tomitriber >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> _______________________________________________ >>>>>> >> cdi-dev mailing list >>>>>> >> cdi-dev at 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 >>>>>> >>>>> >>>>> -- >>>>> Martin Kouba >>>>> Software Engineer >>>>> Red Hat, Czech Republic >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/7192e321/attachment.html From rmannibucau at gmail.com Mon Mar 7 15:35:23 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 21:35:23 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> Message-ID: 2016-03-07 20:53 GMT+01:00 Reza Rahman : > Yes, this can be done with a CompletableFuture that has already been > constructed - just take a look at the API. > > so - just to try to ensure we speak about the same thing: asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ? This works but has the drawback to not reuse the observer thread and keep the original issue: the observer doesn't inherit from the caller context so it would likely be: asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool); which looks weird since you trigger 2 tasks where you actually want just one in another thread originally? asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire async thread This last proposal works not that bad if context propagation would work but since there are cases it would be expected to work and other it shouldn't - from a user point of view auto inheritance can break thread safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed or even just a new scope close to request scoped but inheritable by design. > As far as not adding it to CDI, I can see either way. What was the > original motivation for adding CompletableFutures? > > Also, it's a good idea to run this by the platform expert group. I know at > least JAX-RS is planning to use CompletableFutures for their client API. > > On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau > wrote: > > > 2016-03-07 20:35 GMT+01:00 Reza Rahman : > >> Talking with a colleague about this he reminded me of an important fact I >> almost forgot. The CompletableFuture API can actually be used with custom >> executors. That means users concerned about managed threads in a Java EE >> environment can use it with existing EE 7 concurrency executors. >> >> Basically this means CompletableFutures are already pretty Java EE ready. >> >> If this is the main cited reason for using CompletionStage, is it really >> that valid of an argument to justify yet another custom subclass specific >> only to CDI instead of what's likely to be far more familiar and expected? >> >> > Did he mention it is true for *created* comlpetion future which is not the > case for async events? But this is a good point to not add anything to CDI: > the feature is a one liner *already*. > > >> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >> >> I think this is a very bad idea. It's better not to use either API and >> wait to sort out how CompletableFuture can be used in EE consistently. >> Because of backwards compatibility rules, it is better to have no API than >> a bad API. >> >> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau >> wrote: >> >> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >> >>> >>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>> >>>> >>>> Le 7 mars 2016 08:35, "Martin Kouba" >>> > a ?crit : >>>> > >>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>> > >>>> >> Hi guys, >>>> >> >>>> >> as a user having a ComlpetionStage makes me loose some JDK >>>> utilities, >>>> >> can we move back to CompletionFuture? >>>> >> >>>> >> It would allow for instance: >>>> >> >>>> >> // doesn't work with CompletionStage >>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>> >> .then(...) >>>> > >>>> > >>>> > Well, this should work if the underlying CompletionStage impl >>>> supports toCompletableFuture(), i.e. in Weld 3: >>>> > >>>> >>>> Yes but it is not natural to convert it IMO = we can do better >>>> >>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>> event2.fireAsync(...).toCompletableFuture()) >>>> > >>>> > AFAIK the default async execution facility of CompletableFuture is >>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>>> CompletionStage interface allows us to wrap the async calls without the >>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>> T, ? extends U>)) and supply a default one provided by the impl. >>>> > >>>> >>>> Should use the pool in which the evznt is fired then "then step" is >>>> synchronous is my sample so all is decided at fire time >>>> >>> >>> I don't talk about your particular example - I understand that it's not >>> using async exec (although the "then()" method does not exist). >>> >>> >> was supposed to represent the different flavours (thenRun, thenCompose, >> ...) ;). >> >> That said I agree on the state switching the pool is better but with >> these 2 notes: >> >> - could be better to hide these poorly designed methods then -> don't use >> CompletionXXX but a CDI API with a bridge to CompletionX to let the user go >> back on SE tools >> - we still don't have a *standard* config for the pool(s) underlying CDI >> features so it sounds as poor as SE solution IMO (at least a core/max/ttl >> config in beans.xml) >> >> >>> >>>> > >>>> >> >>>> >> Romain Manni-Bucau >>>> >> @rmannibucau | Blog >>>> >> | Github >>>> >> | LinkedIn >>>> >> | Tomitriber >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> cdi-dev mailing list >>>> >> cdi-dev at 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 >>>> >>>> >>> -- >>> Martin Kouba >>> Software Engineer >>> Red Hat, Czech Republic >>> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/04ade42b/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 16:09:39 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 16:09:39 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> Message-ID: <536990F1-E349-4D85-A110-900B8086BCCA@lycos.com> Responses in-line. > On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau wrote: > > > 2016-03-07 20:53 GMT+01:00 Reza Rahman : >> Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. > > so - just to try to ensure we speak about the same thing: > > asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ? Correct. > > This works but has the drawback to not reuse the observer thread Why would this matter to the average business code developer? All this would run from managed executors of some kind or the other anyway... > and keep the original issue: the observer doesn't inherit from the caller context so it would likely be: > > asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool); Again, why does it matter really? The observer threads themselves should be running from a managed pool that is smart enough to preserve context anyway? If the business developer cares about preserving context in their code, they can use a managed executor themselves on the returned CompletableFuture. > > which looks weird since you trigger 2 tasks where you actually want just one in another thread originally? I don't follow. Whichever executor service you would use, ultimately there are at least three different threads associated here in all cases. > > asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire async thread You mean using the same executor? Why does this matter really? They are all managed executors anyway. At best it's reducing one method parameter. > Are > This last proposal works not that bad if context propagation would work but since there are cases it would be expected to work and other it shouldn't - from a user point of view auto inheritance can break thread safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed or even just a new scope close to request scoped but inheritable by design. > >> As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? >> >> Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API. >> >>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau wrote: >>> >>> >>> 2016-03-07 20:35 GMT+01:00 Reza Rahman : >>>> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. >>>> >>>> Basically this means CompletableFutures are already pretty Java EE ready. >>>> >>>> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? >>> >>> Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. >>> >>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >>>>> >>>>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. >>>>> >>>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau wrote: >>>>>> >>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >>>>>>> >>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>>>>> >>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>>>> > a ?crit : >>>>>>>> > >>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>>>> > >>>>>>>> >> Hi guys, >>>>>>>> >> >>>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>>>>>> >> can we move back to CompletionFuture? >>>>>>>> >> >>>>>>>> >> It would allow for instance: >>>>>>>> >> >>>>>>>> >> // doesn't work with CompletionStage >>>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>>>>>> >> .then(...) >>>>>>>> > >>>>>>>> > >>>>>>>> > Well, this should work if the underlying CompletionStage impl >>>>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>>>> > >>>>>>>> >>>>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>>>> >>>>>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>>>> > >>>>>>>> > AFAIK the default async execution facility of CompletableFuture is >>>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>>>>>>> CompletionStage interface allows us to wrap the async calls without the >>>>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>>>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>>>>> > >>>>>>>> >>>>>>>> Should use the pool in which the evznt is fired then "then step" is >>>>>>>> synchronous is my sample so all is decided at fire time >>>>>>> >>>>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >>>>>> >>>>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). >>>>>> >>>>>> That said I agree on the state switching the pool is better but with these 2 notes: >>>>>> >>>>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools >>>>>> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >>>>>> >>>>>>>> >>>>>>>> > >>>>>>>> >> >>>>>>>> >> Romain Manni-Bucau >>>>>>>> >> @rmannibucau | Blog >>>>>>>> >> | Github >>>>>>>> >> | LinkedIn >>>>>>>> >> | Tomitriber >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> _______________________________________________ >>>>>>>> >> cdi-dev mailing list >>>>>>>> >> cdi-dev at 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 >>>>>>> >>>>>>> -- >>>>>>> Martin Kouba >>>>>>> Software Engineer >>>>>>> Red Hat, Czech Republic >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/2ceef87b/attachment.html From rmannibucau at gmail.com Mon Mar 7 16:24:14 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 22:24:14 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <536990F1-E349-4D85-A110-900B8086BCCA@lycos.com> References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> <536990F1-E349-4D85-A110-900B8086BCCA@lycos.com> Message-ID: 2016-03-07 22:09 GMT+01:00 Reza Rahman : > Responses in-line. > > On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau > wrote: > > > 2016-03-07 20:53 GMT+01:00 Reza Rahman : > >> Yes, this can be done with a CompletableFuture that has already been >> constructed - just take a look at the API. >> >> > so - just to try to ensure we speak about the same thing: > > asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ? > > > Correct. > > > This works but has the drawback to not reuse the observer thread > > > Why would this matter to the average business code developer? All this > would run from managed executors of some kind or the other anyway... > > and keep the original issue: the observer doesn't inherit from the caller > context so it would likely be: > > asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool); > > > Again, why does it matter really? The observer threads themselves should > be running from a managed pool that is smart enough to preserve context > anyway? If the business developer cares about preserving context in their > code, they can use a managed executor themselves on the returned > CompletableFuture. > > Cause it is important to state which thread context is there to keep the integration with other frameworks - think to security ones in particualr - smooth and doable. > > which looks weird since you trigger 2 tasks where you actually want just > one in another thread originally? > > > I don't follow. Whichever executor service you would use, ultimately there > are at least three different threads associated here in all cases. > > > asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire > async thread > > > You mean using the same executor? Why does this matter really? They are > all managed executors anyway. At best it's reducing one method parameter. > > Cause very few apps are 100% EE in practise, probably never will be and even if so JavaEE security is not integrated (yet?) at this level. > Are > This last proposal works not that bad if context propagation would work > but since there are cases it would be expected to work and other it > shouldn't - from a user point of view auto inheritance can break thread > safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed > or even just a new scope close to request scoped but inheritable by design. > > >> As far as not adding it to CDI, I can see either way. What was the >> original motivation for adding CompletableFutures? >> >> Also, it's a good idea to run this by the platform expert group. I know >> at least JAX-RS is planning to use CompletableFutures for their client API. >> >> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau >> wrote: >> >> >> 2016-03-07 20:35 GMT+01:00 Reza Rahman : >> >>> Talking with a colleague about this he reminded me of an important fact >>> I almost forgot. The CompletableFuture API can actually be used with custom >>> executors. That means users concerned about managed threads in a Java EE >>> environment can use it with existing EE 7 concurrency executors. >>> >>> Basically this means CompletableFutures are already pretty Java EE ready. >>> >>> If this is the main cited reason for using CompletionStage, is it really >>> that valid of an argument to justify yet another custom subclass specific >>> only to CDI instead of what's likely to be far more familiar and expected? >>> >>> >> Did he mention it is true for *created* comlpetion future which is not >> the case for async events? But this is a good point to not add anything to >> CDI: the feature is a one liner *already*. >> >> >>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >>> >>> I think this is a very bad idea. It's better not to use either API and >>> wait to sort out how CompletableFuture can be used in EE consistently. >>> Because of backwards compatibility rules, it is better to have no API than >>> a bad API. >>> >>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau >>> wrote: >>> >>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >>> >>>> >>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>> >>>>> >>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>> > a ?crit : >>>>> > >>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>> > >>>>> >> Hi guys, >>>>> >> >>>>> >> as a user having a ComlpetionStage makes me loose some JDK >>>>> utilities, >>>>> >> can we move back to CompletionFuture? >>>>> >> >>>>> >> It would allow for instance: >>>>> >> >>>>> >> // doesn't work with CompletionStage >>>>> >> CompletionFuture.allOf(event1.fireAsync(...), >>>>> event2.fireAsync(...)) >>>>> >> .then(...) >>>>> > >>>>> > >>>>> > Well, this should work if the underlying CompletionStage impl >>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>> > >>>>> >>>>> Yes but it is not natural to convert it IMO = we can do better >>>>> >>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>> event2.fireAsync(...).toCompletableFuture()) >>>>> > >>>>> > AFAIK the default async execution facility of CompletableFuture is >>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using >>>>> the >>>>> CompletionStage interface allows us to wrap the async calls without the >>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>>> super >>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>> > >>>>> >>>>> Should use the pool in which the evznt is fired then "then step" is >>>>> synchronous is my sample so all is decided at fire time >>>>> >>>> >>>> I don't talk about your particular example - I understand that it's not >>>> using async exec (although the "then()" method does not exist). >>>> >>>> >>> was supposed to represent the different flavours (thenRun, thenCompose, >>> ...) ;). >>> >>> That said I agree on the state switching the pool is better but with >>> these 2 notes: >>> >>> - could be better to hide these poorly designed methods then -> don't >>> use CompletionXXX but a CDI API with a bridge to CompletionX to let the >>> user go back on SE tools >>> - we still don't have a *standard* config for the pool(s) underlying CDI >>> features so it sounds as poor as SE solution IMO (at least a core/max/ttl >>> config in beans.xml) >>> >>> >>>> >>>>> > >>>>> >> >>>>> >> Romain Manni-Bucau >>>>> >> @rmannibucau | Blog >>>>> >> | Github >>>>> >> | LinkedIn >>>>> >> | Tomitriber >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> _______________________________________________ >>>>> >> cdi-dev mailing list >>>>> >> cdi-dev at 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 >>>>> >>>>> >>>> -- >>>> Martin Kouba >>>> Software Engineer >>>> Red Hat, Czech Republic >>>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/30de3113/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 16:38:10 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 16:38:10 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> <536990F1-E349-4D85-A110-900B8086BCCA@lycos.com> Message-ID: <4CA96F8A-9D26-466F-8089-1EC38CAB53FF@lycos.com> Responses in-line. Sent from my iPhone > On Mar 7, 2016, at 4:24 PM, Romain Manni-Bucau wrote: > > > 2016-03-07 22:09 GMT+01:00 Reza Rahman : >> Responses in-line. >> >>> On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau wrote: >>> >>> >>> 2016-03-07 20:53 GMT+01:00 Reza Rahman : >>>> Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. >>> >>> so - just to try to ensure we speak about the same thing: >>> >>> asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ? >> >> Correct. >> >>> >>> This works but has the drawback to not reuse the observer thread >> >> Why would this matter to the average business code developer? All this would run from managed executors of some kind or the other anyway... >> >>> and keep the original issue: the observer doesn't inherit from the caller context so it would likely be: >>> >>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool); >> >> Again, why does it matter really? The observer threads themselves should be running from a managed pool that is smart enough to preserve context anyway? If the business developer cares about preserving context in their code, they can use a managed executor themselves on the returned CompletableFuture. > > Cause it is important to state which thread context is there to keep the integration with other frameworks - think to security ones in particualr - smooth and doable. For framework developers usability is hardly a concern. If they need to preserve their own context they can simply pass in their own managed executor to both the observer thread and the CompletableFuture. In the end, the primary focus should be the masses that we hope will adopt CDI into their applications. Making things harder for them to achieve some limited SPI goal is pretty dangerous. >>> >>> which looks weird since you trigger 2 tasks where you actually want just one in another thread originally? >> >> I don't follow. Whichever executor service you would use, ultimately there are at least three different threads associated here in all cases. >> >>> >>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire async thread >> >> You mean using the same executor? Why does this matter really? They are all managed executors anyway. At best it's reducing one method parameter. > > Cause very few apps are 100% EE in practise, probably never will be and even if so JavaEE security is not integrated (yet?) at this level. There is no such thing as context propagation outside of EE managed executors. In SE land, the only thing you have is manually writing your own executor to do the same things. These folks will have to pass around their own executors anyway, even to the observer thread. >>> Are >>> This last proposal works not that bad if context propagation would work but since there are cases it would be expected to work and other it shouldn't - from a user point of view auto inheritance can break thread safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed or even just a new scope close to request scoped but inheritable by design. >>> >>>> As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? >>>> >>>> Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API. >>>> >>>>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau wrote: >>>>> >>>>> >>>>> 2016-03-07 20:35 GMT+01:00 Reza Rahman : >>>>>> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. >>>>>> >>>>>> Basically this means CompletableFutures are already pretty Java EE ready. >>>>>> >>>>>> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? >>>>> >>>>> Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. >>>>> >>>>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >>>>>>> >>>>>>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. >>>>>>> >>>>>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >>>>>>>>> >>>>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>>>>>>> >>>>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>>>>>> > a ?crit : >>>>>>>>>> > >>>>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>>>>>> > >>>>>>>>>> >> Hi guys, >>>>>>>>>> >> >>>>>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>>>>>>>> >> can we move back to CompletionFuture? >>>>>>>>>> >> >>>>>>>>>> >> It would allow for instance: >>>>>>>>>> >> >>>>>>>>>> >> // doesn't work with CompletionStage >>>>>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>>>>>>>> >> .then(...) >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > Well, this should work if the underlying CompletionStage impl >>>>>>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>>>>>> >>>>>>>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>>>>>> > >>>>>>>>>> > AFAIK the default async execution facility of CompletableFuture is >>>>>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>>>>>>>>> CompletionStage interface allows us to wrap the async calls without the >>>>>>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>>>>>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> Should use the pool in which the evznt is fired then "then step" is >>>>>>>>>> synchronous is my sample so all is decided at fire time >>>>>>>>> >>>>>>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >>>>>>>> >>>>>>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). >>>>>>>> >>>>>>>> That said I agree on the state switching the pool is better but with these 2 notes: >>>>>>>> >>>>>>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools >>>>>>>> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >>>>>>>> >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> >> >>>>>>>>>> >> Romain Manni-Bucau >>>>>>>>>> >> @rmannibucau | Blog >>>>>>>>>> >> | Github >>>>>>>>>> >> | LinkedIn >>>>>>>>>> >> | Tomitriber >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> _______________________________________________ >>>>>>>>>> >> cdi-dev mailing list >>>>>>>>>> >> cdi-dev at 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 >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Martin Kouba >>>>>>>>> Software Engineer >>>>>>>>> Red Hat, Czech Republic >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/2295d01f/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 16:48:06 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 16:48:06 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <4CA96F8A-9D26-466F-8089-1EC38CAB53FF@lycos.com> References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> <536990F1-E349-4D85-A110-900B8086BCCA@lycos.com> <4CA96F8A-9D26-466F-8089-1EC38CAB53FF@lycos.com> Message-ID: Not sure how alias works, so resending directly. Responses inline. The bottom line is that we should think about the usability of the most common end user. If anyone needs custom executor service control in the worst case it's still just a matter of one extra parameter as opposed to introducing an obscure alternative to CompletableFuture. > On Mar 7, 2016, at 4:38 PM, Reza Rahman wrote: > > Responses in-line. > > Sent from my iPhone > >> On Mar 7, 2016, at 4:24 PM, Romain Manni-Bucau wrote: >> >> >> 2016-03-07 22:09 GMT+01:00 Reza Rahman : >>> Responses in-line. >>> >>>> On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau wrote: >>>> >>>> >>>> 2016-03-07 20:53 GMT+01:00 Reza Rahman : >>>>> Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. >>>> >>>> so - just to try to ensure we speak about the same thing: >>>> >>>> asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ? >>> >>> Correct. >>> >>>> >>>> This works but has the drawback to not reuse the observer thread >>> >>> Why would this matter to the average business code developer? All this would run from managed executors of some kind or the other anyway... >>> >>>> and keep the original issue: the observer doesn't inherit from the caller context so it would likely be: >>>> >>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool); >>> >>> Again, why does it matter really? The observer threads themselves should be running from a managed pool that is smart enough to preserve context anyway? If the business developer cares about preserving context in their code, they can use a managed executor themselves on the returned CompletableFuture. >> >> Cause it is important to state which thread context is there to keep the integration with other frameworks - think to security ones in particualr - smooth and doable. > > For framework developers usability is hardly a concern. If they need to preserve their own context they can simply pass in their own managed executor to both the observer thread and the CompletableFuture. > > In the end, the primary focus should be the masses that we hope will adopt CDI into their applications. Making things harder for them to achieve some limited SPI goal is pretty dangerous. > >>>> >>>> which looks weird since you trigger 2 tasks where you actually want just one in another thread originally? >>> >>> I don't follow. Whichever executor service you would use, ultimately there are at least three different threads associated here in all cases. >>> >>>> >>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire async thread >>> >>> You mean using the same executor? Why does this matter really? They are all managed executors anyway. At best it's reducing one method parameter. >> >> Cause very few apps are 100% EE in practise, probably never will be and even if so JavaEE security is not integrated (yet?) at this level. > > There is no such thing as context propagation outside of EE managed executors. In SE land, the only thing you have is manually writing your own executor to do the same things. These folks will have to pass around their own executors anyway, even to the observer thread. > >>>> Are >>>> This last proposal works not that bad if context propagation would work but since there are cases it would be expected to work and other it shouldn't - from a user point of view auto inheritance can break thread safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed or even just a new scope close to request scoped but inheritable by design. >>>> >>>>> As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? >>>>> >>>>> Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API. >>>>> >>>>>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>> >>>>>> 2016-03-07 20:35 GMT+01:00 Reza Rahman : >>>>>>> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. >>>>>>> >>>>>>> Basically this means CompletableFutures are already pretty Java EE ready. >>>>>>> >>>>>>> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? >>>>>> >>>>>> Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. >>>>>> >>>>>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >>>>>>>> >>>>>>>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. >>>>>>>> >>>>>>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau wrote: >>>>>>>>> >>>>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >>>>>>>>>> >>>>>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>>>>>>>> >>>>>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>>>>>>> > a ?crit : >>>>>>>>>>> > >>>>>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>>>>>>> > >>>>>>>>>>> >> Hi guys, >>>>>>>>>>> >> >>>>>>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>>>>>>>>> >> can we move back to CompletionFuture? >>>>>>>>>>> >> >>>>>>>>>>> >> It would allow for instance: >>>>>>>>>>> >> >>>>>>>>>>> >> // doesn't work with CompletionStage >>>>>>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>>>>>>>>> >> .then(...) >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > Well, this should work if the underlying CompletionStage impl >>>>>>>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>>>>>>> >>>>>>>>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>>>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>>>>>>> > >>>>>>>>>>> > AFAIK the default async execution facility of CompletableFuture is >>>>>>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>>>>>>>>>> CompletionStage interface allows us to wrap the async calls without the >>>>>>>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>>>>>>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> Should use the pool in which the evznt is fired then "then step" is >>>>>>>>>>> synchronous is my sample so all is decided at fire time >>>>>>>>>> >>>>>>>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >>>>>>>>> >>>>>>>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). >>>>>>>>> >>>>>>>>> That said I agree on the state switching the pool is better but with these 2 notes: >>>>>>>>> >>>>>>>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools >>>>>>>>> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> >> >>>>>>>>>>> >> Romain Manni-Bucau >>>>>>>>>>> >> @rmannibucau | Blog >>>>>>>>>>> >> | Github >>>>>>>>>>> >> | LinkedIn >>>>>>>>>>> >> | Tomitriber >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>> >> cdi-dev mailing list >>>>>>>>>>> >> cdi-dev at 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 >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Martin Kouba >>>>>>>>>> Software Engineer >>>>>>>>>> Red Hat, Czech Republic >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> cdi-dev mailing list >>>>>>>>> cdi-dev at 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 at 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 at 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 at 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. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/8facbfd0/attachment-0001.html From rmannibucau at gmail.com Mon Mar 7 17:07:20 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 23:07:20 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> <536990F1-E349-4D85-A110-900B8086BCCA@lycos.com> <4CA96F8A-9D26-466F-8089-1EC38CAB53FF@lycos.com> Message-ID: Side note: this is still true for CompletionStage. Le 7 mars 2016 22:48, "Reza Rahman" a ?crit : > Not sure how alias works, so resending directly. Responses inline. > > The bottom line is that we should think about the usability of the most > common end user. If anyone needs custom executor service control in the > worst case it's still just a matter of one extra parameter as opposed to > introducing an obscure alternative to CompletableFuture. > > On Mar 7, 2016, at 4:38 PM, Reza Rahman wrote: > > Responses in-line. > > Sent from my iPhone > > On Mar 7, 2016, at 4:24 PM, Romain Manni-Bucau > wrote: > > > 2016-03-07 22:09 GMT+01:00 Reza Rahman : > >> Responses in-line. >> >> On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau >> wrote: >> >> >> 2016-03-07 20:53 GMT+01:00 Reza Rahman : >> >>> Yes, this can be done with a CompletableFuture that has already been >>> constructed - just take a look at the API. >>> >>> >> so - just to try to ensure we speak about the same thing: >> >> asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ? >> >> >> Correct. >> >> >> This works but has the drawback to not reuse the observer thread >> >> >> Why would this matter to the average business code developer? All this >> would run from managed executors of some kind or the other anyway... >> >> and keep the original issue: the observer doesn't inherit from the caller >> context so it would likely be: >> >> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool); >> >> >> Again, why does it matter really? The observer threads themselves should >> be running from a managed pool that is smart enough to preserve context >> anyway? If the business developer cares about preserving context in their >> code, they can use a managed executor themselves on the returned >> CompletableFuture. >> >> > Cause it is important to state which thread context is there to keep the > integration with other frameworks - think to security ones in particualr - > smooth and doable. > > > For framework developers usability is hardly a concern. If they need to > preserve their own context they can simply pass in their own managed > executor to both the observer thread and the CompletableFuture. > > In the end, the primary focus should be the masses that we hope will adopt > CDI into their applications. Making things harder for them to achieve some > limited SPI goal is pretty dangerous. > > >> which looks weird since you trigger 2 tasks where you actually want just >> one in another thread originally? >> >> >> I don't follow. Whichever executor service you would use, ultimately >> there are at least three different threads associated here in all cases. >> >> >> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire >> async thread >> >> >> You mean using the same executor? Why does this matter really? They are >> all managed executors anyway. At best it's reducing one method parameter. >> >> > Cause very few apps are 100% EE in practise, probably never will be and > even if so JavaEE security is not integrated (yet?) at this level. > > > There is no such thing as context propagation outside of EE managed > executors. In SE land, the only thing you have is manually writing your own > executor to do the same things. These folks will have to pass around their > own executors anyway, even to the observer thread. > > Are >> This last proposal works not that bad if context propagation would work >> but since there are cases it would be expected to work and other it >> shouldn't - from a user point of view auto inheritance can break thread >> safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed >> or even just a new scope close to request scoped but inheritable by design. >> >> >>> As far as not adding it to CDI, I can see either way. What was the >>> original motivation for adding CompletableFutures? >>> >>> Also, it's a good idea to run this by the platform expert group. I know >>> at least JAX-RS is planning to use CompletableFutures for their client API. >>> >>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau >>> wrote: >>> >>> >>> 2016-03-07 20:35 GMT+01:00 Reza Rahman : >>> >>>> Talking with a colleague about this he reminded me of an important fact >>>> I almost forgot. The CompletableFuture API can actually be used with custom >>>> executors. That means users concerned about managed threads in a Java EE >>>> environment can use it with existing EE 7 concurrency executors. >>>> >>>> Basically this means CompletableFutures are already pretty Java EE >>>> ready. >>>> >>>> If this is the main cited reason for using CompletionStage, is it >>>> really that valid of an argument to justify yet another custom subclass >>>> specific only to CDI instead of what's likely to be far more familiar and >>>> expected? >>>> >>>> >>> Did he mention it is true for *created* comlpetion future which is not >>> the case for async events? But this is a good point to not add anything to >>> CDI: the feature is a one liner *already*. >>> >>> >>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >>>> >>>> I think this is a very bad idea. It's better not to use either API and >>>> wait to sort out how CompletableFuture can be used in EE consistently. >>>> Because of backwards compatibility rules, it is better to have no API than >>>> a bad API. >>>> >>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau >>>> wrote: >>>> >>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >>>> >>>>> >>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>> >>>>>> >>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>> > a ?crit : >>>>>> > >>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>> > >>>>>> >> Hi guys, >>>>>> >> >>>>>> >> as a user having a ComlpetionStage makes me loose some JDK >>>>>> utilities, >>>>>> >> can we move back to CompletionFuture? >>>>>> >> >>>>>> >> It would allow for instance: >>>>>> >> >>>>>> >> // doesn't work with CompletionStage >>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), >>>>>> event2.fireAsync(...)) >>>>>> >> .then(...) >>>>>> > >>>>>> > >>>>>> > Well, this should work if the underlying CompletionStage impl >>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>> > >>>>>> >>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>> >>>>>> > >>>>>> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>> > >>>>>> > AFAIK the default async execution facility of CompletableFuture is >>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using >>>>>> the >>>>>> CompletionStage interface allows us to wrap the async calls without >>>>>> the >>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>>>> super >>>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>>> > >>>>>> >>>>>> Should use the pool in which the evznt is fired then "then step" is >>>>>> synchronous is my sample so all is decided at fire time >>>>>> >>>>> >>>>> I don't talk about your particular example - I understand that it's >>>>> not using async exec (although the "then()" method does not exist). >>>>> >>>>> >>>> was supposed to represent the different flavours (thenRun, thenCompose, >>>> ...) ;). >>>> >>>> That said I agree on the state switching the pool is better but with >>>> these 2 notes: >>>> >>>> - could be better to hide these poorly designed methods then -> don't >>>> use CompletionXXX but a CDI API with a bridge to CompletionX to let the >>>> user go back on SE tools >>>> - we still don't have a *standard* config for the pool(s) underlying >>>> CDI features so it sounds as poor as SE solution IMO (at least a >>>> core/max/ttl config in beans.xml) >>>> >>>> >>>>> >>>>>> > >>>>>> >> >>>>>> >> Romain Manni-Bucau >>>>>> >> @rmannibucau | Blog >>>>>> >> | Github >>>>>> >> | LinkedIn >>>>>> >> | Tomitriber >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> _______________________________________________ >>>>>> >> cdi-dev mailing list >>>>>> >> cdi-dev at 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 >>>>>> >>>>>> >>>>> -- >>>>> Martin Kouba >>>>> Software Engineer >>>>> Red Hat, Czech Republic >>>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/c0c4e33f/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 17:19:25 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 17:19:25 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> <536990F1-E349-4D85-A110-900B8086BCCA@lycos.com> <4CA96F8A-9D26-466F-8089-1EC38CAB53FF@lycos.com> Message-ID: What is still true for CompletionStage? As I've indicated, it's largely an SPI rather than an end user API like CompletableFuture. For that reason it will never have the level of familiarity that CompletableFuture already does. Let's kindly not argue in circles or repeat ourselves needlessly. It accomplishes nothing productive. > On Mar 7, 2016, at 5:07 PM, Romain Manni-Bucau wrote: > > Side note: this is still true for CompletionStage. > > Le 7 mars 2016 22:48, "Reza Rahman" a ?crit : >> Not sure how alias works, so resending directly. Responses inline. >> >> The bottom line is that we should think about the usability of the most common end user. If anyone needs custom executor service control in the worst case it's still just a matter of one extra parameter as opposed to introducing an obscure alternative to CompletableFuture. >> >>> On Mar 7, 2016, at 4:38 PM, Reza Rahman wrote: >>> >>> Responses in-line. >>> >>> Sent from my iPhone >>> >>>> On Mar 7, 2016, at 4:24 PM, Romain Manni-Bucau wrote: >>>> >>>> >>>> 2016-03-07 22:09 GMT+01:00 Reza Rahman : >>>>> Responses in-line. >>>>> >>>>>> On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>> >>>>>> 2016-03-07 20:53 GMT+01:00 Reza Rahman : >>>>>>> Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. >>>>>> >>>>>> so - just to try to ensure we speak about the same thing: >>>>>> >>>>>> asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ? >>>>> >>>>> Correct. >>>>> >>>>>> >>>>>> This works but has the drawback to not reuse the observer thread >>>>> >>>>> Why would this matter to the average business code developer? All this would run from managed executors of some kind or the other anyway... >>>>> >>>>>> and keep the original issue: the observer doesn't inherit from the caller context so it would likely be: >>>>>> >>>>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool); >>>>> >>>>> Again, why does it matter really? The observer threads themselves should be running from a managed pool that is smart enough to preserve context anyway? If the business developer cares about preserving context in their code, they can use a managed executor themselves on the returned CompletableFuture. >>>> >>>> Cause it is important to state which thread context is there to keep the integration with other frameworks - think to security ones in particualr - smooth and doable. >>> >>> For framework developers usability is hardly a concern. If they need to preserve their own context they can simply pass in their own managed executor to both the observer thread and the CompletableFuture. >>> >>> In the end, the primary focus should be the masses that we hope will adopt CDI into their applications. Making things harder for them to achieve some limited SPI goal is pretty dangerous. >>> >>>>>> >>>>>> which looks weird since you trigger 2 tasks where you actually want just one in another thread originally? >>>>> >>>>> I don't follow. Whichever executor service you would use, ultimately there are at least three different threads associated here in all cases. >>>>> >>>>>> >>>>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire async thread >>>>> >>>>> You mean using the same executor? Why does this matter really? They are all managed executors anyway. At best it's reducing one method parameter. >>>> >>>> Cause very few apps are 100% EE in practise, probably never will be and even if so JavaEE security is not integrated (yet?) at this level. >>> >>> There is no such thing as context propagation outside of EE managed executors. In SE land, the only thing you have is manually writing your own executor to do the same things. These folks will have to pass around their own executors anyway, even to the observer thread. >>> >>>>>> Are >>>>>> This last proposal works not that bad if context propagation would work but since there are cases it would be expected to work and other it shouldn't - from a user point of view auto inheritance can break thread safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed or even just a new scope close to request scoped but inheritable by design. >>>>>> >>>>>>> As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? >>>>>>> >>>>>>> Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API. >>>>>>> >>>>>>>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2016-03-07 20:35 GMT+01:00 Reza Rahman : >>>>>>>>> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. >>>>>>>>> >>>>>>>>> Basically this means CompletableFutures are already pretty Java EE ready. >>>>>>>>> >>>>>>>>> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? >>>>>>>> >>>>>>>> Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. >>>>>>>> >>>>>>>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >>>>>>>>>> >>>>>>>>>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. >>>>>>>>>> >>>>>>>>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau wrote: >>>>>>>>>>> >>>>>>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >>>>>>>>>>>> >>>>>>>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>>>>>>>>>> >>>>>>>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>>>>>>>>> > a ?crit : >>>>>>>>>>>>> > >>>>>>>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>>>>>>>>> > >>>>>>>>>>>>> >> Hi guys, >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>>>>>>>>>>> >> can we move back to CompletionFuture? >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> It would allow for instance: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> // doesn't work with CompletionStage >>>>>>>>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>>>>>>>>>>> >> .then(...) >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > Well, this should work if the underlying CompletionStage impl >>>>>>>>>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>>>>>>>>> >>>>>>>>>>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>>>>>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>>>>>>>>> > >>>>>>>>>>>>> > AFAIK the default async execution facility of CompletableFuture is >>>>>>>>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>>>>>>>>>>>> CompletionStage interface allows us to wrap the async calls without the >>>>>>>>>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>>>>>>>>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> Should use the pool in which the evznt is fired then "then step" is >>>>>>>>>>>>> synchronous is my sample so all is decided at fire time >>>>>>>>>>>> >>>>>>>>>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >>>>>>>>>>> >>>>>>>>>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). >>>>>>>>>>> >>>>>>>>>>> That said I agree on the state switching the pool is better but with these 2 notes: >>>>>>>>>>> >>>>>>>>>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools >>>>>>>>>>> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Romain Manni-Bucau >>>>>>>>>>>>> >> @rmannibucau | Blog >>>>>>>>>>>>> >> | Github >>>>>>>>>>>>> >> | LinkedIn >>>>>>>>>>>>> >> | Tomitriber >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>>>> >> cdi-dev mailing list >>>>>>>>>>>>> >> cdi-dev at 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 >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Martin Kouba >>>>>>>>>>>> Software Engineer >>>>>>>>>>>> Red Hat, Czech Republic >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/074d9ba9/attachment-0001.html From rmannibucau at gmail.com Mon Mar 7 17:26:06 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 23:26:06 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> <536990F1-E349-4D85-A110-900B8086BCCA@lycos.com> <4CA96F8A-9D26-466F-8089-1EC38CAB53FF@lycos.com> Message-ID: You can give CompletionStage a pool too. So it helps the other thread bit not this one if we dont make any hazardeous hypothesis. Le 7 mars 2016 23:19, "Reza Rahman" a ?crit : > > What is still true for CompletionStage? As I've indicated, it's largely an SPI rather than an end user API like CompletableFuture. For that reason it will never have the level of familiarity that CompletableFuture already does. > > Let's kindly not argue in circles or repeat ourselves needlessly. It accomplishes nothing productive. > > On Mar 7, 2016, at 5:07 PM, Romain Manni-Bucau wrote: > >> Side note: this is still true for CompletionStage. >> >> Le 7 mars 2016 22:48, "Reza Rahman" a ?crit : >>> >>> Not sure how alias works, so resending directly. Responses inline. >>> >>> The bottom line is that we should think about the usability of the most common end user. If anyone needs custom executor service control in the worst case it's still just a matter of one extra parameter as opposed to introducing an obscure alternative to CompletableFuture. >>> >>> On Mar 7, 2016, at 4:38 PM, Reza Rahman wrote: >>> >>>> Responses in-line. >>>> >>>> Sent from my iPhone >>>> >>>> On Mar 7, 2016, at 4:24 PM, Romain Manni-Bucau wrote: >>>> >>>>> >>>>> 2016-03-07 22:09 GMT+01:00 Reza Rahman : >>>>>> >>>>>> Responses in-line. >>>>>> >>>>>> On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>>> >>>>>>> 2016-03-07 20:53 GMT+01:00 Reza Rahman : >>>>>>>> >>>>>>>> Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. >>>>>>>> >>>>>>> >>>>>>> so - just to try to ensure we speak about the same thing: >>>>>>> >>>>>>> asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ? >>>>>> >>>>>> >>>>>> Correct. >>>>>> >>>>>>> >>>>>>> This works but has the drawback to not reuse the observer thread >>>>>> >>>>>> >>>>>> Why would this matter to the average business code developer? All this would run from managed executors of some kind or the other anyway... >>>>>> >>>>>>> and keep the original issue: the observer doesn't inherit from the caller context so it would likely be: >>>>>>> >>>>>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool); >>>>>> >>>>>> >>>>>> Again, why does it matter really? The observer threads themselves should be running from a managed pool that is smart enough to preserve context anyway? If the business developer cares about preserving context in their code, they can use a managed executor themselves on the returned CompletableFuture. >>>>>> >>>>> >>>>> Cause it is important to state which thread context is there to keep the integration with other frameworks - think to security ones in particualr - smooth and doable. >>>> >>>> >>>> For framework developers usability is hardly a concern. If they need to preserve their own context they can simply pass in their own managed executor to both the observer thread and the CompletableFuture. >>>> >>>> In the end, the primary focus should be the masses that we hope will adopt CDI into their applications. Making things harder for them to achieve some limited SPI goal is pretty dangerous. >>>> >>>>>>> >>>>>>> which looks weird since you trigger 2 tasks where you actually want just one in another thread originally? >>>>>> >>>>>> >>>>>> I don't follow. Whichever executor service you would use, ultimately there are at least three different threads associated here in all cases. >>>>>> >>>>>>> >>>>>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire async thread >>>>>> >>>>>> >>>>>> You mean using the same executor? Why does this matter really? They are all managed executors anyway. At best it's reducing one method parameter. >>>>>> >>>>> >>>>> Cause very few apps are 100% EE in practise, probably never will be and even if so JavaEE security is not integrated (yet?) at this level. >>>> >>>> >>>> There is no such thing as context propagation outside of EE managed executors. In SE land, the only thing you have is manually writing your own executor to do the same things. These folks will have to pass around their own executors anyway, even to the observer thread. >>>> >>>>>>> Are >>>>>>> This last proposal works not that bad if context propagation would work but since there are cases it would be expected to work and other it shouldn't - from a user point of view auto inheritance can break thread safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed or even just a new scope close to request scoped but inheritable by design. >>>>>>> >>>>>>>> >>>>>>>> As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? >>>>>>>> >>>>>>>> Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API. >>>>>>>> >>>>>>>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau < rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> 2016-03-07 20:35 GMT+01:00 Reza Rahman : >>>>>>>>>> >>>>>>>>>> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. >>>>>>>>>> >>>>>>>>>> Basically this means CompletableFutures are already pretty Java EE ready. >>>>>>>>>> >>>>>>>>>> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >>>>>>>>>> >>>>>>>>>>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. >>>>>>>>>>> >>>>>>>>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau < rmannibucau at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>>>>>>>>>> > a ?crit : >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >> Hi guys, >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>>>>>>>>>>>> >> can we move back to CompletionFuture? >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> It would allow for instance: >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> // doesn't work with CompletionStage >>>>>>>>>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>>>>>>>>>>>> >> .then(...) >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Well, this should work if the underlying CompletionStage impl >>>>>>>>>>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>>>>>>>>>> >>>>>>>>>>>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>>>>>>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > AFAIK the default async execution facility of CompletableFuture is >>>>>>>>>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>>>>>>>>>>>>> CompletionStage interface allows us to wrap the async calls without the >>>>>>>>>>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>>>>>>>>>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> Should use the pool in which the evznt is fired then "then step" is >>>>>>>>>>>>>> synchronous is my sample so all is decided at fire time >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). >>>>>>>>>>>> >>>>>>>>>>>> That said I agree on the state switching the pool is better but with these 2 notes: >>>>>>>>>>>> >>>>>>>>>>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools >>>>>>>>>>>> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Romain Manni-Bucau >>>>>>>>>>>>>> >> @rmannibucau | Blog >>>>>>>>>>>>>> >> | Github >>>>>>>>>>>>>> >> | LinkedIn >>>>>>>>>>>>>> >> | Tomitriber >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>>>>> >> cdi-dev mailing list >>>>>>>>>>>>>> >> cdi-dev at 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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Martin Kouba >>>>>>>>>>>>> Software Engineer >>>>>>>>>>>>> Red Hat, Czech Republic >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/93fe9100/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 17:40:26 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 17:40:26 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> <536990F1-E349-4D85-A110-900B8086BCCA@lycos.com> <4CA96F8A-9D26-466F-8089-1EC38CAB53FF@lycos.com> Message-ID: <8186D956-CFCC-4739-8D93-8BF033FE6134@lycos.com> What hazardous hypothesis? Someone that needs a custom executor will need to deal with one anyway - whether by needing to pass it to the observer dispatcher or the CompletableFuture. CompletionStage is the obscure parent superinterface for the CompletableFuture gateway API. Hence it is mostly functionally equivalent. What's so surprising about that? What I find strangest about this, is that you started with CompletableFuture yourself: https://rmannibucau.wordpress.com/2016/02/25/the-promise-of-completablefuture-jax-rs2-example/. You should already understand the issue of familiarity for that reason alone. If CompletionStage is so great why didn't you write about it? You are hardly alone. Look at pretty much everyone that speaks or write on the topic. They all start with CompletebleFuture unsurprisingly. Let's stop the polemic and be reasonable. Otherwise we risk having another bad API in Java EE for no good reason. Sent from my iPhone > On Mar 7, 2016, at 5:26 PM, Romain Manni-Bucau wrote: > > You can give CompletionStage a pool too. So it helps the other thread bit not this one if we dont make any hazardeous hypothesis. > > Le 7 mars 2016 23:19, "Reza Rahman" a ?crit : > > > > What is still true for CompletionStage? As I've indicated, it's largely an SPI rather than an end user API like CompletableFuture. For that reason it will never have the level of familiarity that CompletableFuture already does. > > > > Let's kindly not argue in circles or repeat ourselves needlessly. It accomplishes nothing productive. > > > > On Mar 7, 2016, at 5:07 PM, Romain Manni-Bucau wrote: > > > >> Side note: this is still true for CompletionStage. > >> > >> Le 7 mars 2016 22:48, "Reza Rahman" a ?crit : > >>> > >>> Not sure how alias works, so resending directly. Responses inline. > >>> > >>> The bottom line is that we should think about the usability of the most common end user. If anyone needs custom executor service control in the worst case it's still just a matter of one extra parameter as opposed to introducing an obscure alternative to CompletableFuture. > >>> > >>> On Mar 7, 2016, at 4:38 PM, Reza Rahman wrote: > >>> > >>>> Responses in-line. > >>>> > >>>> Sent from my iPhone > >>>> > >>>> On Mar 7, 2016, at 4:24 PM, Romain Manni-Bucau wrote: > >>>> > >>>>> > >>>>> 2016-03-07 22:09 GMT+01:00 Reza Rahman : > >>>>>> > >>>>>> Responses in-line. > >>>>>> > >>>>>> On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau wrote: > >>>>>> > >>>>>>> > >>>>>>> 2016-03-07 20:53 GMT+01:00 Reza Rahman : > >>>>>>>> > >>>>>>>> Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. > >>>>>>>> > >>>>>>> > >>>>>>> so - just to try to ensure we speak about the same thing: > >>>>>>> > >>>>>>> asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ? > >>>>>> > >>>>>> > >>>>>> Correct. > >>>>>> > >>>>>>> > >>>>>>> This works but has the drawback to not reuse the observer thread > >>>>>> > >>>>>> > >>>>>> Why would this matter to the average business code developer? All this would run from managed executors of some kind or the other anyway... > >>>>>> > >>>>>>> and keep the original issue: the observer doesn't inherit from the caller context so it would likely be: > >>>>>>> > >>>>>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool); > >>>>>> > >>>>>> > >>>>>> Again, why does it matter really? The observer threads themselves should be running from a managed pool that is smart enough to preserve context anyway? If the business developer cares about preserving context in their code, they can use a managed executor themselves on the returned CompletableFuture. > >>>>>> > >>>>> > >>>>> Cause it is important to state which thread context is there to keep the integration with other frameworks - think to security ones in particualr - smooth and doable. > >>>> > >>>> > >>>> For framework developers usability is hardly a concern. If they need to preserve their own context they can simply pass in their own managed executor to both the observer thread and the CompletableFuture. > >>>> > >>>> In the end, the primary focus should be the masses that we hope will adopt CDI into their applications. Making things harder for them to achieve some limited SPI goal is pretty dangerous. > >>>> > >>>>>>> > >>>>>>> which looks weird since you trigger 2 tasks where you actually want just one in another thread originally? > >>>>>> > >>>>>> > >>>>>> I don't follow. Whichever executor service you would use, ultimately there are at least three different threads associated here in all cases. > >>>>>> > >>>>>>> > >>>>>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire async thread > >>>>>> > >>>>>> > >>>>>> You mean using the same executor? Why does this matter really? They are all managed executors anyway. At best it's reducing one method parameter. > >>>>>> > >>>>> > >>>>> Cause very few apps are 100% EE in practise, probably never will be and even if so JavaEE security is not integrated (yet?) at this level. > >>>> > >>>> > >>>> There is no such thing as context propagation outside of EE managed executors. In SE land, the only thing you have is manually writing your own executor to do the same things. These folks will have to pass around their own executors anyway, even to the observer thread. > >>>> > >>>>>>> Are > >>>>>>> This last proposal works not that bad if context propagation would work but since there are cases it would be expected to work and other it shouldn't - from a user point of view auto inheritance can break thread safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed or even just a new scope close to request scoped but inheritable by design. > >>>>>>> > >>>>>>>> > >>>>>>>> As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? > >>>>>>>> > >>>>>>>> Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API. > >>>>>>>> > >>>>>>>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> 2016-03-07 20:35 GMT+01:00 Reza Rahman : > >>>>>>>>>> > >>>>>>>>>> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. > >>>>>>>>>> > >>>>>>>>>> Basically this means CompletableFutures are already pretty Java EE ready. > >>>>>>>>>> > >>>>>>>>>> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: > >>>>>>>>>> > >>>>>>>>>>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. > >>>>>>>>>>> > >>>>>>>>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau wrote: > >>>>>>>>>>> > >>>>>>>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>>>>>>>>>>> > a ?crit : > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> >> Hi guys, > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, > >>>>>>>>>>>>>> >> can we move back to CompletionFuture? > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> It would allow for instance: > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> // doesn't work with CompletionStage > >>>>>>>>>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) > >>>>>>>>>>>>>> >> .then(...) > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > Well, this should work if the underlying CompletionStage impl > >>>>>>>>>>>>>> supports toCompletableFuture(), i.e. in Weld 3: > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Yes but it is not natural to convert it IMO = we can do better > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), > >>>>>>>>>>>>>> event2.fireAsync(...).toCompletableFuture()) > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > AFAIK the default async execution facility of CompletableFuture is > >>>>>>>>>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the > >>>>>>>>>>>>>> CompletionStage interface allows us to wrap the async calls without the > >>>>>>>>>>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function >>>>>>>>>>>>>> T, ? extends U>)) and supply a default one provided by the impl. > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Should use the pool in which the evznt is fired then "then step" is > >>>>>>>>>>>>>> synchronous is my sample so all is decided at fire time > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). > >>>>>>>>>>>> > >>>>>>>>>>>> That said I agree on the state switching the pool is better but with these 2 notes: > >>>>>>>>>>>> > >>>>>>>>>>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools > >>>>>>>>>>>> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) > >>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> Romain Manni-Bucau > >>>>>>>>>>>>>> >> @rmannibucau | Blog > >>>>>>>>>>>>>> >> | Github > >>>>>>>>>>>>>> >> | LinkedIn > >>>>>>>>>>>>>> >> | Tomitriber > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> _______________________________________________ > >>>>>>>>>>>>>> >> cdi-dev mailing list > >>>>>>>>>>>>>> >> cdi-dev at 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 > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> -- > >>>>>>>>>>>>> Martin Kouba > >>>>>>>>>>>>> Software Engineer > >>>>>>>>>>>>> Red Hat, Czech Republic > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> cdi-dev mailing list > >>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/7456d0ce/attachment-0001.html From rmannibucau at gmail.com Mon Mar 7 17:51:02 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 7 Mar 2016 23:51:02 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: <8186D956-CFCC-4739-8D93-8BF033FE6134@lycos.com> References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> <536990F1-E349-4D85-A110-900B8086BCCA@lycos.com> <4CA96F8A-9D26-466F-8089-1EC38CAB53FF@lycos.com> <8186D956-CFCC-4739-8D93-8BF033FE6134@lycos.com> Message-ID: Le 7 mars 2016 23:40, "Reza Rahman" a ?crit : > > What hazardous hypothesis? Someone that needs a custom executor will need to deal with one anyway - whether by needing to pass it to the observer dispatcher or the CompletableFuture. > > CompletionStage is the obscure parent superinterface for the CompletableFuture gateway API. Hence it is mostly functionally equivalent. What's so surprising about that? > > What I find strangest about this, is that you started with CompletableFuture yourself: https://rmannibucau.wordpress.com/2016/02/25/the-promise-of-completablefuture-jax-rs2-example/. You should already understand the issue of familiarity for that reason alone. If CompletionStage is so great why didn't you write about it? You are hardly alone. Look at pretty much everyone that speaks or write on the topic. They all start with CompletebleFuture unsurprisingly. > Cause it is used as a promise which is irrelevant for cdi topic. > Let's stop the polemic and be reasonable. Otherwise we risk having another bad API in Java EE for no good reason. > > Sent from my iPhone > > On Mar 7, 2016, at 5:26 PM, Romain Manni-Bucau wrote: > >> You can give CompletionStage a pool too. So it helps the other thread bit not this one if we dont make any hazardeous hypothesis. >> >> Le 7 mars 2016 23:19, "Reza Rahman" a ?crit : >> > >> > What is still true for CompletionStage? As I've indicated, it's largely an SPI rather than an end user API like CompletableFuture. For that reason it will never have the level of familiarity that CompletableFuture already does. >> > >> > Let's kindly not argue in circles or repeat ourselves needlessly. It accomplishes nothing productive. >> > >> > On Mar 7, 2016, at 5:07 PM, Romain Manni-Bucau wrote: >> > >> >> Side note: this is still true for CompletionStage. >> >> >> >> Le 7 mars 2016 22:48, "Reza Rahman" a ?crit : >> >>> >> >>> Not sure how alias works, so resending directly. Responses inline. >> >>> >> >>> The bottom line is that we should think about the usability of the most common end user. If anyone needs custom executor service control in the worst case it's still just a matter of one extra parameter as opposed to introducing an obscure alternative to CompletableFuture. >> >>> >> >>> On Mar 7, 2016, at 4:38 PM, Reza Rahman wrote: >> >>> >> >>>> Responses in-line. >> >>>> >> >>>> Sent from my iPhone >> >>>> >> >>>> On Mar 7, 2016, at 4:24 PM, Romain Manni-Bucau < rmannibucau at gmail.com> wrote: >> >>>> >> >>>>> >> >>>>> 2016-03-07 22:09 GMT+01:00 Reza Rahman : >> >>>>>> >> >>>>>> Responses in-line. >> >>>>>> >> >>>>>> On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau < rmannibucau at gmail.com> wrote: >> >>>>>> >> >>>>>>> >> >>>>>>> 2016-03-07 20:53 GMT+01:00 Reza Rahman : >> >>>>>>>> >> >>>>>>>> Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. >> >>>>>>>> >> >>>>>>> >> >>>>>>> so - just to try to ensure we speak about the same thing: >> >>>>>>> >> >>>>>>> asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ? >> >>>>>> >> >>>>>> >> >>>>>> Correct. >> >>>>>> >> >>>>>>> >> >>>>>>> This works but has the drawback to not reuse the observer thread >> >>>>>> >> >>>>>> >> >>>>>> Why would this matter to the average business code developer? All this would run from managed executors of some kind or the other anyway... >> >>>>>> >> >>>>>>> and keep the original issue: the observer doesn't inherit from the caller context so it would likely be: >> >>>>>>> >> >>>>>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool); >> >>>>>> >> >>>>>> >> >>>>>> Again, why does it matter really? The observer threads themselves should be running from a managed pool that is smart enough to preserve context anyway? If the business developer cares about preserving context in their code, they can use a managed executor themselves on the returned CompletableFuture. >> >>>>>> >> >>>>> >> >>>>> Cause it is important to state which thread context is there to keep the integration with other frameworks - think to security ones in particualr - smooth and doable. >> >>>> >> >>>> >> >>>> For framework developers usability is hardly a concern. If they need to preserve their own context they can simply pass in their own managed executor to both the observer thread and the CompletableFuture. >> >>>> >> >>>> In the end, the primary focus should be the masses that we hope will adopt CDI into their applications. Making things harder for them to achieve some limited SPI goal is pretty dangerous. >> >>>> >> >>>>>>> >> >>>>>>> which looks weird since you trigger 2 tasks where you actually want just one in another thread originally? >> >>>>>> >> >>>>>> >> >>>>>> I don't follow. Whichever executor service you would use, ultimately there are at least three different threads associated here in all cases. >> >>>>>> >> >>>>>>> >> >>>>>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire async thread >> >>>>>> >> >>>>>> >> >>>>>> You mean using the same executor? Why does this matter really? They are all managed executors anyway. At best it's reducing one method parameter. >> >>>>>> >> >>>>> >> >>>>> Cause very few apps are 100% EE in practise, probably never will be and even if so JavaEE security is not integrated (yet?) at this level. >> >>>> >> >>>> >> >>>> There is no such thing as context propagation outside of EE managed executors. In SE land, the only thing you have is manually writing your own executor to do the same things. These folks will have to pass around their own executors anyway, even to the observer thread. >> >>>> >> >>>>>>> Are >> >>>>>>> This last proposal works not that bad if context propagation would work but since there are cases it would be expected to work and other it shouldn't - from a user point of view auto inheritance can break thread safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed or even just a new scope close to request scoped but inheritable by design. >> >>>>>>> >> >>>>>>>> >> >>>>>>>> As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? >> >>>>>>>> >> >>>>>>>> Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API. >> >>>>>>>> >> >>>>>>>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau < rmannibucau at gmail.com> wrote: >> >>>>>>>> >> >>>>>>>>> >> >>>>>>>>> 2016-03-07 20:35 GMT+01:00 Reza Rahman : >> >>>>>>>>>> >> >>>>>>>>>> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. >> >>>>>>>>>> >> >>>>>>>>>> Basically this means CompletableFutures are already pretty Java EE ready. >> >>>>>>>>>> >> >>>>>>>>>> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. >> >>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >> >>>>>>>>>> >> >>>>>>>>>>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. >> >>>>>>>>>>> >> >>>>>>>>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau < rmannibucau at gmail.com> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" > >>>>>>>>>>>>>> > a ?crit : >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> >> Hi guys, >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >> >>>>>>>>>>>>>> >> can we move back to CompletionFuture? >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> It would allow for instance: >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> // doesn't work with CompletionStage >> >>>>>>>>>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >> >>>>>>>>>>>>>> >> .then(...) >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > Well, this should work if the underlying CompletionStage impl >> >>>>>>>>>>>>>> supports toCompletableFuture(), i.e. in Weld 3: >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Yes but it is not natural to convert it IMO = we can do better >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >> >>>>>>>>>>>>>> event2.fireAsync(...).toCompletableFuture()) >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > AFAIK the default async execution facility of CompletableFuture is >> >>>>>>>>>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >> >>>>>>>>>>>>>> CompletionStage interface allows us to wrap the async calls without the >> >>>>>>>>>>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function> >>>>>>>>>>>>>> T, ? extends U>)) and supply a default one provided by the impl. >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Should use the pool in which the evznt is fired then "then step" is >> >>>>>>>>>>>>>> synchronous is my sample so all is decided at fire time >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). >> >>>>>>>>>>>> >> >>>>>>>>>>>> That said I agree on the state switching the pool is better but with these 2 notes: >> >>>>>>>>>>>> >> >>>>>>>>>>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools >> >>>>>>>>>>>> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >> >>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> Romain Manni-Bucau >> >>>>>>>>>>>>>> >> @rmannibucau | Blog >> >>>>>>>>>>>>>> >> | Github >> >>>>>>>>>>>>>> >> | LinkedIn >> >>>>>>>>>>>>>> >> | Tomitriber >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> _______________________________________________ >> >>>>>>>>>>>>>> >> cdi-dev mailing list >> >>>>>>>>>>>>>> >> cdi-dev at 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 >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> -- >> >>>>>>>>>>>>> Martin Kouba >> >>>>>>>>>>>>> Software Engineer >> >>>>>>>>>>>>> Red Hat, Czech Republic >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>>> cdi-dev mailing list >> >>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/4bbcf012/attachment-0001.html From reza_rahman at lycos.com Mon Mar 7 18:01:25 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 18:01:25 -0500 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> <536990F1-E349-4D85-A110-900B8086BCCA@lycos.com> <4CA96F8A-9D26-466F-8089-1EC38CAB53FF@lycos.com> <8186D956-CFCC-4739-8D93-8BF033 FE6134@lycos.com> Message-ID: The email chain is getting long so I am starting fresh. Kindly explain what the use case here is then if it's not being used as a promise. Both of these APIs are promises - their purpose is to provide a non-blocking handle to a future event. If that's not the use case here then why are we using either API? From reza_rahman at lycos.com Mon Mar 7 21:15:29 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 7 Mar 2016 21:15:29 -0500 Subject: [cdi-dev] CompletableFuture vs. CompletionStage Message-ID: <9840FA39-0A39-4B81-A26E-100DC297173B@lycos.com> I have forwarded this issue to the Java EE platform EG for review. My inclination now is to simply leave this alone with a final earnest request to kindly think carefully about this before finalizing and getting this into the real world. Please keep in mind that the average developer is not that skilled and looks to resources on the web routinely for answers. All those resources are going to immediately point to CompletableFuture, not some obscure superclass. All I am trying to do is help design an API that is not going to immediately become difficult for the average end developer to understand and use. It's rather unfortunate that I am already feeling fed up in that simple effort to provide feedback. Anyway I am now basically done with this. Unfortunately I have far more urgent matters for Java EE 7 and Java EE 8 to deal with. If I have time I'll look at some more of the CDI 2 work and provide feedback if I can manage time. > On Mar 7, 2016, at 2:53 PM, Reza Rahman wrote: > Argue > Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. > > As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? > > Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API. > >> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau wrote: >> >> >> 2016-03-07 20:35 GMT+01:00 Reza Rahman : >>> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. >>> >>> Basically this means CompletableFutures are already pretty Java EE ready. >>> >>> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? >> >> Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. >> >>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >>>> >>>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. >>>> >>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau wrote: >>>>> >>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >>>>>> >>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>>>> >>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>>> > a ?crit : >>>>>>> > >>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>>> > >>>>>>> >> Hi guys, >>>>>>> >> >>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>>>>> >> can we move back to CompletionFuture? >>>>>>> >> >>>>>>> >> It would allow for instance: >>>>>>> >> >>>>>>> >> // doesn't work with CompletionStage >>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>>>>> >> .then(...) >>>>>>> > >>>>>>> > >>>>>>> > Well, this should work if the underlying CompletionStage impl >>>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>>> > >>>>>>> >>>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>>> >>>>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>>> > >>>>>>> > AFAIK the default async execution facility of CompletableFuture is >>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>>>>>> CompletionStage interface allows us to wrap the async calls without the >>>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>>>> > >>>>>>> >>>>>>> Should use the pool in which the evznt is fired then "then step" is >>>>>>> synchronous is my sample so all is decided at fire time >>>>>> >>>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >>>>> >>>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). >>>>> >>>>> That said I agree on the state switching the pool is better but with these 2 notes: >>>>> >>>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools >>>>> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >>>>> >>>>>>> >>>>>>> > >>>>>>> >> >>>>>>> >> Romain Manni-Bucau >>>>>>> >> @rmannibucau | Blog >>>>>>> >> | Github >>>>>>> >> | LinkedIn >>>>>>> >> | Tomitriber >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> _______________________________________________ >>>>>>> >> cdi-dev mailing list >>>>>>> >> cdi-dev at 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 >>>>>> >>>>>> -- >>>>>> Martin Kouba >>>>>> Software Engineer >>>>>> Red Hat, Czech Republic >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at 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 at 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. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/9cd5a384/attachment.html From rmannibucau at gmail.com Tue Mar 8 02:08:52 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 08:08:52 +0100 Subject: [cdi-dev] async: back to completion future? In-Reply-To: References: <56DD2F49.3010900@redhat.com> <56DD36AB.5040205@redhat.com> <36842B24-8576-4690-8D2E-3915D30B7DDB@lycos.com> <0BADFF5B-D794-4525-A0E9-AB6E581FF350@lycos.com> <7CEECDD3-B2A4-47A4-8506-4375AED6AA70@lycos.com> <536990F1-E349-4D85-A110-900B8086BCCA@lycos.com> <4CA96F8A-9D26-466F-8089-1EC38CAB53FF@lycos.com> Message-ID: 2016-03-08 0:01 GMT+01:00 Reza Rahman : > The email chain is getting long so I am starting fresh. Kindly explain > what the use case here is then if it's not being used as a promise. Both of > these APIs are promises - their purpose is to provide a non-blocking handle > to a future event. > > If that's not the use case here then why are we using either API? > Only the chaining part is useful, the promise (setResult(), setError() side of promises) is an implementation detail. if you want an impl checking the container state to throw an IllegalStateException if the CDI context is down when the chain is triggered you can today. > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/dbc92dc8/attachment-0001.html From arjan.tijms at gmail.com Tue Mar 8 03:16:28 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 8 Mar 2016 09:16:28 +0100 Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: <7F1DB8F2-61DC-459E-8EFC-A93FB6131577@lycos.com> References: <26BB80F0-9295-49AA-A4E5-AD22A4767D7F@lycos.com> <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> <08F09B95-1BBB-4B5A-8C68-4D89DBD92BAB@lycos.com> <886FAD60-6E2E-4467-A535-B3272232DD29@yahoo.de> <5B872657-0DBE-469D-99A3-D2076FB70300@lycos.com> <7F1DB8F2-61DC-459E-8EFC-A93FB6131577@lycos.com> Message-ID: Hi, On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman wrote: > Reading over the CDI spec definition for request scoped beans, I am a tad > confused. When are request scoped beans being destroyed right now? Are they > just bound to the Servlet request thread and destroyed as soon as the > service method returns? In case of a Servlet request (request scoped beans are also tied to other kinds of "requests"), it's indeed not clear. In practice it looks like the moment between the first ServletRequestListener#requestInitialized and ServletRequestListener#requestDestroyed. The exact scope is troublesome for security too, since in most severs the request scope (and session scope and application scope) is active when a SAM is called (the SAM gets an HttpServletRequest after all), but this is not the case in all servers. E.g. in Liberty the RequestScope starts AFTER a SAM is called. Kind regards, Arjan Tijms > In case of asynchronous Servlets, are they kept around until the real HTTP > request actually completes the same way the underlying HTTP connection is > kept around? Or is that too difficult because it would require integration > at a very low level with the Servlet implementation? > > There's some language around asynchronous completion right now but it's > not very clear what actually happens. Does the onComplete, etc asynchronous > callback basically create new request scoped instances? > > > On Mar 7, 2016, at 10:28 AM, Reza Rahman wrote: > > > > Even in the most conservative reading of this, the spec is clearly not > disallowing it. > > > >> On Mar 7, 2016, at 10:05 AM, Mark Struberg wrote: > >> > >> The question is whether the spec does allow us to do it. And if other > containers consequently do it as well. > >> > >> If it does then I will implement it in TomEE. > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman : > >>> > >>> What this is saying is that it is not recommended to use them because > of the possible life-cycle mismatch. If they are not supposed to work at > all, the specification would have simply stated it won't work. > >>> > >>> Anyway personally I have no reason to further discuss this. I'm going > to try to find a way to get this done for developers sooner rather than > later. If TomEE does not want to do it, too bad for developers. > >>> > >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau > wrote: > >>>> > >>>> " > >>>> Tasks that are submitted to a managed instance of ExecutorService may > still be running after the lifecycle of the submitting component. > Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or > @ConversationScoped are not recommended to use as tasks as it cannot be > guaranteed that the tasks will complete before the CDI context is destroyed. > >>>> " > >>>> > >>>> States that the context is not inherited, is that what you mean? > >>>> > >>>> > >>>> > >>>> Romain Manni-Bucau > >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>>> > >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : > >>>> The specification currently references pretty much all the major CDI > scopes specifically with the issue of propagation and lifecycle in mind. > Please see section 2.3. > >>>> > >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg > wrote: > >>>>> Specifically > >>>>> The containers mimic ejb for propagation for a good reason! > >>>>> No session e.g. , new TX, etc > >>>>> > >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so the > Request Context not only doesn't get propagated (which is good), but also > doesn't get set up (which is crap). > >>>>> > >>>>> LieGrue, > >>>>> Strub > >>>>> > >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < > john.d.ament at gmail.com>: > >>>>>> > >>>>>> I agree, in a sense, with what you're saying. There's nothing in > this spec that says it wouldn't be propagated. However, there's nothing in > this spec that states clearly that CDI contexts are propagated. > >>>>>> > >>>>>> If you look at the RI, the RI only seems to propagate transaction > state. Considering the age of the spec, I'm not surprised to see that. > The worst part is that right now, outside of the ASF, all other EE7 impls > seem to be using the RI for concurrency. > >>>>>> > >>>>>> I'm fairly certain that from this spec's standpoint, the only thing > that's actually propagated is the transaction. > >>>>>> > >>>>>> John > >>>>>> > >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman > wrote: > >>>>>> I am re-reading the spec end to end again right now. So far it > seems I have remembered everything correctly. > >>>>>> > >>>>>> You should read over section 2.3. What it is saying is that a > container implementing the Java EE concurrency utilities should ensure > whatever contextual information is needed for managed components to work > correctly should be propagated automatically. For the correct > implementation of CDI scopes, this should also mean any currently active > scopes. The section you are referring to is basically implying that > thinking that it is possible to use these scoped beans in tasks (albeit not > reliably since beans could go out of scope before the thread finishes - for > example if the request ends). > >>>>>> > >>>>>> This does not have anything to do with the context service per se. > The context service is an SPI of sorts to allow end user developers to do > for their own applications what the container does behind the scenes for > managed component context propagation. > >>>>>> > >>>>>> I'll read over the entire spec to see if there is anything to > contradict this. If that's not the case what Romain is describing is most > likely an implementation specific bug that did not take into account CDI > scope propagation. > >>>>>> > >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament > wrote: > >>>>>>> > >>>>>>> Reza, > >>>>>>> > >>>>>>> I read through the concurrency utils spec. Was there a specific > section you had in mind? The only references to CDI were near the > beginning warning users to not use Request/Session scoped beans as tasks > since the outer most context may be destroyed before the work is done. > >>>>>>> > >>>>>>> I have a feeling what you're referring to is the context service: > http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html > >>>>>>> > >>>>>>> If that's the case, then basically this should work OOTB right? > >>>>>>> > >>>>>>> Task task = new MyTask(); > >>>>>>> task = contextService.createContextualProxy(task, Task.class); > >>>>>>> executor.submit(task); > >>>>>>> > >>>>>>> // now magically the context should be prop'd? > >>>>>>> > >>>>>>> Is that about right? > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman > wrote: > >>>>>>> Have you actually looked at the EE concurrency spec text in > detail? What does it say about managed component context propagation? > >>>>>>> > >>>>>>> Without actually doing that further discussing this is just taking > shots in the dark. As an implementer it should not surprise you that this > might simply be a bug because the person implementing the concurrency > utilities for the EE runtime was not told about what to copy over into the > new thread for CDI to work correctly. > >>>>>>> > >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : > >>>>>>>> As far as I know this is precisely the sort of thing that the EE > concurrency spec is intended for. It is supposed to copy over everything > from the underlying thread local context into the new thread for all EE > managed components to function. Since CDI beans are also EE container > managed, it also applies to CDI beans as well. The EE vendor is supposed to > make sure this works properly. > >>>>>>>> > >>>>>>>> I don't think the concurrency utilities specifically lists APIs > for which thread context propagation should work. If this doesn't work in a > specific implementation it's most likely because they didn't take CDI into > account in their own EE concurrency implementation. > >>>>>>>> > >>>>>>>> > >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily > and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped > badly named. So to solve it we would need another scope as I mentionned > several times on this list 100% matching servlet instances lifecycles (on a > pure CDI side we have the same issue for sessions which are recycled during > a request, the session scope is corrupted *by spec* in term of user > behavior). > >>>>>>>> > >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < > john.d.ament at gmail.com> wrote: > >>>>>>>>> > >>>>>>>>> The section of the spec you link to makes no references to > threads. 6.3 makes some notes about normal scopes and threads, and > specifically says that a context is bound to one or more threads. > >>>>>>>>> > >>>>>>>>> I think what's happened is that over the years, people have > simply bound HTTP Request == single thread, but when async processing was > introduced no one thought to clarify that the spawning of a child thread > from the original HTTP request retains the parent's context. > >>>>>>>>> > >>>>>>>>> This is another requested feature, but looks more like a bug or > gap in the spec. > >>>>>>>>> > >>>>>>>>> John > >>>>>>>>> > >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : > >>>>>>>>> Let's see. I suspect the specification text for EE concurrency > is generic enough for implementations to also be able to cover CDI scopes > or any other Java EE API context propagation needs. This means the issue > needs to be solved at the individual implementation level. Changing > anything in the spec is probably just unnecessary ceremony in this case. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, > 2. CDI still prevent it to work since it would violate the spec to > propagate it while request scope is bound to another thread ( > http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles > async listener but not the main AsyncContext part). > >>>>>>>>> > >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : > >>>>>>>>>> This frankly surprises me. I'll check the specification text. > This might indeed just be an implementation bug. The EE concurrency > utilities are supposed to be copying all relevant context. If this is an > issue than it has to be that it is not copying enough of the HTTP request > context for CDI to work. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> The issue is not technical since I got it working but needed to > reverse. From my understanding ee concurrency utilities was done in a time > CDI was not there so it just ignored it somehow and it hasnt been updated > when integrated to the spec. Now with the wording of the CDI - and TCK - it > is impossible to make it working since request scope is bound the thre > request thread - and not the request. Side note: same applies to session > scope and conversation. > >>>>>>>>>> > >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since > they implement essentially this whole stack? > >>>>>>>>>> > >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > >>>>>>>>>>> > >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman >: > >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's > important to make the case for how likely this is supposed to occur in most > business applications. > >>>>>>>>>>> > >>>>>>>>>>> Also, other than making sure that the executor service is > propagating thread local request contexts correctly what other solution are > you proposing? Did you check the specification? How sure are you that this > isn't simply an implementation bug? > >>>>>>>>>>> > >>>>>>>>>>> As far as I know the executor service is supposed to be > preserving all relevant parts of the EE context? > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the > first impl I did then Mark pointed out it was violating CDI spec and > request scope definition. There is a kind of contracdiction there cause > concurrency-utilities doesn't integrate with CDI at all but we can also see > it the opposite way: CDI doesn't provide any way to propagate a context in > another thread. Both point of view are valid so we need to see where we > tackle it. > >>>>>>>>>>> > >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e > help? > >>>>>>>>>>>> > >>>>>>>>>>>> Idea is to give an API to make: > >>>>>>>>>>>> > >>>>>>>>>>>> public void complete() { > >>>>>>>>>>>> try { > >>>>>>>>>>>> asyncContext.complete(); > >>>>>>>>>>>> } finally { > >>>>>>>>>>>> auditContext.end(); > >>>>>>>>>>>> } > >>>>>>>>>>>> } > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> working without hacky and almost impossible context pushing > (cause of injections nature you are not supposed to know what to push in > the context when going async). > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Romain Manni-Bucau > >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>>>>>>>>>>> > >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman >: > >>>>>>>>>>>> Can you kindly share an annotated code example of the > proposed solution so we can all follow and discuss this? > >>>>>>>>>>>> > >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < > rmannibucau at gmail.com> wroteshar: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi guys, > >>>>>>>>>>>>> > >>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit > a cdi scope. Idea is to follow request scope more than cdi spec allows. > First thought it was a concurrency utilities thing but Reza mentionned can > be a CDI one so here it is. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Sample: > >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some > set on it. The i go async (AsyncContext) and trigger a task in another > thread. It would be neat - and mandatory in some case by the loose coupling > nature of CDI - to get the *same* MyBean *instance* in this thread. With a > direct dependency you can easily use message passing pattern - but you > loose the loose coupling cause you need to know until which level you > unwrap, think t principal case which has 2-3 proxies!. However in practice > you have a lot of undirect dependencies, in particular with enterprise > concerns (auditing, security...) so you can't really do it easily/naturally. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Bonus: > >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an > existing context in a thread - wrappers doing it on a > Runnable/Consumer/Function/... would be neat. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Question: > >>>>>>>>>>>>> Would CDI handle it in 2.0? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context > context" (its current instances map) in another thread the more > transparently possible and match the user vision more than a technical > question for now. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Romain Manni-Bucau > >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> cdi-dev mailing list > >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/3e04d684/attachment-0001.html From issues at jboss.org Tue Mar 8 03:17:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Mar 2016 03:17:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-519) Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173289#comment-13173289 ] Martin Kouba commented on CDI-519: ---------------------------------- I've sent a pull request with solution (1). > Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object > ------------------------------------------------------------------------------------------------------ > > Key: CDI-519 > URL: https://issues.jboss.org/browse/CDI-519 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > 5.6.1. The Instance interface: > {quote} > The method destroy() instructs the container to destroy the instance. The bean instance passed to destroy() should be *a dependent scoped bean instance*, or... > {quote} > I think this should be more obvious. E.g. this wouldn't work correctly even though it doesn't violate the spec: > {code:java} > @Dependent > class Bar { > } > class Foo { > @Inject > Instance instance; > void ping() { > instance.destroy(CDI.current().select(Bar.class).get()); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 03:26:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 8 Mar 2016 03:26:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-586) Add spec text for new Literals In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-586: ---------------------------------------- Summary: Add spec text for new Literals Key: CDI-586 URL: https://issues.jboss.org/browse/CDI-586 Project: CDI Specification Issues Issue Type: Clarification Reporter: Antoine Sabot-Durand CDI-485 introduced literals in the API. We should add some information about them in the spec as well -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 03:27:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 8 Mar 2016 03:27:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-586) Add spec text for new Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-586: ------------------------------------- Fix Version/s: 2.0-EDR2 > Add spec text for new Literals > ------------------------------ > > Key: CDI-586 > URL: https://issues.jboss.org/browse/CDI-586 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > CDI-485 introduced literals in the API. We should add some information about them in the spec as well -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 03:33:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Mar 2016 03:33:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-586) Add spec text for new Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173301#comment-13173301 ] Martin Kouba commented on CDI-586: ---------------------------------- Yes, "5.6.3. Using AnnotationLiteral and TypeLiteral" looks like a suitable section. > Add spec text for new Literals > ------------------------------ > > Key: CDI-586 > URL: https://issues.jboss.org/browse/CDI-586 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > CDI-485 introduced literals in the API. We should add some information about them in the spec as well -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 03:38:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Mar 2016 03:38:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-525) Default names should maybe follow the inferring rules from the JavaBean spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173303#comment-13173303 ] Martin Kouba commented on CDI-525: ---------------------------------- [~antoinesabot-durand] This issue should be probably rejected. > Default names should maybe follow the inferring rules from the JavaBean spec > ---------------------------------------------------------------------------- > > Key: CDI-525 > URL: https://issues.jboss.org/browse/CDI-525 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > *3.1.5. Default bean name for a managed bean*: > {quote} > The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case. > {quote} > As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*: > {quote} > However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone. > {quote} > I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}. > Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 03:42:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Mar 2016 03:42:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata injection for EE components In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173304#comment-13173304 ] Martin Kouba commented on CDI-500: ---------------------------------- The impl should probably inject {{null}} and log a warning. > Clarify @Intercepted Bean metadata injection for EE components > -------------------------------------------------------------- > > Key: CDI-500 > URL: https://issues.jboss.org/browse/CDI-500 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > It's not clear what should happen when an interceptor with {{@Intercepted Bean}} metadata is associated with an EE component. > See the CDI spec, "5.5.8. Bean metadata": > {quote} > Additionally, the container must provide beans allowing interceptors and decorators to obtain information about the beans they intercept and decorate: > * a bean with scope @Dependent, qualifier @Intercepted and type Bean which can be injected into any interceptor instance, and > * ... > {quote} > However, most EE components must also support the use of CDI interceptors. See also the Java EE 7 spec, "EE.5.2.5 Annotations and Injection": > {quote} > The component classes listed in Table EE.5-1 with support level "Standard" > all support Java EE resource injection, as well as PostConstruct and PreDestroy callbacks. In addition, if CDI is enabled?which it is by default?these classes also support CDI injection, as described in Section EE.5.24, "Support for Dependency Injection", and the use of interceptors. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 05:19:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 8 Mar 2016 05:19:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-525) Default names should maybe follow the inferring rules from the JavaBean spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173374#comment-13173374 ] Antoine Sabot-Durand commented on CDI-525: ------------------------------------------ [~mkouba] what are the rules used in EL for JSF and JSP? In my memories it was the one defined in Javabeans, but I may be wrong... > Default names should maybe follow the inferring rules from the JavaBean spec > ---------------------------------------------------------------------------- > > Key: CDI-525 > URL: https://issues.jboss.org/browse/CDI-525 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > *3.1.5. Default bean name for a managed bean*: > {quote} > The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case. > {quote} > As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*: > {quote} > However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone. > {quote} > I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}. > Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 05:49:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 8 Mar 2016 05:49:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-586) Add spec text for new Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-586: ---------------------------------------- Assignee: Antoine Sabot-Durand > Add spec text for new Literals > ------------------------------ > > Key: CDI-586 > URL: https://issues.jboss.org/browse/CDI-586 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > CDI-485 introduced literals in the API. We should add some information about them in the spec as well -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 05:49:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 8 Mar 2016 05:49:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-586) Add spec text for new Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173414#comment-13173414 ] Antoine Sabot-Durand commented on CDI-586: ------------------------------------------ Yep I'm on it > Add spec text for new Literals > ------------------------------ > > Key: CDI-586 > URL: https://issues.jboss.org/browse/CDI-586 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > CDI-485 introduced literals in the API. We should add some information about them in the spec as well -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 06:03:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Mar 2016 06:03:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-525) Default names should maybe follow the inferring rules from the JavaBean spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173426#comment-13173426 ] Martin Kouba commented on CDI-525: ---------------------------------- Yep, the {{BeanELResolver}} is also using {{java.beans.Introspector}} and follows JavaBeans spec. On the other hand, the default name of a bean is not a property and we would also break backward compatibility. > Default names should maybe follow the inferring rules from the JavaBean spec > ---------------------------------------------------------------------------- > > Key: CDI-525 > URL: https://issues.jboss.org/browse/CDI-525 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > *3.1.5. Default bean name for a managed bean*: > {quote} > The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case. > {quote} > As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*: > {quote} > However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone. > {quote} > I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}. > Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From tremes at redhat.com Tue Mar 8 06:20:44 2016 From: tremes at redhat.com (Tomas Remes) Date: Tue, 8 Mar 2016 06:20:44 -0500 (EST) Subject: [cdi-dev] inheritance of cdi scopes In-Reply-To: References: <6C9EDD99-5663-4603-9F51-887AB2A81703@lycos.com> Message-ID: <318090432.37011664.1457436044557.JavaMail.zimbra@redhat.com> Hi, If you feel that CDI TCK breaks something then raise an issue please. Tom ----- Original Message ----- From: "Romain Manni-Bucau" To: "Reza Rahman" Cc: cdi-dev at lists.jboss.org Sent: Sunday, March 6, 2016 9:06:59 PM Subject: Re: [cdi-dev] inheritance of cdi scopes 2016-03-06 20:59 GMT+01:00 Reza Rahman < reza_rahman at lycos.com > : As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). On Mar 6, 2016, at 2:45 PM, John D. Ament < john.d.ament at gmail.com > wrote: The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. This is another requested feature, but looks more like a bug or gap in the spec. John On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < rmannibucau at gmail.com > wrote: 2016-03-06 20:25 GMT+01:00 Reza Rahman < reza_rahman at lycos.com > : Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread ( http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < rmannibucau at gmail.com > wrote: 2016-03-06 19:42 GMT+01:00 Reza Rahman < reza_rahman at lycos.com > : This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < rmannibucau at gmail.com > wrote: 2016-03-06 19:20 GMT+01:00 Reza Rahman < reza_rahman at lycos.com > : Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < rmannibucau at gmail.com > wrote: does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? Idea is to give an API to make: public void complete () { try { asyncContext . complete(); } finally { auditContext . end(); } } working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-06 16:40 GMT+01:00 Reza Rahman < reza_rahman at lycos.com > : Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < rmannibucau at gmail.com > wroteshar: Hi guys, spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. Sample: In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. Bonus: One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. Question: Would CDI handle it in 2.0? Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber _______________________________________________ cdi-dev mailing list cdi-dev at 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 at 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 at 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. From reza_rahman at lycos.com Tue Mar 8 07:19:18 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 07:19:18 -0500 Subject: [cdi-dev] CompletableFuture vs. CompletionStage In-Reply-To: References: <9840FA39-0A39-4B81-A26E-100DC297173B@lycos.com> Message-ID: <59B4C96E-D29D-4702-89C3-2D679927F588@lycos.com> FYI I am running a survey on this issue: https://twitter.com/reza_rahman/status/707035213717774336. If you really are open to feedback, I suggest keeping an eye there. When it is done, it is possible I will blog about this if it is clear this is a going to be a problem. In the least people will hopefully have that as a resource when they are confused. The reality is that everyone has limited time. I can provide feedback when I can provide feedback for any number of personal reasons including whether my employer allows it. It is ultimately up to you to consider it fairly and objectively at all times. If you are failing to do that for any reason before the spec is final it is rather unfortunate for anyone relying on the spec. In the end the beauty of all of this is that none of this impacts my livelihood immediately any more. I am just another developer again now. In the end I get to walk over to the Spring camp like everyone else. And thank goodness for that freedom. Kindly do not assume I will be spending a lot of time providing you feedback going forward. That was unlikely at all times given my time constraints. You should assume the same for most developers out there. When you get feedback from us, you should consider it in that light. > On Mar 8, 2016, at 5:37 AM, Antoine Sabot-Durand wrote: > > Answer inline > >> Le mar. 8 mars 2016 ? 03:15, Reza Rahman a ?crit : >> I have forwarded this issue to the Java EE platform EG for review. My inclination now is to simply leave this alone with a final earnest request to kindly think carefully about this before finalizing and getting this into the real world. Please keep in mind that the average developer is not that skilled and looks to resources on the web routinely for answers. All those resources are going to immediately point to CompletableFuture, not some obscure superclass. > > CS is not an obscure superclass it's an interface and all methods in CF returns it, so it's impossible to learn CF and ignore CS existence. > Concurrency is not an easy feature to use, people that think they can cut and paste code from stack overflow without digging in the doc will hit a wall very soon. > We decided to return a CS to allow advanced user to use it to build async pipeline from here. I guess that the majority of beginners will ignore this returned object (as they would have do it if it had been a CF). > >> >> All I am trying to do is help design an API that is not going to immediately become difficult for the average end developer to understand and use. It's rather unfortunate that I am already feeling fed up in that simple effort to provide feedback. > > Reza, feedback is always welcome. But if you don't do it in time you should expect some resistance from the EG who worked a long time (and in an open way) to take these decision. So you need more arguments than "user don't know CS" to make us switch from an interface to an impl, that is not suited for Java EE. > Feedback on possible technical issues are welcome. > >> >> Anyway I am now basically done with this. Unfortunately I have far more urgent matters for Java EE 7 and Java EE 8 to deal with. If I have time I'll look at some more of the CDI 2 work and provide feedback if I can manage time. > > Again it's welcome. We are about to discuss a programmatic APi for SE boot. Your input will be precious here. > >> >>> On Mar 7, 2016, at 2:53 PM, Reza Rahman wrote: >>> Argue >>> Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. >>> >>> As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? >>> >>> Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API. >>> >>>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau wrote: >>>> >>>> >>>> 2016-03-07 20:35 GMT+01:00 Reza Rahman : >>>>> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. >>>>> >>>>> Basically this means CompletableFutures are already pretty Java EE ready. >>>>> >>>>> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? >>>>> >>>> >>>> Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. >>>> >>>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >>>>>> >>>>>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. >>>>>> >>>>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau wrote: >>>>>>> >>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >>>>>>>> >>>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>>>>>> >>>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>>>>> > a ?crit : >>>>>>>>> > >>>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>>>>> > >>>>>>>>> >> Hi guys, >>>>>>>>> >> >>>>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>>>>>>> >> can we move back to CompletionFuture? >>>>>>>>> >> >>>>>>>>> >> It would allow for instance: >>>>>>>>> >> >>>>>>>>> >> // doesn't work with CompletionStage >>>>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>>>>>>> >> .then(...) >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Well, this should work if the underlying CompletionStage impl >>>>>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>>>>> > >>>>>>>>> >>>>>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>>>>> >>>>>>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>>>>> > >>>>>>>>> > AFAIK the default async execution facility of CompletableFuture is >>>>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>>>>>>>> CompletionStage interface allows us to wrap the async calls without the >>>>>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>>>>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>>>>>> > >>>>>>>>> >>>>>>>>> Should use the pool in which the evznt is fired then "then step" is >>>>>>>>> synchronous is my sample so all is decided at fire time >>>>>>>> >>>>>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >>>>>>>> >>>>>>> >>>>>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). >>>>>>> >>>>>>> That said I agree on the state switching the pool is better but with these 2 notes: >>>>>>> >>>>>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools >>>>>>> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >>>>>>> >>>>>>>>> >>>>>>>>> > >>>>>>>>> >> >>>>>>>>> >> Romain Manni-Bucau >>>>>>>>> >> @rmannibucau | Blog >>>>>>>>> >> | Github >>>>>>>>> >> | LinkedIn >>>>>>>>> >> | Tomitriber >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> _______________________________________________ >>>>>>>>> >> cdi-dev mailing list >>>>>>>>> >> cdi-dev at 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 >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Martin Kouba >>>>>>>> Software Engineer >>>>>>>> Red Hat, Czech Republic >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/58d79f78/attachment-0001.html From reza_rahman at lycos.com Tue Mar 8 07:33:46 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 07:33:46 -0500 Subject: [cdi-dev] RequestScope Life Cycle Message-ID: Let's hope some of the implementors weigh in on this some time soon. I could write some tests on this but I would have no idea if I would have uncovered a bug given the ambiguity of the current spec text. > On Mar 8, 2016, at 3:16 AM, arjan tijms wrote: > > Hi, > >> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman wrote: >> Reading over the CDI spec definition for request scoped beans, I am a tad confused. When are request scoped beans being destroyed right now? Are they just bound to the Servlet request thread and destroyed as soon as the service method returns? > > In case of a Servlet request (request scoped beans are also tied to other kinds of "requests"), it's indeed not clear. In practice it looks like the moment between the first ServletRequestListener#requestInitialized and ServletRequestListener#requestDestroyed. > > The exact scope is troublesome for security too, since in most severs the request scope (and session scope and application scope) is active when a SAM is called (the SAM gets an HttpServletRequest after all), but this is not the case in all servers. E.g. in Liberty the RequestScope starts AFTER a SAM is called. > > Kind regards, > Arjan Tijms > > > >> In case of asynchronous Servlets, are they kept around until the real HTTP request actually completes the same way the underlying HTTP connection is kept around? Or is that too difficult because it would require integration at a very low level with the Servlet implementation? >> >> There's some language around asynchronous completion right now but it's not very clear what actually happens. Does the onComplete, etc asynchronous callback basically create new request scoped instances? >> >> > On Mar 7, 2016, at 10:28 AM, Reza Rahman wrote: >> > >> > Even in the most conservative reading of this, the spec is clearly not disallowing it. >> > >> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg wrote: >> >> >> >> The question is whether the spec does allow us to do it. And if other containers consequently do it as well. >> >> >> >> If it does then I will implement it in TomEE. >> >> >> >> LieGrue, >> >> strub >> >> >> >> >> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman : >> >>> >> >>> What this is saying is that it is not recommended to use them because of the possible life-cycle mismatch. If they are not supposed to work at all, the specification would have simply stated it won't work. >> >>> >> >>> Anyway personally I have no reason to further discuss this. I'm going to try to find a way to get this done for developers sooner rather than later. If TomEE does not want to do it, too bad for developers. >> >>> >> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau wrote: >> >>>> >> >>>> " >> >>>> Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. >> >>>> " >> >>>> >> >>>> States that the context is not inherited, is that what you mean? >> >>>> >> >>>> >> >>>> >> >>>> Romain Manni-Bucau >> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>>> >> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >> >>>> The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. >> >>>> >> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >> >>>>> Specifically >> >>>>> The containers mimic ejb for propagation for a good reason! >> >>>>> No session e.g. , new TX, etc >> >>>>> >> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). >> >>>>> >> >>>>> LieGrue, >> >>>>> Strub >> >>>>> >> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >> >>>>>> >> >>>>>> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >> >>>>>> >> >>>>>> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >> >>>>>> >> >>>>>> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >> >>>>>> >> >>>>>> John >> >>>>>> >> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >> >>>>>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >> >>>>>> >> >>>>>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >> >>>>>> >> >>>>>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >> >>>>>> >> >>>>>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >> >>>>>> >> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >> >>>>>>> >> >>>>>>> Reza, >> >>>>>>> >> >>>>>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >> >>>>>>> >> >>>>>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >> >>>>>>> >> >>>>>>> If that's the case, then basically this should work OOTB right? >> >>>>>>> >> >>>>>>> Task task = new MyTask(); >> >>>>>>> task = contextService.createContextualProxy(task, Task.class); >> >>>>>>> executor.submit(task); >> >>>>>>> >> >>>>>>> // now magically the context should be prop'd? >> >>>>>>> >> >>>>>>> Is that about right? >> >>>>>>> >> >>>>>>> John >> >>>>>>> >> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >> >>>>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >> >>>>>>> >> >>>>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >> >>>>>>> >> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >> >>>>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >> >>>>>>>> >> >>>>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >> >>>>>>>> >> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >> >>>>>>>>> >> >>>>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >> >>>>>>>>> >> >>>>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >> >>>>>>>>> >> >>>>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >> >>>>>>>>> >> >>>>>>>>> John >> >>>>>>>>> >> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >> >>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >> >>>>>>>>> >> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >> >>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >> >>>>>>>>>> >> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >> >>>>>>>>>> >> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >> >>>>>>>>>>> >> >>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >> >>>>>>>>>>> >> >>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >> >>>>>>>>>>> >> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >> >>>>>>>>>>>> >> >>>>>>>>>>>> Idea is to give an API to make: >> >>>>>>>>>>>> >> >>>>>>>>>>>> public void complete() { >> >>>>>>>>>>>> try { >> >>>>>>>>>>>> asyncContext.complete(); >> >>>>>>>>>>>> } finally { >> >>>>>>>>>>>> auditContext.end(); >> >>>>>>>>>>>> } >> >>>>>>>>>>>> } >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Romain Manni-Bucau >> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>>>>>>>>>>> >> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >> >>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >> >>>>>>>>>>>> >> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >> >>>>>>>>>>>> >> >>>>>>>>>>>>> Hi guys, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Sample: >> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Bonus: >> >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Question: >> >>>>>>>>>>>>> Would CDI handle it in 2.0? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Romain Manni-Bucau >> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>>>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>>>> cdi-dev mailing list >> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/3cfc7f72/attachment-0001.html From rmannibucau at gmail.com Tue Mar 8 07:44:59 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 13:44:59 +0100 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: Message-ID: In TomEE we restart/stop it around most of hooks including the runnable passed to start(Runnable) of the AsyncContext but keeping the now widespread ThreadLocal nature of the @RequestScoped (= not the same as the startAsync() call sadly). This passes CDI TCK but for the particular request scope I would be happy to clarify it is actually bound to the request and just reuse the same instances. In term of side effects it would breaks the current thread safety users assume (with reason or not) but I have no real clue if it would really breaks apps or not. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-08 13:33 GMT+01:00 Reza Rahman : > Let's hope some of the implementors weigh in on this some time soon. > > I could write some tests on this but I would have no idea if I would have > uncovered a bug given the ambiguity of the current spec text. > > On Mar 8, 2016, at 3:16 AM, arjan tijms wrote: > > Hi, > > On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman wrote: > >> Reading over the CDI spec definition for request scoped beans, I am a tad >> confused. When are request scoped beans being destroyed right now? Are they >> just bound to the Servlet request thread and destroyed as soon as the >> service method returns? > > > In case of a Servlet request (request scoped beans are also tied to other > kinds of "requests"), it's indeed not clear. In practice it looks like the > moment between the first ServletRequestListener#requestInitialized and > ServletRequestListener#requestDestroyed. > > The exact scope is troublesome for security too, since in most severs the > request scope (and session scope and application scope) is active when a > SAM is called (the SAM gets an HttpServletRequest after all), but this is > not the case in all servers. E.g. in Liberty the RequestScope starts AFTER > a SAM is called. > > Kind regards, > Arjan Tijms > > > > >> In case of asynchronous Servlets, are they kept around until the real >> HTTP request actually completes the same way the underlying HTTP connection >> is kept around? Or is that too difficult because it would require >> integration at a very low level with the Servlet implementation? >> >> There's some language around asynchronous completion right now but it's >> not very clear what actually happens. Does the onComplete, etc asynchronous >> callback basically create new request scoped instances? >> >> > On Mar 7, 2016, at 10:28 AM, Reza Rahman wrote: >> > >> > Even in the most conservative reading of this, the spec is clearly not >> disallowing it. >> > >> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg wrote: >> >> >> >> The question is whether the spec does allow us to do it. And if other >> containers consequently do it as well. >> >> >> >> If it does then I will implement it in TomEE. >> >> >> >> LieGrue, >> >> strub >> >> >> >> >> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman : >> >>> >> >>> What this is saying is that it is not recommended to use them because >> of the possible life-cycle mismatch. If they are not supposed to work at >> all, the specification would have simply stated it won't work. >> >>> >> >>> Anyway personally I have no reason to further discuss this. I'm going >> to try to find a way to get this done for developers sooner rather than >> later. If TomEE does not want to do it, too bad for developers. >> >>> >> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >> rmannibucau at gmail.com> wrote: >> >>>> >> >>>> " >> >>>> Tasks that are submitted to a managed instance of ExecutorService >> may still be running after the lifecycle of the submitting component. >> Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or >> @ConversationScoped are not recommended to use as tasks as it cannot be >> guaranteed that the tasks will complete before the CDI context is destroyed. >> >>>> " >> >>>> >> >>>> States that the context is not inherited, is that what you mean? >> >>>> >> >>>> >> >>>> >> >>>> Romain Manni-Bucau >> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>>> >> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >> >>>> The specification currently references pretty much all the major CDI >> scopes specifically with the issue of propagation and lifecycle in mind. >> Please see section 2.3. >> >>>> >> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg >> wrote: >> >>>>> Specifically >> >>>>> The containers mimic ejb for propagation for a good reason! >> >>>>> No session e.g. , new TX, etc >> >>>>> >> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so >> the Request Context not only doesn't get propagated (which is good), but >> also doesn't get set up (which is crap). >> >>>>> >> >>>>> LieGrue, >> >>>>> Strub >> >>>>> >> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >> john.d.ament at gmail.com>: >> >>>>>> >> >>>>>> I agree, in a sense, with what you're saying. There's nothing in >> this spec that says it wouldn't be propagated. However, there's nothing in >> this spec that states clearly that CDI contexts are propagated. >> >>>>>> >> >>>>>> If you look at the RI, the RI only seems to propagate transaction >> state. Considering the age of the spec, I'm not surprised to see that. >> The worst part is that right now, outside of the ASF, all other EE7 impls >> seem to be using the RI for concurrency. >> >>>>>> >> >>>>>> I'm fairly certain that from this spec's standpoint, the only >> thing that's actually propagated is the transaction. >> >>>>>> >> >>>>>> John >> >>>>>> >> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman >> wrote: >> >>>>>> I am re-reading the spec end to end again right now. So far it >> seems I have remembered everything correctly. >> >>>>>> >> >>>>>> You should read over section 2.3. What it is saying is that a >> container implementing the Java EE concurrency utilities should ensure >> whatever contextual information is needed for managed components to work >> correctly should be propagated automatically. For the correct >> implementation of CDI scopes, this should also mean any currently active >> scopes. The section you are referring to is basically implying that >> thinking that it is possible to use these scoped beans in tasks (albeit not >> reliably since beans could go out of scope before the thread finishes - for >> example if the request ends). >> >>>>>> >> >>>>>> This does not have anything to do with the context service per se. >> The context service is an SPI of sorts to allow end user developers to do >> for their own applications what the container does behind the scenes for >> managed component context propagation. >> >>>>>> >> >>>>>> I'll read over the entire spec to see if there is anything to >> contradict this. If that's not the case what Romain is describing is most >> likely an implementation specific bug that did not take into account CDI >> scope propagation. >> >>>>>> >> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament >> wrote: >> >>>>>>> >> >>>>>>> Reza, >> >>>>>>> >> >>>>>>> I read through the concurrency utils spec. Was there a specific >> section you had in mind? The only references to CDI were near the >> beginning warning users to not use Request/Session scoped beans as tasks >> since the outer most context may be destroyed before the work is done. >> >>>>>>> >> >>>>>>> I have a feeling what you're referring to is the context service: >> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >> >>>>>>> >> >>>>>>> If that's the case, then basically this should work OOTB right? >> >>>>>>> >> >>>>>>> Task task = new MyTask(); >> >>>>>>> task = contextService.createContextualProxy(task, Task.class); >> >>>>>>> executor.submit(task); >> >>>>>>> >> >>>>>>> // now magically the context should be prop'd? >> >>>>>>> >> >>>>>>> Is that about right? >> >>>>>>> >> >>>>>>> John >> >>>>>>> >> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman >> wrote: >> >>>>>>> Have you actually looked at the EE concurrency spec text in >> detail? What does it say about managed component context propagation? >> >>>>>>> >> >>>>>>> Without actually doing that further discussing this is just >> taking shots in the dark. As an implementer it should not surprise you that >> this might simply be a bug because the person implementing the concurrency >> utilities for the EE runtime was not told about what to copy over into the >> new thread for CDI to work correctly. >> >>>>>>> >> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >> rmannibucau at gmail.com> wrote: >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >> >>>>>>>> As far as I know this is precisely the sort of thing that the EE >> concurrency spec is intended for. It is supposed to copy over everything >> from the underlying thread local context into the new thread for all EE >> managed components to function. Since CDI beans are also EE container >> managed, it also applies to CDI beans as well. The EE vendor is supposed to >> make sure this works properly. >> >>>>>>>> >> >>>>>>>> I don't think the concurrency utilities specifically lists APIs >> for which thread context propagation should work. If this doesn't work in a >> specific implementation it's most likely because they didn't take CDI into >> account in their own EE concurrency implementation. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily >> and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped >> badly named. So to solve it we would need another scope as I mentionned >> several times on this list 100% matching servlet instances lifecycles (on a >> pure CDI side we have the same issue for sessions which are recycled during >> a request, the session scope is corrupted *by spec* in term of user >> behavior). >> >>>>>>>> >> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >> john.d.ament at gmail.com> wrote: >> >>>>>>>>> >> >>>>>>>>> The section of the spec you link to makes no references to >> threads. 6.3 makes some notes about normal scopes and threads, and >> specifically says that a context is bound to one or more threads. >> >>>>>>>>> >> >>>>>>>>> I think what's happened is that over the years, people have >> simply bound HTTP Request == single thread, but when async processing was >> introduced no one thought to clarify that the spawning of a child thread >> from the original HTTP request retains the parent's context. >> >>>>>>>>> >> >>>>>>>>> This is another requested feature, but looks more like a bug or >> gap in the spec. >> >>>>>>>>> >> >>>>>>>>> John >> >>>>>>>>> >> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >> rmannibucau at gmail.com> wrote: >> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >> >>>>>>>>> Let's see. I suspect the specification text for EE concurrency >> is generic enough for implementations to also be able to cover CDI scopes >> or any other Java EE API context propagation needs. This means the issue >> needs to be solved at the individual implementation level. Changing >> anything in the spec is probably just unnecessary ceremony in this case. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, >> 2. CDI still prevent it to work since it would violate the spec to >> propagate it while request scope is bound to another thread ( >> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles >> async listener but not the main AsyncContext part). >> >>>>>>>>> >> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >> rmannibucau at gmail.com> wrote: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman > >: >> >>>>>>>>>> This frankly surprises me. I'll check the specification text. >> This might indeed just be an implementation bug. The EE concurrency >> utilities are supposed to be copying all relevant context. If this is an >> issue than it has to be that it is not copying enough of the HTTP request >> context for CDI to work. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> The issue is not technical since I got it working but needed >> to reverse. From my understanding ee concurrency utilities was done in a >> time CDI was not there so it just ignored it somehow and it hasnt been >> updated when integrated to the spec. Now with the wording of the CDI - and >> TCK - it is impossible to make it working since request scope is bound the >> thre request thread - and not the request. Side note: same applies to >> session scope and conversation. >> >>>>>>>>>> >> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here >> since they implement essentially this whole stack? >> >>>>>>>>>> >> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >> rmannibucau at gmail.com> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman > >: >> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's >> important to make the case for how likely this is supposed to occur in most >> business applications. >> >>>>>>>>>>> >> >>>>>>>>>>> Also, other than making sure that the executor service is >> propagating thread local request contexts correctly what other solution are >> you proposing? Did you check the specification? How sure are you that this >> isn't simply an implementation bug? >> >>>>>>>>>>> >> >>>>>>>>>>> As far as I know the executor service is supposed to be >> preserving all relevant parts of the EE context? >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the >> first impl I did then Mark pointed out it was violating CDI spec and >> request scope definition. There is a kind of contracdiction there cause >> concurrency-utilities doesn't integrate with CDI at all but we can also see >> it the opposite way: CDI doesn't provide any way to propagate a context in >> another thread. Both point of view are valid so we need to see where we >> tackle it. >> >>>>>>>>>>> >> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >> rmannibucau at gmail.com> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> does >> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >> >>>>>>>>>>>> >> >>>>>>>>>>>> Idea is to give an API to make: >> >>>>>>>>>>>> >> >>>>>>>>>>>> public void complete() { >> >>>>>>>>>>>> try { >> >>>>>>>>>>>> asyncContext.complete(); >> >>>>>>>>>>>> } finally { >> >>>>>>>>>>>> auditContext.end(); >> >>>>>>>>>>>> } >> >>>>>>>>>>>> } >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> working without hacky and almost impossible context pushing >> (cause of injections nature you are not supposed to know what to push in >> the context when going async). >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Romain Manni-Bucau >> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>>>>>>>>>>> >> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >> reza_rahman at lycos.com>: >> >>>>>>>>>>>> Can you kindly share an annotated code example of the >> proposed solution so we can all follow and discuss this? >> >>>>>>>>>>>> >> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >> rmannibucau at gmail.com> wroteshar: >> >>>>>>>>>>>> >> >>>>>>>>>>>>> Hi guys, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit >> a cdi scope. Idea is to follow request scope more than cdi spec allows. >> First thought it was a concurrency utilities thing but Reza mentionned can >> be a CDI one so here it is. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Sample: >> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do >> some set on it. The i go async (AsyncContext) and trigger a task in another >> thread. It would be neat - and mandatory in some case by the loose coupling >> nature of CDI - to get the *same* MyBean *instance* in this thread. With a >> direct dependency you can easily use message passing pattern - but you >> loose the loose coupling cause you need to know until which level you >> unwrap, think t principal case which has 2-3 proxies!. However in practice >> you have a lot of undirect dependencies, in particular with enterprise >> concerns (auditing, security...) so you can't really do it easily/naturally. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Bonus: >> >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an >> existing context in a thread - wrappers doing it on a >> Runnable/Consumer/Function/... would be neat. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Question: >> >>>>>>>>>>>>> Would CDI handle it in 2.0? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a >> "context context" (its current instances map) in another thread the more >> transparently possible and match the user vision more than a technical >> question for now. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Romain Manni-Bucau >> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>>>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>>>> cdi-dev mailing list >> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/7a9e4109/attachment-0001.html From reza_rahman at lycos.com Tue Mar 8 07:53:51 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 07:53:51 -0500 Subject: [cdi-dev] Fwd: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI References: Message-ID: <91FECF58-2D6C-4608-A861-0794B3F454DD@lycos.com> FYI - more feedback from just another developer that happens to care a great deal about EE. Begin forwarded message: > From: Josh Juneau > Date: March 8, 2016 at 7:41:56 AM EST > To: "users at javaee-spec.java.net" > Subject: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI > Reply-To: users at javaee-spec.java.net > > Reza- > > I am in agreement with you. I agree that CompleteableFuture seems to make more sense for asynchronous events than CompletionStage. Given that it is widely acceptable throughout the platform, and the naming aligns more closely with asynchronous activity...I think CompleteableFuture would be a more consistent and standardized choice. > > Thanks > > Josh Juneau > juneau001 at gmail.com > http://jj-blogger.blogspot.com > https://www.apress.com/index.php/author/author/view/id/1866 > > >> On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman wrote: >> The CDI EG is incorporating the concept of CompletableFuture into asynchronous events. Unfortunately for reasons I really don't see as good they are using it's superinterface CompletionStage instead of CompletableFuture. >> >> I think this is a big ease-of-use mistake as CompletableFuture is designed to be the end user high level gateway API while CompletionStage is mostly as SPI intended for framework writers. >> >> Given that the CompletableFuture concept is pretty widely applicable throughout the platform I think there is a need for consistency, oversight and guidance from the platform expert group. Otherwise I fear less than ideal ad-hoc decisions might be made in this case for CDI and possibly others down the line. >> >> What do you think? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/ec36543e/attachment.html From rmannibucau at gmail.com Tue Mar 8 08:06:54 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 14:06:54 +0100 Subject: [cdi-dev] Fwd: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI In-Reply-To: <91FECF58-2D6C-4608-A861-0794B3F454DD@lycos.com> References: <91FECF58-2D6C-4608-A861-0794B3F454DD@lycos.com> Message-ID: @Reza: can you clarify the behavior of this snippet please: CompletionFuture cf = asyncEvent.fireAsync(...); cf.complete(new AnEvent()); // not deterministic even if the container will likely get false calling complete, should it be ignored? throw an exception? other? That's one point where CompletionStage sounds wiser than CompletionFuture for CDI async events. The javadoc makes the goal clear: "@return a {@link CompletionStage} allowing further pipeline composition on the asynchronous operation.". Using CompletionFuture opens the door to the state manipulation which is not intended (or you have a plan for that?) and which is easily misleading IMHO. CompletionFuture would however make a lot of sense for some parts of EE and to replace @Asynchronous AsyncResult hack cause there you need to handle the state yourself. Both being compatible I see it as a consistent usage of each API. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-08 13:53 GMT+01:00 Reza Rahman : > FYI - more feedback from just another developer that happens to care a > great deal about EE. > > Begin forwarded message: > > *From:* Josh Juneau > *Date:* March 8, 2016 at 7:41:56 AM EST > *To:* "users at javaee-spec.java.net" > *Subject:* *[javaee-spec users] Re: CompletableFuture Usage in the > Platfom vs CDI* > *Reply-To:* users at javaee-spec.java.net > > Reza- > > I am in agreement with you. I agree that CompleteableFuture seems to make > more sense for asynchronous events than CompletionStage. Given that it is > widely acceptable throughout the platform, and the naming aligns more > closely with asynchronous activity...I think CompleteableFuture would be a > more consistent and standardized choice. > > Thanks > > Josh Juneau > juneau001 at gmail.com > http://jj-blogger.blogspot.com > https://www.apress.com/index.php/author/author/view/id/1866 > > > On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman wrote: > >> The CDI EG is incorporating the concept of CompletableFuture into >> asynchronous events. Unfortunately for reasons I really don't see as good >> they are using it's superinterface CompletionStage instead of >> CompletableFuture. >> >> I think this is a big ease-of-use mistake as CompletableFuture is >> designed to be the end user high level gateway API while CompletionStage is >> mostly as SPI intended for framework writers. >> >> Given that the CompletableFuture concept is pretty widely applicable >> throughout the platform I think there is a need for consistency, oversight >> and guidance from the platform expert group. Otherwise I fear less than >> ideal ad-hoc decisions might be made in this case for CDI and possibly >> others down the line. >> >> What do you think? > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/b6163a6b/attachment.html From reza_rahman at lycos.com Tue Mar 8 08:08:02 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 08:08:02 -0500 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: Message-ID: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> I never assume anything related to HTTP requests are ever thread safe. I don't know many folks that would make that assumption either. I think this consideration is not a significant one. The spec, docs and tutorials out there are pretty clear about the fact that none of the CDI scopes are really thread safe in the way EJBs are. > On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau wrote: > > In TomEE we restart/stop it around most of hooks including the runnable passed to start(Runnable) of the AsyncContext but keeping the now widespread ThreadLocal nature of the @RequestScoped (= not the same as the startAsync() call sadly). This passes CDI TCK but for the particular request scope I would be happy to clarify it is actually bound to the request and just reuse the same instances. In term of side effects it would breaks the current thread safety users assume (with reason or not) but I have no real clue if it would really breaks apps or not. > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2016-03-08 13:33 GMT+01:00 Reza Rahman : >> Let's hope some of the implementors weigh in on this some time soon. >> >> I could write some tests on this but I would have no idea if I would have uncovered a bug given the ambiguity of the current spec text. >> >>> On Mar 8, 2016, at 3:16 AM, arjan tijms wrote: >>> >>> Hi, >>> >>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman wrote: >>>> Reading over the CDI spec definition for request scoped beans, I am a tad confused. When are request scoped beans being destroyed right now? Are they just bound to the Servlet request thread and destroyed as soon as the service method returns? >>> >>> In case of a Servlet request (request scoped beans are also tied to other kinds of "requests"), it's indeed not clear. In practice it looks like the moment between the first ServletRequestListener#requestInitialized and ServletRequestListener#requestDestroyed. >>> >>> The exact scope is troublesome for security too, since in most severs the request scope (and session scope and application scope) is active when a SAM is called (the SAM gets an HttpServletRequest after all), but this is not the case in all servers. E.g. in Liberty the RequestScope starts AFTER a SAM is called. >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> >>>> In case of asynchronous Servlets, are they kept around until the real HTTP request actually completes the same way the underlying HTTP connection is kept around? Or is that too difficult because it would require integration at a very low level with the Servlet implementation? >>>> >>>> There's some language around asynchronous completion right now but it's not very clear what actually happens. Does the onComplete, etc asynchronous callback basically create new request scoped instances? >>>> >>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman wrote: >>>> > >>>> > Even in the most conservative reading of this, the spec is clearly not disallowing it. >>>> > >>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg wrote: >>>> >> >>>> >> The question is whether the spec does allow us to do it. And if other containers consequently do it as well. >>>> >> >>>> >> If it does then I will implement it in TomEE. >>>> >> >>>> >> LieGrue, >>>> >> strub >>>> >> >>>> >> >>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman : >>>> >>> >>>> >>> What this is saying is that it is not recommended to use them because of the possible life-cycle mismatch. If they are not supposed to work at all, the specification would have simply stated it won't work. >>>> >>> >>>> >>> Anyway personally I have no reason to further discuss this. I'm going to try to find a way to get this done for developers sooner rather than later. If TomEE does not want to do it, too bad for developers. >>>> >>> >>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau wrote: >>>> >>>> >>>> >>>> " >>>> >>>> Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. >>>> >>>> " >>>> >>>> >>>> >>>> States that the context is not inherited, is that what you mean? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Romain Manni-Bucau >>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>> >>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>> >>>> The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. >>>> >>>> >>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >>>> >>>>> Specifically >>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>> >>>>> No session e.g. , new TX, etc >>>> >>>>> >>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). >>>> >>>>> >>>> >>>>> LieGrue, >>>> >>>>> Strub >>>> >>>>> >>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>>> >>>>>> >>>> >>>>>> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >>>> >>>>>> >>>> >>>>>> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >>>> >>>>>> >>>> >>>>>> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >>>> >>>>>> >>>> >>>>>> John >>>> >>>>>> >>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >>>> >>>>>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >>>> >>>>>> >>>> >>>>>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >>>> >>>>>> >>>> >>>>>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >>>> >>>>>> >>>> >>>>>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >>>> >>>>>> >>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >>>> >>>>>>> >>>> >>>>>>> Reza, >>>> >>>>>>> >>>> >>>>>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>>> >>>>>>> >>>> >>>>>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>> >>>>>>> >>>> >>>>>>> If that's the case, then basically this should work OOTB right? >>>> >>>>>>> >>>> >>>>>>> Task task = new MyTask(); >>>> >>>>>>> task = contextService.createContextualProxy(task, Task.class); >>>> >>>>>>> executor.submit(task); >>>> >>>>>>> >>>> >>>>>>> // now magically the context should be prop'd? >>>> >>>>>>> >>>> >>>>>>> Is that about right? >>>> >>>>>>> >>>> >>>>>>> John >>>> >>>>>>> >>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>> >>>>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>> >>>>>>> >>>> >>>>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>> >>>>>>> >>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>> >>>>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>> >>>>>>>> >>>> >>>>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>> >>>>>>>> >>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>> >>>>>>>>> >>>> >>>>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>> >>>>>>>>> >>>> >>>>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>> >>>>>>>>> >>>> >>>>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>> >>>>>>>>> >>>> >>>>>>>>> John >>>> >>>>>>>>> >>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>> >>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>> >>>>>>>>> >>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>> >>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>> >>>>>>>>>> >>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>> >>>>>>>>>> >>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>> >>>>>>>>>>> >>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> Idea is to give an API to make: >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> public void complete() { >>>> >>>>>>>>>>>> try { >>>> >>>>>>>>>>>> asyncContext.complete(); >>>> >>>>>>>>>>>> } finally { >>>> >>>>>>>>>>>> auditContext.end(); >>>> >>>>>>>>>>>> } >>>> >>>>>>>>>>>> } >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> Romain Manni-Bucau >>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>>> Hi guys, >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> Sample: >>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> Bonus: >>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> Question: >>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>>>>>>>>>>> _______________________________________________ >>>> >>>>>>>>>>>>> cdi-dev mailing list >>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/5ced631f/attachment-0001.html From rmannibucau at gmail.com Tue Mar 8 08:17:06 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 14:17:06 +0100 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: 2016-03-08 14:08 GMT+01:00 Reza Rahman : > I never assume anything related to HTTP requests are ever thread safe. I > don't know many folks that would make that assumption either. I think this > consideration is not a significant one. The spec, docs and tutorials out > there are pretty clear about the fact that none of the CDI scopes are > really thread safe in the way EJBs are. > > It is one of the main usage of request scoped in practise. It doesn't come from HTTP side but since it is used this way in several other places (like batch) it is now assumed everywhere. It has even been promoted by several CDI projects so sadly it is to be taken into account now even if I agree it is not the state we should be at today. If changed - servlet 3.0/3.1 broke several things to make the spec cleaner or more explicit so I guess CDI can work on this - it should be made very explicit in the spec and we should study a "thread local scope" replacement to fill the gap and propose a solution to this practise judged abusive. > On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau > wrote: > > In TomEE we restart/stop it around most of hooks including the runnable > passed to start(Runnable) of the AsyncContext but keeping the now > widespread ThreadLocal nature of the @RequestScoped (= not the same as the > startAsync() call sadly). This passes CDI TCK but for the particular > request scope I would be happy to clarify it is actually bound to the > request and just reuse the same instances. In term of side effects it would > breaks the current thread safety users assume (with reason or not) but I > have no real clue if it would really breaks apps or not. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-08 13:33 GMT+01:00 Reza Rahman : > >> Let's hope some of the implementors weigh in on this some time soon. >> >> I could write some tests on this but I would have no idea if I would have >> uncovered a bug given the ambiguity of the current spec text. >> >> On Mar 8, 2016, at 3:16 AM, arjan tijms wrote: >> >> Hi, >> >> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman >> wrote: >> >>> Reading over the CDI spec definition for request scoped beans, I am a >>> tad confused. When are request scoped beans being destroyed right now? Are >>> they just bound to the Servlet request thread and destroyed as soon as the >>> service method returns? >> >> >> In case of a Servlet request (request scoped beans are also tied to other >> kinds of "requests"), it's indeed not clear. In practice it looks like the >> moment between the first ServletRequestListener#requestInitialized and >> ServletRequestListener#requestDestroyed. >> >> The exact scope is troublesome for security too, since in most severs the >> request scope (and session scope and application scope) is active when a >> SAM is called (the SAM gets an HttpServletRequest after all), but this is >> not the case in all servers. E.g. in Liberty the RequestScope starts AFTER >> a SAM is called. >> >> Kind regards, >> Arjan Tijms >> >> >> >> >>> In case of asynchronous Servlets, are they kept around until the real >>> HTTP request actually completes the same way the underlying HTTP connection >>> is kept around? Or is that too difficult because it would require >>> integration at a very low level with the Servlet implementation? >>> >>> There's some language around asynchronous completion right now but it's >>> not very clear what actually happens. Does the onComplete, etc asynchronous >>> callback basically create new request scoped instances? >>> >>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman >>> wrote: >>> > >>> > Even in the most conservative reading of this, the spec is clearly not >>> disallowing it. >>> > >>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg wrote: >>> >> >>> >> The question is whether the spec does allow us to do it. And if other >>> containers consequently do it as well. >>> >> >>> >> If it does then I will implement it in TomEE. >>> >> >>> >> LieGrue, >>> >> strub >>> >> >>> >> >>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman : >>> >>> >>> >>> What this is saying is that it is not recommended to use them >>> because of the possible life-cycle mismatch. If they are not supposed to >>> work at all, the specification would have simply stated it won't work. >>> >>> >>> >>> Anyway personally I have no reason to further discuss this. I'm >>> going to try to find a way to get this done for developers sooner rather >>> than later. If TomEE does not want to do it, too bad for developers. >>> >>> >>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> >>> >>>> " >>> >>>> Tasks that are submitted to a managed instance of ExecutorService >>> may still be running after the lifecycle of the submitting component. >>> Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or >>> @ConversationScoped are not recommended to use as tasks as it cannot be >>> guaranteed that the tasks will complete before the CDI context is destroyed. >>> >>>> " >>> >>>> >>> >>>> States that the context is not inherited, is that what you mean? >>> >>>> >>> >>>> >>> >>>> >>> >>>> Romain Manni-Bucau >>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>>> >>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>> >>>> The specification currently references pretty much all the major >>> CDI scopes specifically with the issue of propagation and lifecycle in >>> mind. Please see section 2.3. >>> >>>> >>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg >>> wrote: >>> >>>>> Specifically >>> >>>>> The containers mimic ejb for propagation for a good reason! >>> >>>>> No session e.g. , new TX, etc >>> >>>>> >>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so >>> the Request Context not only doesn't get propagated (which is good), but >>> also doesn't get set up (which is crap). >>> >>>>> >>> >>>>> LieGrue, >>> >>>>> Strub >>> >>>>> >>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>> john.d.ament at gmail.com>: >>> >>>>>> >>> >>>>>> I agree, in a sense, with what you're saying. There's nothing in >>> this spec that says it wouldn't be propagated. However, there's nothing in >>> this spec that states clearly that CDI contexts are propagated. >>> >>>>>> >>> >>>>>> If you look at the RI, the RI only seems to propagate transaction >>> state. Considering the age of the spec, I'm not surprised to see that. >>> The worst part is that right now, outside of the ASF, all other EE7 impls >>> seem to be using the RI for concurrency. >>> >>>>>> >>> >>>>>> I'm fairly certain that from this spec's standpoint, the only >>> thing that's actually propagated is the transaction. >>> >>>>>> >>> >>>>>> John >>> >>>>>> >>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman >>> wrote: >>> >>>>>> I am re-reading the spec end to end again right now. So far it >>> seems I have remembered everything correctly. >>> >>>>>> >>> >>>>>> You should read over section 2.3. What it is saying is that a >>> container implementing the Java EE concurrency utilities should ensure >>> whatever contextual information is needed for managed components to work >>> correctly should be propagated automatically. For the correct >>> implementation of CDI scopes, this should also mean any currently active >>> scopes. The section you are referring to is basically implying that >>> thinking that it is possible to use these scoped beans in tasks (albeit not >>> reliably since beans could go out of scope before the thread finishes - for >>> example if the request ends). >>> >>>>>> >>> >>>>>> This does not have anything to do with the context service per >>> se. The context service is an SPI of sorts to allow end user developers to >>> do for their own applications what the container does behind the scenes for >>> managed component context propagation. >>> >>>>>> >>> >>>>>> I'll read over the entire spec to see if there is anything to >>> contradict this. If that's not the case what Romain is describing is most >>> likely an implementation specific bug that did not take into account CDI >>> scope propagation. >>> >>>>>> >>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>> john.d.ament at gmail.com> wrote: >>> >>>>>>> >>> >>>>>>> Reza, >>> >>>>>>> >>> >>>>>>> I read through the concurrency utils spec. Was there a specific >>> section you had in mind? The only references to CDI were near the >>> beginning warning users to not use Request/Session scoped beans as tasks >>> since the outer most context may be destroyed before the work is done. >>> >>>>>>> >>> >>>>>>> I have a feeling what you're referring to is the context >>> service: >>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>> >>>>>>> >>> >>>>>>> If that's the case, then basically this should work OOTB right? >>> >>>>>>> >>> >>>>>>> Task task = new MyTask(); >>> >>>>>>> task = contextService.createContextualProxy(task, Task.class); >>> >>>>>>> executor.submit(task); >>> >>>>>>> >>> >>>>>>> // now magically the context should be prop'd? >>> >>>>>>> >>> >>>>>>> Is that about right? >>> >>>>>>> >>> >>>>>>> John >>> >>>>>>> >>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>> reza_rahman at lycos.com> wrote: >>> >>>>>>> Have you actually looked at the EE concurrency spec text in >>> detail? What does it say about managed component context propagation? >>> >>>>>>> >>> >>>>>>> Without actually doing that further discussing this is just >>> taking shots in the dark. As an implementer it should not surprise you that >>> this might simply be a bug because the person implementing the concurrency >>> utilities for the EE runtime was not told about what to copy over into the >>> new thread for CDI to work correctly. >>> >>>>>>> >>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>> >>>>>>>> As far as I know this is precisely the sort of thing that the >>> EE concurrency spec is intended for. It is supposed to copy over everything >>> from the underlying thread local context into the new thread for all EE >>> managed components to function. Since CDI beans are also EE container >>> managed, it also applies to CDI beans as well. The EE vendor is supposed to >>> make sure this works properly. >>> >>>>>>>> >>> >>>>>>>> I don't think the concurrency utilities specifically lists APIs >>> for which thread context propagation should work. If this doesn't work in a >>> specific implementation it's most likely because they didn't take CDI into >>> account in their own EE concurrency implementation. >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily >>> and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped >>> badly named. So to solve it we would need another scope as I mentionned >>> several times on this list 100% matching servlet instances lifecycles (on a >>> pure CDI side we have the same issue for sessions which are recycled during >>> a request, the session scope is corrupted *by spec* in term of user >>> behavior). >>> >>>>>>>> >>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>> john.d.ament at gmail.com> wrote: >>> >>>>>>>>> >>> >>>>>>>>> The section of the spec you link to makes no references to >>> threads. 6.3 makes some notes about normal scopes and threads, and >>> specifically says that a context is bound to one or more threads. >>> >>>>>>>>> >>> >>>>>>>>> I think what's happened is that over the years, people have >>> simply bound HTTP Request == single thread, but when async processing was >>> introduced no one thought to clarify that the spawning of a child thread >>> from the original HTTP request retains the parent's context. >>> >>>>>>>>> >>> >>>>>>>>> This is another requested feature, but looks more like a bug >>> or gap in the spec. >>> >>>>>>>>> >>> >>>>>>>>> John >>> >>>>>>>>> >>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman >> >: >>> >>>>>>>>> Let's see. I suspect the specification text for EE concurrency >>> is generic enough for implementations to also be able to cover CDI scopes >>> or any other Java EE API context propagation needs. This means the issue >>> needs to be solved at the individual implementation level. Changing >>> anything in the spec is probably just unnecessary ceremony in this case. >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, >>> 2. CDI still prevent it to work since it would violate the spec to >>> propagate it while request scope is bound to another thread ( >>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>> handles async listener but not the main AsyncContext part). >>> >>>>>>>>> >>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman >> >: >>> >>>>>>>>>> This frankly surprises me. I'll check the specification text. >>> This might indeed just be an implementation bug. The EE concurrency >>> utilities are supposed to be copying all relevant context. If this is an >>> issue than it has to be that it is not copying enough of the HTTP request >>> context for CDI to work. >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> The issue is not technical since I got it working but needed >>> to reverse. From my understanding ee concurrency utilities was done in a >>> time CDI was not there so it just ignored it somehow and it hasnt been >>> updated when integrated to the spec. Now with the wording of the CDI - and >>> TCK - it is impossible to make it working since request scope is bound the >>> thre request thread - and not the request. Side note: same applies to >>> session scope and conversation. >>> >>>>>>>>>> >>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here >>> since they implement essentially this whole stack? >>> >>>>>>>>>> >>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>> reza_rahman at lycos.com>: >>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's >>> important to make the case for how likely this is supposed to occur in most >>> business applications. >>> >>>>>>>>>>> >>> >>>>>>>>>>> Also, other than making sure that the executor service is >>> propagating thread local request contexts correctly what other solution are >>> you proposing? Did you check the specification? How sure are you that this >>> isn't simply an implementation bug? >>> >>>>>>>>>>> >>> >>>>>>>>>>> As far as I know the executor service is supposed to be >>> preserving all relevant parts of the EE context? >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the >>> first impl I did then Mark pointed out it was violating CDI spec and >>> request scope definition. There is a kind of contracdiction there cause >>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>> it the opposite way: CDI doesn't provide any way to propagate a context in >>> another thread. Both point of view are valid so we need to see where we >>> tackle it. >>> >>>>>>>>>>> >>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> does >>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Idea is to give an API to make: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> public void complete() { >>> >>>>>>>>>>>> try { >>> >>>>>>>>>>>> asyncContext.complete(); >>> >>>>>>>>>>>> } finally { >>> >>>>>>>>>>>> auditContext.end(); >>> >>>>>>>>>>>> } >>> >>>>>>>>>>>> } >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> working without hacky and almost impossible context pushing >>> (cause of injections nature you are not supposed to know what to push in >>> the context when going async). >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Romain Manni-Bucau >>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>> reza_rahman at lycos.com>: >>> >>>>>>>>>>>> Can you kindly share an annotated code example of the >>> proposed solution so we can all follow and discuss this? >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>> rmannibucau at gmail.com> wroteshar: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>>> Hi guys, >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to >>> inherit a cdi scope. Idea is to follow request scope more than cdi spec >>> allows. First thought it was a concurrency utilities thing but Reza >>> mentionned can be a CDI one so here it is. >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Sample: >>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do >>> some set on it. The i go async (AsyncContext) and trigger a task in another >>> thread. It would be neat - and mandatory in some case by the loose coupling >>> nature of CDI - to get the *same* MyBean *instance* in this thread. With a >>> direct dependency you can easily use message passing pattern - but you >>> loose the loose coupling cause you need to know until which level you >>> unwrap, think t principal case which has 2-3 proxies!. However in practice >>> you have a lot of undirect dependencies, in particular with enterprise >>> concerns (auditing, security...) so you can't really do it easily/naturally. >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Bonus: >>> >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an >>> existing context in a thread - wrappers doing it on a >>> Runnable/Consumer/Function/... would be neat. >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Question: >>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a >>> "context context" (its current instances map) in another thread the more >>> transparently possible and match the user vision more than a technical >>> question for now. >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Romain Manni-Bucau >>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>>>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>>>> cdi-dev mailing list >>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/0817e5f5/attachment-0001.html From reza_rahman at lycos.com Tue Mar 8 08:22:43 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 08:22:43 -0500 Subject: [cdi-dev] [javaee-spec users] Re: Fwd: Re: CompletableFuture Usage in the Platfom vs CDI In-Reply-To: References: <91FECF58-2D6C-4608-A861-0794B3F454DD@lycos.com> Message-ID: I think the JDK team made the right usability call by including everything into CompletableFuture as a one stop shop. That's why the API will probably prove more usable in the end. Can a developer erroneously call complete()? Sure, but it's pretty unlikely since it just doesn't fit the client usage pattern for a promise. And they can make this unlikely error either for @Asynchronous, CDI asynchronous events and pretty much just about anywhere CompletableFuture is used as an API. That said, I've also reached out to the JDK team on this. I hope they will have the time to explain their design motivations themselves and clarify what they would expect from EE or just about anyone else needing to use their APIs. > On Mar 8, 2016, at 8:06 AM, Romain Manni-Bucau wrote: > > @Reza: can you clarify the behavior of this snippet please: > > CompletionFuture cf = asyncEvent.fireAsync(...); > cf.complete(new AnEvent()); // not deterministic even if the container will likely get false calling complete, should it be ignored? throw an exception? other? > > That's one point where CompletionStage sounds wiser than CompletionFuture for CDI async events. The javadoc makes the goal clear: "@return a {@link CompletionStage} allowing further pipeline composition on the asynchronous operation.". Using CompletionFuture opens the door to the state manipulation which is not intended (or you have a plan for that?) and which is easily misleading IMHO. > > CompletionFuture would however make a lot of sense for some parts of EE and to replace @Asynchronous AsyncResult hack cause there you need to handle the state yourself. Both being compatible I see it as a consistent usage of each API. > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2016-03-08 13:53 GMT+01:00 Reza Rahman : >> FYI - more feedback from just another developer that happens to care a great deal about EE. >> >> Begin forwarded message: >> >>> From: Josh Juneau >>> Date: March 8, 2016 at 7:41:56 AM EST >>> To: "users at javaee-spec.java.net" >>> Subject: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI >>> Reply-To: users at javaee-spec.java.net >>> >>> Reza- >>> >>> I am in agreement with you. I agree that CompleteableFuture seems to make more sense for asynchronous events than CompletionStage. Given that it is widely acceptable throughout the platform, and the naming aligns more closely with asynchronous activity...I think CompleteableFuture would be a more consistent and standardized choice. >>> >>> Thanks >>> >>> Josh Juneau >>> juneau001 at gmail.com >>> http://jj-blogger.blogspot.com >>> https://www.apress.com/index.php/author/author/view/id/1866 >>> >>> >>>> On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman wrote: >>>> The CDI EG is incorporating the concept of CompletableFuture into asynchronous events. Unfortunately for reasons I really don't see as good they are using it's superinterface CompletionStage instead of CompletableFuture. >>>> >>>> I think this is a big ease-of-use mistake as CompletableFuture is designed to be the end user high level gateway API while CompletionStage is mostly as SPI intended for framework writers. >>>> >>>> Given that the CompletableFuture concept is pretty widely applicable throughout the platform I think there is a need for consistency, oversight and guidance from the platform expert group. Otherwise I fear less than ideal ad-hoc decisions might be made in this case for CDI and possibly others down the line. >>>> >>>> What do you think? >>> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/a540e44f/attachment.html From rmannibucau at gmail.com Tue Mar 8 08:27:25 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 14:27:25 +0100 Subject: [cdi-dev] [javaee-spec users] Re: Fwd: Re: CompletableFuture Usage in the Platfom vs CDI In-Reply-To: References: <91FECF58-2D6C-4608-A861-0794B3F454DD@lycos.com> Message-ID: 2016-03-08 14:22 GMT+01:00 Reza Rahman : > I think the JDK team made the right usability call by including everything > into CompletableFuture as a one stop shop. That's why the API will probably > prove more usable in the end. > > This is also about choosing the right level of exposed API. > Can a developer erroneously call complete()? Sure, but it's pretty > unlikely since it just doesn't fit the client usage pattern for a promise. > And they can make this unlikely error either for @Asynchronous, CDI > asynchronous events and pretty much just about anywhere CompletableFuture > is used as an API. > > In previous sample I would agree it is a programming error but in a real application you can pass the future through several layers and then it is less obvious (this async event opens a nice and fluent way to trigger an event which is actually your returned data as well: return asyncEvent.fireAsync(myResult);). > That said, I've also reached out to the JDK team on this. I hope they will > have the time to explain their design motivations themselves and clarify > what they would expect from EE or just about anyone else needing to use > their APIs. > > Thanks > On Mar 8, 2016, at 8:06 AM, Romain Manni-Bucau > wrote: > > @Reza: can you clarify the behavior of this snippet please: > > CompletionFuture cf = asyncEvent.fireAsync(...); > cf.complete(new AnEvent()); // not deterministic even if the container > will likely get false calling complete, should it be ignored? throw an > exception? other? > > That's one point where CompletionStage sounds wiser than CompletionFuture > for CDI async events. The javadoc makes the goal clear: "@return a {@link > CompletionStage} allowing further pipeline composition on the asynchronous > operation.". Using CompletionFuture opens the door to the state > manipulation which is not intended (or you have a plan for that?) and which > is easily misleading IMHO. > > CompletionFuture would however make a lot of sense for some parts of EE > and to replace @Asynchronous AsyncResult hack cause there you need to > handle the state yourself. Both being compatible I see it as a consistent > usage of each API. > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-08 13:53 GMT+01:00 Reza Rahman : > >> FYI - more feedback from just another developer that happens to care a >> great deal about EE. >> >> Begin forwarded message: >> >> *From:* Josh Juneau >> *Date:* March 8, 2016 at 7:41:56 AM EST >> *To:* "users at javaee-spec.java.net" >> *Subject:* *[javaee-spec users] Re: CompletableFuture Usage in the >> Platfom vs CDI* >> *Reply-To:* users at javaee-spec.java.net >> >> Reza- >> >> I am in agreement with you. I agree that CompleteableFuture seems to >> make more sense for asynchronous events than CompletionStage. Given that >> it is widely acceptable throughout the platform, and the naming aligns more >> closely with asynchronous activity...I think CompleteableFuture would be a >> more consistent and standardized choice. >> >> Thanks >> >> Josh Juneau >> juneau001 at gmail.com >> http://jj-blogger.blogspot.com >> https://www.apress.com/index.php/author/author/view/id/1866 >> >> >> On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman >> wrote: >> >>> The CDI EG is incorporating the concept of CompletableFuture into >>> asynchronous events. Unfortunately for reasons I really don't see as good >>> they are using it's superinterface CompletionStage instead of >>> CompletableFuture. >>> >>> I think this is a big ease-of-use mistake as CompletableFuture is >>> designed to be the end user high level gateway API while CompletionStage is >>> mostly as SPI intended for framework writers. >>> >>> Given that the CompletableFuture concept is pretty widely applicable >>> throughout the platform I think there is a need for consistency, oversight >>> and guidance from the platform expert group. Otherwise I fear less than >>> ideal ad-hoc decisions might be made in this case for CDI and possibly >>> others down the line. >>> >>> What do you think? >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/018f8816/attachment-0001.html From reza_rahman at lycos.com Tue Mar 8 08:30:14 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 08:30:14 -0500 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: Your mention of thread local scope is interesting indeed. We had just such a scope in Resin called @ThreadScoped, completely separate from @RequestScoped. As memory serves though even in Resin we basically implemented @RequestScoped as thread local scope. > On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau wrote: > > 2016-03-08 14:08 GMT+01:00 Reza Rahman : >> I never assume anything related to HTTP requests are ever thread safe. I don't know many folks that would make that assumption either. I think this consideration is not a significant one. The spec, docs and tutorials out there are pretty clear about the fact that none of the CDI scopes are really thread safe in the way EJBs are. >> > > It is one of the main usage of request scoped in practise. It doesn't come from HTTP side but since it is used this way in several other places (like batch) it is now assumed everywhere. It has even been promoted by several CDI projects so sadly it is to be taken into account now even if I agree it is not the state we should be at today. If changed - servlet 3.0/3.1 broke several things to make the spec cleaner or more explicit so I guess CDI can work on this - it should be made very explicit in the spec and we should study a "thread local scope" replacement to fill the gap and propose a solution to this practise judged abusive. > >>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau wrote: >>> >>> In TomEE we restart/stop it around most of hooks including the runnable passed to start(Runnable) of the AsyncContext but keeping the now widespread ThreadLocal nature of the @RequestScoped (= not the same as the startAsync() call sadly). This passes CDI TCK but for the particular request scope I would be happy to clarify it is actually bound to the request and just reuse the same instances. In term of side effects it would breaks the current thread safety users assume (with reason or not) but I have no real clue if it would really breaks apps or not. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>> Let's hope some of the implementors weigh in on this some time soon. >>>> >>>> I could write some tests on this but I would have no idea if I would have uncovered a bug given the ambiguity of the current spec text. >>>> >>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms wrote: >>>>> >>>>> Hi, >>>>> >>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman wrote: >>>>>> Reading over the CDI spec definition for request scoped beans, I am a tad confused. When are request scoped beans being destroyed right now? Are they just bound to the Servlet request thread and destroyed as soon as the service method returns? >>>>> >>>>> In case of a Servlet request (request scoped beans are also tied to other kinds of "requests"), it's indeed not clear. In practice it looks like the moment between the first ServletRequestListener#requestInitialized and ServletRequestListener#requestDestroyed. >>>>> >>>>> The exact scope is troublesome for security too, since in most severs the request scope (and session scope and application scope) is active when a SAM is called (the SAM gets an HttpServletRequest after all), but this is not the case in all servers. E.g. in Liberty the RequestScope starts AFTER a SAM is called. >>>>> >>>>> Kind regards, >>>>> Arjan Tijms >>>>> >>>>> >>>>> >>>>>> In case of asynchronous Servlets, are they kept around until the real HTTP request actually completes the same way the underlying HTTP connection is kept around? Or is that too difficult because it would require integration at a very low level with the Servlet implementation? >>>>>> >>>>>> There's some language around asynchronous completion right now but it's not very clear what actually happens. Does the onComplete, etc asynchronous callback basically create new request scoped instances? >>>>>> >>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman wrote: >>>>>> > >>>>>> > Even in the most conservative reading of this, the spec is clearly not disallowing it. >>>>>> > >>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg wrote: >>>>>> >> >>>>>> >> The question is whether the spec does allow us to do it. And if other containers consequently do it as well. >>>>>> >> >>>>>> >> If it does then I will implement it in TomEE. >>>>>> >> >>>>>> >> LieGrue, >>>>>> >> strub >>>>>> >> >>>>>> >> >>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman : >>>>>> >>> >>>>>> >>> What this is saying is that it is not recommended to use them because of the possible life-cycle mismatch. If they are not supposed to work at all, the specification would have simply stated it won't work. >>>>>> >>> >>>>>> >>> Anyway personally I have no reason to further discuss this. I'm going to try to find a way to get this done for developers sooner rather than later. If TomEE does not want to do it, too bad for developers. >>>>>> >>> >>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau wrote: >>>>>> >>>> >>>>>> >>>> " >>>>>> >>>> Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. >>>>>> >>>> " >>>>>> >>>> >>>>>> >>>> States that the context is not inherited, is that what you mean? >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> Romain Manni-Bucau >>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>> >>>> >>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>>>> >>>> The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. >>>>>> >>>> >>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >>>>>> >>>>> Specifically >>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>> >>>>> No session e.g. , new TX, etc >>>>>> >>>>> >>>>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). >>>>>> >>>>> >>>>>> >>>>> LieGrue, >>>>>> >>>>> Strub >>>>>> >>>>> >>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>>>>> >>>>>> >>>>>> >>>>>> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >>>>>> >>>>>> >>>>>> >>>>>> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >>>>>> >>>>>> >>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >>>>>> >>>>>> >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >>>>>> >>>>>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >>>>>> >>>>>> >>>>>> >>>>>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >>>>>> >>>>>> >>>>>> >>>>>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >>>>>> >>>>>> >>>>>> >>>>>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >>>>>> >>>>>> >>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >>>>>> >>>>>>> >>>>>> >>>>>>> Reza, >>>>>> >>>>>>> >>>>>> >>>>>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>>>>> >>>>>>> >>>>>> >>>>>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>> >>>>>>> >>>>>> >>>>>>> If that's the case, then basically this should work OOTB right? >>>>>> >>>>>>> >>>>>> >>>>>>> Task task = new MyTask(); >>>>>> >>>>>>> task = contextService.createContextualProxy(task, Task.class); >>>>>> >>>>>>> executor.submit(task); >>>>>> >>>>>>> >>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>> >>>>>>> >>>>>> >>>>>>> Is that about right? >>>>>> >>>>>>> >>>>>> >>>>>>> John >>>>>> >>>>>>> >>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>>>> >>>>>>> >>>>>> >>>>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>>>> >>>>>>> >>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>> >>>>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>> >>>>>>>> >>>>>> >>>>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>>> >>>>>>>> >>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> John >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>> >>>>>>>>> >>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>> >>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> public void complete() { >>>>>> >>>>>>>>>>>> try { >>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>> >>>>>>>>>>>> } finally { >>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>> >>>>>>>>>>>> } >>>>>> >>>>>>>>>>>> } >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Hi guys, >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Sample: >>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Bonus: >>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Question: >>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/dde65dd6/attachment-0001.html From rmannibucau at gmail.com Tue Mar 8 08:33:16 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 14:33:16 +0100 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: will try to not hijack this thread and create another one for thread scope ;). Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-08 14:30 GMT+01:00 Reza Rahman : > Your mention of thread local scope is interesting indeed. We had just such > a scope in Resin called @ThreadScoped, completely separate from > @RequestScoped. As memory serves though even in Resin we basically > implemented @RequestScoped as thread local scope. > > On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau > wrote: > > 2016-03-08 14:08 GMT+01:00 Reza Rahman : > >> I never assume anything related to HTTP requests are ever thread safe. I >> don't know many folks that would make that assumption either. I think this >> consideration is not a significant one. The spec, docs and tutorials out >> there are pretty clear about the fact that none of the CDI scopes are >> really thread safe in the way EJBs are. >> >> > It is one of the main usage of request scoped in practise. It doesn't come > from HTTP side but since it is used this way in several other places (like > batch) it is now assumed everywhere. It has even been promoted by several > CDI projects so sadly it is to be taken into account now even if I agree it > is not the state we should be at today. If changed - servlet 3.0/3.1 broke > several things to make the spec cleaner or more explicit so I guess CDI can > work on this - it should be made very explicit in the spec and we should > study a "thread local scope" replacement to fill the gap and propose a > solution to this practise judged abusive. > > >> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau >> wrote: >> >> In TomEE we restart/stop it around most of hooks including the runnable >> passed to start(Runnable) of the AsyncContext but keeping the now >> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >> startAsync() call sadly). This passes CDI TCK but for the particular >> request scope I would be happy to clarify it is actually bound to the >> request and just reuse the same instances. In term of side effects it would >> breaks the current thread safety users assume (with reason or not) but I >> have no real clue if it would really breaks apps or not. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >> >>> Let's hope some of the implementors weigh in on this some time soon. >>> >>> I could write some tests on this but I would have no idea if I would >>> have uncovered a bug given the ambiguity of the current spec text. >>> >>> On Mar 8, 2016, at 3:16 AM, arjan tijms wrote: >>> >>> Hi, >>> >>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman >>> wrote: >>> >>>> Reading over the CDI spec definition for request scoped beans, I am a >>>> tad confused. When are request scoped beans being destroyed right now? Are >>>> they just bound to the Servlet request thread and destroyed as soon as the >>>> service method returns? >>> >>> >>> In case of a Servlet request (request scoped beans are also tied to >>> other kinds of "requests"), it's indeed not clear. In practice it looks >>> like the moment between the first ServletRequestListener#requestInitialized >>> and ServletRequestListener#requestDestroyed. >>> >>> The exact scope is troublesome for security too, since in most severs >>> the request scope (and session scope and application scope) is active when >>> a SAM is called (the SAM gets an HttpServletRequest after all), but this is >>> not the case in all servers. E.g. in Liberty the RequestScope starts AFTER >>> a SAM is called. >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> >>> >>>> In case of asynchronous Servlets, are they kept around until the real >>>> HTTP request actually completes the same way the underlying HTTP connection >>>> is kept around? Or is that too difficult because it would require >>>> integration at a very low level with the Servlet implementation? >>>> >>>> There's some language around asynchronous completion right now but it's >>>> not very clear what actually happens. Does the onComplete, etc asynchronous >>>> callback basically create new request scoped instances? >>>> >>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman >>>> wrote: >>>> > >>>> > Even in the most conservative reading of this, the spec is clearly >>>> not disallowing it. >>>> > >>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg >>>> wrote: >>>> >> >>>> >> The question is whether the spec does allow us to do it. And if >>>> other containers consequently do it as well. >>>> >> >>>> >> If it does then I will implement it in TomEE. >>>> >> >>>> >> LieGrue, >>>> >> strub >>>> >> >>>> >> >>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman : >>>> >>> >>>> >>> What this is saying is that it is not recommended to use them >>>> because of the possible life-cycle mismatch. If they are not supposed to >>>> work at all, the specification would have simply stated it won't work. >>>> >>> >>>> >>> Anyway personally I have no reason to further discuss this. I'm >>>> going to try to find a way to get this done for developers sooner rather >>>> than later. If TomEE does not want to do it, too bad for developers. >>>> >>> >>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>> >>>> >>>> " >>>> >>>> Tasks that are submitted to a managed instance of ExecutorService >>>> may still be running after the lifecycle of the submitting component. >>>> Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or >>>> @ConversationScoped are not recommended to use as tasks as it cannot be >>>> guaranteed that the tasks will complete before the CDI context is destroyed. >>>> >>>> " >>>> >>>> >>>> >>>> States that the context is not inherited, is that what you mean? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Romain Manni-Bucau >>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>> >>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>> >>>> The specification currently references pretty much all the major >>>> CDI scopes specifically with the issue of propagation and lifecycle in >>>> mind. Please see section 2.3. >>>> >>>> >>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg >>>> wrote: >>>> >>>>> Specifically >>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>> >>>>> No session e.g. , new TX, etc >>>> >>>>> >>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so >>>> the Request Context not only doesn't get propagated (which is good), but >>>> also doesn't get set up (which is crap). >>>> >>>>> >>>> >>>>> LieGrue, >>>> >>>>> Strub >>>> >>>>> >>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>> john.d.ament at gmail.com>: >>>> >>>>>> >>>> >>>>>> I agree, in a sense, with what you're saying. There's nothing >>>> in this spec that says it wouldn't be propagated. However, there's nothing >>>> in this spec that states clearly that CDI contexts are propagated. >>>> >>>>>> >>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>> transaction state. Considering the age of the spec, I'm not surprised to >>>> see that. The worst part is that right now, outside of the ASF, all other >>>> EE7 impls seem to be using the RI for concurrency. >>>> >>>>>> >>>> >>>>>> I'm fairly certain that from this spec's standpoint, the only >>>> thing that's actually propagated is the transaction. >>>> >>>>>> >>>> >>>>>> John >>>> >>>>>> >>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>> reza_rahman at lycos.com> wrote: >>>> >>>>>> I am re-reading the spec end to end again right now. So far it >>>> seems I have remembered everything correctly. >>>> >>>>>> >>>> >>>>>> You should read over section 2.3. What it is saying is that a >>>> container implementing the Java EE concurrency utilities should ensure >>>> whatever contextual information is needed for managed components to work >>>> correctly should be propagated automatically. For the correct >>>> implementation of CDI scopes, this should also mean any currently active >>>> scopes. The section you are referring to is basically implying that >>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>> reliably since beans could go out of scope before the thread finishes - for >>>> example if the request ends). >>>> >>>>>> >>>> >>>>>> This does not have anything to do with the context service per >>>> se. The context service is an SPI of sorts to allow end user developers to >>>> do for their own applications what the container does behind the scenes for >>>> managed component context propagation. >>>> >>>>>> >>>> >>>>>> I'll read over the entire spec to see if there is anything to >>>> contradict this. If that's not the case what Romain is describing is most >>>> likely an implementation specific bug that did not take into account CDI >>>> scope propagation. >>>> >>>>>> >>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>> john.d.ament at gmail.com> wrote: >>>> >>>>>>> >>>> >>>>>>> Reza, >>>> >>>>>>> >>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>> specific section you had in mind? The only references to CDI were near the >>>> beginning warning users to not use Request/Session scoped beans as tasks >>>> since the outer most context may be destroyed before the work is done. >>>> >>>>>>> >>>> >>>>>>> I have a feeling what you're referring to is the context >>>> service: >>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>> >>>>>>> >>>> >>>>>>> If that's the case, then basically this should work OOTB right? >>>> >>>>>>> >>>> >>>>>>> Task task = new MyTask(); >>>> >>>>>>> task = contextService.createContextualProxy(task, Task.class); >>>> >>>>>>> executor.submit(task); >>>> >>>>>>> >>>> >>>>>>> // now magically the context should be prop'd? >>>> >>>>>>> >>>> >>>>>>> Is that about right? >>>> >>>>>>> >>>> >>>>>>> John >>>> >>>>>>> >>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>> reza_rahman at lycos.com> wrote: >>>> >>>>>>> Have you actually looked at the EE concurrency spec text in >>>> detail? What does it say about managed component context propagation? >>>> >>>>>>> >>>> >>>>>>> Without actually doing that further discussing this is just >>>> taking shots in the dark. As an implementer it should not surprise you that >>>> this might simply be a bug because the person implementing the concurrency >>>> utilities for the EE runtime was not told about what to copy over into the >>>> new thread for CDI to work correctly. >>>> >>>>>>> >>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman >>> >: >>>> >>>>>>>> As far as I know this is precisely the sort of thing that the >>>> EE concurrency spec is intended for. It is supposed to copy over everything >>>> from the underlying thread local context into the new thread for all EE >>>> managed components to function. Since CDI beans are also EE container >>>> managed, it also applies to CDI beans as well. The EE vendor is supposed to >>>> make sure this works properly. >>>> >>>>>>>> >>>> >>>>>>>> I don't think the concurrency utilities specifically lists >>>> APIs for which thread context propagation should work. If this doesn't work >>>> in a specific implementation it's most likely because they didn't take CDI >>>> into account in their own EE concurrency implementation. >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite >>>> easily and @RequestScoped which is *used* today is sadly a >>>> @ThreadLocalScoped badly named. So to solve it we would need another scope >>>> as I mentionned several times on this list 100% matching servlet instances >>>> lifecycles (on a pure CDI side we have the same issue for sessions which >>>> are recycled during a request, the session scope is corrupted *by spec* in >>>> term of user behavior). >>>> >>>>>>>> >>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>>> john.d.ament at gmail.com> wrote: >>>> >>>>>>>>> >>>> >>>>>>>>> The section of the spec you link to makes no references to >>>> threads. 6.3 makes some notes about normal scopes and threads, and >>>> specifically says that a context is bound to one or more threads. >>>> >>>>>>>>> >>>> >>>>>>>>> I think what's happened is that over the years, people have >>>> simply bound HTTP Request == single thread, but when async processing was >>>> introduced no one thought to clarify that the spawning of a child thread >>>> from the original HTTP request retains the parent's context. >>>> >>>>>>>>> >>>> >>>>>>>>> This is another requested feature, but looks more like a bug >>>> or gap in the spec. >>>> >>>>>>>>> >>>> >>>>>>>>> John >>>> >>>>>>>>> >>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman >>> >: >>>> >>>>>>>>> Let's see. I suspect the specification text for EE >>>> concurrency is generic enough for implementations to also be able to cover >>>> CDI scopes or any other Java EE API context propagation needs. This means >>>> the issue needs to be solved at the individual implementation level. >>>> Changing anything in the spec is probably just unnecessary ceremony in this >>>> case. >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" >>>> users, 2. CDI still prevent it to work since it would violate the spec to >>>> propagate it while request scope is bound to another thread ( >>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>> handles async listener but not the main AsyncContext part). >>>> >>>>>>>>> >>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>> reza_rahman at lycos.com>: >>>> >>>>>>>>>> This frankly surprises me. I'll check the specification >>>> text. This might indeed just be an implementation bug. The EE concurrency >>>> utilities are supposed to be copying all relevant context. If this is an >>>> issue than it has to be that it is not copying enough of the HTTP request >>>> context for CDI to work. >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> The issue is not technical since I got it working but needed >>>> to reverse. From my understanding ee concurrency utilities was done in a >>>> time CDI was not there so it just ignored it somehow and it hasnt been >>>> updated when integrated to the spec. Now with the wording of the CDI - and >>>> TCK - it is impossible to make it working since request scope is bound the >>>> thre request thread - and not the request. Side note: same applies to >>>> session scope and conversation. >>>> >>>>>>>>>> >>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here >>>> since they implement essentially this whole stack? >>>> >>>>>>>>>> >>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>> reza_rahman at lycos.com>: >>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's >>>> important to make the case for how likely this is supposed to occur in most >>>> business applications. >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> Also, other than making sure that the executor service is >>>> propagating thread local request contexts correctly what other solution are >>>> you proposing? Did you check the specification? How sure are you that this >>>> isn't simply an implementation bug? >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> As far as I know the executor service is supposed to be >>>> preserving all relevant parts of the EE context? >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the >>>> first impl I did then Mark pointed out it was violating CDI spec and >>>> request scope definition. There is a kind of contracdiction there cause >>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>> another thread. Both point of view are valid so we need to see where we >>>> tackle it. >>>> >>>>>>>>>>> >>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> does >>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> Idea is to give an API to make: >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> public void complete() { >>>> >>>>>>>>>>>> try { >>>> >>>>>>>>>>>> asyncContext.complete(); >>>> >>>>>>>>>>>> } finally { >>>> >>>>>>>>>>>> auditContext.end(); >>>> >>>>>>>>>>>> } >>>> >>>>>>>>>>>> } >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> working without hacky and almost impossible context >>>> pushing (cause of injections nature you are not supposed to know what to >>>> push in the context when going async). >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> Romain Manni-Bucau >>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>>> reza_rahman at lycos.com>: >>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the >>>> proposed solution so we can all follow and discuss this? >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wroteshar: >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>>> Hi guys, >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to >>>> inherit a cdi scope. Idea is to follow request scope more than cdi spec >>>> allows. First thought it was a concurrency utilities thing but Reza >>>> mentionned can be a CDI one so here it is. >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> Sample: >>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do >>>> some set on it. The i go async (AsyncContext) and trigger a task in another >>>> thread. It would be neat - and mandatory in some case by the loose coupling >>>> nature of CDI - to get the *same* MyBean *instance* in this thread. With a >>>> direct dependency you can easily use message passing pattern - but you >>>> loose the loose coupling cause you need to know until which level you >>>> unwrap, think t principal case which has 2-3 proxies!. However in practice >>>> you have a lot of undirect dependencies, in particular with enterprise >>>> concerns (auditing, security...) so you can't really do it easily/naturally. >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> Bonus: >>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an >>>> existing context in a thread - wrappers doing it on a >>>> Runnable/Consumer/Function/... would be neat. >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> Question: >>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a >>>> "context context" (its current instances map) in another thread the more >>>> transparently possible and match the user vision more than a technical >>>> question for now. >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>>>>>>>>>>> _______________________________________________ >>>> >>>>>>>>>>>>> cdi-dev mailing list >>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/2f23f21c/attachment-0001.html From reza_rahman at lycos.com Tue Mar 8 08:40:13 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 08:40:13 -0500 Subject: [cdi-dev] [javaee-spec users] Re: Fwd: Re: CompletableFuture Usage in the Platfom vs CDI In-Reply-To: References: <91FECF58-2D6C-4608-A861-0794B3F454DD@lycos.com> Message-ID: I think we've managed to devolve into unproductive bickering yet once again today or getting pretty close to it. No matter how many layers you pass a CompletableFuture through, implementation context will always make it clear to the end user it is a promise as far as they are concerned. They would have little reason to call complete(), get() or anything else that is provided as nice API design convenience in CompletableFuture. > On Mar 8, 2016, at 8:27 AM, Romain Manni-Bucau wrote: > > > > 2016-03-08 14:22 GMT+01:00 Reza Rahman : >> I think the JDK team made the right usability call by including everything into CompletableFuture as a one stop shop. That's why the API will probably prove more usable in the end. >> > > This is also about choosing the right level of exposed API. > >> Can a developer erroneously call complete()? Sure, but it's pretty unlikely since it just doesn't fit the client usage pattern for a promise. And they can make this unlikely error either for @Asynchronous, CDI asynchronous events and pretty much just about anywhere CompletableFuture is used as an API. >> > > In previous sample I would agree it is a programming error but in a real application you can pass the future through several layers and then it is less obvious (this async event opens a nice and fluent way to trigger an event which is actually your returned data as well: return asyncEvent.fireAsync(myResult);). > >> That said, I've also reached out to the JDK team on this. I hope they will have the time to explain their design motivations themselves and clarify what they would expect from EE or just about anyone else needing to use their APIs. >> > > Thanks > >>> On Mar 8, 2016, at 8:06 AM, Romain Manni-Bucau wrote: >>> >>> @Reza: can you clarify the behavior of this snippet please: >>> >>> CompletionFuture cf = asyncEvent.fireAsync(...); >>> cf.complete(new AnEvent()); // not deterministic even if the container will likely get false calling complete, should it be ignored? throw an exception? other? >>> >>> That's one point where CompletionStage sounds wiser than CompletionFuture for CDI async events. The javadoc makes the goal clear: "@return a {@link CompletionStage} allowing further pipeline composition on the asynchronous operation.". Using CompletionFuture opens the door to the state manipulation which is not intended (or you have a plan for that?) and which is easily misleading IMHO. >>> >>> CompletionFuture would however make a lot of sense for some parts of EE and to replace @Asynchronous AsyncResult hack cause there you need to handle the state yourself. Both being compatible I see it as a consistent usage of each API. >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2016-03-08 13:53 GMT+01:00 Reza Rahman : >>>> FYI - more feedback from just another developer that happens to care a great deal about EE. >>>> >>>> Begin forwarded message: >>>> >>>>> From: Josh Juneau >>>>> Date: March 8, 2016 at 7:41:56 AM EST >>>>> To: "users at javaee-spec.java.net" >>>>> Subject: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI >>>>> Reply-To: users at javaee-spec.java.net >>>>> >>>>> Reza- >>>>> >>>>> I am in agreement with you. I agree that CompleteableFuture seems to make more sense for asynchronous events than CompletionStage. Given that it is widely acceptable throughout the platform, and the naming aligns more closely with asynchronous activity...I think CompleteableFuture would be a more consistent and standardized choice. >>>>> >>>>> Thanks >>>>> >>>>> Josh Juneau >>>>> juneau001 at gmail.com >>>>> http://jj-blogger.blogspot.com >>>>> https://www.apress.com/index.php/author/author/view/id/1866 >>>>> >>>>> >>>>>> On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman wrote: >>>>>> The CDI EG is incorporating the concept of CompletableFuture into asynchronous events. Unfortunately for reasons I really don't see as good they are using it's superinterface CompletionStage instead of CompletableFuture. >>>>>> >>>>>> I think this is a big ease-of-use mistake as CompletableFuture is designed to be the end user high level gateway API while CompletionStage is mostly as SPI intended for framework writers. >>>>>> >>>>>> Given that the CompletableFuture concept is pretty widely applicable throughout the platform I think there is a need for consistency, oversight and guidance from the platform expert group. Otherwise I fear less than ideal ad-hoc decisions might be made in this case for CDI and possibly others down the line. >>>>>> >>>>>> What do you think? >>>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/65df587e/attachment.html From rmannibucau at gmail.com Tue Mar 8 08:43:10 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 14:43:10 +0100 Subject: [cdi-dev] @ThreadScoped? Message-ID: Hi guys, following request scope thread and to center the discussion on the thread safety part: do we work on this? Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. Questions: - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): JMS ASYNCHONOUS - start/stop API (this is typically an API the user should be able to control for its own threads) - CDI 2.*0*? wdyt? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/5275d46a/attachment.html From rmannibucau at gmail.com Tue Mar 8 08:45:46 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 14:45:46 +0100 Subject: [cdi-dev] [javaee-spec users] Re: Fwd: Re: CompletableFuture Usage in the Platfom vs CDI In-Reply-To: References: <91FECF58-2D6C-4608-A861-0794B3F454DD@lycos.com> Message-ID: For the same reason you don't expose setters in several cases I really think the mutation of an immutable by design result shouldn't be exposed. Code completion being the fastest documentation a user can see, CompletionFuture tends to expose a wrong documentation of the proposed API. 2016-03-08 14:40 GMT+01:00 Reza Rahman : > I think we've managed to devolve into unproductive bickering yet once > again today or getting pretty close to it. > > No matter how many layers you pass a CompletableFuture through, > implementation context will always make it clear to the end user it is a > promise as far as they are concerned. They would have little reason to call > complete(), get() or anything else that is provided as nice API design > convenience in CompletableFuture. > > On Mar 8, 2016, at 8:27 AM, Romain Manni-Bucau > wrote: > > > > 2016-03-08 14:22 GMT+01:00 Reza Rahman : > >> I think the JDK team made the right usability call by including >> everything into CompletableFuture as a one stop shop. That's why the API >> will probably prove more usable in the end. >> >> > This is also about choosing the right level of exposed API. > > >> Can a developer erroneously call complete()? Sure, but it's pretty >> unlikely since it just doesn't fit the client usage pattern for a promise. >> And they can make this unlikely error either for @Asynchronous, CDI >> asynchronous events and pretty much just about anywhere CompletableFuture >> is used as an API. >> >> > In previous sample I would agree it is a programming error but in a real > application you can pass the future through several layers and then it is > less obvious (this async event opens a nice and fluent way to trigger an > event which is actually your returned data as well: return > asyncEvent.fireAsync(myResult);). > > >> That said, I've also reached out to the JDK team on this. I hope they >> will have the time to explain their design motivations themselves and >> clarify what they would expect from EE or just about anyone else needing to >> use their APIs. >> >> > Thanks > > >> On Mar 8, 2016, at 8:06 AM, Romain Manni-Bucau >> wrote: >> >> @Reza: can you clarify the behavior of this snippet please: >> >> CompletionFuture cf = asyncEvent.fireAsync(...); >> cf.complete(new AnEvent()); // not deterministic even if the container >> will likely get false calling complete, should it be ignored? throw an >> exception? other? >> >> That's one point where CompletionStage sounds wiser than CompletionFuture >> for CDI async events. The javadoc makes the goal clear: "@return a >> {@link CompletionStage} allowing further pipeline composition on the >> asynchronous operation.". Using CompletionFuture opens the door to the >> state manipulation which is not intended (or you have a plan for that?) and >> which is easily misleading IMHO. >> >> CompletionFuture would however make a lot of sense for some parts of EE >> and to replace @Asynchronous AsyncResult hack cause there you need to >> handle the state yourself. Both being compatible I see it as a consistent >> usage of each API. >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-03-08 13:53 GMT+01:00 Reza Rahman : >> >>> FYI - more feedback from just another developer that happens to care a >>> great deal about EE. >>> >>> Begin forwarded message: >>> >>> *From:* Josh Juneau >>> *Date:* March 8, 2016 at 7:41:56 AM EST >>> *To:* "users at javaee-spec.java.net" >>> *Subject:* *[javaee-spec users] Re: CompletableFuture Usage in the >>> Platfom vs CDI* >>> *Reply-To:* users at javaee-spec.java.net >>> >>> Reza- >>> >>> I am in agreement with you. I agree that CompleteableFuture seems to >>> make more sense for asynchronous events than CompletionStage. Given that >>> it is widely acceptable throughout the platform, and the naming aligns more >>> closely with asynchronous activity...I think CompleteableFuture would be a >>> more consistent and standardized choice. >>> >>> Thanks >>> >>> Josh Juneau >>> juneau001 at gmail.com >>> http://jj-blogger.blogspot.com >>> https://www.apress.com/index.php/author/author/view/id/1866 >>> >>> >>> On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman >>> wrote: >>> >>>> The CDI EG is incorporating the concept of CompletableFuture into >>>> asynchronous events. Unfortunately for reasons I really don't see as good >>>> they are using it's superinterface CompletionStage instead of >>>> CompletableFuture. >>>> >>>> I think this is a big ease-of-use mistake as CompletableFuture is >>>> designed to be the end user high level gateway API while CompletionStage is >>>> mostly as SPI intended for framework writers. >>>> >>>> Given that the CompletableFuture concept is pretty widely applicable >>>> throughout the platform I think there is a need for consistency, oversight >>>> and guidance from the platform expert group. Otherwise I fear less than >>>> ideal ad-hoc decisions might be made in this case for CDI and possibly >>>> others down the line. >>>> >>>> What do you think? >>> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/e2e7fe03/attachment-0001.html From reza_rahman at lycos.com Tue Mar 8 08:53:13 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 08:53:13 -0500 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: Message-ID: In Resin we added it precisely for these reasons and because it is very useful for framework development as opposed to the Java SE thread local API. We started it whenever a thread starts and destroyed it when the thread ends just like thread local. It keeps things simple and consistent. > On Mar 8, 2016, at 8:43 AM, Romain Manni-Bucau wrote: > > Hi guys, > > following request scope thread and to center the discussion on the thread safety part: do we work on this? > > Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. > > Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. > > Questions: > - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): > > > > > JMS > ASYNCHONOUS > > > > > - start/stop API (this is typically an API the user should be able to control for its own threads) > - CDI 2.*0*? > > wdyt? > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/03947ba8/attachment.html From andraschko.thomas at gmail.com Tue Mar 8 09:08:30 2016 From: andraschko.thomas at gmail.com (Thomas Andraschko) Date: Tue, 8 Mar 2016 15:08:30 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: Message-ID: +1 I also use a own implementation of @ThreadScoped, but currently only via manual start/stop via: ThreadContext.start() or ThreadContext.stop(); If provide something, how will it act in a servlet environment? Will it share the same length as RequestScoped? Threads are reused by Tomcat AFAIR, so actually it would be longer as one request. 2016-03-08 14:53 GMT+01:00 Reza Rahman : > In Resin we added it precisely for these reasons and because it is very > useful for framework development as opposed to the Java SE thread local > API. We started it whenever a thread starts and destroyed it when the > thread ends just like thread local. It keeps things simple and consistent. > > On Mar 8, 2016, at 8:43 AM, Romain Manni-Bucau > wrote: > > Hi guys, > > following request scope thread and to center the discussion on the thread > safety part: do we work on this? > > Background: @RequestScoped is often used as a ThreadLocal instance > solution. A lot of SE or Batch implementations rely on it from what I saw > as well as async implementations reusing existing business logic with this > thread safety constraint. > > Proposal: providing a @ThreadScoped implementation is cheap for CDI and > implemenation and would avoid the headache we can have with @RequestScoped. > Will also remove the quite dark side of the spec regarding servlet request > and request scope since now we would have a more natural solution for all > of these situation so @RequestScoped goals wouldn't collide as much. > > Questions: > - is it automatically started as request scoped is (JMS, @Async, ...)? > Alternative could be some configuration in beans.xml (merged accross the > app): > > > > > JMS > ASYNCHONOUS > > > > > - start/stop API (this is typically an API the user should be able to > control for its own threads) > - CDI 2.*0*? > > wdyt? > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/8f9f21ea/attachment.html From reza_rahman at lycos.com Tue Mar 8 09:10:37 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 09:10:37 -0500 Subject: [cdi-dev] CompletableFuture vs. CompletionStage In-Reply-To: <59B4C96E-D29D-4702-89C3-2D679927F588@lycos.com> References: <9840FA39-0A39-4B81-A26E-100DC297173B@lycos.com> <59B4C96E-D29D-4702-89C3-2D679927F588@lycos.com> Message-ID: One of the SE folks just pointed me to this: http://cs.oswego.edu/pipermail/concurrency-interest/2015-January/013600.html. They are already working on allowing subclasses that change the default executor. If I get more feedback from them I will pass it on here. > On Mar 8, 2016, at 7:19 AM, Reza Rahman wrote: > > FYI I am running a survey on this issue: https://twitter.com/reza_rahman/status/707035213717774336. If you really are open to feedback, I suggest keeping an eye there. When it is done, it is possible I will blog about this if it is clear this is a going to be a problem. In the least people will hopefully have that as a resource when they are confused. > > The reality is that everyone has limited time. I can provide feedback when I can provide feedback for any number of personal reasons including whether my employer allows it. It is ultimately up to you to consider it fairly and objectively at all times. If you are failing to do that for any reason before the spec is final it is rather unfortunate for anyone relying on the spec. > > In the end the beauty of all of this is that none of this impacts my livelihood immediately any more. I am just another developer again now. In the end I get to walk over to the Spring camp like everyone else. And thank goodness for that freedom. > > Kindly do not assume I will be spending a lot of time providing you feedback going forward. That was unlikely at all times given my time constraints. You should assume the same for most developers out there. When you get feedback from us, you should consider it in that light. > >> On Mar 8, 2016, at 5:37 AM, Antoine Sabot-Durand wrote: >> >> Answer inline >> >>> Le mar. 8 mars 2016 ? 03:15, Reza Rahman a ?crit : >>> I have forwarded this issue to the Java EE platform EG for review. My inclination now is to simply leave this alone with a final earnest request to kindly think carefully about this before finalizing and getting this into the real world. Please keep in mind that the average developer is not that skilled and looks to resources on the web routinely for answers. All those resources are going to immediately point to CompletableFuture, not some obscure superclass. >> >> CS is not an obscure superclass it's an interface and all methods in CF returns it, so it's impossible to learn CF and ignore CS existence. >> Concurrency is not an easy feature to use, people that think they can cut and paste code from stack overflow without digging in the doc will hit a wall very soon. >> We decided to return a CS to allow advanced user to use it to build async pipeline from here. I guess that the majority of beginners will ignore this returned object (as they would have do it if it had been a CF). >> >>> >>> All I am trying to do is help design an API that is not going to immediately become difficult for the average end developer to understand and use. It's rather unfortunate that I am already feeling fed up in that simple effort to provide feedback. >> >> Reza, feedback is always welcome. But if you don't do it in time you should expect some resistance from the EG who worked a long time (and in an open way) to take these decision. So you need more arguments than "user don't know CS" to make us switch from an interface to an impl, that is not suited for Java EE. >> Feedback on possible technical issues are welcome. >> >>> >>> Anyway I am now basically done with this. Unfortunately I have far more urgent matters for Java EE 7 and Java EE 8 to deal with. If I have time I'll look at some more of the CDI 2 work and provide feedback if I can manage time. >> >> Again it's welcome. We are about to discuss a programmatic APi for SE boot. Your input will be precious here. >> >>> >>>> On Mar 7, 2016, at 2:53 PM, Reza Rahman wrote: >>>> Argue >>>> Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. >>>> >>>> As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? >>>> >>>> Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API. >>>> >>>>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau wrote: >>>>> >>>>> >>>>> 2016-03-07 20:35 GMT+01:00 Reza Rahman : >>>>>> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. >>>>>> >>>>>> Basically this means CompletableFutures are already pretty Java EE ready. >>>>>> >>>>>> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? >>>>> >>>>> Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. >>>>> >>>>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman wrote: >>>>>>> >>>>>>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. >>>>>>> >>>>>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba : >>>>>>>>> >>>>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >>>>>>>>>> >>>>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" >>>>>>>>> > a ?crit : >>>>>>>>>> > >>>>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >>>>>>>>>> > >>>>>>>>>> >> Hi guys, >>>>>>>>>> >> >>>>>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >>>>>>>>>> >> can we move back to CompletionFuture? >>>>>>>>>> >> >>>>>>>>>> >> It would allow for instance: >>>>>>>>>> >> >>>>>>>>>> >> // doesn't work with CompletionStage >>>>>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >>>>>>>>>> >> .then(...) >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > Well, this should work if the underlying CompletionStage impl >>>>>>>>>> supports toCompletableFuture(), i.e. in Weld 3: >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> Yes but it is not natural to convert it IMO = we can do better >>>>>>>>>> >>>>>>>>>> > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >>>>>>>>>> event2.fireAsync(...).toCompletableFuture()) >>>>>>>>>> > >>>>>>>>>> > AFAIK the default async execution facility of CompletableFuture is >>>>>>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the >>>>>>>>>> CompletionStage interface allows us to wrap the async calls without the >>>>>>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function>>>>>>>>> T, ? extends U>)) and supply a default one provided by the impl. >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> Should use the pool in which the evznt is fired then "then step" is >>>>>>>>>> synchronous is my sample so all is decided at fire time >>>>>>>>> >>>>>>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >>>>>>>> >>>>>>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). >>>>>>>> >>>>>>>> That said I agree on the state switching the pool is better but with these 2 notes: >>>>>>>> >>>>>>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools >>>>>>>> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >>>>>>>> >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> >> >>>>>>>>>> >> Romain Manni-Bucau >>>>>>>>>> >> @rmannibucau | Blog >>>>>>>>>> >> | Github >>>>>>>>>> >> | LinkedIn >>>>>>>>>> >> | Tomitriber >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> _______________________________________________ >>>>>>>>>> >> cdi-dev mailing list >>>>>>>>>> >> cdi-dev at 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 >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Martin Kouba >>>>>>>>> Software Engineer >>>>>>>>> Red Hat, Czech Republic >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/dd2b3913/attachment-0001.html From rmannibucau at gmail.com Tue Mar 8 09:18:02 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 15:18:02 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: Message-ID: 2016-03-08 15:08 GMT+01:00 Thomas Andraschko : > +1 > > I also use a own implementation of @ThreadScoped, but currently only via > manual start/stop via: ThreadContext.start() or ThreadContext.stop(); > > If provide something, how will it act in a servlet environment? Will it > share the same length as RequestScoped? > Threads are reused by Tomcat AFAIR, so actually it would be longer as one > request. > > Fair point so we have 2 scopes actually: - ThreadScoped - TaskScoped (guess most of people will understand the first one as this one so we need another name) Originally I was only thinking to the second one (ie one available during a task which can be started/stopped implicitely - see my first question - or manually by the user). ThreadScoped is however really harder to get right I think cause of the numerous pools EE has so it can probably be a EE defined scope but at CDI level I think tackling TaskScoped is easier to start. wdyt? > 2016-03-08 14:53 GMT+01:00 Reza Rahman : > >> In Resin we added it precisely for these reasons and because it is very >> useful for framework development as opposed to the Java SE thread local >> API. We started it whenever a thread starts and destroyed it when the >> thread ends just like thread local. It keeps things simple and consistent. >> >> On Mar 8, 2016, at 8:43 AM, Romain Manni-Bucau >> wrote: >> >> Hi guys, >> >> following request scope thread and to center the discussion on the thread >> safety part: do we work on this? >> >> Background: @RequestScoped is often used as a ThreadLocal instance >> solution. A lot of SE or Batch implementations rely on it from what I saw >> as well as async implementations reusing existing business logic with this >> thread safety constraint. >> >> Proposal: providing a @ThreadScoped implementation is cheap for CDI and >> implemenation and would avoid the headache we can have with @RequestScoped. >> Will also remove the quite dark side of the spec regarding servlet request >> and request scope since now we would have a more natural solution for all >> of these situation so @RequestScoped goals wouldn't collide as much. >> >> Questions: >> - is it automatically started as request scoped is (JMS, @Async, ...)? >> Alternative could be some configuration in beans.xml (merged accross the >> app): >> >> >> >> >> JMS >> ASYNCHONOUS >> >> >> >> >> - start/stop API (this is typically an API the user should be able to >> control for its own threads) >> - CDI 2.*0*? >> >> wdyt? >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/9823fdbc/attachment.html From reza_rahman at lycos.com Tue Mar 8 09:24:04 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 09:24:04 -0500 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: Message-ID: <6F2EAF53-0FCF-4CA3-BE4A-C7D52C1ADC82@lycos.com> FYI thread instances are also re-used in application server environments via managed thread pools. They are considered started when retrieved from the thread pool and run. They are considered to end when returned back to the thread pool. All this happens transparent to the end user. As far as they are concerned they are simply getting new threads. As a result even with pooling in play the thread scope will always be equal to or shorter than an HTTP request. > On Mar 8, 2016, at 9:08 AM, Thomas Andraschko wrote: > > +1 > > I also use a own implementation of @ThreadScoped, but currently only via manual start/stop via: ThreadContext.start() or ThreadContext.stop(); > > If provide something, how will it act in a servlet environment? Will it share the same length as RequestScoped? > Threads are reused by Tomcat AFAIR, so actually it would be longer as one request. > > 2016-03-08 14:53 GMT+01:00 Reza Rahman : >> In Resin we added it precisely for these reasons and because it is very useful for framework development as opposed to the Java SE thread local API. We started it whenever a thread starts and destroyed it when the thread ends just like thread local. It keeps things simple and consistent. >> >>> On Mar 8, 2016, at 8:43 AM, Romain Manni-Bucau wrote: >>> >>> Hi guys, >>> >>> following request scope thread and to center the discussion on the thread safety part: do we work on this? >>> >>> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. >>> >>> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. >>> >>> Questions: >>> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): >>> >>> >>> >>> >>> JMS >>> ASYNCHONOUS >>> >>> >>> >>> >>> - start/stop API (this is typically an API the user should be able to control for its own threads) >>> - CDI 2.*0*? >>> >>> wdyt? >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/e43ac958/attachment.html From issues at jboss.org Tue Mar 8 10:13:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 8 Mar 2016 10:13:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-586) Add spec text for new Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-586 started by Antoine Sabot-Durand. ------------------------------------------------ > Add spec text for new Literals > ------------------------------ > > Key: CDI-586 > URL: https://issues.jboss.org/browse/CDI-586 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > CDI-485 introduced literals in the API. We should add some information about them in the spec as well -- This message was sent by Atlassian JIRA (v6.4.11#64026) From stephan at knitelius.com Tue Mar 8 10:21:44 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Tue, 08 Mar 2016 15:21:44 +0000 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: So the proposal would be to enable propagation of request scope to asynchronous threads and keep it alive until all concurrent processes referencing it are completed? On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau wrote: > will try to not hijack this thread and create another one for thread scope > ;). > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-08 14:30 GMT+01:00 Reza Rahman : > >> Your mention of thread local scope is interesting indeed. We had just >> such a scope in Resin called @ThreadScoped, completely separate from >> @RequestScoped. As memory serves though even in Resin we basically >> implemented @RequestScoped as thread local scope. >> >> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau >> wrote: >> >> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >> >>> I never assume anything related to HTTP requests are ever thread safe. I >>> don't know many folks that would make that assumption either. I think this >>> consideration is not a significant one. The spec, docs and tutorials out >>> there are pretty clear about the fact that none of the CDI scopes are >>> really thread safe in the way EJBs are. >>> >>> >> It is one of the main usage of request scoped in practise. It doesn't >> come from HTTP side but since it is used this way in several other places >> (like batch) it is now assumed everywhere. It has even been promoted by >> several CDI projects so sadly it is to be taken into account now even if I >> agree it is not the state we should be at today. If changed - servlet >> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I >> guess CDI can work on this - it should be made very explicit in the spec >> and we should study a "thread local scope" replacement to fill the gap and >> propose a solution to this practise judged abusive. >> >> >>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau >>> wrote: >>> >>> In TomEE we restart/stop it around most of hooks including the runnable >>> passed to start(Runnable) of the AsyncContext but keeping the now >>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >>> startAsync() call sadly). This passes CDI TCK but for the particular >>> request scope I would be happy to clarify it is actually bound to the >>> request and just reuse the same instances. In term of side effects it would >>> breaks the current thread safety users assume (with reason or not) but I >>> have no real clue if it would really breaks apps or not. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>> >>>> Let's hope some of the implementors weigh in on this some time soon. >>>> >>>> I could write some tests on this but I would have no idea if I would >>>> have uncovered a bug given the ambiguity of the current spec text. >>>> >>>> On Mar 8, 2016, at 3:16 AM, arjan tijms wrote: >>>> >>>> Hi, >>>> >>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman >>>> wrote: >>>> >>>>> Reading over the CDI spec definition for request scoped beans, I am a >>>>> tad confused. When are request scoped beans being destroyed right now? Are >>>>> they just bound to the Servlet request thread and destroyed as soon as the >>>>> service method returns? >>>> >>>> >>>> In case of a Servlet request (request scoped beans are also tied to >>>> other kinds of "requests"), it's indeed not clear. In practice it looks >>>> like the moment between the first ServletRequestListener#requestInitialized >>>> and ServletRequestListener#requestDestroyed. >>>> >>>> The exact scope is troublesome for security too, since in most severs >>>> the request scope (and session scope and application scope) is active when >>>> a SAM is called (the SAM gets an HttpServletRequest after all), but this is >>>> not the case in all servers. E.g. in Liberty the RequestScope starts AFTER >>>> a SAM is called. >>>> >>>> Kind regards, >>>> Arjan Tijms >>>> >>>> >>>> >>>> >>>>> In case of asynchronous Servlets, are they kept around until the real >>>>> HTTP request actually completes the same way the underlying HTTP connection >>>>> is kept around? Or is that too difficult because it would require >>>>> integration at a very low level with the Servlet implementation? >>>>> >>>>> There's some language around asynchronous completion right now but >>>>> it's not very clear what actually happens. Does the onComplete, etc >>>>> asynchronous callback basically create new request scoped instances? >>>>> >>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman >>>>> wrote: >>>>> > >>>>> > Even in the most conservative reading of this, the spec is clearly >>>>> not disallowing it. >>>>> > >>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg >>>>> wrote: >>>>> >> >>>>> >> The question is whether the spec does allow us to do it. And if >>>>> other containers consequently do it as well. >>>>> >> >>>>> >> If it does then I will implement it in TomEE. >>>>> >> >>>>> >> LieGrue, >>>>> >> strub >>>>> >> >>>>> >> >>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman >>>> >: >>>>> >>> >>>>> >>> What this is saying is that it is not recommended to use them >>>>> because of the possible life-cycle mismatch. If they are not supposed to >>>>> work at all, the specification would have simply stated it won't work. >>>>> >>> >>>>> >>> Anyway personally I have no reason to further discuss this. I'm >>>>> going to try to find a way to get this done for developers sooner rather >>>>> than later. If TomEE does not want to do it, too bad for developers. >>>>> >>> >>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>> >>>>> >>>> " >>>>> >>>> Tasks that are submitted to a managed instance of ExecutorService >>>>> may still be running after the lifecycle of the submitting component. >>>>> Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or >>>>> @ConversationScoped are not recommended to use as tasks as it cannot be >>>>> guaranteed that the tasks will complete before the CDI context is destroyed. >>>>> >>>> " >>>>> >>>> >>>>> >>>> States that the context is not inherited, is that what you mean? >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> Romain Manni-Bucau >>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>> >>>> >>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>>> >>>> The specification currently references pretty much all the major >>>>> CDI scopes specifically with the issue of propagation and lifecycle in >>>>> mind. Please see section 2.3. >>>>> >>>> >>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg >>>>> wrote: >>>>> >>>>> Specifically >>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>> >>>>> No session e.g. , new TX, etc >>>>> >>>>> >>>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so >>>>> the Request Context not only doesn't get propagated (which is good), but >>>>> also doesn't get set up (which is crap). >>>>> >>>>> >>>>> >>>>> LieGrue, >>>>> >>>>> Strub >>>>> >>>>> >>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>>> john.d.ament at gmail.com>: >>>>> >>>>>> >>>>> >>>>>> I agree, in a sense, with what you're saying. There's nothing >>>>> in this spec that says it wouldn't be propagated. However, there's nothing >>>>> in this spec that states clearly that CDI contexts are propagated. >>>>> >>>>>> >>>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>>> transaction state. Considering the age of the spec, I'm not surprised to >>>>> see that. The worst part is that right now, outside of the ASF, all other >>>>> EE7 impls seem to be using the RI for concurrency. >>>>> >>>>>> >>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the only >>>>> thing that's actually propagated is the transaction. >>>>> >>>>>> >>>>> >>>>>> John >>>>> >>>>>> >>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>>> reza_rahman at lycos.com> wrote: >>>>> >>>>>> I am re-reading the spec end to end again right now. So far it >>>>> seems I have remembered everything correctly. >>>>> >>>>>> >>>>> >>>>>> You should read over section 2.3. What it is saying is that a >>>>> container implementing the Java EE concurrency utilities should ensure >>>>> whatever contextual information is needed for managed components to work >>>>> correctly should be propagated automatically. For the correct >>>>> implementation of CDI scopes, this should also mean any currently active >>>>> scopes. The section you are referring to is basically implying that >>>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>>> reliably since beans could go out of scope before the thread finishes - for >>>>> example if the request ends). >>>>> >>>>>> >>>>> >>>>>> This does not have anything to do with the context service per >>>>> se. The context service is an SPI of sorts to allow end user developers to >>>>> do for their own applications what the container does behind the scenes for >>>>> managed component context propagation. >>>>> >>>>>> >>>>> >>>>>> I'll read over the entire spec to see if there is anything to >>>>> contradict this. If that's not the case what Romain is describing is most >>>>> likely an implementation specific bug that did not take into account CDI >>>>> scope propagation. >>>>> >>>>>> >>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>>> john.d.ament at gmail.com> wrote: >>>>> >>>>>>> >>>>> >>>>>>> Reza, >>>>> >>>>>>> >>>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>>> specific section you had in mind? The only references to CDI were near the >>>>> beginning warning users to not use Request/Session scoped beans as tasks >>>>> since the outer most context may be destroyed before the work is done. >>>>> >>>>>>> >>>>> >>>>>>> I have a feeling what you're referring to is the context >>>>> service: >>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>> >>>>>>> >>>>> >>>>>>> If that's the case, then basically this should work OOTB right? >>>>> >>>>>>> >>>>> >>>>>>> Task task = new MyTask(); >>>>> >>>>>>> task = contextService.createContextualProxy(task, Task.class); >>>>> >>>>>>> executor.submit(task); >>>>> >>>>>>> >>>>> >>>>>>> // now magically the context should be prop'd? >>>>> >>>>>>> >>>>> >>>>>>> Is that about right? >>>>> >>>>>>> >>>>> >>>>>>> John >>>>> >>>>>>> >>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>>> reza_rahman at lycos.com> wrote: >>>>> >>>>>>> Have you actually looked at the EE concurrency spec text in >>>>> detail? What does it say about managed component context propagation? >>>>> >>>>>>> >>>>> >>>>>>> Without actually doing that further discussing this is just >>>>> taking shots in the dark. As an implementer it should not surprise you that >>>>> this might simply be a bug because the person implementing the concurrency >>>>> utilities for the EE runtime was not told about what to copy over into the >>>>> new thread for CDI to work correctly. >>>>> >>>>>>> >>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman >>>> >: >>>>> >>>>>>>> As far as I know this is precisely the sort of thing that the >>>>> EE concurrency spec is intended for. It is supposed to copy over everything >>>>> from the underlying thread local context into the new thread for all EE >>>>> managed components to function. Since CDI beans are also EE container >>>>> managed, it also applies to CDI beans as well. The EE vendor is supposed to >>>>> make sure this works properly. >>>>> >>>>>>>> >>>>> >>>>>>>> I don't think the concurrency utilities specifically lists >>>>> APIs for which thread context propagation should work. If this doesn't work >>>>> in a specific implementation it's most likely because they didn't take CDI >>>>> into account in their own EE concurrency implementation. >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite >>>>> easily and @RequestScoped which is *used* today is sadly a >>>>> @ThreadLocalScoped badly named. So to solve it we would need another scope >>>>> as I mentionned several times on this list 100% matching servlet instances >>>>> lifecycles (on a pure CDI side we have the same issue for sessions which >>>>> are recycled during a request, the session scope is corrupted *by spec* in >>>>> term of user behavior). >>>>> >>>>>>>> >>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>>>> john.d.ament at gmail.com> wrote: >>>>> >>>>>>>>> >>>>> >>>>>>>>> The section of the spec you link to makes no references to >>>>> threads. 6.3 makes some notes about normal scopes and threads, and >>>>> specifically says that a context is bound to one or more threads. >>>>> >>>>>>>>> >>>>> >>>>>>>>> I think what's happened is that over the years, people have >>>>> simply bound HTTP Request == single thread, but when async processing was >>>>> introduced no one thought to clarify that the spawning of a child thread >>>>> from the original HTTP request retains the parent's context. >>>>> >>>>>>>>> >>>>> >>>>>>>>> This is another requested feature, but looks more like a bug >>>>> or gap in the spec. >>>>> >>>>>>>>> >>>>> >>>>>>>>> John >>>>> >>>>>>>>> >>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman < >>>>> reza_rahman at lycos.com>: >>>>> >>>>>>>>> Let's see. I suspect the specification text for EE >>>>> concurrency is generic enough for implementations to also be able to cover >>>>> CDI scopes or any other Java EE API context propagation needs. This means >>>>> the issue needs to be solved at the individual implementation level. >>>>> Changing anything in the spec is probably just unnecessary ceremony in this >>>>> case. >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" >>>>> users, 2. CDI still prevent it to work since it would violate the spec to >>>>> propagate it while request scope is bound to another thread ( >>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>> handles async listener but not the main AsyncContext part). >>>>> >>>>>>>>> >>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>>> reza_rahman at lycos.com>: >>>>> >>>>>>>>>> This frankly surprises me. I'll check the specification >>>>> text. This might indeed just be an implementation bug. The EE concurrency >>>>> utilities are supposed to be copying all relevant context. If this is an >>>>> issue than it has to be that it is not copying enough of the HTTP request >>>>> context for CDI to work. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> The issue is not technical since I got it working but >>>>> needed to reverse. From my understanding ee concurrency utilities was done >>>>> in a time CDI was not there so it just ignored it somehow and it hasnt been >>>>> updated when integrated to the spec. Now with the wording of the CDI - and >>>>> TCK - it is impossible to make it working since request scope is bound the >>>>> thre request thread - and not the request. Side note: same applies to >>>>> session scope and conversation. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here >>>>> since they implement essentially this whole stack? >>>>> >>>>>>>>>> >>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>>> reza_rahman at lycos.com>: >>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's >>>>> important to make the case for how likely this is supposed to occur in most >>>>> business applications. >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> Also, other than making sure that the executor service is >>>>> propagating thread local request contexts correctly what other solution are >>>>> you proposing? Did you check the specification? How sure are you that this >>>>> isn't simply an implementation bug? >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> As far as I know the executor service is supposed to be >>>>> preserving all relevant parts of the EE context? >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the >>>>> first impl I did then Mark pointed out it was violating CDI spec and >>>>> request scope definition. There is a kind of contracdiction there cause >>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>> another thread. Both point of view are valid so we need to see where we >>>>> tackle it. >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> does >>>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> public void complete() { >>>>> >>>>>>>>>>>> try { >>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>> >>>>>>>>>>>> } finally { >>>>> >>>>>>>>>>>> auditContext.end(); >>>>> >>>>>>>>>>>> } >>>>> >>>>>>>>>>>> } >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> working without hacky and almost impossible context >>>>> pushing (cause of injections nature you are not supposed to know what to >>>>> push in the context when going async). >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>>>> reza_rahman at lycos.com>: >>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the >>>>> proposed solution so we can all follow and discuss this? >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wroteshar: >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>>> Hi guys, >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to >>>>> inherit a cdi scope. Idea is to follow request scope more than cdi spec >>>>> allows. First thought it was a concurrency utilities thing but Reza >>>>> mentionned can be a CDI one so here it is. >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> Sample: >>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do >>>>> some set on it. The i go async (AsyncContext) and trigger a task in another >>>>> thread. It would be neat - and mandatory in some case by the loose coupling >>>>> nature of CDI - to get the *same* MyBean *instance* in this thread. With a >>>>> direct dependency you can easily use message passing pattern - but you >>>>> loose the loose coupling cause you need to know until which level you >>>>> unwrap, think t principal case which has 2-3 proxies!. However in practice >>>>> you have a lot of undirect dependencies, in particular with enterprise >>>>> concerns (auditing, security...) so you can't really do it easily/naturally. >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> Bonus: >>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop >>>>> an existing context in a thread - wrappers doing it on a >>>>> Runnable/Consumer/Function/... would be neat. >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> Question: >>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a >>>>> "context context" (its current instances map) in another thread the more >>>>> transparently possible and match the user vision more than a technical >>>>> question for now. >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>> >>>>>>>>>>>>> _______________________________________________ >>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/6c42d213/attachment-0001.html From issues at jboss.org Tue Mar 8 10:40:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 8 Mar 2016 10:40:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-586) Add spec text for new Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173681#comment-13173681 ] Tomas Remes commented on CDI-586: --------------------------------- I just realized that InjectLiteral could be useful as well (used in TCK). Others which came to our minds (with Martin) could be VetoedLiteral and ObservesLiteral...but that's probably questionable. > Add spec text for new Literals > ------------------------------ > > Key: CDI-586 > URL: https://issues.jboss.org/browse/CDI-586 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > CDI-485 introduced literals in the API. We should add some information about them in the spec as well -- This message was sent by Atlassian JIRA (v6.4.11#64026) From rmannibucau at gmail.com Tue Mar 8 10:47:59 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 16:47:59 +0100 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: Yes (just making clear it is servlet related asynchronism - ie AsyncContext#complete() is called and listeners are completed - to avoid the ambiguity of @Async, JMS etc.. where request scope is now) Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : > > > So the proposal would be to enable propagation of request scope to > asynchronous threads and keep it alive until all concurrent processes > referencing it are completed? > > On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau > wrote: > >> will try to not hijack this thread and create another one for thread >> scope ;). >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >> >>> Your mention of thread local scope is interesting indeed. We had just >>> such a scope in Resin called @ThreadScoped, completely separate from >>> @RequestScoped. As memory serves though even in Resin we basically >>> implemented @RequestScoped as thread local scope. >>> >>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau >>> wrote: >>> >>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>> >>>> I never assume anything related to HTTP requests are ever thread safe. >>>> I don't know many folks that would make that assumption either. I think >>>> this consideration is not a significant one. The spec, docs and tutorials >>>> out there are pretty clear about the fact that none of the CDI scopes are >>>> really thread safe in the way EJBs are. >>>> >>>> >>> It is one of the main usage of request scoped in practise. It doesn't >>> come from HTTP side but since it is used this way in several other places >>> (like batch) it is now assumed everywhere. It has even been promoted by >>> several CDI projects so sadly it is to be taken into account now even if I >>> agree it is not the state we should be at today. If changed - servlet >>> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I >>> guess CDI can work on this - it should be made very explicit in the spec >>> and we should study a "thread local scope" replacement to fill the gap and >>> propose a solution to this practise judged abusive. >>> >>> >>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau >>>> wrote: >>>> >>>> In TomEE we restart/stop it around most of hooks including the runnable >>>> passed to start(Runnable) of the AsyncContext but keeping the now >>>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >>>> startAsync() call sadly). This passes CDI TCK but for the particular >>>> request scope I would be happy to clarify it is actually bound to the >>>> request and just reuse the same instances. In term of side effects it would >>>> breaks the current thread safety users assume (with reason or not) but I >>>> have no real clue if it would really breaks apps or not. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>> >>>>> Let's hope some of the implementors weigh in on this some time soon. >>>>> >>>>> I could write some tests on this but I would have no idea if I would >>>>> have uncovered a bug given the ambiguity of the current spec text. >>>>> >>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms wrote: >>>>> >>>>> Hi, >>>>> >>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman >>>>> wrote: >>>>> >>>>>> Reading over the CDI spec definition for request scoped beans, I am a >>>>>> tad confused. When are request scoped beans being destroyed right now? Are >>>>>> they just bound to the Servlet request thread and destroyed as soon as the >>>>>> service method returns? >>>>> >>>>> >>>>> In case of a Servlet request (request scoped beans are also tied to >>>>> other kinds of "requests"), it's indeed not clear. In practice it looks >>>>> like the moment between the first ServletRequestListener#requestInitialized >>>>> and ServletRequestListener#requestDestroyed. >>>>> >>>>> The exact scope is troublesome for security too, since in most severs >>>>> the request scope (and session scope and application scope) is active when >>>>> a SAM is called (the SAM gets an HttpServletRequest after all), but this is >>>>> not the case in all servers. E.g. in Liberty the RequestScope starts AFTER >>>>> a SAM is called. >>>>> >>>>> Kind regards, >>>>> Arjan Tijms >>>>> >>>>> >>>>> >>>>> >>>>>> In case of asynchronous Servlets, are they kept around until the real >>>>>> HTTP request actually completes the same way the underlying HTTP connection >>>>>> is kept around? Or is that too difficult because it would require >>>>>> integration at a very low level with the Servlet implementation? >>>>>> >>>>>> There's some language around asynchronous completion right now but >>>>>> it's not very clear what actually happens. Does the onComplete, etc >>>>>> asynchronous callback basically create new request scoped instances? >>>>>> >>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman >>>>>> wrote: >>>>>> > >>>>>> > Even in the most conservative reading of this, the spec is clearly >>>>>> not disallowing it. >>>>>> > >>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg >>>>>> wrote: >>>>>> >> >>>>>> >> The question is whether the spec does allow us to do it. And if >>>>>> other containers consequently do it as well. >>>>>> >> >>>>>> >> If it does then I will implement it in TomEE. >>>>>> >> >>>>>> >> LieGrue, >>>>>> >> strub >>>>>> >> >>>>>> >> >>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman >>>>> >: >>>>>> >>> >>>>>> >>> What this is saying is that it is not recommended to use them >>>>>> because of the possible life-cycle mismatch. If they are not supposed to >>>>>> work at all, the specification would have simply stated it won't work. >>>>>> >>> >>>>>> >>> Anyway personally I have no reason to further discuss this. I'm >>>>>> going to try to find a way to get this done for developers sooner rather >>>>>> than later. If TomEE does not want to do it, too bad for developers. >>>>>> >>> >>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wrote: >>>>>> >>>> >>>>>> >>>> " >>>>>> >>>> Tasks that are submitted to a managed instance of >>>>>> ExecutorService may still be running after the lifecycle of the submitting >>>>>> component. Therefore, CDI beans with a scope of @RequestScoped, >>>>>> @SessionScoped, or @ConversationScoped are not recommended to use as tasks >>>>>> as it cannot be guaranteed that the tasks will complete before the CDI >>>>>> context is destroyed. >>>>>> >>>> " >>>>>> >>>> >>>>>> >>>> States that the context is not inherited, is that what you mean? >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> Romain Manni-Bucau >>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>> >>>> >>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>>>> >>>> The specification currently references pretty much all the major >>>>>> CDI scopes specifically with the issue of propagation and lifecycle in >>>>>> mind. Please see section 2.3. >>>>>> >>>> >>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg >>>>>> wrote: >>>>>> >>>>> Specifically >>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>> >>>>> No session e.g. , new TX, etc >>>>>> >>>>> >>>>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, >>>>>> so the Request Context not only doesn't get propagated (which is good), but >>>>>> also doesn't get set up (which is crap). >>>>>> >>>>> >>>>>> >>>>> LieGrue, >>>>>> >>>>> Strub >>>>>> >>>>> >>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>>>> john.d.ament at gmail.com>: >>>>>> >>>>>> >>>>>> >>>>>> I agree, in a sense, with what you're saying. There's nothing >>>>>> in this spec that says it wouldn't be propagated. However, there's nothing >>>>>> in this spec that states clearly that CDI contexts are propagated. >>>>>> >>>>>> >>>>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>>>> transaction state. Considering the age of the spec, I'm not surprised to >>>>>> see that. The worst part is that right now, outside of the ASF, all other >>>>>> EE7 impls seem to be using the RI for concurrency. >>>>>> >>>>>> >>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the only >>>>>> thing that's actually propagated is the transaction. >>>>>> >>>>>> >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>>>> reza_rahman at lycos.com> wrote: >>>>>> >>>>>> I am re-reading the spec end to end again right now. So far it >>>>>> seems I have remembered everything correctly. >>>>>> >>>>>> >>>>>> >>>>>> You should read over section 2.3. What it is saying is that a >>>>>> container implementing the Java EE concurrency utilities should ensure >>>>>> whatever contextual information is needed for managed components to work >>>>>> correctly should be propagated automatically. For the correct >>>>>> implementation of CDI scopes, this should also mean any currently active >>>>>> scopes. The section you are referring to is basically implying that >>>>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>>>> reliably since beans could go out of scope before the thread finishes - for >>>>>> example if the request ends). >>>>>> >>>>>> >>>>>> >>>>>> This does not have anything to do with the context service per >>>>>> se. The context service is an SPI of sorts to allow end user developers to >>>>>> do for their own applications what the container does behind the scenes for >>>>>> managed component context propagation. >>>>>> >>>>>> >>>>>> >>>>>> I'll read over the entire spec to see if there is anything to >>>>>> contradict this. If that's not the case what Romain is describing is most >>>>>> likely an implementation specific bug that did not take into account CDI >>>>>> scope propagation. >>>>>> >>>>>> >>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>>>> john.d.ament at gmail.com> wrote: >>>>>> >>>>>>> >>>>>> >>>>>>> Reza, >>>>>> >>>>>>> >>>>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>>>> specific section you had in mind? The only references to CDI were near the >>>>>> beginning warning users to not use Request/Session scoped beans as tasks >>>>>> since the outer most context may be destroyed before the work is done. >>>>>> >>>>>>> >>>>>> >>>>>>> I have a feeling what you're referring to is the context >>>>>> service: >>>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>> >>>>>>> >>>>>> >>>>>>> If that's the case, then basically this should work OOTB >>>>>> right? >>>>>> >>>>>>> >>>>>> >>>>>>> Task task = new MyTask(); >>>>>> >>>>>>> task = contextService.createContextualProxy(task, Task.class); >>>>>> >>>>>>> executor.submit(task); >>>>>> >>>>>>> >>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>> >>>>>>> >>>>>> >>>>>>> Is that about right? >>>>>> >>>>>>> >>>>>> >>>>>>> John >>>>>> >>>>>>> >>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>>>> reza_rahman at lycos.com> wrote: >>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text in >>>>>> detail? What does it say about managed component context propagation? >>>>>> >>>>>>> >>>>>> >>>>>>> Without actually doing that further discussing this is just >>>>>> taking shots in the dark. As an implementer it should not surprise you that >>>>>> this might simply be a bug because the person implementing the concurrency >>>>>> utilities for the EE runtime was not told about what to copy over into the >>>>>> new thread for CDI to work correctly. >>>>>> >>>>>>> >>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wrote: >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman < >>>>>> reza_rahman at lycos.com>: >>>>>> >>>>>>>> As far as I know this is precisely the sort of thing that >>>>>> the EE concurrency spec is intended for. It is supposed to copy over >>>>>> everything from the underlying thread local context into the new thread for >>>>>> all EE managed components to function. Since CDI beans are also EE >>>>>> container managed, it also applies to CDI beans as well. The EE vendor is >>>>>> supposed to make sure this works properly. >>>>>> >>>>>>>> >>>>>> >>>>>>>> I don't think the concurrency utilities specifically lists >>>>>> APIs for which thread context propagation should work. If this doesn't work >>>>>> in a specific implementation it's most likely because they didn't take CDI >>>>>> into account in their own EE concurrency implementation. >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite >>>>>> easily and @RequestScoped which is *used* today is sadly a >>>>>> @ThreadLocalScoped badly named. So to solve it we would need another scope >>>>>> as I mentionned several times on this list 100% matching servlet instances >>>>>> lifecycles (on a pure CDI side we have the same issue for sessions which >>>>>> are recycled during a request, the session scope is corrupted *by spec* in >>>>>> term of user behavior). >>>>>> >>>>>>>> >>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>>>>> john.d.ament at gmail.com> wrote: >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> The section of the spec you link to makes no references to >>>>>> threads. 6.3 makes some notes about normal scopes and threads, and >>>>>> specifically says that a context is bound to one or more threads. >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> I think what's happened is that over the years, people have >>>>>> simply bound HTTP Request == single thread, but when async processing was >>>>>> introduced no one thought to clarify that the spawning of a child thread >>>>>> from the original HTTP request retains the parent's context. >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> This is another requested feature, but looks more like a >>>>>> bug or gap in the spec. >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> John >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wrote: >>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman < >>>>>> reza_rahman at lycos.com>: >>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE >>>>>> concurrency is generic enough for implementations to also be able to cover >>>>>> CDI scopes or any other Java EE API context propagation needs. This means >>>>>> the issue needs to be solved at the individual implementation level. >>>>>> Changing anything in the spec is probably just unnecessary ceremony in this >>>>>> case. >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" >>>>>> users, 2. CDI still prevent it to work since it would violate the spec to >>>>>> propagate it while request scope is bound to another thread ( >>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>> handles async listener but not the main AsyncContext part). >>>>>> >>>>>>>>> >>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wrote: >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>>>> reza_rahman at lycos.com>: >>>>>> >>>>>>>>>> This frankly surprises me. I'll check the specification >>>>>> text. This might indeed just be an implementation bug. The EE concurrency >>>>>> utilities are supposed to be copying all relevant context. If this is an >>>>>> issue than it has to be that it is not copying enough of the HTTP request >>>>>> context for CDI to work. >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> The issue is not technical since I got it working but >>>>>> needed to reverse. From my understanding ee concurrency utilities was done >>>>>> in a time CDI was not there so it just ignored it somehow and it hasnt been >>>>>> updated when integrated to the spec. Now with the wording of the CDI - and >>>>>> TCK - it is impossible to make it working since request scope is bound the >>>>>> thre request thread - and not the request. Side note: same applies to >>>>>> session scope and conversation. >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here >>>>>> since they implement essentially this whole stack? >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wrote: >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>>>> reza_rahman at lycos.com>: >>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? >>>>>> It's important to make the case for how likely this is supposed to occur in >>>>>> most business applications. >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> Also, other than making sure that the executor service is >>>>>> propagating thread local request contexts correctly what other solution are >>>>>> you proposing? Did you check the specification? How sure are you that this >>>>>> isn't simply an implementation bug? >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to be >>>>>> preserving all relevant parts of the EE context? >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was >>>>>> the first impl I did then Mark pointed out it was violating CDI spec and >>>>>> request scope definition. There is a kind of contracdiction there cause >>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>> another thread. Both point of view are valid so we need to see where we >>>>>> tackle it. >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wrote: >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> does >>>>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> public void complete() { >>>>>> >>>>>>>>>>>> try { >>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>> >>>>>>>>>>>> } finally { >>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>> >>>>>>>>>>>> } >>>>>> >>>>>>>>>>>> } >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> working without hacky and almost impossible context >>>>>> pushing (cause of injections nature you are not supposed to know what to >>>>>> push in the context when going async). >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>>>>> reza_rahman at lycos.com>: >>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the >>>>>> proposed solution so we can all follow and discuss this? >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wroteshar: >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Hi guys, >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to >>>>>> inherit a cdi scope. Idea is to follow request scope more than cdi spec >>>>>> allows. First thought it was a concurrency utilities thing but Reza >>>>>> mentionned can be a CDI one so here it is. >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Sample: >>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do >>>>>> some set on it. The i go async (AsyncContext) and trigger a task in another >>>>>> thread. It would be neat - and mandatory in some case by the loose coupling >>>>>> nature of CDI - to get the *same* MyBean *instance* in this thread. With a >>>>>> direct dependency you can easily use message passing pattern - but you >>>>>> loose the loose coupling cause you need to know until which level you >>>>>> unwrap, think t principal case which has 2-3 proxies!. However in practice >>>>>> you have a lot of undirect dependencies, in particular with enterprise >>>>>> concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Bonus: >>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop >>>>>> an existing context in a thread - wrappers doing it on a >>>>>> Runnable/Consumer/Function/... would be neat. >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Question: >>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a >>>>>> "context context" (its current instances map) in another thread the more >>>>>> transparently possible and match the user vision more than a technical >>>>>> question for now. >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/9bb6a436/attachment-0001.html From stephan at knitelius.com Tue Mar 8 10:55:13 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Tue, 08 Mar 2016 15:55:13 +0000 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: I am not sure I am following you 100%. For me a request is anything which comes into the context of the application. No matter if it comes in via Servlet, WebSockets, JMS, Remote EJB, etc... The request scope should be propagated to all asynchronous operations launched within that call, terminating it when all request associated asynchronous operations are completed. Knitti On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau wrote: > Yes (just making clear it is servlet related asynchronism - ie > AsyncContext#complete() is called and listeners are completed - to avoid > the ambiguity of @Async, JMS etc.. where request scope is now) > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : > >> >> >> So the proposal would be to enable propagation of request scope to >> asynchronous threads and keep it alive until all concurrent processes >> referencing it are completed? >> >> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau >> wrote: >> >>> will try to not hijack this thread and create another one for thread >>> scope ;). >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >>> >>>> Your mention of thread local scope is interesting indeed. We had just >>>> such a scope in Resin called @ThreadScoped, completely separate from >>>> @RequestScoped. As memory serves though even in Resin we basically >>>> implemented @RequestScoped as thread local scope. >>>> >>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau >>>> wrote: >>>> >>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>>> >>>>> I never assume anything related to HTTP requests are ever thread safe. >>>>> I don't know many folks that would make that assumption either. I think >>>>> this consideration is not a significant one. The spec, docs and tutorials >>>>> out there are pretty clear about the fact that none of the CDI scopes are >>>>> really thread safe in the way EJBs are. >>>>> >>>>> >>>> It is one of the main usage of request scoped in practise. It doesn't >>>> come from HTTP side but since it is used this way in several other places >>>> (like batch) it is now assumed everywhere. It has even been promoted by >>>> several CDI projects so sadly it is to be taken into account now even if I >>>> agree it is not the state we should be at today. If changed - servlet >>>> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I >>>> guess CDI can work on this - it should be made very explicit in the spec >>>> and we should study a "thread local scope" replacement to fill the gap and >>>> propose a solution to this practise judged abusive. >>>> >>>> >>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau >>>>> wrote: >>>>> >>>>> In TomEE we restart/stop it around most of hooks including the >>>>> runnable passed to start(Runnable) of the AsyncContext but keeping the now >>>>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >>>>> startAsync() call sadly). This passes CDI TCK but for the particular >>>>> request scope I would be happy to clarify it is actually bound to the >>>>> request and just reuse the same instances. In term of side effects it would >>>>> breaks the current thread safety users assume (with reason or not) but I >>>>> have no real clue if it would really breaks apps or not. >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog >>>>> | Github >>>>> | LinkedIn >>>>> | Tomitriber >>>>> >>>>> >>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>>> >>>>>> Let's hope some of the implementors weigh in on this some time soon. >>>>>> >>>>>> I could write some tests on this but I would have no idea if I would >>>>>> have uncovered a bug given the ambiguity of the current spec text. >>>>>> >>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman >>>>>> wrote: >>>>>> >>>>>>> Reading over the CDI spec definition for request scoped beans, I am >>>>>>> a tad confused. When are request scoped beans being destroyed right now? >>>>>>> Are they just bound to the Servlet request thread and destroyed as soon as >>>>>>> the service method returns? >>>>>> >>>>>> >>>>>> In case of a Servlet request (request scoped beans are also tied to >>>>>> other kinds of "requests"), it's indeed not clear. In practice it looks >>>>>> like the moment between the first ServletRequestListener#requestInitialized >>>>>> and ServletRequestListener#requestDestroyed. >>>>>> >>>>>> The exact scope is troublesome for security too, since in most severs >>>>>> the request scope (and session scope and application scope) is active when >>>>>> a SAM is called (the SAM gets an HttpServletRequest after all), but this is >>>>>> not the case in all servers. E.g. in Liberty the RequestScope starts AFTER >>>>>> a SAM is called. >>>>>> >>>>>> Kind regards, >>>>>> Arjan Tijms >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> In case of asynchronous Servlets, are they kept around until the >>>>>>> real HTTP request actually completes the same way the underlying HTTP >>>>>>> connection is kept around? Or is that too difficult because it would >>>>>>> require integration at a very low level with the Servlet implementation? >>>>>>> >>>>>>> There's some language around asynchronous completion right now but >>>>>>> it's not very clear what actually happens. Does the onComplete, etc >>>>>>> asynchronous callback basically create new request scoped instances? >>>>>>> >>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman >>>>>>> wrote: >>>>>>> > >>>>>>> > Even in the most conservative reading of this, the spec is clearly >>>>>>> not disallowing it. >>>>>>> > >>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg >>>>>>> wrote: >>>>>>> >> >>>>>>> >> The question is whether the spec does allow us to do it. And if >>>>>>> other containers consequently do it as well. >>>>>>> >> >>>>>>> >> If it does then I will implement it in TomEE. >>>>>>> >> >>>>>>> >> LieGrue, >>>>>>> >> strub >>>>>>> >> >>>>>>> >> >>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman < >>>>>>> reza_rahman at lycos.com>: >>>>>>> >>> >>>>>>> >>> What this is saying is that it is not recommended to use them >>>>>>> because of the possible life-cycle mismatch. If they are not supposed to >>>>>>> work at all, the specification would have simply stated it won't work. >>>>>>> >>> >>>>>>> >>> Anyway personally I have no reason to further discuss this. I'm >>>>>>> going to try to find a way to get this done for developers sooner rather >>>>>>> than later. If TomEE does not want to do it, too bad for developers. >>>>>>> >>> >>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>> >>>>>>> >>>> " >>>>>>> >>>> Tasks that are submitted to a managed instance of >>>>>>> ExecutorService may still be running after the lifecycle of the submitting >>>>>>> component. Therefore, CDI beans with a scope of @RequestScoped, >>>>>>> @SessionScoped, or @ConversationScoped are not recommended to use as tasks >>>>>>> as it cannot be guaranteed that the tasks will complete before the CDI >>>>>>> context is destroyed. >>>>>>> >>>> " >>>>>>> >>>> >>>>>>> >>>> States that the context is not inherited, is that what you mean? >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> Romain Manni-Bucau >>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>> >>>> >>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>>>>> >>>> The specification currently references pretty much all the >>>>>>> major CDI scopes specifically with the issue of propagation and lifecycle >>>>>>> in mind. Please see section 2.3. >>>>>>> >>>> >>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg >>>>>>> wrote: >>>>>>> >>>>> Specifically >>>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>>> >>>>> No session e.g. , new TX, etc >>>>>>> >>>>> >>>>>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, >>>>>>> so the Request Context not only doesn't get propagated (which is good), but >>>>>>> also doesn't get set up (which is crap). >>>>>>> >>>>> >>>>>>> >>>>> LieGrue, >>>>>>> >>>>> Strub >>>>>>> >>>>> >>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>>>>> john.d.ament at gmail.com>: >>>>>>> >>>>>> >>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's >>>>>>> nothing in this spec that says it wouldn't be propagated. However, there's >>>>>>> nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>> >>>>>> >>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>>>>> transaction state. Considering the age of the spec, I'm not surprised to >>>>>>> see that. The worst part is that right now, outside of the ASF, all other >>>>>>> EE7 impls seem to be using the RI for concurrency. >>>>>>> >>>>>> >>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the only >>>>>>> thing that's actually propagated is the transaction. >>>>>>> >>>>>> >>>>>>> >>>>>> John >>>>>>> >>>>>> >>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>>>>> reza_rahman at lycos.com> wrote: >>>>>>> >>>>>> I am re-reading the spec end to end again right now. So far >>>>>>> it seems I have remembered everything correctly. >>>>>>> >>>>>> >>>>>>> >>>>>> You should read over section 2.3. What it is saying is that a >>>>>>> container implementing the Java EE concurrency utilities should ensure >>>>>>> whatever contextual information is needed for managed components to work >>>>>>> correctly should be propagated automatically. For the correct >>>>>>> implementation of CDI scopes, this should also mean any currently active >>>>>>> scopes. The section you are referring to is basically implying that >>>>>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>>>>> reliably since beans could go out of scope before the thread finishes - for >>>>>>> example if the request ends). >>>>>>> >>>>>> >>>>>>> >>>>>> This does not have anything to do with the context service >>>>>>> per se. The context service is an SPI of sorts to allow end user developers >>>>>>> to do for their own applications what the container does behind the scenes >>>>>>> for managed component context propagation. >>>>>>> >>>>>> >>>>>>> >>>>>> I'll read over the entire spec to see if there is anything to >>>>>>> contradict this. If that's not the case what Romain is describing is most >>>>>>> likely an implementation specific bug that did not take into account CDI >>>>>>> scope propagation. >>>>>>> >>>>>> >>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>>>>> john.d.ament at gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Reza, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>>>>> specific section you had in mind? The only references to CDI were near the >>>>>>> beginning warning users to not use Request/Session scoped beans as tasks >>>>>>> since the outer most context may be destroyed before the work is done. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I have a feeling what you're referring to is the context >>>>>>> service: >>>>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> If that's the case, then basically this should work OOTB >>>>>>> right? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>> >>>>>>> task = contextService.createContextualProxy(task, >>>>>>> Task.class); >>>>>>> >>>>>>> executor.submit(task); >>>>>>> >>>>>>> >>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is that about right? >>>>>>> >>>>>>> >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>>>>> reza_rahman at lycos.com> wrote: >>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text in >>>>>>> detail? What does it say about managed component context propagation? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Without actually doing that further discussing this is just >>>>>>> taking shots in the dark. As an implementer it should not surprise you that >>>>>>> this might simply be a bug because the person implementing the concurrency >>>>>>> utilities for the EE runtime was not told about what to copy over into the >>>>>>> new thread for CDI to work correctly. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman < >>>>>>> reza_rahman at lycos.com>: >>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing that >>>>>>> the EE concurrency spec is intended for. It is supposed to copy over >>>>>>> everything from the underlying thread local context into the new thread for >>>>>>> all EE managed components to function. Since CDI beans are also EE >>>>>>> container managed, it also applies to CDI beans as well. The EE vendor is >>>>>>> supposed to make sure this works properly. >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> I don't think the concurrency utilities specifically lists >>>>>>> APIs for which thread context propagation should work. If this doesn't work >>>>>>> in a specific implementation it's most likely because they didn't take CDI >>>>>>> into account in their own EE concurrency implementation. >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite >>>>>>> easily and @RequestScoped which is *used* today is sadly a >>>>>>> @ThreadLocalScoped badly named. So to solve it we would need another scope >>>>>>> as I mentionned several times on this list 100% matching servlet instances >>>>>>> lifecycles (on a pure CDI side we have the same issue for sessions which >>>>>>> are recycled during a request, the session scope is corrupted *by spec* in >>>>>>> term of user behavior). >>>>>>> >>>>>>>> >>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>>>>>> john.d.ament at gmail.com> wrote: >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> The section of the spec you link to makes no references to >>>>>>> threads. 6.3 makes some notes about normal scopes and threads, and >>>>>>> specifically says that a context is bound to one or more threads. >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> I think what's happened is that over the years, people >>>>>>> have simply bound HTTP Request == single thread, but when async processing >>>>>>> was introduced no one thought to clarify that the spawning of a child >>>>>>> thread from the original HTTP request retains the parent's context. >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> This is another requested feature, but looks more like a >>>>>>> bug or gap in the spec. >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> John >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman < >>>>>>> reza_rahman at lycos.com>: >>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE >>>>>>> concurrency is generic enough for implementations to also be able to cover >>>>>>> CDI scopes or any other Java EE API context propagation needs. This means >>>>>>> the issue needs to be solved at the individual implementation level. >>>>>>> Changing anything in the spec is probably just unnecessary ceremony in this >>>>>>> case. >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" >>>>>>> users, 2. CDI still prevent it to work since it would violate the spec to >>>>>>> propagate it while request scope is bound to another thread ( >>>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>>> handles async listener but not the main AsyncContext part). >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>>>>> reza_rahman at lycos.com>: >>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the specification >>>>>>> text. This might indeed just be an implementation bug. The EE concurrency >>>>>>> utilities are supposed to be copying all relevant context. If this is an >>>>>>> issue than it has to be that it is not copying enough of the HTTP request >>>>>>> context for CDI to work. >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> The issue is not technical since I got it working but >>>>>>> needed to reverse. From my understanding ee concurrency utilities was done >>>>>>> in a time CDI was not there so it just ignored it somehow and it hasnt been >>>>>>> updated when integrated to the spec. Now with the wording of the CDI - and >>>>>>> TCK - it is impossible to make it working since request scope is bound the >>>>>>> thre request thread - and not the request. Side note: same applies to >>>>>>> session scope and conversation. >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here >>>>>>> since they implement essentially this whole stack? >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>>>>> reza_rahman at lycos.com>: >>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? >>>>>>> It's important to make the case for how likely this is supposed to occur in >>>>>>> most business applications. >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> Also, other than making sure that the executor service >>>>>>> is propagating thread local request contexts correctly what other solution >>>>>>> are you proposing? Did you check the specification? How sure are you that >>>>>>> this isn't simply an implementation bug? >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to be >>>>>>> preserving all relevant parts of the EE context? >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was >>>>>>> the first impl I did then Mark pointed out it was violating CDI spec and >>>>>>> request scope definition. There is a kind of contracdiction there cause >>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>> tackle it. >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> does >>>>>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>> >>>>>>>>>>>> try { >>>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>>> >>>>>>>>>>>> } finally { >>>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>>> >>>>>>>>>>>> } >>>>>>> >>>>>>>>>>>> } >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context >>>>>>> pushing (cause of injections nature you are not supposed to know what to >>>>>>> push in the context when going async). >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>>>>>> reza_rahman at lycos.com>: >>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the >>>>>>> proposed solution so we can all follow and discuss this? >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to >>>>>>> inherit a cdi scope. Idea is to follow request scope more than cdi spec >>>>>>> allows. First thought it was a concurrency utilities thing but Reza >>>>>>> mentionned can be a CDI one so here it is. >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> Sample: >>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I >>>>>>> do some set on it. The i go async (AsyncContext) and trigger a task in >>>>>>> another thread. It would be neat - and mandatory in some case by the loose >>>>>>> coupling nature of CDI - to get the *same* MyBean *instance* in this >>>>>>> thread. With a direct dependency you can easily use message passing pattern >>>>>>> - but you loose the loose coupling cause you need to know until which level >>>>>>> you unwrap, think t principal case which has 2-3 proxies!. However in >>>>>>> practice you have a lot of undirect dependencies, in particular with >>>>>>> enterprise concerns (auditing, security...) so you can't really do it >>>>>>> easily/naturally. >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop >>>>>>> an existing context in a thread - wrappers doing it on a >>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> Question: >>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a >>>>>>> "context context" (its current instances map) in another thread the more >>>>>>> transparently possible and match the user vision more than a technical >>>>>>> question for now. >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/df630750/attachment-0001.html From pbenedict at apache.org Tue Mar 8 11:00:04 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 8 Mar 2016 10:00:04 -0600 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: I agree with Stephan. Since the introduction of asynchronous processing in Servlet 3.1, the 1:1 assumption between request-thread has been removed. A "request" should not be synonymous with a single thread anymore; but the entire request operation. Cheers, Paul On Tue, Mar 8, 2016 at 9:55 AM, Stephan Knitelius wrote: > I am not sure I am following you 100%. > > For me a request is anything which comes into the context of the > application. No matter if it comes in via Servlet, WebSockets, JMS, Remote > EJB, etc... > > The request scope should be propagated to all asynchronous operations > launched within that call, terminating it when all request associated > asynchronous operations are completed. > > Knitti > > > > On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau > wrote: > >> Yes (just making clear it is servlet related asynchronism - ie >> AsyncContext#complete() is called and listeners are completed - to avoid >> the ambiguity of @Async, JMS etc.. where request scope is now) >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : >> >>> >>> >>> So the proposal would be to enable propagation of request scope to >>> asynchronous threads and keep it alive until all concurrent processes >>> referencing it are completed? >>> >>> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau >>> wrote: >>> >>>> will try to not hijack this thread and create another one for thread >>>> scope ;). >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >>>> >>>>> Your mention of thread local scope is interesting indeed. We had just >>>>> such a scope in Resin called @ThreadScoped, completely separate from >>>>> @RequestScoped. As memory serves though even in Resin we basically >>>>> implemented @RequestScoped as thread local scope. >>>>> >>>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau >>>>> wrote: >>>>> >>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>>>> >>>>>> I never assume anything related to HTTP requests are ever thread >>>>>> safe. I don't know many folks that would make that assumption either. I >>>>>> think this consideration is not a significant one. The spec, docs and >>>>>> tutorials out there are pretty clear about the fact that none of the CDI >>>>>> scopes are really thread safe in the way EJBs are. >>>>>> >>>>>> >>>>> It is one of the main usage of request scoped in practise. It doesn't >>>>> come from HTTP side but since it is used this way in several other places >>>>> (like batch) it is now assumed everywhere. It has even been promoted by >>>>> several CDI projects so sadly it is to be taken into account now even if I >>>>> agree it is not the state we should be at today. If changed - servlet >>>>> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I >>>>> guess CDI can work on this - it should be made very explicit in the spec >>>>> and we should study a "thread local scope" replacement to fill the gap and >>>>> propose a solution to this practise judged abusive. >>>>> >>>>> >>>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau >>>>>> wrote: >>>>>> >>>>>> In TomEE we restart/stop it around most of hooks including the >>>>>> runnable passed to start(Runnable) of the AsyncContext but keeping the now >>>>>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >>>>>> startAsync() call sadly). This passes CDI TCK but for the particular >>>>>> request scope I would be happy to clarify it is actually bound to the >>>>>> request and just reuse the same instances. In term of side effects it would >>>>>> breaks the current thread safety users assume (with reason or not) but I >>>>>> have no real clue if it would really breaks apps or not. >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog >>>>>> | Github >>>>>> | LinkedIn >>>>>> | Tomitriber >>>>>> >>>>>> >>>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>>>> >>>>>>> Let's hope some of the implementors weigh in on this some time soon. >>>>>>> >>>>>>> I could write some tests on this but I would have no idea if I would >>>>>>> have uncovered a bug given the ambiguity of the current spec text. >>>>>>> >>>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman >>>>>>> wrote: >>>>>>> >>>>>>>> Reading over the CDI spec definition for request scoped beans, I am >>>>>>>> a tad confused. When are request scoped beans being destroyed right now? >>>>>>>> Are they just bound to the Servlet request thread and destroyed as soon as >>>>>>>> the service method returns? >>>>>>> >>>>>>> >>>>>>> In case of a Servlet request (request scoped beans are also tied to >>>>>>> other kinds of "requests"), it's indeed not clear. In practice it looks >>>>>>> like the moment between the first ServletRequestListener#requestInitialized >>>>>>> and ServletRequestListener#requestDestroyed. >>>>>>> >>>>>>> The exact scope is troublesome for security too, since in most >>>>>>> severs the request scope (and session scope and application scope) is >>>>>>> active when a SAM is called (the SAM gets an HttpServletRequest after all), >>>>>>> but this is not the case in all servers. E.g. in Liberty the RequestScope >>>>>>> starts AFTER a SAM is called. >>>>>>> >>>>>>> Kind regards, >>>>>>> Arjan Tijms >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> In case of asynchronous Servlets, are they kept around until the >>>>>>>> real HTTP request actually completes the same way the underlying HTTP >>>>>>>> connection is kept around? Or is that too difficult because it would >>>>>>>> require integration at a very low level with the Servlet implementation? >>>>>>>> >>>>>>>> There's some language around asynchronous completion right now but >>>>>>>> it's not very clear what actually happens. Does the onComplete, etc >>>>>>>> asynchronous callback basically create new request scoped instances? >>>>>>>> >>>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > Even in the most conservative reading of this, the spec is >>>>>>>> clearly not disallowing it. >>>>>>>> > >>>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg >>>>>>>> wrote: >>>>>>>> >> >>>>>>>> >> The question is whether the spec does allow us to do it. And if >>>>>>>> other containers consequently do it as well. >>>>>>>> >> >>>>>>>> >> If it does then I will implement it in TomEE. >>>>>>>> >> >>>>>>>> >> LieGrue, >>>>>>>> >> strub >>>>>>>> >> >>>>>>>> >> >>>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman < >>>>>>>> reza_rahman at lycos.com>: >>>>>>>> >>> >>>>>>>> >>> What this is saying is that it is not recommended to use them >>>>>>>> because of the possible life-cycle mismatch. If they are not supposed to >>>>>>>> work at all, the specification would have simply stated it won't work. >>>>>>>> >>> >>>>>>>> >>> Anyway personally I have no reason to further discuss this. I'm >>>>>>>> going to try to find a way to get this done for developers sooner rather >>>>>>>> than later. If TomEE does not want to do it, too bad for developers. >>>>>>>> >>> >>>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>> >>>>>>>> >>>> " >>>>>>>> >>>> Tasks that are submitted to a managed instance of >>>>>>>> ExecutorService may still be running after the lifecycle of the submitting >>>>>>>> component. Therefore, CDI beans with a scope of @RequestScoped, >>>>>>>> @SessionScoped, or @ConversationScoped are not recommended to use as tasks >>>>>>>> as it cannot be guaranteed that the tasks will complete before the CDI >>>>>>>> context is destroyed. >>>>>>>> >>>> " >>>>>>>> >>>> >>>>>>>> >>>> States that the context is not inherited, is that what you >>>>>>>> mean? >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> Romain Manni-Bucau >>>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>> >>>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>>>>>> >>>> The specification currently references pretty much all the >>>>>>>> major CDI scopes specifically with the issue of propagation and lifecycle >>>>>>>> in mind. Please see section 2.3. >>>>>>>> >>>> >>>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg >>>>>>>> wrote: >>>>>>>> >>>>> Specifically >>>>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>>>> >>>>> No session e.g. , new TX, etc >>>>>>>> >>>>> >>>>>>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, >>>>>>>> so the Request Context not only doesn't get propagated (which is good), but >>>>>>>> also doesn't get set up (which is crap). >>>>>>>> >>>>> >>>>>>>> >>>>> LieGrue, >>>>>>>> >>>>> Strub >>>>>>>> >>>>> >>>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>>>>>> john.d.ament at gmail.com>: >>>>>>>> >>>>>> >>>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's >>>>>>>> nothing in this spec that says it wouldn't be propagated. However, there's >>>>>>>> nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>>> >>>>>> >>>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>>>>>> transaction state. Considering the age of the spec, I'm not surprised to >>>>>>>> see that. The worst part is that right now, outside of the ASF, all other >>>>>>>> EE7 impls seem to be using the RI for concurrency. >>>>>>>> >>>>>> >>>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the >>>>>>>> only thing that's actually propagated is the transaction. >>>>>>>> >>>>>> >>>>>>>> >>>>>> John >>>>>>>> >>>>>> >>>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>> >>>>>> I am re-reading the spec end to end again right now. So far >>>>>>>> it seems I have remembered everything correctly. >>>>>>>> >>>>>> >>>>>>>> >>>>>> You should read over section 2.3. What it is saying is that >>>>>>>> a container implementing the Java EE concurrency utilities should ensure >>>>>>>> whatever contextual information is needed for managed components to work >>>>>>>> correctly should be propagated automatically. For the correct >>>>>>>> implementation of CDI scopes, this should also mean any currently active >>>>>>>> scopes. The section you are referring to is basically implying that >>>>>>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>>>>>> reliably since beans could go out of scope before the thread finishes - for >>>>>>>> example if the request ends). >>>>>>>> >>>>>> >>>>>>>> >>>>>> This does not have anything to do with the context service >>>>>>>> per se. The context service is an SPI of sorts to allow end user developers >>>>>>>> to do for their own applications what the container does behind the scenes >>>>>>>> for managed component context propagation. >>>>>>>> >>>>>> >>>>>>>> >>>>>> I'll read over the entire spec to see if there is anything >>>>>>>> to contradict this. If that's not the case what Romain is describing is >>>>>>>> most likely an implementation specific bug that did not take into account >>>>>>>> CDI scope propagation. >>>>>>>> >>>>>> >>>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Reza, >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>>>>>> specific section you had in mind? The only references to CDI were near the >>>>>>>> beginning warning users to not use Request/Session scoped beans as tasks >>>>>>>> since the outer most context may be destroyed before the work is done. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> I have a feeling what you're referring to is the context >>>>>>>> service: >>>>>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> If that's the case, then basically this should work OOTB >>>>>>>> right? >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>>> >>>>>>> task = contextService.createContextualProxy(task, >>>>>>>> Task.class); >>>>>>>> >>>>>>> executor.submit(task); >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Is that about right? >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> John >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text in >>>>>>>> detail? What does it say about managed component context propagation? >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Without actually doing that further discussing this is just >>>>>>>> taking shots in the dark. As an implementer it should not surprise you that >>>>>>>> this might simply be a bug because the person implementing the concurrency >>>>>>>> utilities for the EE runtime was not told about what to copy over into the >>>>>>>> new thread for CDI to work correctly. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman < >>>>>>>> reza_rahman at lycos.com>: >>>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing that >>>>>>>> the EE concurrency spec is intended for. It is supposed to copy over >>>>>>>> everything from the underlying thread local context into the new thread for >>>>>>>> all EE managed components to function. Since CDI beans are also EE >>>>>>>> container managed, it also applies to CDI beans as well. The EE vendor is >>>>>>>> supposed to make sure this works properly. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically lists >>>>>>>> APIs for which thread context propagation should work. If this doesn't work >>>>>>>> in a specific implementation it's most likely because they didn't take CDI >>>>>>>> into account in their own EE concurrency implementation. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite >>>>>>>> easily and @RequestScoped which is *used* today is sadly a >>>>>>>> @ThreadLocalScoped badly named. So to solve it we would need another scope >>>>>>>> as I mentionned several times on this list 100% matching servlet instances >>>>>>>> lifecycles (on a pure CDI side we have the same issue for sessions which >>>>>>>> are recycled during a request, the session scope is corrupted *by spec* in >>>>>>>> term of user behavior). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> The section of the spec you link to makes no references >>>>>>>> to threads. 6.3 makes some notes about normal scopes and threads, and >>>>>>>> specifically says that a context is bound to one or more threads. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> I think what's happened is that over the years, people >>>>>>>> have simply bound HTTP Request == single thread, but when async processing >>>>>>>> was introduced no one thought to clarify that the spawning of a child >>>>>>>> thread from the original HTTP request retains the parent's context. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> This is another requested feature, but looks more like a >>>>>>>> bug or gap in the spec. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> John >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman < >>>>>>>> reza_rahman at lycos.com>: >>>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE >>>>>>>> concurrency is generic enough for implementations to also be able to cover >>>>>>>> CDI scopes or any other Java EE API context propagation needs. This means >>>>>>>> the issue needs to be solved at the individual implementation level. >>>>>>>> Changing anything in the spec is probably just unnecessary ceremony in this >>>>>>>> case. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" >>>>>>>> users, 2. CDI still prevent it to work since it would violate the spec to >>>>>>>> propagate it while request scope is bound to another thread ( >>>>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>>>> handles async listener but not the main AsyncContext part). >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>>>>>> reza_rahman at lycos.com>: >>>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the specification >>>>>>>> text. This might indeed just be an implementation bug. The EE concurrency >>>>>>>> utilities are supposed to be copying all relevant context. If this is an >>>>>>>> issue than it has to be that it is not copying enough of the HTTP request >>>>>>>> context for CDI to work. >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but >>>>>>>> needed to reverse. From my understanding ee concurrency utilities was done >>>>>>>> in a time CDI was not there so it just ignored it somehow and it hasnt been >>>>>>>> updated when integrated to the spec. Now with the wording of the CDI - and >>>>>>>> TCK - it is impossible to make it working since request scope is bound the >>>>>>>> thre request thread - and not the request. Side note: same applies to >>>>>>>> session scope and conversation. >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light >>>>>>>> here since they implement essentially this whole stack? >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>>>>>> reza_rahman at lycos.com>: >>>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? >>>>>>>> It's important to make the case for how likely this is supposed to occur in >>>>>>>> most business applications. >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor service >>>>>>>> is propagating thread local request contexts correctly what other solution >>>>>>>> are you proposing? Did you check the specification? How sure are you that >>>>>>>> this isn't simply an implementation bug? >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to be >>>>>>>> preserving all relevant parts of the EE context? >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was >>>>>>>> the first impl I did then Mark pointed out it was violating CDI spec and >>>>>>>> request scope definition. There is a kind of contracdiction there cause >>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>>> tackle it. >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> does >>>>>>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>> >>>>>>>>>>>> try { >>>>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>>>> >>>>>>>>>>>> } finally { >>>>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>>>> >>>>>>>>>>>> } >>>>>>>> >>>>>>>>>>>> } >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context >>>>>>>> pushing (cause of injections nature you are not supposed to know what to >>>>>>>> push in the context when going async). >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>>>>>>> reza_rahman at lycos.com>: >>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the >>>>>>>> proposed solution so we can all follow and discuss this? >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to >>>>>>>> inherit a cdi scope. Idea is to follow request scope more than cdi spec >>>>>>>> allows. First thought it was a concurrency utilities thing but Reza >>>>>>>> mentionned can be a CDI one so here it is. >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I >>>>>>>> do some set on it. The i go async (AsyncContext) and trigger a task in >>>>>>>> another thread. It would be neat - and mandatory in some case by the loose >>>>>>>> coupling nature of CDI - to get the *same* MyBean *instance* in this >>>>>>>> thread. With a direct dependency you can easily use message passing pattern >>>>>>>> - but you loose the loose coupling cause you need to know until which level >>>>>>>> you unwrap, think t principal case which has 2-3 proxies!. However in >>>>>>>> practice you have a lot of undirect dependencies, in particular with >>>>>>>> enterprise concerns (auditing, security...) so you can't really do it >>>>>>>> easily/naturally. >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of >>>>>>>> push/pop an existing context in a thread - wrappers doing it on a >>>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a >>>>>>>> "context context" (its current instances map) in another thread the more >>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>> question for now. >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/f7ba3301/attachment-0001.html From rmannibucau at gmail.com Tue Mar 8 11:38:20 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 17:38:20 +0100 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: For Servlet 3.1 I don't have much doubts on the beneficial side but for the other cases I'm sure it would break a lot of code written on EE 6 or 7 where @RequestScoped beans have been used as thread local intances. So typically a HTTP request or JMS message calling an @Asynchronous EJB would break apps if you decide to propagate the context now. Same for websockets - which still don't have a scope - but in a lighter way since it is not yet mainstream. Even if such change makes sense it shouldn't be done without widely asking users to acknowledge it. Doing it is much more work and wider than the original mail so maybe it should be discussed in two steps. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-08 17:00 GMT+01:00 Paul Benedict : > I agree with Stephan. Since the introduction of asynchronous processing in > Servlet 3.1, the 1:1 assumption between request-thread has been removed. A > "request" should not be synonymous with a single thread anymore; but the > entire request operation. > > Cheers, > Paul > > On Tue, Mar 8, 2016 at 9:55 AM, Stephan Knitelius > wrote: > >> I am not sure I am following you 100%. >> >> For me a request is anything which comes into the context of the >> application. No matter if it comes in via Servlet, WebSockets, JMS, Remote >> EJB, etc... >> >> The request scope should be propagated to all asynchronous operations >> launched within that call, terminating it when all request associated >> asynchronous operations are completed. >> >> Knitti >> >> >> >> On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau >> wrote: >> >>> Yes (just making clear it is servlet related asynchronism - ie >>> AsyncContext#complete() is called and listeners are completed - to avoid >>> the ambiguity of @Async, JMS etc.. where request scope is now) >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : >>> >>>> >>>> >>>> So the proposal would be to enable propagation of request scope to >>>> asynchronous threads and keep it alive until all concurrent processes >>>> referencing it are completed? >>>> >>>> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau >>>> wrote: >>>> >>>>> will try to not hijack this thread and create another one for thread >>>>> scope ;). >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog >>>>> | Github >>>>> | LinkedIn >>>>> | Tomitriber >>>>> >>>>> >>>>> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >>>>> >>>>>> Your mention of thread local scope is interesting indeed. We had just >>>>>> such a scope in Resin called @ThreadScoped, completely separate from >>>>>> @RequestScoped. As memory serves though even in Resin we basically >>>>>> implemented @RequestScoped as thread local scope. >>>>>> >>>>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau >>>>>> wrote: >>>>>> >>>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>>>>> >>>>>>> I never assume anything related to HTTP requests are ever thread >>>>>>> safe. I don't know many folks that would make that assumption either. I >>>>>>> think this consideration is not a significant one. The spec, docs and >>>>>>> tutorials out there are pretty clear about the fact that none of the CDI >>>>>>> scopes are really thread safe in the way EJBs are. >>>>>>> >>>>>>> >>>>>> It is one of the main usage of request scoped in practise. It doesn't >>>>>> come from HTTP side but since it is used this way in several other places >>>>>> (like batch) it is now assumed everywhere. It has even been promoted by >>>>>> several CDI projects so sadly it is to be taken into account now even if I >>>>>> agree it is not the state we should be at today. If changed - servlet >>>>>> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I >>>>>> guess CDI can work on this - it should be made very explicit in the spec >>>>>> and we should study a "thread local scope" replacement to fill the gap and >>>>>> propose a solution to this practise judged abusive. >>>>>> >>>>>> >>>>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>> In TomEE we restart/stop it around most of hooks including the >>>>>>> runnable passed to start(Runnable) of the AsyncContext but keeping the now >>>>>>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >>>>>>> startAsync() call sadly). This passes CDI TCK but for the particular >>>>>>> request scope I would be happy to clarify it is actually bound to the >>>>>>> request and just reuse the same instances. In term of side effects it would >>>>>>> breaks the current thread safety users assume (with reason or not) but I >>>>>>> have no real clue if it would really breaks apps or not. >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau | Blog >>>>>>> | Github >>>>>>> | LinkedIn >>>>>>> | Tomitriber >>>>>>> >>>>>>> >>>>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>>>>> >>>>>>>> Let's hope some of the implementors weigh in on this some time soon. >>>>>>>> >>>>>>>> I could write some tests on this but I would have no idea if I >>>>>>>> would have uncovered a bug given the ambiguity of the current spec text. >>>>>>>> >>>>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Reading over the CDI spec definition for request scoped beans, I >>>>>>>>> am a tad confused. When are request scoped beans being destroyed right now? >>>>>>>>> Are they just bound to the Servlet request thread and destroyed as soon as >>>>>>>>> the service method returns? >>>>>>>> >>>>>>>> >>>>>>>> In case of a Servlet request (request scoped beans are also tied to >>>>>>>> other kinds of "requests"), it's indeed not clear. In practice it looks >>>>>>>> like the moment between the first ServletRequestListener#requestInitialized >>>>>>>> and ServletRequestListener#requestDestroyed. >>>>>>>> >>>>>>>> The exact scope is troublesome for security too, since in most >>>>>>>> severs the request scope (and session scope and application scope) is >>>>>>>> active when a SAM is called (the SAM gets an HttpServletRequest after all), >>>>>>>> but this is not the case in all servers. E.g. in Liberty the RequestScope >>>>>>>> starts AFTER a SAM is called. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Arjan Tijms >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In case of asynchronous Servlets, are they kept around until the >>>>>>>>> real HTTP request actually completes the same way the underlying HTTP >>>>>>>>> connection is kept around? Or is that too difficult because it would >>>>>>>>> require integration at a very low level with the Servlet implementation? >>>>>>>>> >>>>>>>>> There's some language around asynchronous completion right now but >>>>>>>>> it's not very clear what actually happens. Does the onComplete, etc >>>>>>>>> asynchronous callback basically create new request scoped instances? >>>>>>>>> >>>>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman >>>>>>>>> wrote: >>>>>>>>> > >>>>>>>>> > Even in the most conservative reading of this, the spec is >>>>>>>>> clearly not disallowing it. >>>>>>>>> > >>>>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg >>>>>>>>> wrote: >>>>>>>>> >> >>>>>>>>> >> The question is whether the spec does allow us to do it. And if >>>>>>>>> other containers consequently do it as well. >>>>>>>>> >> >>>>>>>>> >> If it does then I will implement it in TomEE. >>>>>>>>> >> >>>>>>>>> >> LieGrue, >>>>>>>>> >> strub >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman < >>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>> >>> >>>>>>>>> >>> What this is saying is that it is not recommended to use them >>>>>>>>> because of the possible life-cycle mismatch. If they are not supposed to >>>>>>>>> work at all, the specification would have simply stated it won't work. >>>>>>>>> >>> >>>>>>>>> >>> Anyway personally I have no reason to further discuss this. >>>>>>>>> I'm going to try to find a way to get this done for developers sooner >>>>>>>>> rather than later. If TomEE does not want to do it, too bad for developers. >>>>>>>>> >>> >>>>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>> >>>>>>>>> >>>> " >>>>>>>>> >>>> Tasks that are submitted to a managed instance of >>>>>>>>> ExecutorService may still be running after the lifecycle of the submitting >>>>>>>>> component. Therefore, CDI beans with a scope of @RequestScoped, >>>>>>>>> @SessionScoped, or @ConversationScoped are not recommended to use as tasks >>>>>>>>> as it cannot be guaranteed that the tasks will complete before the CDI >>>>>>>>> context is destroyed. >>>>>>>>> >>>> " >>>>>>>>> >>>> >>>>>>>>> >>>> States that the context is not inherited, is that what you >>>>>>>>> mean? >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> Romain Manni-Bucau >>>>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>> >>>> >>>>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman >>>>>>>> >: >>>>>>>>> >>>> The specification currently references pretty much all the >>>>>>>>> major CDI scopes specifically with the issue of propagation and lifecycle >>>>>>>>> in mind. Please see section 2.3. >>>>>>>>> >>>> >>>>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg < >>>>>>>>> struberg at yahoo.de> wrote: >>>>>>>>> >>>>> Specifically >>>>>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>>>>> >>>>> No session e.g. , new TX, etc >>>>>>>>> >>>>> >>>>>>>>> >>>>> Sadly the concurrency utilis only mention >>>>>>>>> @ApplicationScoped, so the Request Context not only doesn't get propagated >>>>>>>>> (which is good), but also doesn't get set up (which is crap). >>>>>>>>> >>>>> >>>>>>>>> >>>>> LieGrue, >>>>>>>>> >>>>> Strub >>>>>>>>> >>>>> >>>>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>>>>>>> john.d.ament at gmail.com>: >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's >>>>>>>>> nothing in this spec that says it wouldn't be propagated. However, there's >>>>>>>>> nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>>>>>>> transaction state. Considering the age of the spec, I'm not surprised to >>>>>>>>> see that. The worst part is that right now, outside of the ASF, all other >>>>>>>>> EE7 impls seem to be using the RI for concurrency. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the >>>>>>>>> only thing that's actually propagated is the transaction. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> John >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>> >>>>>> I am re-reading the spec end to end again right now. So far >>>>>>>>> it seems I have remembered everything correctly. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> You should read over section 2.3. What it is saying is that >>>>>>>>> a container implementing the Java EE concurrency utilities should ensure >>>>>>>>> whatever contextual information is needed for managed components to work >>>>>>>>> correctly should be propagated automatically. For the correct >>>>>>>>> implementation of CDI scopes, this should also mean any currently active >>>>>>>>> scopes. The section you are referring to is basically implying that >>>>>>>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>>>>>>> reliably since beans could go out of scope before the thread finishes - for >>>>>>>>> example if the request ends). >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> This does not have anything to do with the context service >>>>>>>>> per se. The context service is an SPI of sorts to allow end user developers >>>>>>>>> to do for their own applications what the container does behind the scenes >>>>>>>>> for managed component context propagation. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I'll read over the entire spec to see if there is anything >>>>>>>>> to contradict this. If that's not the case what Romain is describing is >>>>>>>>> most likely an implementation specific bug that did not take into account >>>>>>>>> CDI scope propagation. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Reza, >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>>>>>>> specific section you had in mind? The only references to CDI were near the >>>>>>>>> beginning warning users to not use Request/Session scoped beans as tasks >>>>>>>>> since the outer most context may be destroyed before the work is done. >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> I have a feeling what you're referring to is the context >>>>>>>>> service: >>>>>>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> If that's the case, then basically this should work OOTB >>>>>>>>> right? >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>>>> >>>>>>> task = contextService.createContextualProxy(task, >>>>>>>>> Task.class); >>>>>>>>> >>>>>>> executor.submit(task); >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Is that about right? >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> John >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text >>>>>>>>> in detail? What does it say about managed component context propagation? >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Without actually doing that further discussing this is >>>>>>>>> just taking shots in the dark. As an implementer it should not surprise you >>>>>>>>> that this might simply be a bug because the person implementing the >>>>>>>>> concurrency utilities for the EE runtime was not told about what to copy >>>>>>>>> over into the new thread for CDI to work correctly. >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman < >>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing that >>>>>>>>> the EE concurrency spec is intended for. It is supposed to copy over >>>>>>>>> everything from the underlying thread local context into the new thread for >>>>>>>>> all EE managed components to function. Since CDI beans are also EE >>>>>>>>> container managed, it also applies to CDI beans as well. The EE vendor is >>>>>>>>> supposed to make sure this works properly. >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically >>>>>>>>> lists APIs for which thread context propagation should work. If this >>>>>>>>> doesn't work in a specific implementation it's most likely because they >>>>>>>>> didn't take CDI into account in their own EE concurrency implementation. >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite >>>>>>>>> easily and @RequestScoped which is *used* today is sadly a >>>>>>>>> @ThreadLocalScoped badly named. So to solve it we would need another scope >>>>>>>>> as I mentionned several times on this list 100% matching servlet instances >>>>>>>>> lifecycles (on a pure CDI side we have the same issue for sessions which >>>>>>>>> are recycled during a request, the session scope is corrupted *by spec* in >>>>>>>>> term of user behavior). >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The section of the spec you link to makes no references >>>>>>>>> to threads. 6.3 makes some notes about normal scopes and threads, and >>>>>>>>> specifically says that a context is bound to one or more threads. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I think what's happened is that over the years, people >>>>>>>>> have simply bound HTTP Request == single thread, but when async processing >>>>>>>>> was introduced no one thought to clarify that the spawning of a child >>>>>>>>> thread from the original HTTP request retains the parent's context. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This is another requested feature, but looks more like a >>>>>>>>> bug or gap in the spec. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman < >>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE >>>>>>>>> concurrency is generic enough for implementations to also be able to cover >>>>>>>>> CDI scopes or any other Java EE API context propagation needs. This means >>>>>>>>> the issue needs to be solved at the individual implementation level. >>>>>>>>> Changing anything in the spec is probably just unnecessary ceremony in this >>>>>>>>> case. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" >>>>>>>>> users, 2. CDI still prevent it to work since it would violate the spec to >>>>>>>>> propagate it while request scope is bound to another thread ( >>>>>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>>>>> handles async listener but not the main AsyncContext part). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the specification >>>>>>>>> text. This might indeed just be an implementation bug. The EE concurrency >>>>>>>>> utilities are supposed to be copying all relevant context. If this is an >>>>>>>>> issue than it has to be that it is not copying enough of the HTTP request >>>>>>>>> context for CDI to work. >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but >>>>>>>>> needed to reverse. From my understanding ee concurrency utilities was done >>>>>>>>> in a time CDI was not there so it just ignored it somehow and it hasnt been >>>>>>>>> updated when integrated to the spec. Now with the wording of the CDI - and >>>>>>>>> TCK - it is impossible to make it working since request scope is bound the >>>>>>>>> thre request thread - and not the request. Side note: same applies to >>>>>>>>> session scope and conversation. >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light >>>>>>>>> here since they implement essentially this whole stack? >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? >>>>>>>>> It's important to make the case for how likely this is supposed to occur in >>>>>>>>> most business applications. >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor service >>>>>>>>> is propagating thread local request contexts correctly what other solution >>>>>>>>> are you proposing? Did you check the specification? How sure are you that >>>>>>>>> this isn't simply an implementation bug? >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to >>>>>>>>> be preserving all relevant parts of the EE context? >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was >>>>>>>>> the first impl I did then Mark pointed out it was violating CDI spec and >>>>>>>>> request scope definition. There is a kind of contracdiction there cause >>>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>>>> tackle it. >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> does >>>>>>>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>>> >>>>>>>>>>>> try { >>>>>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>>>>> >>>>>>>>>>>> } finally { >>>>>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>>>>> >>>>>>>>>>>> } >>>>>>>>> >>>>>>>>>>>> } >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context >>>>>>>>> pushing (cause of injections nature you are not supposed to know what to >>>>>>>>> push in the context when going async). >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the >>>>>>>>> proposed solution so we can all follow and discuss this? >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to >>>>>>>>> inherit a cdi scope. Idea is to follow request scope more than cdi spec >>>>>>>>> allows. First thought it was a concurrency utilities thing but Reza >>>>>>>>> mentionned can be a CDI one so here it is. >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I >>>>>>>>> do some set on it. The i go async (AsyncContext) and trigger a task in >>>>>>>>> another thread. It would be neat - and mandatory in some case by the loose >>>>>>>>> coupling nature of CDI - to get the *same* MyBean *instance* in this >>>>>>>>> thread. With a direct dependency you can easily use message passing pattern >>>>>>>>> - but you loose the loose coupling cause you need to know until which level >>>>>>>>> you unwrap, think t principal case which has 2-3 proxies!. However in >>>>>>>>> practice you have a lot of undirect dependencies, in particular with >>>>>>>>> enterprise concerns (auditing, security...) so you can't really do it >>>>>>>>> easily/naturally. >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of >>>>>>>>> push/pop an existing context in a thread - wrappers doing it on a >>>>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a >>>>>>>>> "context context" (its current instances map) in another thread the more >>>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>>> question for now. >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/522a7c7f/attachment-0001.html From antoine at sabot-durand.net Tue Mar 8 11:44:56 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 08 Mar 2016 16:44:56 +0000 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: As we already discussed during async event debate, we really should think about propagating normal scopes to be align on servlet and prepare CDI for reactive programming. We can't break the way existing built-in normal scopes work today (no propagating and ApplicationScoped being shared) but nothing prevent us to introduce new normal scope supporting propagation (@AsyncRequestScoped for instance). Le mar. 8 mars 2016 ? 17:38, Romain Manni-Bucau a ?crit : > For Servlet 3.1 I don't have much doubts on the beneficial side but for > the other cases I'm sure it would break a lot of code written on EE 6 or 7 > where @RequestScoped beans have been used as thread local intances. So > typically a HTTP request or JMS message calling an @Asynchronous EJB would > break apps if you decide to propagate the context now. Same for websockets > - which still don't have a scope - but in a lighter way since it is not yet > mainstream. > > Even if such change makes sense it shouldn't be done without widely asking > users to acknowledge it. Doing it is much more work and wider than the > original mail so maybe it should be discussed in two steps. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-08 17:00 GMT+01:00 Paul Benedict : > >> I agree with Stephan. Since the introduction of asynchronous processing >> in Servlet 3.1, the 1:1 assumption between request-thread has been removed. >> A "request" should not be synonymous with a single thread anymore; but the >> entire request operation. >> >> Cheers, >> Paul >> >> On Tue, Mar 8, 2016 at 9:55 AM, Stephan Knitelius >> wrote: >> >>> I am not sure I am following you 100%. >>> >>> For me a request is anything which comes into the context of the >>> application. No matter if it comes in via Servlet, WebSockets, JMS, Remote >>> EJB, etc... >>> >>> The request scope should be propagated to all asynchronous operations >>> launched within that call, terminating it when all request associated >>> asynchronous operations are completed. >>> >>> Knitti >>> >>> >>> >>> On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau >>> wrote: >>> >>>> Yes (just making clear it is servlet related asynchronism - ie >>>> AsyncContext#complete() is called and listeners are completed - to avoid >>>> the ambiguity of @Async, JMS etc.. where request scope is now) >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : >>>> >>>>> >>>>> >>>>> So the proposal would be to enable propagation of request scope to >>>>> asynchronous threads and keep it alive until all concurrent processes >>>>> referencing it are completed? >>>>> >>>>> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau >>>>> wrote: >>>>> >>>>>> will try to not hijack this thread and create another one for thread >>>>>> scope ;). >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog >>>>>> | Github >>>>>> | LinkedIn >>>>>> | Tomitriber >>>>>> >>>>>> >>>>>> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >>>>>> >>>>>>> Your mention of thread local scope is interesting indeed. We had >>>>>>> just such a scope in Resin called @ThreadScoped, completely separate from >>>>>>> @RequestScoped. As memory serves though even in Resin we basically >>>>>>> implemented @RequestScoped as thread local scope. >>>>>>> >>>>>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>>>>>> >>>>>>>> I never assume anything related to HTTP requests are ever thread >>>>>>>> safe. I don't know many folks that would make that assumption either. I >>>>>>>> think this consideration is not a significant one. The spec, docs and >>>>>>>> tutorials out there are pretty clear about the fact that none of the CDI >>>>>>>> scopes are really thread safe in the way EJBs are. >>>>>>>> >>>>>>>> >>>>>>> It is one of the main usage of request scoped in practise. It >>>>>>> doesn't come from HTTP side but since it is used this way in several other >>>>>>> places (like batch) it is now assumed everywhere. It has even been promoted >>>>>>> by several CDI projects so sadly it is to be taken into account now even if >>>>>>> I agree it is not the state we should be at today. If changed - servlet >>>>>>> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I >>>>>>> guess CDI can work on this - it should be made very explicit in the spec >>>>>>> and we should study a "thread local scope" replacement to fill the gap and >>>>>>> propose a solution to this practise judged abusive. >>>>>>> >>>>>>> >>>>>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>> In TomEE we restart/stop it around most of hooks including the >>>>>>>> runnable passed to start(Runnable) of the AsyncContext but keeping the now >>>>>>>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >>>>>>>> startAsync() call sadly). This passes CDI TCK but for the particular >>>>>>>> request scope I would be happy to clarify it is actually bound to the >>>>>>>> request and just reuse the same instances. In term of side effects it would >>>>>>>> breaks the current thread safety users assume (with reason or not) but I >>>>>>>> have no real clue if it would really breaks apps or not. >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog >>>>>>>> | Github >>>>>>>> | LinkedIn >>>>>>>> | Tomitriber >>>>>>>> >>>>>>>> >>>>>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>>>>>> >>>>>>>>> Let's hope some of the implementors weigh in on this some time >>>>>>>>> soon. >>>>>>>>> >>>>>>>>> I could write some tests on this but I would have no idea if I >>>>>>>>> would have uncovered a bug given the ambiguity of the current spec text. >>>>>>>>> >>>>>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Reading over the CDI spec definition for request scoped beans, I >>>>>>>>>> am a tad confused. When are request scoped beans being destroyed right now? >>>>>>>>>> Are they just bound to the Servlet request thread and destroyed as soon as >>>>>>>>>> the service method returns? >>>>>>>>> >>>>>>>>> >>>>>>>>> In case of a Servlet request (request scoped beans are also tied >>>>>>>>> to other kinds of "requests"), it's indeed not clear. In practice it looks >>>>>>>>> like the moment between the first ServletRequestListener#requestInitialized >>>>>>>>> and ServletRequestListener#requestDestroyed. >>>>>>>>> >>>>>>>>> The exact scope is troublesome for security too, since in most >>>>>>>>> severs the request scope (and session scope and application scope) is >>>>>>>>> active when a SAM is called (the SAM gets an HttpServletRequest after all), >>>>>>>>> but this is not the case in all servers. E.g. in Liberty the RequestScope >>>>>>>>> starts AFTER a SAM is called. >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> Arjan Tijms >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> In case of asynchronous Servlets, are they kept around until the >>>>>>>>>> real HTTP request actually completes the same way the underlying HTTP >>>>>>>>>> connection is kept around? Or is that too difficult because it would >>>>>>>>>> require integration at a very low level with the Servlet implementation? >>>>>>>>>> >>>>>>>>>> There's some language around asynchronous completion right now >>>>>>>>>> but it's not very clear what actually happens. Does the onComplete, etc >>>>>>>>>> asynchronous callback basically create new request scoped instances? >>>>>>>>>> >>>>>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman >>>>>>>>>> wrote: >>>>>>>>>> > >>>>>>>>>> > Even in the most conservative reading of this, the spec is >>>>>>>>>> clearly not disallowing it. >>>>>>>>>> > >>>>>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg >>>>>>>>>> wrote: >>>>>>>>>> >> >>>>>>>>>> >> The question is whether the spec does allow us to do it. And >>>>>>>>>> if other containers consequently do it as well. >>>>>>>>>> >> >>>>>>>>>> >> If it does then I will implement it in TomEE. >>>>>>>>>> >> >>>>>>>>>> >> LieGrue, >>>>>>>>>> >> strub >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman < >>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>> >>> >>>>>>>>>> >>> What this is saying is that it is not recommended to use them >>>>>>>>>> because of the possible life-cycle mismatch. If they are not supposed to >>>>>>>>>> work at all, the specification would have simply stated it won't work. >>>>>>>>>> >>> >>>>>>>>>> >>> Anyway personally I have no reason to further discuss this. >>>>>>>>>> I'm going to try to find a way to get this done for developers sooner >>>>>>>>>> rather than later. If TomEE does not want to do it, too bad for developers. >>>>>>>>>> >>> >>>>>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>> >>>>>>>>>> >>>> " >>>>>>>>>> >>>> Tasks that are submitted to a managed instance of >>>>>>>>>> ExecutorService may still be running after the lifecycle of the submitting >>>>>>>>>> component. Therefore, CDI beans with a scope of @RequestScoped, >>>>>>>>>> @SessionScoped, or @ConversationScoped are not recommended to use as tasks >>>>>>>>>> as it cannot be guaranteed that the tasks will complete before the CDI >>>>>>>>>> context is destroyed. >>>>>>>>>> >>>> " >>>>>>>>>> >>>> >>>>>>>>>> >>>> States that the context is not inherited, is that what you >>>>>>>>>> mean? >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> Romain Manni-Bucau >>>>>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>> >>>> >>>>>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman >>>>>>>>> >: >>>>>>>>>> >>>> The specification currently references pretty much all the >>>>>>>>>> major CDI scopes specifically with the issue of propagation and lifecycle >>>>>>>>>> in mind. Please see section 2.3. >>>>>>>>>> >>>> >>>>>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg < >>>>>>>>>> struberg at yahoo.de> wrote: >>>>>>>>>> >>>>> Specifically >>>>>>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>>>>>> >>>>> No session e.g. , new TX, etc >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Sadly the concurrency utilis only mention >>>>>>>>>> @ApplicationScoped, so the Request Context not only doesn't get propagated >>>>>>>>>> (which is good), but also doesn't get set up (which is crap). >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> LieGrue, >>>>>>>>>> >>>>> Strub >>>>>>>>>> >>>>> >>>>>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>>>>>>>> john.d.ament at gmail.com>: >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's >>>>>>>>>> nothing in this spec that says it wouldn't be propagated. However, there's >>>>>>>>>> nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>>>>>>>> transaction state. Considering the age of the spec, I'm not surprised to >>>>>>>>>> see that. The worst part is that right now, outside of the ASF, all other >>>>>>>>>> EE7 impls seem to be using the RI for concurrency. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the >>>>>>>>>> only thing that's actually propagated is the transaction. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> John >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>> >>>>>> I am re-reading the spec end to end again right now. So >>>>>>>>>> far it seems I have remembered everything correctly. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> You should read over section 2.3. What it is saying is >>>>>>>>>> that a container implementing the Java EE concurrency utilities should >>>>>>>>>> ensure whatever contextual information is needed for managed components to >>>>>>>>>> work correctly should be propagated automatically. For the correct >>>>>>>>>> implementation of CDI scopes, this should also mean any currently active >>>>>>>>>> scopes. The section you are referring to is basically implying that >>>>>>>>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>>>>>>>> reliably since beans could go out of scope before the thread finishes - for >>>>>>>>>> example if the request ends). >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> This does not have anything to do with the context service >>>>>>>>>> per se. The context service is an SPI of sorts to allow end user developers >>>>>>>>>> to do for their own applications what the container does behind the scenes >>>>>>>>>> for managed component context propagation. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> I'll read over the entire spec to see if there is anything >>>>>>>>>> to contradict this. If that's not the case what Romain is describing is >>>>>>>>>> most likely an implementation specific bug that did not take into account >>>>>>>>>> CDI scope propagation. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Reza, >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>>>>>>>> specific section you had in mind? The only references to CDI were near the >>>>>>>>>> beginning warning users to not use Request/Session scoped beans as tasks >>>>>>>>>> since the outer most context may be destroyed before the work is done. >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> I have a feeling what you're referring to is the context >>>>>>>>>> service: >>>>>>>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> If that's the case, then basically this should work OOTB >>>>>>>>>> right? >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>>>>> >>>>>>> task = contextService.createContextualProxy(task, >>>>>>>>>> Task.class); >>>>>>>>>> >>>>>>> executor.submit(task); >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Is that about right? >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> John >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text >>>>>>>>>> in detail? What does it say about managed component context propagation? >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Without actually doing that further discussing this is >>>>>>>>>> just taking shots in the dark. As an implementer it should not surprise you >>>>>>>>>> that this might simply be a bug because the person implementing the >>>>>>>>>> concurrency utilities for the EE runtime was not told about what to copy >>>>>>>>>> over into the new thread for CDI to work correctly. >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman < >>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing >>>>>>>>>> that the EE concurrency spec is intended for. It is supposed to copy over >>>>>>>>>> everything from the underlying thread local context into the new thread for >>>>>>>>>> all EE managed components to function. Since CDI beans are also EE >>>>>>>>>> container managed, it also applies to CDI beans as well. The EE vendor is >>>>>>>>>> supposed to make sure this works properly. >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically >>>>>>>>>> lists APIs for which thread context propagation should work. If this >>>>>>>>>> doesn't work in a specific implementation it's most likely because they >>>>>>>>>> didn't take CDI into account in their own EE concurrency implementation. >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite >>>>>>>>>> easily and @RequestScoped which is *used* today is sadly a >>>>>>>>>> @ThreadLocalScoped badly named. So to solve it we would need another scope >>>>>>>>>> as I mentionned several times on this list 100% matching servlet instances >>>>>>>>>> lifecycles (on a pure CDI side we have the same issue for sessions which >>>>>>>>>> are recycled during a request, the session scope is corrupted *by spec* in >>>>>>>>>> term of user behavior). >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>>>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> The section of the spec you link to makes no references >>>>>>>>>> to threads. 6.3 makes some notes about normal scopes and threads, and >>>>>>>>>> specifically says that a context is bound to one or more threads. >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> I think what's happened is that over the years, people >>>>>>>>>> have simply bound HTTP Request == single thread, but when async processing >>>>>>>>>> was introduced no one thought to clarify that the spawning of a child >>>>>>>>>> thread from the original HTTP request retains the parent's context. >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> This is another requested feature, but looks more like >>>>>>>>>> a bug or gap in the spec. >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> John >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman < >>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE >>>>>>>>>> concurrency is generic enough for implementations to also be able to cover >>>>>>>>>> CDI scopes or any other Java EE API context propagation needs. This means >>>>>>>>>> the issue needs to be solved at the individual implementation level. >>>>>>>>>> Changing anything in the spec is probably just unnecessary ceremony in this >>>>>>>>>> case. >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" >>>>>>>>>> users, 2. CDI still prevent it to work since it would violate the spec to >>>>>>>>>> propagate it while request scope is bound to another thread ( >>>>>>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>>>>>> handles async listener but not the main AsyncContext part). >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the >>>>>>>>>> specification text. This might indeed just be an implementation bug. The EE >>>>>>>>>> concurrency utilities are supposed to be copying all relevant context. If >>>>>>>>>> this is an issue than it has to be that it is not copying enough of the >>>>>>>>>> HTTP request context for CDI to work. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but >>>>>>>>>> needed to reverse. From my understanding ee concurrency utilities was done >>>>>>>>>> in a time CDI was not there so it just ignored it somehow and it hasnt been >>>>>>>>>> updated when integrated to the spec. Now with the wording of the CDI - and >>>>>>>>>> TCK - it is impossible to make it working since request scope is bound the >>>>>>>>>> thre request thread - and not the request. Side note: same applies to >>>>>>>>>> session scope and conversation. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light >>>>>>>>>> here since they implement essentially this whole stack? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? >>>>>>>>>> It's important to make the case for how likely this is supposed to occur in >>>>>>>>>> most business applications. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor >>>>>>>>>> service is propagating thread local request contexts correctly what other >>>>>>>>>> solution are you proposing? Did you check the specification? How sure are >>>>>>>>>> you that this isn't simply an implementation bug? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to >>>>>>>>>> be preserving all relevant parts of the EE context? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That >>>>>>>>>> was the first impl I did then Mark pointed out it was violating CDI spec >>>>>>>>>> and request scope definition. There is a kind of contracdiction there cause >>>>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>>>>> tackle it. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> does >>>>>>>>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>>>> >>>>>>>>>>>> try { >>>>>>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>> >>>>>>>>>>>> } finally { >>>>>>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context >>>>>>>>>> pushing (cause of injections nature you are not supposed to know what to >>>>>>>>>> push in the context when going async). >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of >>>>>>>>>> the proposed solution so we can all follow and discuss this? >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to >>>>>>>>>> inherit a cdi scope. Idea is to follow request scope more than cdi spec >>>>>>>>>> allows. First thought it was a concurrency utilities thing but Reza >>>>>>>>>> mentionned can be a CDI one so here it is. >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, >>>>>>>>>> I do some set on it. The i go async (AsyncContext) and trigger a task in >>>>>>>>>> another thread. It would be neat - and mandatory in some case by the loose >>>>>>>>>> coupling nature of CDI - to get the *same* MyBean *instance* in this >>>>>>>>>> thread. With a direct dependency you can easily use message passing pattern >>>>>>>>>> - but you loose the loose coupling cause you need to know until which level >>>>>>>>>> you unwrap, think t principal case which has 2-3 proxies!. However in >>>>>>>>>> practice you have a lot of undirect dependencies, in particular with >>>>>>>>>> enterprise concerns (auditing, security...) so you can't really do it >>>>>>>>>> easily/naturally. >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of >>>>>>>>>> push/pop an existing context in a thread - wrappers doing it on a >>>>>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a >>>>>>>>>> "context context" (its current instances map) in another thread the more >>>>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>>>> question for now. >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | >>>>>>>>>> Tomitriber >>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/6221d049/attachment-0001.html From rmannibucau at gmail.com Tue Mar 8 11:46:12 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 17:46:12 +0100 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: is a flag an option? @RequestScoped(inherited = true) Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-08 17:44 GMT+01:00 Antoine Sabot-Durand : > As we already discussed during async event debate, we really should think > about propagating normal scopes to be align on servlet and prepare CDI for > reactive programming. > We can't break the way existing built-in normal scopes work today (no > propagating and ApplicationScoped being shared) but nothing prevent us to > introduce new normal scope supporting propagation (@AsyncRequestScoped for > instance). > > Le mar. 8 mars 2016 ? 17:38, Romain Manni-Bucau a > ?crit : > >> For Servlet 3.1 I don't have much doubts on the beneficial side but for >> the other cases I'm sure it would break a lot of code written on EE 6 or 7 >> where @RequestScoped beans have been used as thread local intances. So >> typically a HTTP request or JMS message calling an @Asynchronous EJB would >> break apps if you decide to propagate the context now. Same for websockets >> - which still don't have a scope - but in a lighter way since it is not yet >> mainstream. >> >> Even if such change makes sense it shouldn't be done >> without widely asking users to acknowledge it. Doing it is much more work >> and wider than the original mail so maybe it should be discussed in two >> steps. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-03-08 17:00 GMT+01:00 Paul Benedict : >> >>> I agree with Stephan. Since the introduction of asynchronous processing >>> in Servlet 3.1, the 1:1 assumption between request-thread has been removed. >>> A "request" should not be synonymous with a single thread anymore; but the >>> entire request operation. >>> >>> Cheers, >>> Paul >>> >>> On Tue, Mar 8, 2016 at 9:55 AM, Stephan Knitelius >> > wrote: >>> >>>> I am not sure I am following you 100%. >>>> >>>> For me a request is anything which comes into the context of the >>>> application. No matter if it comes in via Servlet, WebSockets, JMS, Remote >>>> EJB, etc... >>>> >>>> The request scope should be propagated to all asynchronous operations >>>> launched within that call, terminating it when all request associated >>>> asynchronous operations are completed. >>>> >>>> Knitti >>>> >>>> >>>> >>>> On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau >>>> wrote: >>>> >>>>> Yes (just making clear it is servlet related asynchronism - ie >>>>> AsyncContext#complete() is called and listeners are completed - to avoid >>>>> the ambiguity of @Async, JMS etc.. where request scope is now) >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog >>>>> | Github >>>>> | LinkedIn >>>>> | Tomitriber >>>>> >>>>> >>>>> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : >>>>> >>>>>> >>>>>> >>>>>> So the proposal would be to enable propagation of request scope to >>>>>> asynchronous threads and keep it alive until all concurrent processes >>>>>> referencing it are completed? >>>>>> >>>>>> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau >>>>>> wrote: >>>>>> >>>>>>> will try to not hijack this thread and create another one for thread >>>>>>> scope ;). >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau | Blog >>>>>>> | Github >>>>>>> | LinkedIn >>>>>>> | Tomitriber >>>>>>> >>>>>>> >>>>>>> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >>>>>>> >>>>>>>> Your mention of thread local scope is interesting indeed. We had >>>>>>>> just such a scope in Resin called @ThreadScoped, completely separate from >>>>>>>> @RequestScoped. As memory serves though even in Resin we basically >>>>>>>> implemented @RequestScoped as thread local scope. >>>>>>>> >>>>>>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>>>>>>> >>>>>>>>> I never assume anything related to HTTP requests are ever thread >>>>>>>>> safe. I don't know many folks that would make that assumption either. I >>>>>>>>> think this consideration is not a significant one. The spec, docs and >>>>>>>>> tutorials out there are pretty clear about the fact that none of the CDI >>>>>>>>> scopes are really thread safe in the way EJBs are. >>>>>>>>> >>>>>>>>> >>>>>>>> It is one of the main usage of request scoped in practise. It >>>>>>>> doesn't come from HTTP side but since it is used this way in several other >>>>>>>> places (like batch) it is now assumed everywhere. It has even been promoted >>>>>>>> by several CDI projects so sadly it is to be taken into account now even if >>>>>>>> I agree it is not the state we should be at today. If changed - servlet >>>>>>>> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I >>>>>>>> guess CDI can work on this - it should be made very explicit in the spec >>>>>>>> and we should study a "thread local scope" replacement to fill the gap and >>>>>>>> propose a solution to this practise judged abusive. >>>>>>>> >>>>>>>> >>>>>>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>> In TomEE we restart/stop it around most of hooks including the >>>>>>>>> runnable passed to start(Runnable) of the AsyncContext but keeping the now >>>>>>>>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >>>>>>>>> startAsync() call sadly). This passes CDI TCK but for the particular >>>>>>>>> request scope I would be happy to clarify it is actually bound to the >>>>>>>>> request and just reuse the same instances. In term of side effects it would >>>>>>>>> breaks the current thread safety users assume (with reason or not) but I >>>>>>>>> have no real clue if it would really breaks apps or not. >>>>>>>>> >>>>>>>>> >>>>>>>>> Romain Manni-Bucau >>>>>>>>> @rmannibucau | Blog >>>>>>>>> | Github >>>>>>>>> | LinkedIn >>>>>>>>> | Tomitriber >>>>>>>>> >>>>>>>>> >>>>>>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>>>>>>> >>>>>>>>>> Let's hope some of the implementors weigh in on this some time >>>>>>>>>> soon. >>>>>>>>>> >>>>>>>>>> I could write some tests on this but I would have no idea if I >>>>>>>>>> would have uncovered a bug given the ambiguity of the current spec text. >>>>>>>>>> >>>>>>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman < >>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>> >>>>>>>>>>> Reading over the CDI spec definition for request scoped beans, I >>>>>>>>>>> am a tad confused. When are request scoped beans being destroyed right now? >>>>>>>>>>> Are they just bound to the Servlet request thread and destroyed as soon as >>>>>>>>>>> the service method returns? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In case of a Servlet request (request scoped beans are also tied >>>>>>>>>> to other kinds of "requests"), it's indeed not clear. In practice it looks >>>>>>>>>> like the moment between the first ServletRequestListener#requestInitialized >>>>>>>>>> and ServletRequestListener#requestDestroyed. >>>>>>>>>> >>>>>>>>>> The exact scope is troublesome for security too, since in most >>>>>>>>>> severs the request scope (and session scope and application scope) is >>>>>>>>>> active when a SAM is called (the SAM gets an HttpServletRequest after all), >>>>>>>>>> but this is not the case in all servers. E.g. in Liberty the RequestScope >>>>>>>>>> starts AFTER a SAM is called. >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> Arjan Tijms >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> In case of asynchronous Servlets, are they kept around until the >>>>>>>>>>> real HTTP request actually completes the same way the underlying HTTP >>>>>>>>>>> connection is kept around? Or is that too difficult because it would >>>>>>>>>>> require integration at a very low level with the Servlet implementation? >>>>>>>>>>> >>>>>>>>>>> There's some language around asynchronous completion right now >>>>>>>>>>> but it's not very clear what actually happens. Does the onComplete, etc >>>>>>>>>>> asynchronous callback basically create new request scoped instances? >>>>>>>>>>> >>>>>>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman < >>>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>>> > >>>>>>>>>>> > Even in the most conservative reading of this, the spec is >>>>>>>>>>> clearly not disallowing it. >>>>>>>>>>> > >>>>>>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg >>>>>>>>>>> wrote: >>>>>>>>>>> >> >>>>>>>>>>> >> The question is whether the spec does allow us to do it. And >>>>>>>>>>> if other containers consequently do it as well. >>>>>>>>>>> >> >>>>>>>>>>> >> If it does then I will implement it in TomEE. >>>>>>>>>>> >> >>>>>>>>>>> >> LieGrue, >>>>>>>>>>> >> strub >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman < >>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>> >>> >>>>>>>>>>> >>> What this is saying is that it is not recommended to use >>>>>>>>>>> them because of the possible life-cycle mismatch. If they are not supposed >>>>>>>>>>> to work at all, the specification would have simply stated it won't work. >>>>>>>>>>> >>> >>>>>>>>>>> >>> Anyway personally I have no reason to further discuss this. >>>>>>>>>>> I'm going to try to find a way to get this done for developers sooner >>>>>>>>>>> rather than later. If TomEE does not want to do it, too bad for developers. >>>>>>>>>>> >>> >>>>>>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> " >>>>>>>>>>> >>>> Tasks that are submitted to a managed instance of >>>>>>>>>>> ExecutorService may still be running after the lifecycle of the submitting >>>>>>>>>>> component. Therefore, CDI beans with a scope of @RequestScoped, >>>>>>>>>>> @SessionScoped, or @ConversationScoped are not recommended to use as tasks >>>>>>>>>>> as it cannot be guaranteed that the tasks will complete before the CDI >>>>>>>>>>> context is destroyed. >>>>>>>>>>> >>>> " >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> States that the context is not inherited, is that what you >>>>>>>>>>> mean? >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Romain Manni-Bucau >>>>>>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman < >>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>> >>>> The specification currently references pretty much all the >>>>>>>>>>> major CDI scopes specifically with the issue of propagation and lifecycle >>>>>>>>>>> in mind. Please see section 2.3. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg < >>>>>>>>>>> struberg at yahoo.de> wrote: >>>>>>>>>>> >>>>> Specifically >>>>>>>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>>>>>>> >>>>> No session e.g. , new TX, etc >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Sadly the concurrency utilis only mention >>>>>>>>>>> @ApplicationScoped, so the Request Context not only doesn't get propagated >>>>>>>>>>> (which is good), but also doesn't get set up (which is crap). >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> LieGrue, >>>>>>>>>>> >>>>> Strub >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>>>>>>>>> john.d.ament at gmail.com>: >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's >>>>>>>>>>> nothing in this spec that says it wouldn't be propagated. However, there's >>>>>>>>>>> nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>>>>>>>>> transaction state. Considering the age of the spec, I'm not surprised to >>>>>>>>>>> see that. The worst part is that right now, outside of the ASF, all other >>>>>>>>>>> EE7 impls seem to be using the RI for concurrency. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the >>>>>>>>>>> only thing that's actually propagated is the transaction. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> John >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>>> >>>>>> I am re-reading the spec end to end again right now. So >>>>>>>>>>> far it seems I have remembered everything correctly. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> You should read over section 2.3. What it is saying is >>>>>>>>>>> that a container implementing the Java EE concurrency utilities should >>>>>>>>>>> ensure whatever contextual information is needed for managed components to >>>>>>>>>>> work correctly should be propagated automatically. For the correct >>>>>>>>>>> implementation of CDI scopes, this should also mean any currently active >>>>>>>>>>> scopes. The section you are referring to is basically implying that >>>>>>>>>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>>>>>>>>> reliably since beans could go out of scope before the thread finishes - for >>>>>>>>>>> example if the request ends). >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> This does not have anything to do with the context >>>>>>>>>>> service per se. The context service is an SPI of sorts to allow end user >>>>>>>>>>> developers to do for their own applications what the container does behind >>>>>>>>>>> the scenes for managed component context propagation. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> I'll read over the entire spec to see if there is >>>>>>>>>>> anything to contradict this. If that's not the case what Romain is >>>>>>>>>>> describing is most likely an implementation specific bug that did not take >>>>>>>>>>> into account CDI scope propagation. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>>>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> Reza, >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>>>>>>>>> specific section you had in mind? The only references to CDI were near the >>>>>>>>>>> beginning warning users to not use Request/Session scoped beans as tasks >>>>>>>>>>> since the outer most context may be destroyed before the work is done. >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> I have a feeling what you're referring to is the context >>>>>>>>>>> service: >>>>>>>>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> If that's the case, then basically this should work OOTB >>>>>>>>>>> right? >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>>>>>> >>>>>>> task = contextService.createContextualProxy(task, >>>>>>>>>>> Task.class); >>>>>>>>>>> >>>>>>> executor.submit(task); >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> Is that about right? >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> John >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text >>>>>>>>>>> in detail? What does it say about managed component context propagation? >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> Without actually doing that further discussing this is >>>>>>>>>>> just taking shots in the dark. As an implementer it should not surprise you >>>>>>>>>>> that this might simply be a bug because the person implementing the >>>>>>>>>>> concurrency utilities for the EE runtime was not told about what to copy >>>>>>>>>>> over into the new thread for CDI to work correctly. >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman < >>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing >>>>>>>>>>> that the EE concurrency spec is intended for. It is supposed to copy over >>>>>>>>>>> everything from the underlying thread local context into the new thread for >>>>>>>>>>> all EE managed components to function. Since CDI beans are also EE >>>>>>>>>>> container managed, it also applies to CDI beans as well. The EE vendor is >>>>>>>>>>> supposed to make sure this works properly. >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically >>>>>>>>>>> lists APIs for which thread context propagation should work. If this >>>>>>>>>>> doesn't work in a specific implementation it's most likely because they >>>>>>>>>>> didn't take CDI into account in their own EE concurrency implementation. >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it >>>>>>>>>>> quite easily and @RequestScoped which is *used* today is sadly a >>>>>>>>>>> @ThreadLocalScoped badly named. So to solve it we would need another scope >>>>>>>>>>> as I mentionned several times on this list 100% matching servlet instances >>>>>>>>>>> lifecycles (on a pure CDI side we have the same issue for sessions which >>>>>>>>>>> are recycled during a request, the session scope is corrupted *by spec* in >>>>>>>>>>> term of user behavior). >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>>>>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> The section of the spec you link to makes no >>>>>>>>>>> references to threads. 6.3 makes some notes about normal scopes and >>>>>>>>>>> threads, and specifically says that a context is bound to one or more >>>>>>>>>>> threads. >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> I think what's happened is that over the years, people >>>>>>>>>>> have simply bound HTTP Request == single thread, but when async processing >>>>>>>>>>> was introduced no one thought to clarify that the spawning of a child >>>>>>>>>>> thread from the original HTTP request retains the parent's context. >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> This is another requested feature, but looks more like >>>>>>>>>>> a bug or gap in the spec. >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> John >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman < >>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE >>>>>>>>>>> concurrency is generic enough for implementations to also be able to cover >>>>>>>>>>> CDI scopes or any other Java EE API context propagation needs. This means >>>>>>>>>>> the issue needs to be solved at the individual implementation level. >>>>>>>>>>> Changing anything in the spec is probably just unnecessary ceremony in this >>>>>>>>>>> case. >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for >>>>>>>>>>> "EE" users, 2. CDI still prevent it to work since it would violate the spec >>>>>>>>>>> to propagate it while request scope is bound to another thread ( >>>>>>>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>>>>>>> handles async listener but not the main AsyncContext part). >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the >>>>>>>>>>> specification text. This might indeed just be an implementation bug. The EE >>>>>>>>>>> concurrency utilities are supposed to be copying all relevant context. If >>>>>>>>>>> this is an issue than it has to be that it is not copying enough of the >>>>>>>>>>> HTTP request context for CDI to work. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but >>>>>>>>>>> needed to reverse. From my understanding ee concurrency utilities was done >>>>>>>>>>> in a time CDI was not there so it just ignored it somehow and it hasnt been >>>>>>>>>>> updated when integrated to the spec. Now with the wording of the CDI - and >>>>>>>>>>> TCK - it is impossible to make it working since request scope is bound the >>>>>>>>>>> thre request thread - and not the request. Side note: same applies to >>>>>>>>>>> session scope and conversation. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light >>>>>>>>>>> here since they implement essentially this whole stack? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit >>>>>>>>>>> simpler? It's important to make the case for how likely this is supposed to >>>>>>>>>>> occur in most business applications. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor >>>>>>>>>>> service is propagating thread local request contexts correctly what other >>>>>>>>>>> solution are you proposing? Did you check the specification? How sure are >>>>>>>>>>> you that this isn't simply an implementation bug? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to >>>>>>>>>>> be preserving all relevant parts of the EE context? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That >>>>>>>>>>> was the first impl I did then Mark pointed out it was violating CDI spec >>>>>>>>>>> and request scope definition. There is a kind of contracdiction there cause >>>>>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>>>>>> tackle it. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> does >>>>>>>>>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>>>>> >>>>>>>>>>>> try { >>>>>>>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>> >>>>>>>>>>>> } finally { >>>>>>>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context >>>>>>>>>>> pushing (cause of injections nature you are not supposed to know what to >>>>>>>>>>> push in the context when going async). >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | >>>>>>>>>>> Tomitriber >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of >>>>>>>>>>> the proposed solution so we can all follow and discuss this? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability >>>>>>>>>>> to inherit a cdi scope. Idea is to follow request scope more than cdi spec >>>>>>>>>>> allows. First thought it was a concurrency utilities thing but Reza >>>>>>>>>>> mentionned can be a CDI one so here it is. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, >>>>>>>>>>> I do some set on it. The i go async (AsyncContext) and trigger a task in >>>>>>>>>>> another thread. It would be neat - and mandatory in some case by the loose >>>>>>>>>>> coupling nature of CDI - to get the *same* MyBean *instance* in this >>>>>>>>>>> thread. With a direct dependency you can easily use message passing pattern >>>>>>>>>>> - but you loose the loose coupling cause you need to know until which level >>>>>>>>>>> you unwrap, think t principal case which has 2-3 proxies!. However in >>>>>>>>>>> practice you have a lot of undirect dependencies, in particular with >>>>>>>>>>> enterprise concerns (auditing, security...) so you can't really do it >>>>>>>>>>> easily/naturally. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of >>>>>>>>>>> push/pop an existing context in a thread - wrappers doing it on a >>>>>>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse >>>>>>>>>>> a "context context" (its current instances map) in another thread the more >>>>>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>>>>> question for now. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | >>>>>>>>>>> Tomitriber >>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/de72032f/attachment-0001.html From reza_rahman at lycos.com Tue Mar 8 11:55:11 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 11:55:11 -0500 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: I am honestly not sure this will break much since the existing definition is sufficiently ambiguous. If we really have to have different semantics, it's far better to just have a flag on existing annotations rather than introduce a whole new mostly duplicate API set. > On Mar 8, 2016, at 11:46 AM, Romain Manni-Bucau wrote: > > is a flag an option? @RequestScoped(inherited = true) > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2016-03-08 17:44 GMT+01:00 Antoine Sabot-Durand : >> As we already discussed during async event debate, we really should think about propagating normal scopes to be align on servlet and prepare CDI for reactive programming. >> We can't break the way existing built-in normal scopes work today (no propagating and ApplicationScoped being shared) but nothing prevent us to introduce new normal scope supporting propagation (@AsyncRequestScoped for instance). >> >>> Le mar. 8 mars 2016 ? 17:38, Romain Manni-Bucau a ?crit : >>> For Servlet 3.1 I don't have much doubts on the beneficial side but for the other cases I'm sure it would break a lot of code written on EE 6 or 7 where @RequestScoped beans have been used as thread local intances. So typically a HTTP request or JMS message calling an @Asynchronous EJB would break apps if you decide to propagate the context now. Same for websockets - which still don't have a scope - but in a lighter way since it is not yet mainstream. >>> >>> Even if such change makes sense it shouldn't be done without widely asking users to acknowledge it. Doing it is much more work and wider than the original mail so maybe it should be discussed in two steps. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2016-03-08 17:00 GMT+01:00 Paul Benedict : >>>> I agree with Stephan. Since the introduction of asynchronous processing in Servlet 3.1, the 1:1 assumption between request-thread has been removed. A "request" should not be synonymous with a single thread anymore; but the entire request operation. >>>> >>>> Cheers, >>>> Paul >>>> >>>>> On Tue, Mar 8, 2016 at 9:55 AM, Stephan Knitelius wrote: >>>>> I am not sure I am following you 100%. >>>>> >>>>> For me a request is anything which comes into the context of the application. No matter if it comes in via Servlet, WebSockets, JMS, Remote EJB, etc... >>>>> >>>>> The request scope should be propagated to all asynchronous operations launched within that call, terminating it when all request associated asynchronous operations are completed. >>>>> >>>>> Knitti >>>>> >>>>> >>>>> >>>>>> On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau wrote: >>>>>> Yes (just making clear it is servlet related asynchronism - ie AsyncContext#complete() is called and listeners are completed - to avoid the ambiguity of @Async, JMS etc.. where request scope is now) >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>> >>>>>> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : >>>>>>> >>>>>>> >>>>>>> So the proposal would be to enable propagation of request scope to asynchronous threads and keep it alive until all concurrent processes referencing it are completed? >>>>>>> >>>>>>> >>>>>>>> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau wrote: >>>>>>>> will try to not hijack this thread and create another one for thread scope ;). >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>>>>>> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >>>>>>>>> Your mention of thread local scope is interesting indeed. We had just such a scope in Resin called @ThreadScoped, completely separate from @RequestScoped. As memory serves though even in Resin we basically implemented @RequestScoped as thread local scope. >>>>>>>>> >>>>>>>>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau wrote: >>>>>>>>>> >>>>>>>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>>>>>>>>>> I never assume anything related to HTTP requests are ever thread safe. I don't know many folks that would make that assumption either. I think this consideration is not a significant one. The spec, docs and tutorials out there are pretty clear about the fact that none of the CDI scopes are really thread safe in the way EJBs are. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It is one of the main usage of request scoped in practise. It doesn't come from HTTP side but since it is used this way in several other places (like batch) it is now assumed everywhere. It has even been promoted by several CDI projects so sadly it is to be taken into account now even if I agree it is not the state we should be at today. If changed - servlet 3.0/3.1 broke several things to make the spec cleaner or more explicit so I guess CDI can work on this - it should be made very explicit in the spec and we should study a "thread local scope" replacement to fill the gap and propose a solution to this practise judged abusive. >>>>>>>>>> >>>>>>>>>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau wrote: >>>>>>>>>>>> >>>>>>>>>>>> In TomEE we restart/stop it around most of hooks including the runnable passed to start(Runnable) of the AsyncContext but keeping the now widespread ThreadLocal nature of the @RequestScoped (= not the same as the startAsync() call sadly). This passes CDI TCK but for the particular request scope I would be happy to clarify it is actually bound to the request and just reuse the same instances. In term of side effects it would breaks the current thread safety users assume (with reason or not) but I have no real clue if it would really breaks apps or not. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>> >>>>>>>>>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>>>>>>>>>>> Let's hope some of the implementors weigh in on this some time soon. >>>>>>>>>>>>> >>>>>>>>>>>>> I could write some tests on this but I would have no idea if I would have uncovered a bug given the ambiguity of the current spec text. >>>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman wrote: >>>>>>>>>>>>>>> Reading over the CDI spec definition for request scoped beans, I am a tad confused. When are request scoped beans being destroyed right now? Are they just bound to the Servlet request thread and destroyed as soon as the service method returns? >>>>>>>>>>>>>> >>>>>>>>>>>>>> In case of a Servlet request (request scoped beans are also tied to other kinds of "requests"), it's indeed not clear. In practice it looks like the moment between the first ServletRequestListener#requestInitialized and ServletRequestListener#requestDestroyed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The exact scope is troublesome for security too, since in most severs the request scope (and session scope and application scope) is active when a SAM is called (the SAM gets an HttpServletRequest after all), but this is not the case in all servers. E.g. in Liberty the RequestScope starts AFTER a SAM is called. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Kind regards, >>>>>>>>>>>>>> Arjan Tijms >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> In case of asynchronous Servlets, are they kept around until the real HTTP request actually completes the same way the underlying HTTP connection is kept around? Or is that too difficult because it would require integration at a very low level with the Servlet implementation? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There's some language around asynchronous completion right now but it's not very clear what actually happens. Does the onComplete, etc asynchronous callback basically create new request scoped instances? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman wrote: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Even in the most conservative reading of this, the spec is clearly not disallowing it. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg wrote: >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> The question is whether the spec does allow us to do it. And if other containers consequently do it as well. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> If it does then I will implement it in TomEE. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> LieGrue, >>>>>>>>>>>>>>> >> strub >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman : >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> What this is saying is that it is not recommended to use them because of the possible life-cycle mismatch. If they are not supposed to work at all, the specification would have simply stated it won't work. >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> Anyway personally I have no reason to further discuss this. I'm going to try to find a way to get this done for developers sooner rather than later. If TomEE does not want to do it, too bad for developers. >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> " >>>>>>>>>>>>>>> >>>> Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. >>>>>>>>>>>>>>> >>>> " >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> States that the context is not inherited, is that what you mean? >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> Romain Manni-Bucau >>>>>>>>>>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>> >>>> The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >>>>>>>>>>>>>>> >>>>> Specifically >>>>>>>>>>>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>>>>>>>>>>> >>>>> No session e.g. , new TX, etc >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> LieGrue, >>>>>>>>>>>>>>> >>>>> Strub >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> John >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >>>>>>>>>>>>>>> >>>>>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> Reza, >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> If that's the case, then basically this should work OOTB right? >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>>>>>>>>>> >>>>>>> task = contextService.createContextualProxy(task, Task.class); >>>>>>>>>>>>>>> >>>>>>> executor.submit(task); >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> Is that about right? >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> John >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>>>>>>>>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> John >>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>>>>>>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>>>>>>>>> >>>>>>>>>>>> try { >>>>>>>>>>>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>>>>>> >>>>>>>>>>>> } finally { >>>>>>>>>>>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>>>>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>>>>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>>>>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/2ba785b3/attachment-0001.html From antoine at sabot-durand.net Tue Mar 8 11:55:51 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 08 Mar 2016 16:55:51 +0000 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: I'm not a big fan of this option: not very clear for end user and introducing a member in exisitng scope annotaion could bring issues. But please Romain, feel free to fill a ticket a propose something. The main problem is more the implementation than the API anyway ;). Antoine Le mar. 8 mars 2016 ? 17:46, Romain Manni-Bucau a ?crit : > is a flag an option? @RequestScoped(inherited = true) > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-08 17:44 GMT+01:00 Antoine Sabot-Durand > : > >> As we already discussed during async event debate, we really should think >> about propagating normal scopes to be align on servlet and prepare CDI for >> reactive programming. >> We can't break the way existing built-in normal scopes work today (no >> propagating and ApplicationScoped being shared) but nothing prevent us to >> introduce new normal scope supporting propagation (@AsyncRequestScoped for >> instance). >> >> Le mar. 8 mars 2016 ? 17:38, Romain Manni-Bucau >> a ?crit : >> >>> For Servlet 3.1 I don't have much doubts on the beneficial side but for >>> the other cases I'm sure it would break a lot of code written on EE 6 or 7 >>> where @RequestScoped beans have been used as thread local intances. So >>> typically a HTTP request or JMS message calling an @Asynchronous EJB would >>> break apps if you decide to propagate the context now. Same for websockets >>> - which still don't have a scope - but in a lighter way since it is not yet >>> mainstream. >>> >>> Even if such change makes sense it shouldn't be done >>> without widely asking users to acknowledge it. Doing it is much more work >>> and wider than the original mail so maybe it should be discussed in two >>> steps. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-03-08 17:00 GMT+01:00 Paul Benedict : >>> >>>> I agree with Stephan. Since the introduction of asynchronous processing >>>> in Servlet 3.1, the 1:1 assumption between request-thread has been removed. >>>> A "request" should not be synonymous with a single thread anymore; but the >>>> entire request operation. >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Tue, Mar 8, 2016 at 9:55 AM, Stephan Knitelius < >>>> stephan at knitelius.com> wrote: >>>> >>>>> I am not sure I am following you 100%. >>>>> >>>>> For me a request is anything which comes into the context of the >>>>> application. No matter if it comes in via Servlet, WebSockets, JMS, Remote >>>>> EJB, etc... >>>>> >>>>> The request scope should be propagated to all asynchronous operations >>>>> launched within that call, terminating it when all request associated >>>>> asynchronous operations are completed. >>>>> >>>>> Knitti >>>>> >>>>> >>>>> >>>>> On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau >>>>> wrote: >>>>> >>>>>> Yes (just making clear it is servlet related asynchronism - ie >>>>>> AsyncContext#complete() is called and listeners are completed - to avoid >>>>>> the ambiguity of @Async, JMS etc.. where request scope is now) >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog >>>>>> | Github >>>>>> | LinkedIn >>>>>> | Tomitriber >>>>>> >>>>>> >>>>>> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : >>>>>> >>>>>>> >>>>>>> >>>>>>> So the proposal would be to enable propagation of request scope to >>>>>>> asynchronous threads and keep it alive until all concurrent processes >>>>>>> referencing it are completed? >>>>>>> >>>>>>> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>>> will try to not hijack this thread and create another one for >>>>>>>> thread scope ;). >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog >>>>>>>> | Github >>>>>>>> | LinkedIn >>>>>>>> | Tomitriber >>>>>>>> >>>>>>>> >>>>>>>> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >>>>>>>> >>>>>>>>> Your mention of thread local scope is interesting indeed. We had >>>>>>>>> just such a scope in Resin called @ThreadScoped, completely separate from >>>>>>>>> @RequestScoped. As memory serves though even in Resin we basically >>>>>>>>> implemented @RequestScoped as thread local scope. >>>>>>>>> >>>>>>>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>>>>>>>> >>>>>>>>>> I never assume anything related to HTTP requests are ever thread >>>>>>>>>> safe. I don't know many folks that would make that assumption either. I >>>>>>>>>> think this consideration is not a significant one. The spec, docs and >>>>>>>>>> tutorials out there are pretty clear about the fact that none of the CDI >>>>>>>>>> scopes are really thread safe in the way EJBs are. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> It is one of the main usage of request scoped in practise. It >>>>>>>>> doesn't come from HTTP side but since it is used this way in several other >>>>>>>>> places (like batch) it is now assumed everywhere. It has even been promoted >>>>>>>>> by several CDI projects so sadly it is to be taken into account now even if >>>>>>>>> I agree it is not the state we should be at today. If changed - servlet >>>>>>>>> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I >>>>>>>>> guess CDI can work on this - it should be made very explicit in the spec >>>>>>>>> and we should study a "thread local scope" replacement to fill the gap and >>>>>>>>> propose a solution to this practise judged abusive. >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> In TomEE we restart/stop it around most of hooks including the >>>>>>>>>> runnable passed to start(Runnable) of the AsyncContext but keeping the now >>>>>>>>>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >>>>>>>>>> startAsync() call sadly). This passes CDI TCK but for the particular >>>>>>>>>> request scope I would be happy to clarify it is actually bound to the >>>>>>>>>> request and just reuse the same instances. In term of side effects it would >>>>>>>>>> breaks the current thread safety users assume (with reason or not) but I >>>>>>>>>> have no real clue if it would really breaks apps or not. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau | Blog >>>>>>>>>> | Github >>>>>>>>>> | LinkedIn >>>>>>>>>> | Tomitriber >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>>>>>>>> >>>>>>>>>>> Let's hope some of the implementors weigh in on this some time >>>>>>>>>>> soon. >>>>>>>>>>> >>>>>>>>>>> I could write some tests on this but I would have no idea if I >>>>>>>>>>> would have uncovered a bug given the ambiguity of the current spec text. >>>>>>>>>>> >>>>>>>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman < >>>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Reading over the CDI spec definition for request scoped beans, >>>>>>>>>>>> I am a tad confused. When are request scoped beans being destroyed right >>>>>>>>>>>> now? Are they just bound to the Servlet request thread and destroyed as >>>>>>>>>>>> soon as the service method returns? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In case of a Servlet request (request scoped beans are also tied >>>>>>>>>>> to other kinds of "requests"), it's indeed not clear. In practice it looks >>>>>>>>>>> like the moment between the first ServletRequestListener#requestInitialized >>>>>>>>>>> and ServletRequestListener#requestDestroyed. >>>>>>>>>>> >>>>>>>>>>> The exact scope is troublesome for security too, since in most >>>>>>>>>>> severs the request scope (and session scope and application scope) is >>>>>>>>>>> active when a SAM is called (the SAM gets an HttpServletRequest after all), >>>>>>>>>>> but this is not the case in all servers. E.g. in Liberty the RequestScope >>>>>>>>>>> starts AFTER a SAM is called. >>>>>>>>>>> >>>>>>>>>>> Kind regards, >>>>>>>>>>> Arjan Tijms >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> In case of asynchronous Servlets, are they kept around until >>>>>>>>>>>> the real HTTP request actually completes the same way the underlying HTTP >>>>>>>>>>>> connection is kept around? Or is that too difficult because it would >>>>>>>>>>>> require integration at a very low level with the Servlet implementation? >>>>>>>>>>>> >>>>>>>>>>>> There's some language around asynchronous completion right now >>>>>>>>>>>> but it's not very clear what actually happens. Does the onComplete, etc >>>>>>>>>>>> asynchronous callback basically create new request scoped instances? >>>>>>>>>>>> >>>>>>>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > Even in the most conservative reading of this, the spec is >>>>>>>>>>>> clearly not disallowing it. >>>>>>>>>>>> > >>>>>>>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg < >>>>>>>>>>>> struberg at yahoo.de> wrote: >>>>>>>>>>>> >> >>>>>>>>>>>> >> The question is whether the spec does allow us to do it. And >>>>>>>>>>>> if other containers consequently do it as well. >>>>>>>>>>>> >> >>>>>>>>>>>> >> If it does then I will implement it in TomEE. >>>>>>>>>>>> >> >>>>>>>>>>>> >> LieGrue, >>>>>>>>>>>> >> strub >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> What this is saying is that it is not recommended to use >>>>>>>>>>>> them because of the possible life-cycle mismatch. If they are not supposed >>>>>>>>>>>> to work at all, the specification would have simply stated it won't work. >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Anyway personally I have no reason to further discuss this. >>>>>>>>>>>> I'm going to try to find a way to get this done for developers sooner >>>>>>>>>>>> rather than later. If TomEE does not want to do it, too bad for developers. >>>>>>>>>>>> >>> >>>>>>>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> " >>>>>>>>>>>> >>>> Tasks that are submitted to a managed instance of >>>>>>>>>>>> ExecutorService may still be running after the lifecycle of the submitting >>>>>>>>>>>> component. Therefore, CDI beans with a scope of @RequestScoped, >>>>>>>>>>>> @SessionScoped, or @ConversationScoped are not recommended to use as tasks >>>>>>>>>>>> as it cannot be guaranteed that the tasks will complete before the CDI >>>>>>>>>>>> context is destroyed. >>>>>>>>>>>> >>>> " >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> States that the context is not inherited, is that what you >>>>>>>>>>>> mean? >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Romain Manni-Bucau >>>>>>>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>>> The specification currently references pretty much all the >>>>>>>>>>>> major CDI scopes specifically with the issue of propagation and lifecycle >>>>>>>>>>>> in mind. Please see section 2.3. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg < >>>>>>>>>>>> struberg at yahoo.de> wrote: >>>>>>>>>>>> >>>>> Specifically >>>>>>>>>>>> >>>>> The containers mimic ejb for propagation for a good >>>>>>>>>>>> reason! >>>>>>>>>>>> >>>>> No session e.g. , new TX, etc >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Sadly the concurrency utilis only mention >>>>>>>>>>>> @ApplicationScoped, so the Request Context not only doesn't get propagated >>>>>>>>>>>> (which is good), but also doesn't get set up (which is crap). >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> LieGrue, >>>>>>>>>>>> >>>>> Strub >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>>>>>>>>>> john.d.ament at gmail.com>: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's >>>>>>>>>>>> nothing in this spec that says it wouldn't be propagated. However, there's >>>>>>>>>>>> nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>>>>>>>>>> transaction state. Considering the age of the spec, I'm not surprised to >>>>>>>>>>>> see that. The worst part is that right now, outside of the ASF, all other >>>>>>>>>>>> EE7 impls seem to be using the RI for concurrency. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the >>>>>>>>>>>> only thing that's actually propagated is the transaction. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> John >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>>>> >>>>>> I am re-reading the spec end to end again right now. So >>>>>>>>>>>> far it seems I have remembered everything correctly. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> You should read over section 2.3. What it is saying is >>>>>>>>>>>> that a container implementing the Java EE concurrency utilities should >>>>>>>>>>>> ensure whatever contextual information is needed for managed components to >>>>>>>>>>>> work correctly should be propagated automatically. For the correct >>>>>>>>>>>> implementation of CDI scopes, this should also mean any currently active >>>>>>>>>>>> scopes. The section you are referring to is basically implying that >>>>>>>>>>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>>>>>>>>>> reliably since beans could go out of scope before the thread finishes - for >>>>>>>>>>>> example if the request ends). >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> This does not have anything to do with the context >>>>>>>>>>>> service per se. The context service is an SPI of sorts to allow end user >>>>>>>>>>>> developers to do for their own applications what the container does behind >>>>>>>>>>>> the scenes for managed component context propagation. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> I'll read over the entire spec to see if there is >>>>>>>>>>>> anything to contradict this. If that's not the case what Romain is >>>>>>>>>>>> describing is most likely an implementation specific bug that did not take >>>>>>>>>>>> into account CDI scope propagation. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>>>>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Reza, >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>>>>>>>>>> specific section you had in mind? The only references to CDI were near the >>>>>>>>>>>> beginning warning users to not use Request/Session scoped beans as tasks >>>>>>>>>>>> since the outer most context may be destroyed before the work is done. >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> I have a feeling what you're referring to is the >>>>>>>>>>>> context service: >>>>>>>>>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> If that's the case, then basically this should work >>>>>>>>>>>> OOTB right? >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>>>>>>> >>>>>>> task = contextService.createContextualProxy(task, >>>>>>>>>>>> Task.class); >>>>>>>>>>>> >>>>>>> executor.submit(task); >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Is that about right? >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> John >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec >>>>>>>>>>>> text in detail? What does it say about managed component context >>>>>>>>>>>> propagation? >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Without actually doing that further discussing this is >>>>>>>>>>>> just taking shots in the dark. As an implementer it should not surprise you >>>>>>>>>>>> that this might simply be a bug because the person implementing the >>>>>>>>>>>> concurrency utilities for the EE runtime was not told about what to copy >>>>>>>>>>>> over into the new thread for CDI to work correctly. >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing >>>>>>>>>>>> that the EE concurrency spec is intended for. It is supposed to copy over >>>>>>>>>>>> everything from the underlying thread local context into the new thread for >>>>>>>>>>>> all EE managed components to function. Since CDI beans are also EE >>>>>>>>>>>> container managed, it also applies to CDI beans as well. The EE vendor is >>>>>>>>>>>> supposed to make sure this works properly. >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically >>>>>>>>>>>> lists APIs for which thread context propagation should work. If this >>>>>>>>>>>> doesn't work in a specific implementation it's most likely because they >>>>>>>>>>>> didn't take CDI into account in their own EE concurrency implementation. >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it >>>>>>>>>>>> quite easily and @RequestScoped which is *used* today is sadly a >>>>>>>>>>>> @ThreadLocalScoped badly named. So to solve it we would need another scope >>>>>>>>>>>> as I mentionned several times on this list 100% matching servlet instances >>>>>>>>>>>> lifecycles (on a pure CDI side we have the same issue for sessions which >>>>>>>>>>>> are recycled during a request, the session scope is corrupted *by spec* in >>>>>>>>>>>> term of user behavior). >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>>>>>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> The section of the spec you link to makes no >>>>>>>>>>>> references to threads. 6.3 makes some notes about normal scopes and >>>>>>>>>>>> threads, and specifically says that a context is bound to one or more >>>>>>>>>>>> threads. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> I think what's happened is that over the years, >>>>>>>>>>>> people have simply bound HTTP Request == single thread, but when async >>>>>>>>>>>> processing was introduced no one thought to clarify that the spawning of a >>>>>>>>>>>> child thread from the original HTTP request retains the parent's context. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> This is another requested feature, but looks more >>>>>>>>>>>> like a bug or gap in the spec. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> John >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE >>>>>>>>>>>> concurrency is generic enough for implementations to also be able to cover >>>>>>>>>>>> CDI scopes or any other Java EE API context propagation needs. This means >>>>>>>>>>>> the issue needs to be solved at the individual implementation level. >>>>>>>>>>>> Changing anything in the spec is probably just unnecessary ceremony in this >>>>>>>>>>>> case. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for >>>>>>>>>>>> "EE" users, 2. CDI still prevent it to work since it would violate the spec >>>>>>>>>>>> to propagate it while request scope is bound to another thread ( >>>>>>>>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>>>>>>>> handles async listener but not the main AsyncContext part). >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the >>>>>>>>>>>> specification text. This might indeed just be an implementation bug. The EE >>>>>>>>>>>> concurrency utilities are supposed to be copying all relevant context. If >>>>>>>>>>>> this is an issue than it has to be that it is not copying enough of the >>>>>>>>>>>> HTTP request context for CDI to work. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working >>>>>>>>>>>> but needed to reverse. From my understanding ee concurrency utilities was >>>>>>>>>>>> done in a time CDI was not there so it just ignored it somehow and it hasnt >>>>>>>>>>>> been updated when integrated to the spec. Now with the wording of the CDI - >>>>>>>>>>>> and TCK - it is impossible to make it working since request scope is bound >>>>>>>>>>>> the thre request thread - and not the request. Side note: same applies to >>>>>>>>>>>> session scope and conversation. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light >>>>>>>>>>>> here since they implement essentially this whole stack? >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit >>>>>>>>>>>> simpler? It's important to make the case for how likely this is supposed to >>>>>>>>>>>> occur in most business applications. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor >>>>>>>>>>>> service is propagating thread local request contexts correctly what other >>>>>>>>>>>> solution are you proposing? Did you check the specification? How sure are >>>>>>>>>>>> you that this isn't simply an implementation bug? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed >>>>>>>>>>>> to be preserving all relevant parts of the EE context? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That >>>>>>>>>>>> was the first impl I did then Mark pointed out it was violating CDI spec >>>>>>>>>>>> and request scope definition. There is a kind of contracdiction there cause >>>>>>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>>>>>>> tackle it. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> does >>>>>>>>>>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>>>>>> >>>>>>>>>>>> try { >>>>>>>>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>>> >>>>>>>>>>>> } finally { >>>>>>>>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible >>>>>>>>>>>> context pushing (cause of injections nature you are not supposed to know >>>>>>>>>>>> what to push in the context when going async). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | >>>>>>>>>>>> Tomitriber >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of >>>>>>>>>>>> the proposed solution so we can all follow and discuss this? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability >>>>>>>>>>>> to inherit a cdi scope. Idea is to follow request scope more than cdi spec >>>>>>>>>>>> allows. First thought it was a concurrency utilities thing but Reza >>>>>>>>>>>> mentionned can be a CDI one so here it is. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is >>>>>>>>>>>> @RequestScoped, I do some set on it. The i go async (AsyncContext) and >>>>>>>>>>>> trigger a task in another thread. It would be neat - and mandatory in some >>>>>>>>>>>> case by the loose coupling nature of CDI - to get the *same* MyBean >>>>>>>>>>>> *instance* in this thread. With a direct dependency you can easily use >>>>>>>>>>>> message passing pattern - but you loose the loose coupling cause you need >>>>>>>>>>>> to know until which level you unwrap, think t principal case which has 2-3 >>>>>>>>>>>> proxies!. However in practice you have a lot of undirect dependencies, in >>>>>>>>>>>> particular with enterprise concerns (auditing, security...) so you can't >>>>>>>>>>>> really do it easily/naturally. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of >>>>>>>>>>>> push/pop an existing context in a thread - wrappers doing it on a >>>>>>>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse >>>>>>>>>>>> a "context context" (its current instances map) in another thread the more >>>>>>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>>>>>> question for now. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | >>>>>>>>>>>> Tomitriber >>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/5fab1f40/attachment-0001.html From pbenedict at apache.org Tue Mar 8 11:57:48 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 8 Mar 2016 10:57:48 -0600 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: Given that @WebServlet(asyncSupport=true) enables asynchronous behavior, I opine that @RequestScoped should do the same to opt-in to asynchronous propagation. That seems like a reasonable middle ground to me. Cheers, Paul On Tue, Mar 8, 2016 at 10:55 AM, Reza Rahman wrote: > I am honestly not sure this will break much since the existing definition > is sufficiently ambiguous. If we really have to have different semantics, > it's far better to just have a flag on existing annotations rather than > introduce a whole new mostly duplicate API set. > > On Mar 8, 2016, at 11:46 AM, Romain Manni-Bucau > wrote: > > is a flag an option? @RequestScoped(inherited = true) > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-08 17:44 GMT+01:00 Antoine Sabot-Durand > : > >> As we already discussed during async event debate, we really should think >> about propagating normal scopes to be align on servlet and prepare CDI for >> reactive programming. >> We can't break the way existing built-in normal scopes work today (no >> propagating and ApplicationScoped being shared) but nothing prevent us to >> introduce new normal scope supporting propagation (@AsyncRequestScoped for >> instance). >> >> Le mar. 8 mars 2016 ? 17:38, Romain Manni-Bucau >> a ?crit : >> >>> For Servlet 3.1 I don't have much doubts on the beneficial side but for >>> the other cases I'm sure it would break a lot of code written on EE 6 or 7 >>> where @RequestScoped beans have been used as thread local intances. So >>> typically a HTTP request or JMS message calling an @Asynchronous EJB would >>> break apps if you decide to propagate the context now. Same for websockets >>> - which still don't have a scope - but in a lighter way since it is not yet >>> mainstream. >>> >>> Even if such change makes sense it shouldn't be done >>> without widely asking users to acknowledge it. Doing it is much more work >>> and wider than the original mail so maybe it should be discussed in two >>> steps. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-03-08 17:00 GMT+01:00 Paul Benedict : >>> >>>> I agree with Stephan. Since the introduction of asynchronous processing >>>> in Servlet 3.1, the 1:1 assumption between request-thread has been removed. >>>> A "request" should not be synonymous with a single thread anymore; but the >>>> entire request operation. >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Tue, Mar 8, 2016 at 9:55 AM, Stephan Knitelius < >>>> stephan at knitelius.com> wrote: >>>> >>>>> I am not sure I am following you 100%. >>>>> >>>>> For me a request is anything which comes into the context of the >>>>> application. No matter if it comes in via Servlet, WebSockets, JMS, Remote >>>>> EJB, etc... >>>>> >>>>> The request scope should be propagated to all asynchronous operations >>>>> launched within that call, terminating it when all request associated >>>>> asynchronous operations are completed. >>>>> >>>>> Knitti >>>>> >>>>> >>>>> >>>>> On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau >>>>> wrote: >>>>> >>>>>> Yes (just making clear it is servlet related asynchronism - ie >>>>>> AsyncContext#complete() is called and listeners are completed - to avoid >>>>>> the ambiguity of @Async, JMS etc.. where request scope is now) >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog >>>>>> | Github >>>>>> | LinkedIn >>>>>> | Tomitriber >>>>>> >>>>>> >>>>>> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : >>>>>> >>>>>>> >>>>>>> >>>>>>> So the proposal would be to enable propagation of request scope to >>>>>>> asynchronous threads and keep it alive until all concurrent processes >>>>>>> referencing it are completed? >>>>>>> >>>>>>> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>>> will try to not hijack this thread and create another one for >>>>>>>> thread scope ;). >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog >>>>>>>> | Github >>>>>>>> | LinkedIn >>>>>>>> | Tomitriber >>>>>>>> >>>>>>>> >>>>>>>> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >>>>>>>> >>>>>>>>> Your mention of thread local scope is interesting indeed. We had >>>>>>>>> just such a scope in Resin called @ThreadScoped, completely separate from >>>>>>>>> @RequestScoped. As memory serves though even in Resin we basically >>>>>>>>> implemented @RequestScoped as thread local scope. >>>>>>>>> >>>>>>>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>>>>>>>> >>>>>>>>>> I never assume anything related to HTTP requests are ever thread >>>>>>>>>> safe. I don't know many folks that would make that assumption either. I >>>>>>>>>> think this consideration is not a significant one. The spec, docs and >>>>>>>>>> tutorials out there are pretty clear about the fact that none of the CDI >>>>>>>>>> scopes are really thread safe in the way EJBs are. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> It is one of the main usage of request scoped in practise. It >>>>>>>>> doesn't come from HTTP side but since it is used this way in several other >>>>>>>>> places (like batch) it is now assumed everywhere. It has even been promoted >>>>>>>>> by several CDI projects so sadly it is to be taken into account now even if >>>>>>>>> I agree it is not the state we should be at today. If changed - servlet >>>>>>>>> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I >>>>>>>>> guess CDI can work on this - it should be made very explicit in the spec >>>>>>>>> and we should study a "thread local scope" replacement to fill the gap and >>>>>>>>> propose a solution to this practise judged abusive. >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> In TomEE we restart/stop it around most of hooks including the >>>>>>>>>> runnable passed to start(Runnable) of the AsyncContext but keeping the now >>>>>>>>>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >>>>>>>>>> startAsync() call sadly). This passes CDI TCK but for the particular >>>>>>>>>> request scope I would be happy to clarify it is actually bound to the >>>>>>>>>> request and just reuse the same instances. In term of side effects it would >>>>>>>>>> breaks the current thread safety users assume (with reason or not) but I >>>>>>>>>> have no real clue if it would really breaks apps or not. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau | Blog >>>>>>>>>> | Github >>>>>>>>>> | LinkedIn >>>>>>>>>> | Tomitriber >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>>>>>>>> >>>>>>>>>>> Let's hope some of the implementors weigh in on this some time >>>>>>>>>>> soon. >>>>>>>>>>> >>>>>>>>>>> I could write some tests on this but I would have no idea if I >>>>>>>>>>> would have uncovered a bug given the ambiguity of the current spec text. >>>>>>>>>>> >>>>>>>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman < >>>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Reading over the CDI spec definition for request scoped beans, >>>>>>>>>>>> I am a tad confused. When are request scoped beans being destroyed right >>>>>>>>>>>> now? Are they just bound to the Servlet request thread and destroyed as >>>>>>>>>>>> soon as the service method returns? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In case of a Servlet request (request scoped beans are also tied >>>>>>>>>>> to other kinds of "requests"), it's indeed not clear. In practice it looks >>>>>>>>>>> like the moment between the first ServletRequestListener#requestInitialized >>>>>>>>>>> and ServletRequestListener#requestDestroyed. >>>>>>>>>>> >>>>>>>>>>> The exact scope is troublesome for security too, since in most >>>>>>>>>>> severs the request scope (and session scope and application scope) is >>>>>>>>>>> active when a SAM is called (the SAM gets an HttpServletRequest after all), >>>>>>>>>>> but this is not the case in all servers. E.g. in Liberty the RequestScope >>>>>>>>>>> starts AFTER a SAM is called. >>>>>>>>>>> >>>>>>>>>>> Kind regards, >>>>>>>>>>> Arjan Tijms >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> In case of asynchronous Servlets, are they kept around until >>>>>>>>>>>> the real HTTP request actually completes the same way the underlying HTTP >>>>>>>>>>>> connection is kept around? Or is that too difficult because it would >>>>>>>>>>>> require integration at a very low level with the Servlet implementation? >>>>>>>>>>>> >>>>>>>>>>>> There's some language around asynchronous completion right now >>>>>>>>>>>> but it's not very clear what actually happens. Does the onComplete, etc >>>>>>>>>>>> asynchronous callback basically create new request scoped instances? >>>>>>>>>>>> >>>>>>>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > Even in the most conservative reading of this, the spec is >>>>>>>>>>>> clearly not disallowing it. >>>>>>>>>>>> > >>>>>>>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg < >>>>>>>>>>>> struberg at yahoo.de> wrote: >>>>>>>>>>>> >> >>>>>>>>>>>> >> The question is whether the spec does allow us to do it. And >>>>>>>>>>>> if other containers consequently do it as well. >>>>>>>>>>>> >> >>>>>>>>>>>> >> If it does then I will implement it in TomEE. >>>>>>>>>>>> >> >>>>>>>>>>>> >> LieGrue, >>>>>>>>>>>> >> strub >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> What this is saying is that it is not recommended to use >>>>>>>>>>>> them because of the possible life-cycle mismatch. If they are not supposed >>>>>>>>>>>> to work at all, the specification would have simply stated it won't work. >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Anyway personally I have no reason to further discuss this. >>>>>>>>>>>> I'm going to try to find a way to get this done for developers sooner >>>>>>>>>>>> rather than later. If TomEE does not want to do it, too bad for developers. >>>>>>>>>>>> >>> >>>>>>>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> " >>>>>>>>>>>> >>>> Tasks that are submitted to a managed instance of >>>>>>>>>>>> ExecutorService may still be running after the lifecycle of the submitting >>>>>>>>>>>> component. Therefore, CDI beans with a scope of @RequestScoped, >>>>>>>>>>>> @SessionScoped, or @ConversationScoped are not recommended to use as tasks >>>>>>>>>>>> as it cannot be guaranteed that the tasks will complete before the CDI >>>>>>>>>>>> context is destroyed. >>>>>>>>>>>> >>>> " >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> States that the context is not inherited, is that what you >>>>>>>>>>>> mean? >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Romain Manni-Bucau >>>>>>>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>>> The specification currently references pretty much all the >>>>>>>>>>>> major CDI scopes specifically with the issue of propagation and lifecycle >>>>>>>>>>>> in mind. Please see section 2.3. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg < >>>>>>>>>>>> struberg at yahoo.de> wrote: >>>>>>>>>>>> >>>>> Specifically >>>>>>>>>>>> >>>>> The containers mimic ejb for propagation for a good >>>>>>>>>>>> reason! >>>>>>>>>>>> >>>>> No session e.g. , new TX, etc >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Sadly the concurrency utilis only mention >>>>>>>>>>>> @ApplicationScoped, so the Request Context not only doesn't get propagated >>>>>>>>>>>> (which is good), but also doesn't get set up (which is crap). >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> LieGrue, >>>>>>>>>>>> >>>>> Strub >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>>>>>>>>>> john.d.ament at gmail.com>: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's >>>>>>>>>>>> nothing in this spec that says it wouldn't be propagated. However, there's >>>>>>>>>>>> nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>>>>>>>>>> transaction state. Considering the age of the spec, I'm not surprised to >>>>>>>>>>>> see that. The worst part is that right now, outside of the ASF, all other >>>>>>>>>>>> EE7 impls seem to be using the RI for concurrency. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the >>>>>>>>>>>> only thing that's actually propagated is the transaction. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> John >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>>>> >>>>>> I am re-reading the spec end to end again right now. So >>>>>>>>>>>> far it seems I have remembered everything correctly. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> You should read over section 2.3. What it is saying is >>>>>>>>>>>> that a container implementing the Java EE concurrency utilities should >>>>>>>>>>>> ensure whatever contextual information is needed for managed components to >>>>>>>>>>>> work correctly should be propagated automatically. For the correct >>>>>>>>>>>> implementation of CDI scopes, this should also mean any currently active >>>>>>>>>>>> scopes. The section you are referring to is basically implying that >>>>>>>>>>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>>>>>>>>>> reliably since beans could go out of scope before the thread finishes - for >>>>>>>>>>>> example if the request ends). >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> This does not have anything to do with the context >>>>>>>>>>>> service per se. The context service is an SPI of sorts to allow end user >>>>>>>>>>>> developers to do for their own applications what the container does behind >>>>>>>>>>>> the scenes for managed component context propagation. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> I'll read over the entire spec to see if there is >>>>>>>>>>>> anything to contradict this. If that's not the case what Romain is >>>>>>>>>>>> describing is most likely an implementation specific bug that did not take >>>>>>>>>>>> into account CDI scope propagation. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>>>>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Reza, >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>>>>>>>>>> specific section you had in mind? The only references to CDI were near the >>>>>>>>>>>> beginning warning users to not use Request/Session scoped beans as tasks >>>>>>>>>>>> since the outer most context may be destroyed before the work is done. >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> I have a feeling what you're referring to is the >>>>>>>>>>>> context service: >>>>>>>>>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> If that's the case, then basically this should work >>>>>>>>>>>> OOTB right? >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>>>>>>> >>>>>>> task = contextService.createContextualProxy(task, >>>>>>>>>>>> Task.class); >>>>>>>>>>>> >>>>>>> executor.submit(task); >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Is that about right? >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> John >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec >>>>>>>>>>>> text in detail? What does it say about managed component context >>>>>>>>>>>> propagation? >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Without actually doing that further discussing this is >>>>>>>>>>>> just taking shots in the dark. As an implementer it should not surprise you >>>>>>>>>>>> that this might simply be a bug because the person implementing the >>>>>>>>>>>> concurrency utilities for the EE runtime was not told about what to copy >>>>>>>>>>>> over into the new thread for CDI to work correctly. >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing >>>>>>>>>>>> that the EE concurrency spec is intended for. It is supposed to copy over >>>>>>>>>>>> everything from the underlying thread local context into the new thread for >>>>>>>>>>>> all EE managed components to function. Since CDI beans are also EE >>>>>>>>>>>> container managed, it also applies to CDI beans as well. The EE vendor is >>>>>>>>>>>> supposed to make sure this works properly. >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically >>>>>>>>>>>> lists APIs for which thread context propagation should work. If this >>>>>>>>>>>> doesn't work in a specific implementation it's most likely because they >>>>>>>>>>>> didn't take CDI into account in their own EE concurrency implementation. >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it >>>>>>>>>>>> quite easily and @RequestScoped which is *used* today is sadly a >>>>>>>>>>>> @ThreadLocalScoped badly named. So to solve it we would need another scope >>>>>>>>>>>> as I mentionned several times on this list 100% matching servlet instances >>>>>>>>>>>> lifecycles (on a pure CDI side we have the same issue for sessions which >>>>>>>>>>>> are recycled during a request, the session scope is corrupted *by spec* in >>>>>>>>>>>> term of user behavior). >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>>>>>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> The section of the spec you link to makes no >>>>>>>>>>>> references to threads. 6.3 makes some notes about normal scopes and >>>>>>>>>>>> threads, and specifically says that a context is bound to one or more >>>>>>>>>>>> threads. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> I think what's happened is that over the years, >>>>>>>>>>>> people have simply bound HTTP Request == single thread, but when async >>>>>>>>>>>> processing was introduced no one thought to clarify that the spawning of a >>>>>>>>>>>> child thread from the original HTTP request retains the parent's context. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> This is another requested feature, but looks more >>>>>>>>>>>> like a bug or gap in the spec. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> John >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE >>>>>>>>>>>> concurrency is generic enough for implementations to also be able to cover >>>>>>>>>>>> CDI scopes or any other Java EE API context propagation needs. This means >>>>>>>>>>>> the issue needs to be solved at the individual implementation level. >>>>>>>>>>>> Changing anything in the spec is probably just unnecessary ceremony in this >>>>>>>>>>>> case. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for >>>>>>>>>>>> "EE" users, 2. CDI still prevent it to work since it would violate the spec >>>>>>>>>>>> to propagate it while request scope is bound to another thread ( >>>>>>>>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>>>>>>>> handles async listener but not the main AsyncContext part). >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the >>>>>>>>>>>> specification text. This might indeed just be an implementation bug. The EE >>>>>>>>>>>> concurrency utilities are supposed to be copying all relevant context. If >>>>>>>>>>>> this is an issue than it has to be that it is not copying enough of the >>>>>>>>>>>> HTTP request context for CDI to work. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working >>>>>>>>>>>> but needed to reverse. From my understanding ee concurrency utilities was >>>>>>>>>>>> done in a time CDI was not there so it just ignored it somehow and it hasnt >>>>>>>>>>>> been updated when integrated to the spec. Now with the wording of the CDI - >>>>>>>>>>>> and TCK - it is impossible to make it working since request scope is bound >>>>>>>>>>>> the thre request thread - and not the request. Side note: same applies to >>>>>>>>>>>> session scope and conversation. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light >>>>>>>>>>>> here since they implement essentially this whole stack? >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit >>>>>>>>>>>> simpler? It's important to make the case for how likely this is supposed to >>>>>>>>>>>> occur in most business applications. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor >>>>>>>>>>>> service is propagating thread local request contexts correctly what other >>>>>>>>>>>> solution are you proposing? Did you check the specification? How sure are >>>>>>>>>>>> you that this isn't simply an implementation bug? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed >>>>>>>>>>>> to be preserving all relevant parts of the EE context? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That >>>>>>>>>>>> was the first impl I did then Mark pointed out it was violating CDI spec >>>>>>>>>>>> and request scope definition. There is a kind of contracdiction there cause >>>>>>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>>>>>>> tackle it. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> does >>>>>>>>>>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>>>>>> >>>>>>>>>>>> try { >>>>>>>>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>>> >>>>>>>>>>>> } finally { >>>>>>>>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible >>>>>>>>>>>> context pushing (cause of injections nature you are not supposed to know >>>>>>>>>>>> what to push in the context when going async). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | >>>>>>>>>>>> Tomitriber >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>>>>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of >>>>>>>>>>>> the proposed solution so we can all follow and discuss this? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability >>>>>>>>>>>> to inherit a cdi scope. Idea is to follow request scope more than cdi spec >>>>>>>>>>>> allows. First thought it was a concurrency utilities thing but Reza >>>>>>>>>>>> mentionned can be a CDI one so here it is. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is >>>>>>>>>>>> @RequestScoped, I do some set on it. The i go async (AsyncContext) and >>>>>>>>>>>> trigger a task in another thread. It would be neat - and mandatory in some >>>>>>>>>>>> case by the loose coupling nature of CDI - to get the *same* MyBean >>>>>>>>>>>> *instance* in this thread. With a direct dependency you can easily use >>>>>>>>>>>> message passing pattern - but you loose the loose coupling cause you need >>>>>>>>>>>> to know until which level you unwrap, think t principal case which has 2-3 >>>>>>>>>>>> proxies!. However in practice you have a lot of undirect dependencies, in >>>>>>>>>>>> particular with enterprise concerns (auditing, security...) so you can't >>>>>>>>>>>> really do it easily/naturally. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of >>>>>>>>>>>> push/pop an existing context in a thread - wrappers doing it on a >>>>>>>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse >>>>>>>>>>>> a "context context" (its current instances map) in another thread the more >>>>>>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>>>>>> question for now. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | >>>>>>>>>>>> Tomitriber >>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/55855157/attachment-0001.html From reza_rahman at lycos.com Tue Mar 8 12:03:36 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 12:03:36 -0500 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: You have it right. This is going to be hard enough for HTTP request but at least the Servlet container is fully in control of the underlying connection so determining when a request ends can be reliably detected. It's much harder for MDB, WebSocket, etc with async involved in possibly many Java EE APIs (but it's not impossible). That being said, just getting it working correctly for HTTP request is a huge step forward. > On Mar 8, 2016, at 10:55 AM, Stephan Knitelius wrote: > > I am not sure I am following you 100%. > > For me a request is anything which comes into the context of the application. No matter if it comes in via Servlet, WebSockets, JMS, Remote EJB, etc... > > The request scope should be propagated to all asynchronous operations launched within that call, terminating it when all request associated asynchronous operations are completed. > > Knitti > > > >> On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau wrote: >> Yes (just making clear it is servlet related asynchronism - ie AsyncContext#complete() is called and listeners are completed - to avoid the ambiguity of @Async, JMS etc.. where request scope is now) >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : >>> >>> >>> So the proposal would be to enable propagation of request scope to asynchronous threads and keep it alive until all concurrent processes referencing it are completed? >>> >>> >>>> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau wrote: >>>> will try to not hijack this thread and create another one for thread scope ;). >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >>>>> Your mention of thread local scope is interesting indeed. We had just such a scope in Resin called @ThreadScoped, completely separate from @RequestScoped. As memory serves though even in Resin we basically implemented @RequestScoped as thread local scope. >>>>> >>>>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau wrote: >>>>>> >>>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>>>>>> I never assume anything related to HTTP requests are ever thread safe. I don't know many folks that would make that assumption either. I think this consideration is not a significant one. The spec, docs and tutorials out there are pretty clear about the fact that none of the CDI scopes are really thread safe in the way EJBs are. >>>>>> >>>>>> It is one of the main usage of request scoped in practise. It doesn't come from HTTP side but since it is used this way in several other places (like batch) it is now assumed everywhere. It has even been promoted by several CDI projects so sadly it is to be taken into account now even if I agree it is not the state we should be at today. If changed - servlet 3.0/3.1 broke several things to make the spec cleaner or more explicit so I guess CDI can work on this - it should be made very explicit in the spec and we should study a "thread local scope" replacement to fill the gap and propose a solution to this practise judged abusive. >>>>>> >>>>>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> In TomEE we restart/stop it around most of hooks including the runnable passed to start(Runnable) of the AsyncContext but keeping the now widespread ThreadLocal nature of the @RequestScoped (= not the same as the startAsync() call sadly). This passes CDI TCK but for the particular request scope I would be happy to clarify it is actually bound to the request and just reuse the same instances. In term of side effects it would breaks the current thread safety users assume (with reason or not) but I have no real clue if it would really breaks apps or not. >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>>>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>>>>>>> Let's hope some of the implementors weigh in on this some time soon. >>>>>>>>> >>>>>>>>> I could write some tests on this but I would have no idea if I would have uncovered a bug given the ambiguity of the current spec text. >>>>>>>>> >>>>>>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman wrote: >>>>>>>>>>> Reading over the CDI spec definition for request scoped beans, I am a tad confused. When are request scoped beans being destroyed right now? Are they just bound to the Servlet request thread and destroyed as soon as the service method returns? >>>>>>>>>> >>>>>>>>>> In case of a Servlet request (request scoped beans are also tied to other kinds of "requests"), it's indeed not clear. In practice it looks like the moment between the first ServletRequestListener#requestInitialized and ServletRequestListener#requestDestroyed. >>>>>>>>>> >>>>>>>>>> The exact scope is troublesome for security too, since in most severs the request scope (and session scope and application scope) is active when a SAM is called (the SAM gets an HttpServletRequest after all), but this is not the case in all servers. E.g. in Liberty the RequestScope starts AFTER a SAM is called. >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> Arjan Tijms >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> In case of asynchronous Servlets, are they kept around until the real HTTP request actually completes the same way the underlying HTTP connection is kept around? Or is that too difficult because it would require integration at a very low level with the Servlet implementation? >>>>>>>>>>> >>>>>>>>>>> There's some language around asynchronous completion right now but it's not very clear what actually happens. Does the onComplete, etc asynchronous callback basically create new request scoped instances? >>>>>>>>>>> >>>>>>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman wrote: >>>>>>>>>>> > >>>>>>>>>>> > Even in the most conservative reading of this, the spec is clearly not disallowing it. >>>>>>>>>>> > >>>>>>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg wrote: >>>>>>>>>>> >> >>>>>>>>>>> >> The question is whether the spec does allow us to do it. And if other containers consequently do it as well. >>>>>>>>>>> >> >>>>>>>>>>> >> If it does then I will implement it in TomEE. >>>>>>>>>>> >> >>>>>>>>>>> >> LieGrue, >>>>>>>>>>> >> strub >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman : >>>>>>>>>>> >>> >>>>>>>>>>> >>> What this is saying is that it is not recommended to use them because of the possible life-cycle mismatch. If they are not supposed to work at all, the specification would have simply stated it won't work. >>>>>>>>>>> >>> >>>>>>>>>>> >>> Anyway personally I have no reason to further discuss this. I'm going to try to find a way to get this done for developers sooner rather than later. If TomEE does not want to do it, too bad for developers. >>>>>>>>>>> >>> >>>>>>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau wrote: >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> " >>>>>>>>>>> >>>> Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. >>>>>>>>>>> >>>> " >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> States that the context is not inherited, is that what you mean? >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Romain Manni-Bucau >>>>>>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>>>>>>>>> >>>> The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >>>>>>>>>>> >>>>> Specifically >>>>>>>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>>>>>>> >>>>> No session e.g. , new TX, etc >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> LieGrue, >>>>>>>>>>> >>>>> Strub >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> John >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >>>>>>>>>>> >>>>>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> Reza, >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> If that's the case, then basically this should work OOTB right? >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>>>>>> >>>>>>> task = contextService.createContextualProxy(task, Task.class); >>>>>>>>>>> >>>>>>> executor.submit(task); >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> Is that about right? >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> John >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>>>>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> John >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>>>>> >>>>>>>>>>>> try { >>>>>>>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>> >>>>>>>>>>>> } finally { >>>>>>>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/14235459/attachment-0001.html From issues at jboss.org Tue Mar 8 12:06:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 8 Mar 2016 12:06:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-587) Propose a way to propagate an existing context In-Reply-To: References: Message-ID: Romain Manni-Bucau created CDI-587: -------------------------------------- Summary: Propose a way to propagate an existing context Key: CDI-587 URL: https://issues.jboss.org/browse/CDI-587 Project: CDI Specification Issues Issue Type: Epic Components: Contexts Affects Versions: 1.2.Final Reporter: Romain Manni-Bucau The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context. An example is starting an AsyncContext in a servlet. One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads. Note however this issue is not only bound to servlets even if it is the easiest example. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From rmannibucau at gmail.com Tue Mar 8 12:06:40 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 18:06:40 +0100 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: created https://issues.jboss.org/browse/CDI-587, I'm not sure if there is a public link to this thread but would be great to link it in the issue if possible. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-08 18:03 GMT+01:00 Reza Rahman : > You have it right. > > This is going to be hard enough for HTTP request but at least the Servlet > container is fully in control of the underlying connection so determining > when a request ends can be reliably detected. It's much harder for MDB, > WebSocket, etc with async involved in possibly many Java EE APIs (but it's > not impossible). > > That being said, just getting it working correctly for HTTP request is a > huge step forward. > > On Mar 8, 2016, at 10:55 AM, Stephan Knitelius > wrote: > > I am not sure I am following you 100%. > > For me a request is anything which comes into the context of the > application. No matter if it comes in via Servlet, WebSockets, JMS, Remote > EJB, etc... > > The request scope should be propagated to all asynchronous operations > launched within that call, terminating it when all request associated > asynchronous operations are completed. > > Knitti > > > > On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau > wrote: > >> Yes (just making clear it is servlet related asynchronism - ie >> AsyncContext#complete() is called and listeners are completed - to avoid >> the ambiguity of @Async, JMS etc.. where request scope is now) >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : >> >>> >>> >>> So the proposal would be to enable propagation of request scope to >>> asynchronous threads and keep it alive until all concurrent processes >>> referencing it are completed? >>> >>> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau >>> wrote: >>> >>>> will try to not hijack this thread and create another one for thread >>>> scope ;). >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >>>> >>>>> Your mention of thread local scope is interesting indeed. We had just >>>>> such a scope in Resin called @ThreadScoped, completely separate from >>>>> @RequestScoped. As memory serves though even in Resin we basically >>>>> implemented @RequestScoped as thread local scope. >>>>> >>>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau >>>>> wrote: >>>>> >>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>>>> >>>>>> I never assume anything related to HTTP requests are ever thread >>>>>> safe. I don't know many folks that would make that assumption either. I >>>>>> think this consideration is not a significant one. The spec, docs and >>>>>> tutorials out there are pretty clear about the fact that none of the CDI >>>>>> scopes are really thread safe in the way EJBs are. >>>>>> >>>>>> >>>>> It is one of the main usage of request scoped in practise. It doesn't >>>>> come from HTTP side but since it is used this way in several other places >>>>> (like batch) it is now assumed everywhere. It has even been promoted by >>>>> several CDI projects so sadly it is to be taken into account now even if I >>>>> agree it is not the state we should be at today. If changed - servlet >>>>> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I >>>>> guess CDI can work on this - it should be made very explicit in the spec >>>>> and we should study a "thread local scope" replacement to fill the gap and >>>>> propose a solution to this practise judged abusive. >>>>> >>>>> >>>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau >>>>>> wrote: >>>>>> >>>>>> In TomEE we restart/stop it around most of hooks including the >>>>>> runnable passed to start(Runnable) of the AsyncContext but keeping the now >>>>>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >>>>>> startAsync() call sadly). This passes CDI TCK but for the particular >>>>>> request scope I would be happy to clarify it is actually bound to the >>>>>> request and just reuse the same instances. In term of side effects it would >>>>>> breaks the current thread safety users assume (with reason or not) but I >>>>>> have no real clue if it would really breaks apps or not. >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog >>>>>> | Github >>>>>> | LinkedIn >>>>>> | Tomitriber >>>>>> >>>>>> >>>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>>>> >>>>>>> Let's hope some of the implementors weigh in on this some time soon. >>>>>>> >>>>>>> I could write some tests on this but I would have no idea if I would >>>>>>> have uncovered a bug given the ambiguity of the current spec text. >>>>>>> >>>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman >>>>>>> wrote: >>>>>>> >>>>>>>> Reading over the CDI spec definition for request scoped beans, I am >>>>>>>> a tad confused. When are request scoped beans being destroyed right now? >>>>>>>> Are they just bound to the Servlet request thread and destroyed as soon as >>>>>>>> the service method returns? >>>>>>> >>>>>>> >>>>>>> In case of a Servlet request (request scoped beans are also tied to >>>>>>> other kinds of "requests"), it's indeed not clear. In practice it looks >>>>>>> like the moment between the first ServletRequestListener#requestInitialized >>>>>>> and ServletRequestListener#requestDestroyed. >>>>>>> >>>>>>> The exact scope is troublesome for security too, since in most >>>>>>> severs the request scope (and session scope and application scope) is >>>>>>> active when a SAM is called (the SAM gets an HttpServletRequest after all), >>>>>>> but this is not the case in all servers. E.g. in Liberty the RequestScope >>>>>>> starts AFTER a SAM is called. >>>>>>> >>>>>>> Kind regards, >>>>>>> Arjan Tijms >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> In case of asynchronous Servlets, are they kept around until the >>>>>>>> real HTTP request actually completes the same way the underlying HTTP >>>>>>>> connection is kept around? Or is that too difficult because it would >>>>>>>> require integration at a very low level with the Servlet implementation? >>>>>>>> >>>>>>>> There's some language around asynchronous completion right now but >>>>>>>> it's not very clear what actually happens. Does the onComplete, etc >>>>>>>> asynchronous callback basically create new request scoped instances? >>>>>>>> >>>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > Even in the most conservative reading of this, the spec is >>>>>>>> clearly not disallowing it. >>>>>>>> > >>>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg >>>>>>>> wrote: >>>>>>>> >> >>>>>>>> >> The question is whether the spec does allow us to do it. And if >>>>>>>> other containers consequently do it as well. >>>>>>>> >> >>>>>>>> >> If it does then I will implement it in TomEE. >>>>>>>> >> >>>>>>>> >> LieGrue, >>>>>>>> >> strub >>>>>>>> >> >>>>>>>> >> >>>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman < >>>>>>>> reza_rahman at lycos.com>: >>>>>>>> >>> >>>>>>>> >>> What this is saying is that it is not recommended to use them >>>>>>>> because of the possible life-cycle mismatch. If they are not supposed to >>>>>>>> work at all, the specification would have simply stated it won't work. >>>>>>>> >>> >>>>>>>> >>> Anyway personally I have no reason to further discuss this. I'm >>>>>>>> going to try to find a way to get this done for developers sooner rather >>>>>>>> than later. If TomEE does not want to do it, too bad for developers. >>>>>>>> >>> >>>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>> >>>>>>>> >>>> " >>>>>>>> >>>> Tasks that are submitted to a managed instance of >>>>>>>> ExecutorService may still be running after the lifecycle of the submitting >>>>>>>> component. Therefore, CDI beans with a scope of @RequestScoped, >>>>>>>> @SessionScoped, or @ConversationScoped are not recommended to use as tasks >>>>>>>> as it cannot be guaranteed that the tasks will complete before the CDI >>>>>>>> context is destroyed. >>>>>>>> >>>> " >>>>>>>> >>>> >>>>>>>> >>>> States that the context is not inherited, is that what you >>>>>>>> mean? >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> Romain Manni-Bucau >>>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>> >>>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>>>>>> >>>> The specification currently references pretty much all the >>>>>>>> major CDI scopes specifically with the issue of propagation and lifecycle >>>>>>>> in mind. Please see section 2.3. >>>>>>>> >>>> >>>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg >>>>>>>> wrote: >>>>>>>> >>>>> Specifically >>>>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>>>> >>>>> No session e.g. , new TX, etc >>>>>>>> >>>>> >>>>>>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, >>>>>>>> so the Request Context not only doesn't get propagated (which is good), but >>>>>>>> also doesn't get set up (which is crap). >>>>>>>> >>>>> >>>>>>>> >>>>> LieGrue, >>>>>>>> >>>>> Strub >>>>>>>> >>>>> >>>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>>>>>> john.d.ament at gmail.com>: >>>>>>>> >>>>>> >>>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's >>>>>>>> nothing in this spec that says it wouldn't be propagated. However, there's >>>>>>>> nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>>> >>>>>> >>>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>>>>>> transaction state. Considering the age of the spec, I'm not surprised to >>>>>>>> see that. The worst part is that right now, outside of the ASF, all other >>>>>>>> EE7 impls seem to be using the RI for concurrency. >>>>>>>> >>>>>> >>>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the >>>>>>>> only thing that's actually propagated is the transaction. >>>>>>>> >>>>>> >>>>>>>> >>>>>> John >>>>>>>> >>>>>> >>>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>> >>>>>> I am re-reading the spec end to end again right now. So far >>>>>>>> it seems I have remembered everything correctly. >>>>>>>> >>>>>> >>>>>>>> >>>>>> You should read over section 2.3. What it is saying is that >>>>>>>> a container implementing the Java EE concurrency utilities should ensure >>>>>>>> whatever contextual information is needed for managed components to work >>>>>>>> correctly should be propagated automatically. For the correct >>>>>>>> implementation of CDI scopes, this should also mean any currently active >>>>>>>> scopes. The section you are referring to is basically implying that >>>>>>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>>>>>> reliably since beans could go out of scope before the thread finishes - for >>>>>>>> example if the request ends). >>>>>>>> >>>>>> >>>>>>>> >>>>>> This does not have anything to do with the context service >>>>>>>> per se. The context service is an SPI of sorts to allow end user developers >>>>>>>> to do for their own applications what the container does behind the scenes >>>>>>>> for managed component context propagation. >>>>>>>> >>>>>> >>>>>>>> >>>>>> I'll read over the entire spec to see if there is anything >>>>>>>> to contradict this. If that's not the case what Romain is describing is >>>>>>>> most likely an implementation specific bug that did not take into account >>>>>>>> CDI scope propagation. >>>>>>>> >>>>>> >>>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Reza, >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>>>>>> specific section you had in mind? The only references to CDI were near the >>>>>>>> beginning warning users to not use Request/Session scoped beans as tasks >>>>>>>> since the outer most context may be destroyed before the work is done. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> I have a feeling what you're referring to is the context >>>>>>>> service: >>>>>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> If that's the case, then basically this should work OOTB >>>>>>>> right? >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>>> >>>>>>> task = contextService.createContextualProxy(task, >>>>>>>> Task.class); >>>>>>>> >>>>>>> executor.submit(task); >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Is that about right? >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> John >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text in >>>>>>>> detail? What does it say about managed component context propagation? >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Without actually doing that further discussing this is just >>>>>>>> taking shots in the dark. As an implementer it should not surprise you that >>>>>>>> this might simply be a bug because the person implementing the concurrency >>>>>>>> utilities for the EE runtime was not told about what to copy over into the >>>>>>>> new thread for CDI to work correctly. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman < >>>>>>>> reza_rahman at lycos.com>: >>>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing that >>>>>>>> the EE concurrency spec is intended for. It is supposed to copy over >>>>>>>> everything from the underlying thread local context into the new thread for >>>>>>>> all EE managed components to function. Since CDI beans are also EE >>>>>>>> container managed, it also applies to CDI beans as well. The EE vendor is >>>>>>>> supposed to make sure this works properly. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically lists >>>>>>>> APIs for which thread context propagation should work. If this doesn't work >>>>>>>> in a specific implementation it's most likely because they didn't take CDI >>>>>>>> into account in their own EE concurrency implementation. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite >>>>>>>> easily and @RequestScoped which is *used* today is sadly a >>>>>>>> @ThreadLocalScoped badly named. So to solve it we would need another scope >>>>>>>> as I mentionned several times on this list 100% matching servlet instances >>>>>>>> lifecycles (on a pure CDI side we have the same issue for sessions which >>>>>>>> are recycled during a request, the session scope is corrupted *by spec* in >>>>>>>> term of user behavior). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> The section of the spec you link to makes no references >>>>>>>> to threads. 6.3 makes some notes about normal scopes and threads, and >>>>>>>> specifically says that a context is bound to one or more threads. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> I think what's happened is that over the years, people >>>>>>>> have simply bound HTTP Request == single thread, but when async processing >>>>>>>> was introduced no one thought to clarify that the spawning of a child >>>>>>>> thread from the original HTTP request retains the parent's context. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> This is another requested feature, but looks more like a >>>>>>>> bug or gap in the spec. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> John >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman < >>>>>>>> reza_rahman at lycos.com>: >>>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE >>>>>>>> concurrency is generic enough for implementations to also be able to cover >>>>>>>> CDI scopes or any other Java EE API context propagation needs. This means >>>>>>>> the issue needs to be solved at the individual implementation level. >>>>>>>> Changing anything in the spec is probably just unnecessary ceremony in this >>>>>>>> case. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" >>>>>>>> users, 2. CDI still prevent it to work since it would violate the spec to >>>>>>>> propagate it while request scope is bound to another thread ( >>>>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>>>> handles async listener but not the main AsyncContext part). >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>>>>>> reza_rahman at lycos.com>: >>>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the specification >>>>>>>> text. This might indeed just be an implementation bug. The EE concurrency >>>>>>>> utilities are supposed to be copying all relevant context. If this is an >>>>>>>> issue than it has to be that it is not copying enough of the HTTP request >>>>>>>> context for CDI to work. >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but >>>>>>>> needed to reverse. From my understanding ee concurrency utilities was done >>>>>>>> in a time CDI was not there so it just ignored it somehow and it hasnt been >>>>>>>> updated when integrated to the spec. Now with the wording of the CDI - and >>>>>>>> TCK - it is impossible to make it working since request scope is bound the >>>>>>>> thre request thread - and not the request. Side note: same applies to >>>>>>>> session scope and conversation. >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light >>>>>>>> here since they implement essentially this whole stack? >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>>>>>> reza_rahman at lycos.com>: >>>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? >>>>>>>> It's important to make the case for how likely this is supposed to occur in >>>>>>>> most business applications. >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor service >>>>>>>> is propagating thread local request contexts correctly what other solution >>>>>>>> are you proposing? Did you check the specification? How sure are you that >>>>>>>> this isn't simply an implementation bug? >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to be >>>>>>>> preserving all relevant parts of the EE context? >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was >>>>>>>> the first impl I did then Mark pointed out it was violating CDI spec and >>>>>>>> request scope definition. There is a kind of contracdiction there cause >>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>>> tackle it. >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> does >>>>>>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>> >>>>>>>>>>>> try { >>>>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>>>> >>>>>>>>>>>> } finally { >>>>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>>>> >>>>>>>>>>>> } >>>>>>>> >>>>>>>>>>>> } >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context >>>>>>>> pushing (cause of injections nature you are not supposed to know what to >>>>>>>> push in the context when going async). >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>>>>>>> reza_rahman at lycos.com>: >>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the >>>>>>>> proposed solution so we can all follow and discuss this? >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to >>>>>>>> inherit a cdi scope. Idea is to follow request scope more than cdi spec >>>>>>>> allows. First thought it was a concurrency utilities thing but Reza >>>>>>>> mentionned can be a CDI one so here it is. >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I >>>>>>>> do some set on it. The i go async (AsyncContext) and trigger a task in >>>>>>>> another thread. It would be neat - and mandatory in some case by the loose >>>>>>>> coupling nature of CDI - to get the *same* MyBean *instance* in this >>>>>>>> thread. With a direct dependency you can easily use message passing pattern >>>>>>>> - but you loose the loose coupling cause you need to know until which level >>>>>>>> you unwrap, think t principal case which has 2-3 proxies!. However in >>>>>>>> practice you have a lot of undirect dependencies, in particular with >>>>>>>> enterprise concerns (auditing, security...) so you can't really do it >>>>>>>> easily/naturally. >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of >>>>>>>> push/pop an existing context in a thread - wrappers doing it on a >>>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a >>>>>>>> "context context" (its current instances map) in another thread the more >>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>> question for now. >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/a1f20011/attachment-0001.html From reza_rahman at lycos.com Tue Mar 8 12:08:28 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Tue, 8 Mar 2016 12:08:28 -0500 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> Message-ID: <6F840ABC-929A-44BF-9303-F124C612457B@lycos.com> You can get a link from the CDI spec site. Just browse. Sent from my iPhone > On Mar 8, 2016, at 12:06 PM, Romain Manni-Bucau wrote: > > created https://issues.jboss.org/browse/CDI-587, I'm not sure if there is a public link to this thread but would be great to link it in the issue if possible. > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2016-03-08 18:03 GMT+01:00 Reza Rahman : >> You have it right. >> >> This is going to be hard enough for HTTP request but at least the Servlet container is fully in control of the underlying connection so determining when a request ends can be reliably detected. It's much harder for MDB, WebSocket, etc with async involved in possibly many Java EE APIs (but it's not impossible). >> >> That being said, just getting it working correctly for HTTP request is a huge step forward. >> >>> On Mar 8, 2016, at 10:55 AM, Stephan Knitelius wrote: >>> >>> I am not sure I am following you 100%. >>> >>> For me a request is anything which comes into the context of the application. No matter if it comes in via Servlet, WebSockets, JMS, Remote EJB, etc... >>> >>> The request scope should be propagated to all asynchronous operations launched within that call, terminating it when all request associated asynchronous operations are completed. >>> >>> Knitti >>> >>> >>> >>>> On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau wrote: >>>> Yes (just making clear it is servlet related asynchronism - ie AsyncContext#complete() is called and listeners are completed - to avoid the ambiguity of @Async, JMS etc.. where request scope is now) >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : >>>>> >>>>> >>>>> So the proposal would be to enable propagation of request scope to asynchronous threads and keep it alive until all concurrent processes referencing it are completed? >>>>> >>>>> >>>>>> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau wrote: >>>>>> will try to not hijack this thread and create another one for thread scope ;). >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>> >>>>>> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >>>>>>> Your mention of thread local scope is interesting indeed. We had just such a scope in Resin called @ThreadScoped, completely separate from @RequestScoped. As memory serves though even in Resin we basically implemented @RequestScoped as thread local scope. >>>>>>> >>>>>>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>>>>>>>> I never assume anything related to HTTP requests are ever thread safe. I don't know many folks that would make that assumption either. I think this consideration is not a significant one. The spec, docs and tutorials out there are pretty clear about the fact that none of the CDI scopes are really thread safe in the way EJBs are. >>>>>>>>> >>>>>>>> >>>>>>>> It is one of the main usage of request scoped in practise. It doesn't come from HTTP side but since it is used this way in several other places (like batch) it is now assumed everywhere. It has even been promoted by several CDI projects so sadly it is to be taken into account now even if I agree it is not the state we should be at today. If changed - servlet 3.0/3.1 broke several things to make the spec cleaner or more explicit so I guess CDI can work on this - it should be made very explicit in the spec and we should study a "thread local scope" replacement to fill the gap and propose a solution to this practise judged abusive. >>>>>>>> >>>>>>>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau wrote: >>>>>>>>>> >>>>>>>>>> In TomEE we restart/stop it around most of hooks including the runnable passed to start(Runnable) of the AsyncContext but keeping the now widespread ThreadLocal nature of the @RequestScoped (= not the same as the startAsync() call sadly). This passes CDI TCK but for the particular request scope I would be happy to clarify it is actually bound to the request and just reuse the same instances. In term of side effects it would breaks the current thread safety users assume (with reason or not) but I have no real clue if it would really breaks apps or not. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>> >>>>>>>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>>>>>>>>> Let's hope some of the implementors weigh in on this some time soon. >>>>>>>>>>> >>>>>>>>>>> I could write some tests on this but I would have no idea if I would have uncovered a bug given the ambiguity of the current spec text. >>>>>>>>>>> >>>>>>>>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman wrote: >>>>>>>>>>>>> Reading over the CDI spec definition for request scoped beans, I am a tad confused. When are request scoped beans being destroyed right now? Are they just bound to the Servlet request thread and destroyed as soon as the service method returns? >>>>>>>>>>>> >>>>>>>>>>>> In case of a Servlet request (request scoped beans are also tied to other kinds of "requests"), it's indeed not clear. In practice it looks like the moment between the first ServletRequestListener#requestInitialized and ServletRequestListener#requestDestroyed. >>>>>>>>>>>> >>>>>>>>>>>> The exact scope is troublesome for security too, since in most severs the request scope (and session scope and application scope) is active when a SAM is called (the SAM gets an HttpServletRequest after all), but this is not the case in all servers. E.g. in Liberty the RequestScope starts AFTER a SAM is called. >>>>>>>>>>>> >>>>>>>>>>>> Kind regards, >>>>>>>>>>>> Arjan Tijms >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> In case of asynchronous Servlets, are they kept around until the real HTTP request actually completes the same way the underlying HTTP connection is kept around? Or is that too difficult because it would require integration at a very low level with the Servlet implementation? >>>>>>>>>>>>> >>>>>>>>>>>>> There's some language around asynchronous completion right now but it's not very clear what actually happens. Does the onComplete, etc asynchronous callback basically create new request scoped instances? >>>>>>>>>>>>> >>>>>>>>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > Even in the most conservative reading of this, the spec is clearly not disallowing it. >>>>>>>>>>>>> > >>>>>>>>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg wrote: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> The question is whether the spec does allow us to do it. And if other containers consequently do it as well. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> If it does then I will implement it in TomEE. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> LieGrue, >>>>>>>>>>>>> >> strub >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman : >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> What this is saying is that it is not recommended to use them because of the possible life-cycle mismatch. If they are not supposed to work at all, the specification would have simply stated it won't work. >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Anyway personally I have no reason to further discuss this. I'm going to try to find a way to get this done for developers sooner rather than later. If TomEE does not want to do it, too bad for developers. >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau wrote: >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> " >>>>>>>>>>>>> >>>> Tasks that are submitted to a managed instance of ExecutorService may still be running after the lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped, @SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed that the tasks will complete before the CDI context is destroyed. >>>>>>>>>>>>> >>>> " >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> States that the context is not inherited, is that what you mean? >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Romain Manni-Bucau >>>>>>>>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman : >>>>>>>>>>>>> >>>> The specification currently references pretty much all the major CDI scopes specifically with the issue of propagation and lifecycle in mind. Please see section 2.3. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg wrote: >>>>>>>>>>>>> >>>>> Specifically >>>>>>>>>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>>>>>>>>> >>>>> No session e.g. , new TX, etc >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, so the Request Context not only doesn't get propagated (which is good), but also doesn't get set up (which is crap). >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> LieGrue, >>>>>>>>>>>>> >>>>> Strub >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament : >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's nothing in this spec that says it wouldn't be propagated. However, there's nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate transaction state. Considering the age of the spec, I'm not surprised to see that. The worst part is that right now, outside of the ASF, all other EE7 impls seem to be using the RI for concurrency. >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the only thing that's actually propagated is the transaction. >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> John >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman wrote: >>>>>>>>>>>>> >>>>>> I am re-reading the spec end to end again right now. So far it seems I have remembered everything correctly. >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> You should read over section 2.3. What it is saying is that a container implementing the Java EE concurrency utilities should ensure whatever contextual information is needed for managed components to work correctly should be propagated automatically. For the correct implementation of CDI scopes, this should also mean any currently active scopes. The section you are referring to is basically implying that thinking that it is possible to use these scoped beans in tasks (albeit not reliably since beans could go out of scope before the thread finishes - for example if the request ends). >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> This does not have anything to do with the context service per se. The context service is an SPI of sorts to allow end user developers to do for their own applications what the container does behind the scenes for managed component context propagation. >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> I'll read over the entire spec to see if there is anything to contradict this. If that's not the case what Romain is describing is most likely an implementation specific bug that did not take into account CDI scope propagation. >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament wrote: >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> Reza, >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a specific section you had in mind? The only references to CDI were near the beginning warning users to not use Request/Session scoped beans as tasks since the outer most context may be destroyed before the work is done. >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> I have a feeling what you're referring to is the context service: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> If that's the case, then basically this should work OOTB right? >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>>>>>>>> >>>>>>> task = contextService.createContextualProxy(task, Task.class); >>>>>>>>>>>>> >>>>>>> executor.submit(task); >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> Is that about right? >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> John >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman wrote: >>>>>>>>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text in detail? What does it say about managed component context propagation? >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> Without actually doing that further discussing this is just taking shots in the dark. As an implementer it should not surprise you that this might simply be a bug because the person implementing the concurrency utilities for the EE runtime was not told about what to copy over into the new thread for CDI to work correctly. >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman : >>>>>>>>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing that the EE concurrency spec is intended for. It is supposed to copy over everything from the underlying thread local context into the new thread for all EE managed components to function. Since CDI beans are also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed to make sure this works properly. >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically lists APIs for which thread context propagation should work. If this doesn't work in a specific implementation it's most likely because they didn't take CDI into account in their own EE concurrency implementation. >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would need another scope as I mentionned several times on this list 100% matching servlet instances lifecycles (on a pure CDI side we have the same issue for sessions which are recycled during a request, the session scope is corrupted *by spec* in term of user behavior). >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament wrote: >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> The section of the spec you link to makes no references to threads. 6.3 makes some notes about normal scopes and threads, and specifically says that a context is bound to one or more threads. >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> I think what's happened is that over the years, people have simply bound HTTP Request == single thread, but when async processing was introduced no one thought to clarify that the spawning of a child thread from the original HTTP request retains the parent's context. >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> This is another requested feature, but looks more like a bug or gap in the spec. >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> John >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau wrote: >>>>>>>>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman : >>>>>>>>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE concurrency is generic enough for implementations to also be able to cover CDI scopes or any other Java EE API context propagation needs. This means the issue needs to be solved at the individual implementation level. Changing anything in the spec is probably just unnecessary ceremony in this case. >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still prevent it to work since it would violate the spec to propagate it while request scope is bound to another thread (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context handles async listener but not the main AsyncContext part). >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman : >>>>>>>>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the specification text. This might indeed just be an implementation bug. The EE concurrency utilities are supposed to be copying all relevant context. If this is an issue than it has to be that it is not copying enough of the HTTP request context for CDI to work. >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light here since they implement essentially this whole stack? >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman : >>>>>>>>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? It's important to make the case for how likely this is supposed to occur in most business applications. >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor service is propagating thread local request contexts correctly what other solution are you proposing? Did you check the specification? How sure are you that this isn't simply an implementation bug? >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to be preserving all relevant parts of the EE context? >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was the first impl I did then Mark pointed out it was violating CDI spec and request scope definition. There is a kind of contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but we can also see it the opposite way: CDI doesn't provide any way to propagate a context in another thread. Both point of view are valid so we need to see where we tackle it. >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>>>>>>> >>>>>>>>>>>> try { >>>>>>>>>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>>>>>>>>> >>>>>>>>>>>> } finally { >>>>>>>>>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async). >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman : >>>>>>>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau wroteshar: >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/3fec5093/attachment-0001.html From issues at jboss.org Tue Mar 8 12:12:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 8 Mar 2016 12:12:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-587) Propose a way to propagate an existing context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated CDI-587: ----------------------------------- Description: The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context. An example is starting an AsyncContext in a servlet. One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads. Note however this issue is not only bound to servlets even if it is the easiest example. The original thread disucssion on the list: http://cdi-development-mailing-list.1064426.n5.nabble.com/RequestScope-Life-Cycle-td5712701.html was: The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context. An example is starting an AsyncContext in a servlet. One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads. Note however this issue is not only bound to servlets even if it is the easiest example. > Propose a way to propagate an existing context > ---------------------------------------------- > > Key: CDI-587 > URL: https://issues.jboss.org/browse/CDI-587 > Project: CDI Specification Issues > Issue Type: Epic > Components: Contexts > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context. > An example is starting an AsyncContext in a servlet. > One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads. > Note however this issue is not only bound to servlets even if it is the easiest example. > The original thread disucssion on the list: http://cdi-development-mailing-list.1064426.n5.nabble.com/RequestScope-Life-Cycle-td5712701.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From rmannibucau at gmail.com Tue Mar 8 12:11:59 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 8 Mar 2016 18:11:59 +0100 Subject: [cdi-dev] RequestScope Life Cycle In-Reply-To: <6F840ABC-929A-44BF-9303-F124C612457B@lycos.com> References: <763E5788-EB3B-4412-9F7A-25E7413EAC26@lycos.com> <6F840ABC-929A-44BF-9303-F124C612457B@lycos.com> Message-ID: Thanks Reza updated the jira Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-08 18:08 GMT+01:00 Reza Rahman : > You can get a link from the CDI spec site. Just browse. > > Sent from my iPhone > > On Mar 8, 2016, at 12:06 PM, Romain Manni-Bucau > wrote: > > created https://issues.jboss.org/browse/CDI-587, I'm not sure if there is > a public link to this thread but would be great to link it in the issue if > possible. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-08 18:03 GMT+01:00 Reza Rahman : > >> You have it right. >> >> This is going to be hard enough for HTTP request but at least the Servlet >> container is fully in control of the underlying connection so determining >> when a request ends can be reliably detected. It's much harder for MDB, >> WebSocket, etc with async involved in possibly many Java EE APIs (but it's >> not impossible). >> >> That being said, just getting it working correctly for HTTP request is a >> huge step forward. >> >> On Mar 8, 2016, at 10:55 AM, Stephan Knitelius >> wrote: >> >> I am not sure I am following you 100%. >> >> For me a request is anything which comes into the context of the >> application. No matter if it comes in via Servlet, WebSockets, JMS, Remote >> EJB, etc... >> >> The request scope should be propagated to all asynchronous operations >> launched within that call, terminating it when all request associated >> asynchronous operations are completed. >> >> Knitti >> >> >> >> On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau >> wrote: >> >>> Yes (just making clear it is servlet related asynchronism - ie >>> AsyncContext#complete() is called and listeners are completed - to avoid >>> the ambiguity of @Async, JMS etc.. where request scope is now) >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius : >>> >>>> >>>> >>>> So the proposal would be to enable propagation of request scope to >>>> asynchronous threads and keep it alive until all concurrent processes >>>> referencing it are completed? >>>> >>>> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau >>>> wrote: >>>> >>>>> will try to not hijack this thread and create another one for thread >>>>> scope ;). >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog >>>>> | Github >>>>> | LinkedIn >>>>> | Tomitriber >>>>> >>>>> >>>>> 2016-03-08 14:30 GMT+01:00 Reza Rahman : >>>>> >>>>>> Your mention of thread local scope is interesting indeed. We had just >>>>>> such a scope in Resin called @ThreadScoped, completely separate from >>>>>> @RequestScoped. As memory serves though even in Resin we basically >>>>>> implemented @RequestScoped as thread local scope. >>>>>> >>>>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau >>>>>> wrote: >>>>>> >>>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman : >>>>>> >>>>>>> I never assume anything related to HTTP requests are ever thread >>>>>>> safe. I don't know many folks that would make that assumption either. I >>>>>>> think this consideration is not a significant one. The spec, docs and >>>>>>> tutorials out there are pretty clear about the fact that none of the CDI >>>>>>> scopes are really thread safe in the way EJBs are. >>>>>>> >>>>>>> >>>>>> It is one of the main usage of request scoped in practise. It doesn't >>>>>> come from HTTP side but since it is used this way in several other places >>>>>> (like batch) it is now assumed everywhere. It has even been promoted by >>>>>> several CDI projects so sadly it is to be taken into account now even if I >>>>>> agree it is not the state we should be at today. If changed - servlet >>>>>> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I >>>>>> guess CDI can work on this - it should be made very explicit in the spec >>>>>> and we should study a "thread local scope" replacement to fill the gap and >>>>>> propose a solution to this practise judged abusive. >>>>>> >>>>>> >>>>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>> In TomEE we restart/stop it around most of hooks including the >>>>>>> runnable passed to start(Runnable) of the AsyncContext but keeping the now >>>>>>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >>>>>>> startAsync() call sadly). This passes CDI TCK but for the particular >>>>>>> request scope I would be happy to clarify it is actually bound to the >>>>>>> request and just reuse the same instances. In term of side effects it would >>>>>>> breaks the current thread safety users assume (with reason or not) but I >>>>>>> have no real clue if it would really breaks apps or not. >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau | Blog >>>>>>> | Github >>>>>>> | LinkedIn >>>>>>> | Tomitriber >>>>>>> >>>>>>> >>>>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman : >>>>>>> >>>>>>>> Let's hope some of the implementors weigh in on this some time soon. >>>>>>>> >>>>>>>> I could write some tests on this but I would have no idea if I >>>>>>>> would have uncovered a bug given the ambiguity of the current spec text. >>>>>>>> >>>>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Reading over the CDI spec definition for request scoped beans, I >>>>>>>>> am a tad confused. When are request scoped beans being destroyed right now? >>>>>>>>> Are they just bound to the Servlet request thread and destroyed as soon as >>>>>>>>> the service method returns? >>>>>>>> >>>>>>>> >>>>>>>> In case of a Servlet request (request scoped beans are also tied to >>>>>>>> other kinds of "requests"), it's indeed not clear. In practice it looks >>>>>>>> like the moment between the first ServletRequestListener#requestInitialized >>>>>>>> and ServletRequestListener#requestDestroyed. >>>>>>>> >>>>>>>> The exact scope is troublesome for security too, since in most >>>>>>>> severs the request scope (and session scope and application scope) is >>>>>>>> active when a SAM is called (the SAM gets an HttpServletRequest after all), >>>>>>>> but this is not the case in all servers. E.g. in Liberty the RequestScope >>>>>>>> starts AFTER a SAM is called. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Arjan Tijms >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In case of asynchronous Servlets, are they kept around until the >>>>>>>>> real HTTP request actually completes the same way the underlying HTTP >>>>>>>>> connection is kept around? Or is that too difficult because it would >>>>>>>>> require integration at a very low level with the Servlet implementation? >>>>>>>>> >>>>>>>>> There's some language around asynchronous completion right now but >>>>>>>>> it's not very clear what actually happens. Does the onComplete, etc >>>>>>>>> asynchronous callback basically create new request scoped instances? >>>>>>>>> >>>>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman >>>>>>>>> wrote: >>>>>>>>> > >>>>>>>>> > Even in the most conservative reading of this, the spec is >>>>>>>>> clearly not disallowing it. >>>>>>>>> > >>>>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg >>>>>>>>> wrote: >>>>>>>>> >> >>>>>>>>> >> The question is whether the spec does allow us to do it. And if >>>>>>>>> other containers consequently do it as well. >>>>>>>>> >> >>>>>>>>> >> If it does then I will implement it in TomEE. >>>>>>>>> >> >>>>>>>>> >> LieGrue, >>>>>>>>> >> strub >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman < >>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>> >>> >>>>>>>>> >>> What this is saying is that it is not recommended to use them >>>>>>>>> because of the possible life-cycle mismatch. If they are not supposed to >>>>>>>>> work at all, the specification would have simply stated it won't work. >>>>>>>>> >>> >>>>>>>>> >>> Anyway personally I have no reason to further discuss this. >>>>>>>>> I'm going to try to find a way to get this done for developers sooner >>>>>>>>> rather than later. If TomEE does not want to do it, too bad for developers. >>>>>>>>> >>> >>>>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>> >>>>>>>>> >>>> " >>>>>>>>> >>>> Tasks that are submitted to a managed instance of >>>>>>>>> ExecutorService may still be running after the lifecycle of the submitting >>>>>>>>> component. Therefore, CDI beans with a scope of @RequestScoped, >>>>>>>>> @SessionScoped, or @ConversationScoped are not recommended to use as tasks >>>>>>>>> as it cannot be guaranteed that the tasks will complete before the CDI >>>>>>>>> context is destroyed. >>>>>>>>> >>>> " >>>>>>>>> >>>> >>>>>>>>> >>>> States that the context is not inherited, is that what you >>>>>>>>> mean? >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> Romain Manni-Bucau >>>>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>> >>>> >>>>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman >>>>>>>> >: >>>>>>>>> >>>> The specification currently references pretty much all the >>>>>>>>> major CDI scopes specifically with the issue of propagation and lifecycle >>>>>>>>> in mind. Please see section 2.3. >>>>>>>>> >>>> >>>>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg < >>>>>>>>> struberg at yahoo.de> wrote: >>>>>>>>> >>>>> Specifically >>>>>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>>>>> >>>>> No session e.g. , new TX, etc >>>>>>>>> >>>>> >>>>>>>>> >>>>> Sadly the concurrency utilis only mention >>>>>>>>> @ApplicationScoped, so the Request Context not only doesn't get propagated >>>>>>>>> (which is good), but also doesn't get set up (which is crap). >>>>>>>>> >>>>> >>>>>>>>> >>>>> LieGrue, >>>>>>>>> >>>>> Strub >>>>>>>>> >>>>> >>>>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>>>>>>> john.d.ament at gmail.com>: >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's >>>>>>>>> nothing in this spec that says it wouldn't be propagated. However, there's >>>>>>>>> nothing in this spec that states clearly that CDI contexts are propagated. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>>>>>>> transaction state. Considering the age of the spec, I'm not surprised to >>>>>>>>> see that. The worst part is that right now, outside of the ASF, all other >>>>>>>>> EE7 impls seem to be using the RI for concurrency. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the >>>>>>>>> only thing that's actually propagated is the transaction. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> John >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>> >>>>>> I am re-reading the spec end to end again right now. So far >>>>>>>>> it seems I have remembered everything correctly. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> You should read over section 2.3. What it is saying is that >>>>>>>>> a container implementing the Java EE concurrency utilities should ensure >>>>>>>>> whatever contextual information is needed for managed components to work >>>>>>>>> correctly should be propagated automatically. For the correct >>>>>>>>> implementation of CDI scopes, this should also mean any currently active >>>>>>>>> scopes. The section you are referring to is basically implying that >>>>>>>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>>>>>>> reliably since beans could go out of scope before the thread finishes - for >>>>>>>>> example if the request ends). >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> This does not have anything to do with the context service >>>>>>>>> per se. The context service is an SPI of sorts to allow end user developers >>>>>>>>> to do for their own applications what the container does behind the scenes >>>>>>>>> for managed component context propagation. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I'll read over the entire spec to see if there is anything >>>>>>>>> to contradict this. If that's not the case what Romain is describing is >>>>>>>>> most likely an implementation specific bug that did not take into account >>>>>>>>> CDI scope propagation. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Reza, >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>>>>>>> specific section you had in mind? The only references to CDI were near the >>>>>>>>> beginning warning users to not use Request/Session scoped beans as tasks >>>>>>>>> since the outer most context may be destroyed before the work is done. >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> I have a feeling what you're referring to is the context >>>>>>>>> service: >>>>>>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> If that's the case, then basically this should work OOTB >>>>>>>>> right? >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Task task = new MyTask(); >>>>>>>>> >>>>>>> task = contextService.createContextualProxy(task, >>>>>>>>> Task.class); >>>>>>>>> >>>>>>> executor.submit(task); >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Is that about right? >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> John >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>>>>>>> reza_rahman at lycos.com> wrote: >>>>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text >>>>>>>>> in detail? What does it say about managed component context propagation? >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Without actually doing that further discussing this is >>>>>>>>> just taking shots in the dark. As an implementer it should not surprise you >>>>>>>>> that this might simply be a bug because the person implementing the >>>>>>>>> concurrency utilities for the EE runtime was not told about what to copy >>>>>>>>> over into the new thread for CDI to work correctly. >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman < >>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing that >>>>>>>>> the EE concurrency spec is intended for. It is supposed to copy over >>>>>>>>> everything from the underlying thread local context into the new thread for >>>>>>>>> all EE managed components to function. Since CDI beans are also EE >>>>>>>>> container managed, it also applies to CDI beans as well. The EE vendor is >>>>>>>>> supposed to make sure this works properly. >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically >>>>>>>>> lists APIs for which thread context propagation should work. If this >>>>>>>>> doesn't work in a specific implementation it's most likely because they >>>>>>>>> didn't take CDI into account in their own EE concurrency implementation. >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite >>>>>>>>> easily and @RequestScoped which is *used* today is sadly a >>>>>>>>> @ThreadLocalScoped badly named. So to solve it we would need another scope >>>>>>>>> as I mentionned several times on this list 100% matching servlet instances >>>>>>>>> lifecycles (on a pure CDI side we have the same issue for sessions which >>>>>>>>> are recycled during a request, the session scope is corrupted *by spec* in >>>>>>>>> term of user behavior). >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament < >>>>>>>>> john.d.ament at gmail.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The section of the spec you link to makes no references >>>>>>>>> to threads. 6.3 makes some notes about normal scopes and threads, and >>>>>>>>> specifically says that a context is bound to one or more threads. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I think what's happened is that over the years, people >>>>>>>>> have simply bound HTTP Request == single thread, but when async processing >>>>>>>>> was introduced no one thought to clarify that the spawning of a child >>>>>>>>> thread from the original HTTP request retains the parent's context. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This is another requested feature, but looks more like a >>>>>>>>> bug or gap in the spec. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman < >>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE >>>>>>>>> concurrency is generic enough for implementations to also be able to cover >>>>>>>>> CDI scopes or any other Java EE API context propagation needs. This means >>>>>>>>> the issue needs to be solved at the individual implementation level. >>>>>>>>> Changing anything in the spec is probably just unnecessary ceremony in this >>>>>>>>> case. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE" >>>>>>>>> users, 2. CDI still prevent it to work since it would violate the spec to >>>>>>>>> propagate it while request scope is bound to another thread ( >>>>>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context >>>>>>>>> handles async listener but not the main AsyncContext part). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the specification >>>>>>>>> text. This might indeed just be an implementation bug. The EE concurrency >>>>>>>>> utilities are supposed to be copying all relevant context. If this is an >>>>>>>>> issue than it has to be that it is not copying enough of the HTTP request >>>>>>>>> context for CDI to work. >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but >>>>>>>>> needed to reverse. From my understanding ee concurrency utilities was done >>>>>>>>> in a time CDI was not there so it just ignored it somehow and it hasnt been >>>>>>>>> updated when integrated to the spec. Now with the wording of the CDI - and >>>>>>>>> TCK - it is impossible to make it working since request scope is bound the >>>>>>>>> thre request thread - and not the request. Side note: same applies to >>>>>>>>> session scope and conversation. >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light >>>>>>>>> here since they implement essentially this whole stack? >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler? >>>>>>>>> It's important to make the case for how likely this is supposed to occur in >>>>>>>>> most business applications. >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor service >>>>>>>>> is propagating thread local request contexts correctly what other solution >>>>>>>>> are you proposing? Did you check the specification? How sure are you that >>>>>>>>> this isn't simply an implementation bug? >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to >>>>>>>>> be preserving all relevant parts of the EE context? >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was >>>>>>>>> the first impl I did then Mark pointed out it was violating CDI spec and >>>>>>>>> request scope definition. There is a kind of contracdiction there cause >>>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see >>>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in >>>>>>>>> another thread. Both point of view are valid so we need to see where we >>>>>>>>> tackle it. >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> does >>>>>>>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> Idea is to give an API to make: >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> public void complete() { >>>>>>>>> >>>>>>>>>>>> try { >>>>>>>>> >>>>>>>>>>>> asyncContext.complete(); >>>>>>>>> >>>>>>>>>>>> } finally { >>>>>>>>> >>>>>>>>>>>> auditContext.end(); >>>>>>>>> >>>>>>>>>>>> } >>>>>>>>> >>>>>>>>>>>> } >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context >>>>>>>>> pushing (cause of injections nature you are not supposed to know what to >>>>>>>>> push in the context when going async). >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman < >>>>>>>>> reza_rahman at lycos.com>: >>>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the >>>>>>>>> proposed solution so we can all follow and discuss this? >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wroteshar: >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to >>>>>>>>> inherit a cdi scope. Idea is to follow request scope more than cdi spec >>>>>>>>> allows. First thought it was a concurrency utilities thing but Reza >>>>>>>>> mentionned can be a CDI one so here it is. >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Sample: >>>>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I >>>>>>>>> do some set on it. The i go async (AsyncContext) and trigger a task in >>>>>>>>> another thread. It would be neat - and mandatory in some case by the loose >>>>>>>>> coupling nature of CDI - to get the *same* MyBean *instance* in this >>>>>>>>> thread. With a direct dependency you can easily use message passing pattern >>>>>>>>> - but you loose the loose coupling cause you need to know until which level >>>>>>>>> you unwrap, think t principal case which has 2-3 proxies!. However in >>>>>>>>> practice you have a lot of undirect dependencies, in particular with >>>>>>>>> enterprise concerns (auditing, security...) so you can't really do it >>>>>>>>> easily/naturally. >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Bonus: >>>>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of >>>>>>>>> push/pop an existing context in a thread - wrappers doing it on a >>>>>>>>> Runnable/Consumer/Function/... would be neat. >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Question: >>>>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0? >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a >>>>>>>>> "context context" (its current instances map) in another thread the more >>>>>>>>> transparently possible and match the user vision more than a technical >>>>>>>>> question for now. >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>> >>>>>>>>>>>>> cdi-dev mailing list >>>>>>>>> >>>>>>>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/0abf5685/attachment-0001.html From issues at jboss.org Wed Mar 9 04:29:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 9 Mar 2016 04:29:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-485) Provide literals for built-in annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-485: ------------------------------------- Fix Version/s: 2.0-EDR2 > Provide literals for built-in annotations > ----------------------------------------- > > Key: CDI-485 > URL: https://issues.jboss.org/browse/CDI-485 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: Martin Kouba > Fix For: 2.0-EDR2 > > > Annotation literals are often useful and therefore many projects implement them themselves. For example: > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/literal/DefaultLiteral.java > https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/literal/DefaultLiteral.java > https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/jboss/forge/furnace/container/cdi/util/DefaultLiteral.java > https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java/io/astefanutti/metrics/cdi/DefaultLiteral.java > to name a few. > It would be nice to provide these within the CDI API, e.g: > {code:JAVA} > @Target( { TYPE, METHOD, PARAMETER, FIELD }) > @Retention(RUNTIME) > @Documented > @Qualifier > public @interface Default { > @SuppressWarnings("all") > final class Literal extends AnnotationLiteral implements Default { > private Literal() { > } > } > final Default INSTANCE = new Literal(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 04:32:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 9 Mar 2016 04:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-586) Add spec text for new Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174029#comment-13174029 ] Antoine Sabot-Durand commented on CDI-586: ------------------------------------------ Yes [~tremes]. I had the same reaction when writing text here. I'll create the matching ticket. > Add spec text for new Literals > ------------------------------ > > Key: CDI-586 > URL: https://issues.jboss.org/browse/CDI-586 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > CDI-485 introduced literals in the API. We should add some information about them in the spec as well -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 04:44:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 9 Mar 2016 04:44:02 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174041#comment-13174041 ] Antoine Sabot-Durand commented on CDI-527: ------------------------------------------ To sum up. We need to find the best name for the annotation (suggestions welcome) and add the SPI part for this feature. [~struberg] what is your roadmap on the PR update. > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 04:44:04 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 9 Mar 2016 04:44:04 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174041#comment-13174041 ] Antoine Sabot-Durand edited comment on CDI-527 at 3/9/16 4:43 AM: ------------------------------------------------------------------ To sum up. We need to find the best name for the annotation (suggestions welcome) and add the SPI part for this feature. [~struberg] what is your proposed roadmap on the PR update? was (Author: antoinesabot-durand): To sum up. We need to find the best name for the annotation (suggestions welcome) and add the SPI part for this feature. [~struberg] what is your roadmap on the PR update. > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 04:48:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 9 Mar 2016 04:48:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174047#comment-13174047 ] Romain Manni-Bucau commented on CDI-527: ---------------------------------------- Suggestion: @Passthrough > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 05:24:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 9 Mar 2016 05:24:02 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-588) Adding missing annotation Literals In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-588: ---------------------------------------- Summary: Adding missing annotation Literals Key: CDI-588 URL: https://issues.jboss.org/browse/CDI-588 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Antoine Sabot-Durand We forgot literals for {{Inject}} and more questionably literals for: * {{Observes}} and {{ObservesAsync}} * {{Produces}} and {{Disposes}} * {{Specializes}} * {{TransientReference}} * {{Vetoed}} Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 06:18:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 9 Mar 2016 06:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-588) Adding missing annotation Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174120#comment-13174120 ] Martin Kouba commented on CDI-588: ---------------------------------- +1 for {{Vetoed}}, {{Inject}}, {{Specializes}} and {{TransientReference}} > Adding missing annotation Literals > ---------------------------------- > > Key: CDI-588 > URL: https://issues.jboss.org/browse/CDI-588 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > > We forgot literals for {{Inject}} and more questionably literals for: > * {{Observes}} and {{ObservesAsync}} > * {{Produces}} and {{Disposes}} > * {{Specializes}} > * {{TransientReference}} > * {{Vetoed}} > Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 06:57:00 2016 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Wed, 9 Mar 2016 06:57:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-588) Adding missing annotation Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174145#comment-13174145 ] Antonin Stefanutti commented on CDI-588: ---------------------------------------- I wonder whether that would make sense / be possible to provide literal for {{Priority}}. I've just needed it here: https://github.com/apache/camel/blob/1b89ecd902cfce8b8a074580cfec084de8df582d/components/camel-test-cdi/src/main/java/org/apache/camel/test/cdi/PriorityLiteral.java#L22 The use case is to select an alternative globally for the entire application from a test synthetic bean archive and not having it selected for the test bean archive only with is useless. > Adding missing annotation Literals > ---------------------------------- > > Key: CDI-588 > URL: https://issues.jboss.org/browse/CDI-588 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > > We forgot literals for {{Inject}} and more questionably literals for: > * {{Observes}} and {{ObservesAsync}} > * {{Produces}} and {{Disposes}} > * {{Specializes}} > * {{TransientReference}} > * {{Vetoed}} > Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 06:59:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 9 Mar 2016 06:59:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-588) Adding missing annotation Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174146#comment-13174146 ] Martin Kouba commented on CDI-588: ---------------------------------- +1 for {{Priority}} literal! > Adding missing annotation Literals > ---------------------------------- > > Key: CDI-588 > URL: https://issues.jboss.org/browse/CDI-588 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > > We forgot literals for {{Inject}} and more questionably literals for: > * {{Observes}} and {{ObservesAsync}} > * {{Produces}} and {{Disposes}} > * {{Specializes}} > * {{TransientReference}} > * {{Vetoed}} > Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 07:00:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 9 Mar 2016 07:00:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-588) Adding missing annotation Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba reassigned CDI-588: -------------------------------- Assignee: Martin Kouba > Adding missing annotation Literals > ---------------------------------- > > Key: CDI-588 > URL: https://issues.jboss.org/browse/CDI-588 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Assignee: Martin Kouba > > We forgot literals for {{Inject}} and more questionably literals for: > * {{Observes}} and {{ObservesAsync}} > * {{Produces}} and {{Disposes}} > * {{Specializes}} > * {{TransientReference}} > * {{Vetoed}} > Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 07:13:00 2016 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Wed, 9 Mar 2016 07:13:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-588) Adding missing annotation Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174145#comment-13174145 ] Antonin Stefanutti edited comment on CDI-588 at 3/9/16 7:12 AM: ---------------------------------------------------------------- I wonder whether that would make sense / be possible to provide literal for {{Priority}}. I've just needed it here: https://github.com/apache/camel/blob/1b89ecd902cfce8b8a074580cfec084de8df582d/components/camel-test-cdi/src/main/java/org/apache/camel/test/cdi/PriorityLiteral.java#L22 The use case is to automatically select an alternative globally for the entire application from a test synthetic bean archive and not having it selected for the test bean archive only which is useless. was (Author: stefanutti): I wonder whether that would make sense / be possible to provide literal for {{Priority}}. I've just needed it here: https://github.com/apache/camel/blob/1b89ecd902cfce8b8a074580cfec084de8df582d/components/camel-test-cdi/src/main/java/org/apache/camel/test/cdi/PriorityLiteral.java#L22 The use case is to select an alternative globally for the entire application from a test synthetic bean archive and not having it selected for the test bean archive only with is useless. > Adding missing annotation Literals > ---------------------------------- > > Key: CDI-588 > URL: https://issues.jboss.org/browse/CDI-588 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Assignee: Martin Kouba > > We forgot literals for {{Inject}} and more questionably literals for: > * {{Observes}} and {{ObservesAsync}} > * {{Produces}} and {{Disposes}} > * {{Specializes}} > * {{TransientReference}} > * {{Vetoed}} > Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 09:15:02 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 9 Mar 2016 09:15:02 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-560) A bean archive does not have to contain a beans.xml file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174269#comment-13174269 ] Tomas Remes commented on CDI-560: --------------------------------- I created https://github.com/cdi-spec/cdi/pull/280 > A bean archive does not have to contain a beans.xml file > -------------------------------------------------------- > > Key: CDI-560 > URL: https://issues.jboss.org/browse/CDI-560 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 2.0-EDR1 > Environment: Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > An archive which: > contains a beans.xml file with the bean-discovery-mode of none, or, > contains an extension and no beans.xml file > is not a bean archive. > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0 (proposed) > > > Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > {quote} > An archive which: > * contains a beans.xml file with the bean-discovery-mode of none, or, > * contains an extension and no beans.xml file > is not a bean archive. > {quote} > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 06:45:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 10 Mar 2016 06:45:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-550) Misleading AfterBeanDiscovery.addBean() description WRT interceptors and decorators In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174823#comment-13174823 ] Tomas Remes commented on CDI-550: --------------------------------- I opened https://github.com/cdi-spec/cdi/pull/281 > Misleading AfterBeanDiscovery.addBean() description WRT interceptors and decorators > ----------------------------------------------------------------------------------- > > Key: CDI-550 > URL: https://issues.jboss.org/browse/CDI-550 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > Priority: Minor > > 11.5.3. AfterBeanDiscovery event: > {quote} > * {{addBean()}} fires an event of type ProcessBean containing the given Bean and then registers the Bean with the container, thereby making it available for injection into other beans. The given Bean may implement Interceptor or Decorator. > {quote} > The wording is a bit misleading because interceptors and decorats are NOT available for injection. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 10:00:05 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 10 Mar 2016 10:00:05 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-479) How to identify the bean a static observer method belongs to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174953#comment-13174953 ] Tomas Remes commented on CDI-479: --------------------------------- I am not sure but isn't the answer for the first question in `4.2. Inheritance of member-level metadata`: {quote} If X declares an initializer, non-static observer, @PostConstruct or @PreDestroy method x() then Y inherits x() if and only if neither Y nor any intermediate class that is a subclass of X and a superclass of Y overrides the method x() {quote} >From this I would say the observer shouldn't be detected (because is static) in the first case. > How to identify the bean a static observer method belongs to > ------------------------------------------------------------ > > Key: CDI-479 > URL: https://issues.jboss.org/browse/CDI-479 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > Let's sum up some parts of the spec which are relevant to static observer methods: > "10.4. Observer methods": > {quote} > An observer method is a non-abstract method of a managed bean class or session bean class... > An observer method may be either static or non-static. > {quote} > "10.3. Observer resolution": > {quote} > An event is delivered to an observer method if: > * The observer method belongs to an enabled bean. > * ... > {quote} > "12.4.3. Bean discovery": > {quote} > For each observer method of every enabled bean, the container registers an instance of the ObserverMethod interface defined in The ObserverMethod interface. > {quote} > Now what is the algorithm to *identify the bean a static observer method belongs to*? Is is bound to all beans whose Bean.getBeanClass() declares the method? There are two special scenarios I have in mind: > h3. Static observer method on an abstract class > {code:java} > public abstract class Foo { > public static observe1(@Observes Event1 event1) { > } > } > public class Bar extends Foo { > } > {code} > Foo is not a bean. Foo.observe1() is not a method of managed bean class Bar (if we strictly follow the JSL). Is the observer method detected? Does it belong to Bar? What if there are several subclasses of Foo? > h3. Specialization > {code:java} > public class Foo { > public static observe1(@Observes Event2 event2) { > } > } > @Specializes > public class Bar extends Foo { > } > {code} > Foo is specialized by Bar and thus it's disabled. Is the observer method detected? Does it belong to Bar? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 10:00:05 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 10 Mar 2016 10:00:05 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-479) How to identify the bean a static observer method belongs to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174953#comment-13174953 ] Tomas Remes edited comment on CDI-479 at 3/10/16 10:00 AM: ----------------------------------------------------------- I am not sure but isn't the answer for the first question in {{4.2. Inheritance of member-level metadata}}: {quote} If X declares an initializer, non-static observer, @PostConstruct or @PreDestroy method x() then Y inherits x() if and only if neither Y nor any intermediate class that is a subclass of X and a superclass of Y overrides the method x() {quote} >From this I would say the observer shouldn't be detected (because is static) in the first case. was (Author: tremes): I am not sure but isn't the answer for the first question in `4.2. Inheritance of member-level metadata`: {quote} If X declares an initializer, non-static observer, @PostConstruct or @PreDestroy method x() then Y inherits x() if and only if neither Y nor any intermediate class that is a subclass of X and a superclass of Y overrides the method x() {quote} >From this I would say the observer shouldn't be detected (because is static) in the first case. > How to identify the bean a static observer method belongs to > ------------------------------------------------------------ > > Key: CDI-479 > URL: https://issues.jboss.org/browse/CDI-479 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > Let's sum up some parts of the spec which are relevant to static observer methods: > "10.4. Observer methods": > {quote} > An observer method is a non-abstract method of a managed bean class or session bean class... > An observer method may be either static or non-static. > {quote} > "10.3. Observer resolution": > {quote} > An event is delivered to an observer method if: > * The observer method belongs to an enabled bean. > * ... > {quote} > "12.4.3. Bean discovery": > {quote} > For each observer method of every enabled bean, the container registers an instance of the ObserverMethod interface defined in The ObserverMethod interface. > {quote} > Now what is the algorithm to *identify the bean a static observer method belongs to*? Is is bound to all beans whose Bean.getBeanClass() declares the method? There are two special scenarios I have in mind: > h3. Static observer method on an abstract class > {code:java} > public abstract class Foo { > public static observe1(@Observes Event1 event1) { > } > } > public class Bar extends Foo { > } > {code} > Foo is not a bean. Foo.observe1() is not a method of managed bean class Bar (if we strictly follow the JSL). Is the observer method detected? Does it belong to Bar? What if there are several subclasses of Foo? > h3. Specialization > {code:java} > public class Foo { > public static observe1(@Observes Event2 event2) { > } > } > @Specializes > public class Bar extends Foo { > } > {code} > Foo is specialized by Bar and thus it's disabled. Is the observer method detected? Does it belong to Bar? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From struberg at yahoo.de Thu Mar 10 13:43:29 2016 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 10 Mar 2016 19:43:29 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: Message-ID: Back from JavaLand conference, so sorry for not kicking in earlier. I not quite get the argumentation chain. It?s that all triggered by async servlet requests? And isn?t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? LieGrue, strub > Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau : > > Hi guys, > > following request scope thread and to center the discussion on the thread safety part: do we work on this? > > Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. > > Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. > > Questions: > - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): > > > > > JMS > ASYNCHONOUS > > > > > - start/stop API (this is typically an API the user should be able to control for its own threads) > - CDI 2.*0*? > > wdyt? > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. From rmannibucau at gmail.com Thu Mar 10 13:52:34 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 10 Mar 2016 19:52:34 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: Message-ID: Hi Mark, think 2.3.3.4 states the opposite. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-10 19:43 GMT+01:00 Mark Struberg : > Back from JavaLand conference, so sorry for not kicking in earlier. > > I not quite get the argumentation chain. It?s that all triggered by async > servlet requests? And isn?t the servlet spec also saying that all the > request param etc may max be assigned to a single thread AT A TIME! > > Means that it might not be on multiple threads in parallel, but the data > is allowed to get moved from one thread to another (disapearing from the > first one), right? > Would really need to dig into the wording of the async servlets spec > again, maybe has this in the back of his head? > > LieGrue, > strub > > > > > > Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau >: > > > > Hi guys, > > > > following request scope thread and to center the discussion on the > thread safety part: do we work on this? > > > > Background: @RequestScoped is often used as a ThreadLocal instance > solution. A lot of SE or Batch implementations rely on it from what I saw > as well as async implementations reusing existing business logic with this > thread safety constraint. > > > > Proposal: providing a @ThreadScoped implementation is cheap for CDI and > implemenation and would avoid the headache we can have with @RequestScoped. > Will also remove the quite dark side of the spec regarding servlet request > and request scope since now we would have a more natural solution for all > of these situation so @RequestScoped goals wouldn't collide as much. > > > > Questions: > > - is it automatically started as request scoped is (JMS, @Async, ...)? > Alternative could be some configuration in beans.xml (merged accross the > app): > > > > > > > > > > JMS > > ASYNCHONOUS > > > > > > > > > > - start/stop API (this is typically an API the user should be able to > control for its own threads) > > - CDI 2.*0*? > > > > wdyt? > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160310/bd58fc4c/attachment-0001.html From reza_rahman at lycos.com Thu Mar 10 14:10:13 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Thu, 10 Mar 2016 14:10:13 -0500 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: Message-ID: To save time I suggest looping in someone knowledgable and level headed from the Servlet EG if they are not here already. I can certainly vouch for either Ed, Shingwai or Greg. > On Mar 10, 2016, at 1:43 PM, Mark Struberg d wrote: > Save > Back from JavaLand conference, so sorry for not kicking in earlier. > > I not quite get the argumentation chain. It?s that all triggered by async servlet requests? And isn?t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! > > Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? > Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? > > LieGrue, > strub > > > > >> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau : >> >> Hi guys, >> >> following request scope thread and to center the discussion on the thread safety part: do we work on this? >> >> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. >> >> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. >> >> Questions: >> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): >> >> >> >> >> JMS >> ASYNCHONOUS >> >> >> >> >> - start/stop API (this is typically an API the user should be able to control for its own threads) >> - CDI 2.*0*? >> >> wdyt? >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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. From issues at jboss.org Thu Mar 10 15:02:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 10 Mar 2016 15:02:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-479) How to identify the bean a static observer method belongs to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175124#comment-13175124 ] Martin Kouba commented on CDI-479: ---------------------------------- Ok, so I've read the spec again and I also think both the observer methods from examples should be ignored because: 1. in example one it's not a method of a managed bean class 2. in example two the method does not belong to an enabled bean On the other hand, it might confusing for users as they might expect them to work. I suppose we don't have a TCK test for this, do we? > How to identify the bean a static observer method belongs to > ------------------------------------------------------------ > > Key: CDI-479 > URL: https://issues.jboss.org/browse/CDI-479 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > Let's sum up some parts of the spec which are relevant to static observer methods: > "10.4. Observer methods": > {quote} > An observer method is a non-abstract method of a managed bean class or session bean class... > An observer method may be either static or non-static. > {quote} > "10.3. Observer resolution": > {quote} > An event is delivered to an observer method if: > * The observer method belongs to an enabled bean. > * ... > {quote} > "12.4.3. Bean discovery": > {quote} > For each observer method of every enabled bean, the container registers an instance of the ObserverMethod interface defined in The ObserverMethod interface. > {quote} > Now what is the algorithm to *identify the bean a static observer method belongs to*? Is is bound to all beans whose Bean.getBeanClass() declares the method? There are two special scenarios I have in mind: > h3. Static observer method on an abstract class > {code:java} > public abstract class Foo { > public static observe1(@Observes Event1 event1) { > } > } > public class Bar extends Foo { > } > {code} > Foo is not a bean. Foo.observe1() is not a method of managed bean class Bar (if we strictly follow the JSL). Is the observer method detected? Does it belong to Bar? What if there are several subclasses of Foo? > h3. Specialization > {code:java} > public class Foo { > public static observe1(@Observes Event2 event2) { > } > } > @Specializes > public class Bar extends Foo { > } > {code} > Foo is specialized by Bar and thus it's disabled. Is the observer method detected? Does it belong to Bar? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 11 01:47:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 11 Mar 2016 01:47:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-479) How to identify the bean a static observer method belongs to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175235#comment-13175235 ] Tomas Remes commented on CDI-479: --------------------------------- I've found this. # We have {{org.jboss.cdi.tck.tests.event.broken.observer.beanNotManaged.ObserverMethodOnIncorrectBeanTest}} where we check that observer is disabled (not resolved) at non-managed bean and at abstract class with abstract method observer which is overriden in extending class. # We have {{org.jboss.cdi.tck.tests.event.observer.ObserverNotificationTest#testObserversNotified}} where we check that observer is disabled at bean which is not selected alternative. I think we can expand both cases in TCK and probably close this issue. What do you think [~antoinesabot-durand]? > How to identify the bean a static observer method belongs to > ------------------------------------------------------------ > > Key: CDI-479 > URL: https://issues.jboss.org/browse/CDI-479 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > Let's sum up some parts of the spec which are relevant to static observer methods: > "10.4. Observer methods": > {quote} > An observer method is a non-abstract method of a managed bean class or session bean class... > An observer method may be either static or non-static. > {quote} > "10.3. Observer resolution": > {quote} > An event is delivered to an observer method if: > * The observer method belongs to an enabled bean. > * ... > {quote} > "12.4.3. Bean discovery": > {quote} > For each observer method of every enabled bean, the container registers an instance of the ObserverMethod interface defined in The ObserverMethod interface. > {quote} > Now what is the algorithm to *identify the bean a static observer method belongs to*? Is is bound to all beans whose Bean.getBeanClass() declares the method? There are two special scenarios I have in mind: > h3. Static observer method on an abstract class > {code:java} > public abstract class Foo { > public static observe1(@Observes Event1 event1) { > } > } > public class Bar extends Foo { > } > {code} > Foo is not a bean. Foo.observe1() is not a method of managed bean class Bar (if we strictly follow the JSL). Is the observer method detected? Does it belong to Bar? What if there are several subclasses of Foo? > h3. Specialization > {code:java} > public class Foo { > public static observe1(@Observes Event2 event2) { > } > } > @Specializes > public class Bar extends Foo { > } > {code} > Foo is specialized by Bar and thus it's disabled. Is the observer method detected? Does it belong to Bar? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From struberg at yahoo.de Fri Mar 11 06:01:48 2016 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 11 Mar 2016 12:01:48 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: Message-ID: <23FBC9B6-0B33-4B11-A5A3-AAF0F805528B@yahoo.de> >From the servlet spec: ?Java Enterprise Edition features such as Section 15.2.2, ?Web Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of Security Identity in EJBTM Calls? on page 15-176 are available only to threads executing the initial request or when the request is dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition features may be available to other threads operating directly on the response object via the AsyncContext.start(Runnable) method.? check ?available only to threads executing the initial request? Also if you look at the servlet AsyncContext then all the wording is written as MAY and not as MUST. LieGrue, strub > Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau : > > Hi Mark, > > think 2.3.3.4 states the opposite. > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2016-03-10 19:43 GMT+01:00 Mark Struberg : > Back from JavaLand conference, so sorry for not kicking in earlier. > > I not quite get the argumentation chain. It?s that all triggered by async servlet requests? And isn?t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! > > Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? > Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? > > LieGrue, > strub > > > > > > Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau : > > > > Hi guys, > > > > following request scope thread and to center the discussion on the thread safety part: do we work on this? > > > > Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. > > > > Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. > > > > Questions: > > - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): > > > > > > > > > > JMS > > ASYNCHONOUS > > > > > > > > > > - start/stop API (this is typically an API the user should be able to control for its own threads) > > - CDI 2.*0*? > > > > wdyt? > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at 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. > > From issues at jboss.org Fri Mar 11 06:35:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 11 Mar 2016 06:35:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-508) Nested classes except for static nested classes should not be managed beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175327#comment-13175327 ] Tomas Remes commented on CDI-508: --------------------------------- I created https://github.com/cdi-spec/cdi/pull/282 > Nested classes except for static nested classes should not be managed beans > --------------------------------------------------------------------------- > > Key: CDI-508 > URL: https://issues.jboss.org/browse/CDI-508 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > The spec should explicitly state that all nested classes (inner, anonymous, local) except for static nested classes are not managed beans. > *3.1.1. Which Java classes are managed beans?* is confusing: > {quote} > A *top-level* Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions: > * It is not a *non-static inner class*. > * It is a concrete class, or is annotated @Decorator. > * ... > {quote} > # A *top-level* Java class is never nested > # Term *non-static inner class* is inaccurate, static nested classes are not inner > # It seems that *concrete class* is not defined in JLS, it should be probably replaced with something like non-abstract... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 11 07:39:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Fri, 11 Mar 2016 07:39:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-441) Enhance wording for indirect specialization in 4.3.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175357#comment-13175357 ] Matej Novotny commented on CDI-441: ----------------------------------- Created https://github.com/cdi-spec/cdi/pull/283 > Enhance wording for indirect specialization in 4.3.1 > ---------------------------------------------------- > > Key: CDI-441 > URL: https://issues.jboss.org/browse/CDI-441 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 1.2.Final > Reporter: Tomas Remes > > In the 4.3.1. Direct and indirect specialization is following: > {quote} > Formally, a bean X is said to specialize another bean Y if either: > ? X directly specializes Y, or > ? a bean Z exists, such that X directly specializes Z and Z specializes Y. > {quote} > It is not fully straightforward to deduce that the second point here is not just redundant first case, but rather transitive relationship in indirect specialization. > Therefore I think the wording for indirect specialization should be enhanced. Explanation from Jozef is at http://lists.jboss.org/pipermail/cdi-dev/2014-June/005082.html. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From reza_rahman at lycos.com Fri Mar 11 09:44:32 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Fri, 11 Mar 2016 09:44:32 -0500 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: <23FBC9B6-0B33-4B11-A5A3-AAF0F805528B@yahoo.de> References: <23FBC9B6-0B33-4B11-A5A3-AAF0F805528B@yahoo.de> Message-ID: This is essentially in keeping with the minimalist nature of the EE concurrency JSR. I believe most of it is left to vendors to do the right thing for users. May be a good idea is this language can be tightened up. > On Mar 11, 2016, at 6:01 AM, Mark Struberg wrote: > E > From the servlet spec: > > ?Java Enterprise Edition features such as Section 15.2.2, ?Web Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of Security Identity in EJBTM Calls? on page 15-176 are available only to threads executing the initial request or when the request is dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition features may be available to other threads operating directly on the response object via the AsyncContext.start(Runnable) method.? > > check ?available only to threads executing the initial request? > > Also if you look at the servlet AsyncContext then all the wording is written as MAY and not as MUST. > > LieGrue, > strub > > >> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau : >> >> Hi Mark, >> >> think 2.3.3.4 states the opposite. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >> 2016-03-10 19:43 GMT+01:00 Mark Struberg : >> Back from JavaLand conference, so sorry for not kicking in earlier. >> >> I not quite get the argumentation chain. It?s that all triggered by async servlet requests? And isn?t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! >> >> Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? >> Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? >> >> LieGrue, >> strub >> >> >> >> >>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau : >>> >>> Hi guys, >>> >>> following request scope thread and to center the discussion on the thread safety part: do we work on this? >>> >>> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. >>> >>> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. >>> >>> Questions: >>> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): >>> >>> >>> >>> >>> JMS >>> ASYNCHONOUS >>> >>> >>> >>> >>> - start/stop API (this is typically an API the user should be able to control for its own threads) >>> - CDI 2.*0*? >>> >>> wdyt? >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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. From issues at jboss.org Fri Mar 11 10:05:01 2016 From: issues at jboss.org (Bauke Scholtz (JIRA)) Date: Fri, 11 Mar 2016 10:05:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175437#comment-13175437 ] Bauke Scholtz commented on CDI-10: ---------------------------------- Another use case I discovered during developing JSF : being able to use package private methods (or fields) among CDI beans. Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable field of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable field). As this object is mutable, I'd rather keep it package private. Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field. {code:java} @SessionScoped public class SomeSessionScopedBean { private Map map; static Map getMap(SomeSessionScopedBean instance) { return instance.map; } } {code} This only doesn't work if the passed-in argument is actually a proxy instance obtained via `@Inject`. I had to work around it with `context.get(bean)`, but this theoretically less efficient than just unwrapping the proxy instance. > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 11 10:06:00 2016 From: issues at jboss.org (Bauke Scholtz (JIRA)) Date: Fri, 11 Mar 2016 10:06:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175437#comment-13175437 ] Bauke Scholtz edited comment on CDI-10 at 3/11/16 10:05 AM: ------------------------------------------------------------ Another use case I discovered during developing JSF : being able to use package private methods (or fields) among CDI beans. Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable field of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable field). As this object is mutable, I'd rather keep it package private. Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field. {code:java} @SessionScoped public class SomeSessionScopedBean { private Map map; static Map getMap(SomeSessionScopedBean instance) { return instance.map; } } {code} This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance. was (Author: bauke): Another use case I discovered during developing JSF : being able to use package private methods (or fields) among CDI beans. Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable field of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable field). As this object is mutable, I'd rather keep it package private. Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field. {code:java} @SessionScoped public class SomeSessionScopedBean { private Map map; static Map getMap(SomeSessionScopedBean instance) { return instance.map; } } {code} This only doesn't work if the passed-in argument is actually a proxy instance obtained via `@Inject`. I had to work around it with `context.get(bean)`, but this theoretically less efficient than just unwrapping the proxy instance. > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 11 10:08:01 2016 From: issues at jboss.org (Bauke Scholtz (JIRA)) Date: Fri, 11 Mar 2016 10:08:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175437#comment-13175437 ] Bauke Scholtz edited comment on CDI-10 at 3/11/16 10:07 AM: ------------------------------------------------------------ Another use case I discovered during developing JSF : being able to use package private methods (or fields) among CDI beans. Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable field of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable field). As this field is mutable, I'd rather keep it package private. Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field. {code:java} @SessionScoped public class SomeSessionScopedBean { private Map map; static Map getMap(SomeSessionScopedBean instance) { return instance.map; } } {code} This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance. was (Author: bauke): Another use case I discovered during developing JSF : being able to use package private methods (or fields) among CDI beans. Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable field of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable field). As this object is mutable, I'd rather keep it package private. Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field. {code:java} @SessionScoped public class SomeSessionScopedBean { private Map map; static Map getMap(SomeSessionScopedBean instance) { return instance.map; } } {code} This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance. > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 11 10:09:00 2016 From: issues at jboss.org (Bauke Scholtz (JIRA)) Date: Fri, 11 Mar 2016 10:09:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175437#comment-13175437 ] Bauke Scholtz edited comment on CDI-10 at 3/11/16 10:08 AM: ------------------------------------------------------------ Another use case I discovered during developing JSF : being able to use package private methods (or fields) among CDI beans. Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable property of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable object). As this object is mutable, I'd rather keep it package private. Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field. {code:java} @SessionScoped public class SomeSessionScopedBean { private Map map; static Map getMap(SomeSessionScopedBean instance) { return instance.map; } } {code} This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance. was (Author: bauke): Another use case I discovered during developing JSF : being able to use package private methods (or fields) among CDI beans. Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable field of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable field). As this field is mutable, I'd rather keep it package private. Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field. {code:java} @SessionScoped public class SomeSessionScopedBean { private Map map; static Map getMap(SomeSessionScopedBean instance) { return instance.map; } } {code} This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance. > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 11 10:10:00 2016 From: issues at jboss.org (Bauke Scholtz (JIRA)) Date: Fri, 11 Mar 2016 10:10:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175437#comment-13175437 ] Bauke Scholtz edited comment on CDI-10 at 3/11/16 10:09 AM: ------------------------------------------------------------ Another use case I discovered during developing JSF : being able to use package private methods (or fields) among CDI beans. Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable property of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable object). As this mutable object is hidden/constrained from public usage, I'd rather keep it package private. Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field. {code:java} @SessionScoped public class SomeSessionScopedBean { private Map map; static Map getMap(SomeSessionScopedBean instance) { return instance.map; } } {code} This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance. was (Author: bauke): Another use case I discovered during developing JSF : being able to use package private methods (or fields) among CDI beans. Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable property of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable object). As this object is mutable, I'd rather keep it package private. Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field. {code:java} @SessionScoped public class SomeSessionScopedBean { private Map map; static Map getMap(SomeSessionScopedBean instance) { return instance.map; } } {code} This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance. > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From struberg at yahoo.de Fri Mar 11 11:16:50 2016 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 11 Mar 2016 17:16:50 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: <23FBC9B6-0B33-4B11-A5A3-AAF0F805528B@yahoo.de> Message-ID: Yes, but certain things in EE are assumed to be handled on a single thread. And if you run on a servr then this is really not a blocker most times. If I get many paralllel requests hitting my box then I do not need async handling _that_ often. The whole overhead for setting up the new thread, etc often heavily exceeds the benefits. So I would not put too much energy into it? LieGrue, strub > Am 11.03.2016 um 15:44 schrieb Reza Rahman : > > This is essentially in keeping with the minimalist nature of the EE concurrency JSR. I believe most of it is left to vendors to do the right thing for users. May be a good idea is this language can be tightened up. > >> On Mar 11, 2016, at 6:01 AM, Mark Struberg wrote: >> E >> From the servlet spec: >> >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of Security Identity in EJBTM Calls? on page 15-176 are available only to threads executing the initial request or when the request is dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition features may be available to other threads operating directly on the response object via the AsyncContext.start(Runnable) method.? >> >> check ?available only to threads executing the initial request? >> >> Also if you look at the servlet AsyncContext then all the wording is written as MAY and not as MUST. >> >> LieGrue, >> strub >> >> >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau : >>> >>> Hi Mark, >>> >>> think 2.3.3.4 states the opposite. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg : >>> Back from JavaLand conference, so sorry for not kicking in earlier. >>> >>> I not quite get the argumentation chain. It?s that all triggered by async servlet requests? And isn?t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! >>> >>> Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? >>> Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau : >>>> >>>> Hi guys, >>>> >>>> following request scope thread and to center the discussion on the thread safety part: do we work on this? >>>> >>>> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. >>>> >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. >>>> >>>> Questions: >>>> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): >>>> >>>> >>>> >>>> >>>> JMS >>>> ASYNCHONOUS >>>> >>>> >>>> >>>> >>>> - start/stop API (this is typically an API the user should be able to control for its own threads) >>>> - CDI 2.*0*? >>>> >>>> wdyt? >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at 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 at 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 at 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. From issues at jboss.org Fri Mar 11 11:24:05 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 11 Mar 2016 11:24:05 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175515#comment-13175515 ] Mark Struberg commented on CDI-10: ---------------------------------- Have not read through all the comments, but context.get(bean) will only give you the 'Contextual Instance', means the singleton in the context. But that might already be wrapped with an Interceptor/Decorator proxy, so you don't have guaranteed access to the native class neither :/ > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 11 12:57:01 2016 From: issues at jboss.org (Bauke Scholtz (JIRA)) Date: Fri, 11 Mar 2016 12:57:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175586#comment-13175586 ] Bauke Scholtz commented on CDI-10: ---------------------------------- Perhaps not as per the spec, but it works fine in both Weld and OWB. Thanks for the heads up though, I may need to rethink the approach. > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 11 15:21:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 11 Mar 2016 15:21:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175618#comment-13175618 ] Mark Struberg commented on CDI-10: ---------------------------------- I fear it does _not_ work with neither ;) Just try it with an intercepted bean and you'll see what I mean. > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Mar 12 11:20:00 2016 From: issues at jboss.org (Bauke Scholtz (JIRA)) Date: Sat, 12 Mar 2016 11:20:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175812#comment-13175812 ] Bauke Scholtz commented on CDI-10: ---------------------------------- I understand that, but those beans are not part of public API. It's an implementation detail and not supposed to be intercepted/injected/whatever by enduser. > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Mar 12 11:21:00 2016 From: issues at jboss.org (Bauke Scholtz (JIRA)) Date: Sat, 12 Mar 2016 11:21:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175812#comment-13175812 ] Bauke Scholtz edited comment on CDI-10 at 3/12/16 11:20 AM: ------------------------------------------------------------ I understand that, but those beans are not part of public API. It's an implementation detail and not supposed to be intercepted/injected/whatever by enduser. Arjan Tijms suggested an alternate solution: a producer with a package private qualifier. I will try that sooner or later. was (Author: bauke): I understand that, but those beans are not part of public API. It's an implementation detail and not supposed to be intercepted/injected/whatever by enduser. > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Mar 12 11:21:00 2016 From: issues at jboss.org (Bauke Scholtz (JIRA)) Date: Sat, 12 Mar 2016 11:21:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175812#comment-13175812 ] Bauke Scholtz edited comment on CDI-10 at 3/12/16 11:20 AM: ------------------------------------------------------------ I understand that, but those beans are not part of public API. It's an implementation detail and not supposed to be intercepted/injected/whatever by enduser. Arjan Tijms suggested a potential alternate solution: a producer with a package private qualifier. I will try that sooner or later. was (Author: bauke): I understand that, but those beans are not part of public API. It's an implementation detail and not supposed to be intercepted/injected/whatever by enduser. Arjan Tijms suggested an alternate solution: a producer with a package private qualifier. I will try that sooner or later. > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Mar 12 11:22:00 2016 From: issues at jboss.org (Bauke Scholtz (JIRA)) Date: Sat, 12 Mar 2016 11:22:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175812#comment-13175812 ] Bauke Scholtz edited comment on CDI-10 at 3/12/16 11:21 AM: ------------------------------------------------------------ I understand that, but those beans are not part of public API. It's an implementation detail and not supposed to be intercepted/injected/whatever by enduser. Arjan Tijms suggested a potential alternate solution: a producer with a package private qualifier. I will try that sooner or later. Nonetheless, ability to unwrap the CDI proxy via native API is still much appreciated :) was (Author: bauke): I understand that, but those beans are not part of public API. It's an implementation detail and not supposed to be intercepted/injected/whatever by enduser. Arjan Tijms suggested a potential alternate solution: a producer with a package private qualifier. I will try that sooner or later. > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Mar 12 15:19:00 2016 From: issues at jboss.org (Bauke Scholtz (JIRA)) Date: Sat, 12 Mar 2016 15:19:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175812#comment-13175812 ] Bauke Scholtz edited comment on CDI-10 at 3/12/16 3:18 PM: ----------------------------------------------------------- I understand that, but those beans are not part of public API. It's an implementation detail and not supposed to be intercepted/injected/whatever by enduser. Arjan Tijms suggested a potential alternate solution: a producer with a package private qualifier. I will try that sooner or later. Update: it was quite convoluted and inefficient. In the end I went for "plain" protected methods along a disclaimer in javadoc. Nonetheless, ability to unwrap the CDI proxy via native API is still much appreciated :) was (Author: bauke): I understand that, but those beans are not part of public API. It's an implementation detail and not supposed to be intercepted/injected/whatever by enduser. Arjan Tijms suggested a potential alternate solution: a producer with a package private qualifier. I will try that sooner or later. Nonetheless, ability to unwrap the CDI proxy via native API is still much appreciated :) > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 07:04:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 14 Mar 2016 07:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175987#comment-13175987 ] Antoine Sabot-Durand commented on CDI-494: ------------------------------------------ This discussion already occurred on the mailing list: http://cdi-development-mailing-list.1064426.n5.nabble.com/Events-and-Type-Variables-in-CDI-1-1-tt5709814.html#none And obviously some people changed their mind may times on the topic. I think that if it's doable in the impl, we should clarify in the less strict version (i.e allowing unbounded wildcards) so +1 for PR with JLS compliant rewording. > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 07:53:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 14 Mar 2016 07:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176032#comment-13176032 ] Martin Kouba commented on CDI-494: ---------------------------------- Yes, I've probably changed my mind (not sure if many times ;-). [~struberg] What do OWB guys think about this issue? > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 08:07:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 14 Mar 2016 08:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176040#comment-13176040 ] Mark Struberg commented on CDI-494: ----------------------------------- That whole area is a big pile of work. I need to dig into it each time I have to work on it ;) It's also important to always keep in the back of the head that generic coercion for standard injection and for Decorators/Producers work a bit different, especially when it comes to wildcards! > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 09:13:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 14 Mar 2016 09:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176089#comment-13176089 ] Antoine Sabot-Durand commented on CDI-494: ------------------------------------------ Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List }}is similar to {{List}}. The only difference is that in the first version we won't need type information later. OTHO List (or List) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 09:22:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 14 Mar 2016 09:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176089#comment-13176089 ] Antoine Sabot-Durand edited comment on CDI-494 at 3/14/16 9:21 AM: ------------------------------------------------------------------- Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List }} is similar to {{List}}. The only difference is that in the first version we won't need type information later. OTHO List (or List) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 was (Author: antoinesabot-durand): Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List }}is similar to {{List}}. The only difference is that in the first version we won't need type information later. OTHO List (or List) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 09:22:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 14 Mar 2016 09:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176089#comment-13176089 ] Antoine Sabot-Durand edited comment on CDI-494 at 3/14/16 9:21 AM: ------------------------------------------------------------------- Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List}} is similar to {{List}}. The only difference is that in the first version we won't need type information later. OTHO List (or List) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 was (Author: antoinesabot-durand): Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List }} is similar to {{List}}. The only difference is that in the first version we won't need type information later. OTHO List (or List) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 09:23:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 14 Mar 2016 09:23:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176089#comment-13176089 ] Antoine Sabot-Durand edited comment on CDI-494 at 3/14/16 9:22 AM: ------------------------------------------------------------------- Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List}} is similar to {{List}}. The only difference is that in the first version we won't need type information later. OTHO {{List}} (or {{List}}) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 was (Author: antoinesabot-durand): Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List}} is similar to {{List}}. The only difference is that in the first version we won't need type information later. OTHO List (or List) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 10:32:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 14 Mar 2016 10:32:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-494: ------------------------------------- Comment: was deleted (was: Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List}} is similar to {{List}}. The only difference is that in the first version we won't need type information later. OTHO {{List}} (or {{List}}) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1) > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mpaluch at paluch.biz Mon Mar 14 12:18:06 2016 From: mpaluch at paluch.biz (Mark Paluch) Date: Mon, 14 Mar 2016 17:18:06 +0100 Subject: [cdi-dev] How to initiate a MR of JSR250 for @Priority Message-ID: Hi there, I noticed that we miss an update of JSR 250 for @Priority. Currently, @Priority allows only TYPE as target but we need PARAMETER for ordered events. How is the procedure to get an update and who can help? Best regards, Mark From antoine at sabot-durand.net Tue Mar 15 05:40:57 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 15 Mar 2016 09:40:57 +0000 Subject: [cdi-dev] How to initiate a MR of JSR250 for @Priority In-Reply-To: References: Message-ID: Good question Mark, I already asked about 5 or 6 times to Linda and Bill. I will retry a 7th time today. Antoine Le lun. 14 mars 2016 ? 17:18, Mark Paluch a ?crit : > Hi there, > > I noticed that we miss an update of JSR 250 for @Priority. Currently, > @Priority allows only TYPE as target but we need PARAMETER for ordered > events. How is the procedure to get an update and who can help? > > Best regards, Mark > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160315/3d118be3/attachment-0001.html From ondrej.mihalyi at gmail.com Tue Mar 15 13:12:31 2016 From: ondrej.mihalyi at gmail.com (=?UTF-8?Q?Ondrej_Mih=C3=A1lyi?=) Date: Tue, 15 Mar 2016 18:12:31 +0100 Subject: [cdi-dev] Standrdization of option to disable CDI for all app modules in single file? Message-ID: Hi, Some Java EE 6 apps still have issues with implicit scanning, even though they don't use guava and sometimes it is not possible to put beans.xml file into the problematic JARs. People are having issues with this when migrating to Glassfish 4 or Payara from Glassfish 3. With Payara server, we are thinking of creating an option in server-specific app descriptor to disable CDI completely either for whole application or just for specific modules. I think it would make sense to consider some standardization of this approach in CDI 2, as I've seen issues with this on stackoverflow also with other app servers. Or is it already planned? Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160315/dc122c68/attachment.html From rmannibucau at gmail.com Tue Mar 15 13:19:30 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 15 Mar 2016 18:19:30 +0100 Subject: [cdi-dev] Standrdization of option to disable CDI for all app modules in single file? In-Reply-To: References: Message-ID: Hi Ondrej, would it be possible to push it on ee list too? Scanning is not limited to CDI and at EE level EJB, Servlet etc... can get the exact same issue. A global scanning config would benefit the whole platform and CDI could just reuse it when not in EE. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-15 18:12 GMT+01:00 Ondrej Mih?lyi : > Hi, > > Some Java EE 6 apps still have issues with implicit scanning, even though > they don't use guava and sometimes it is not possible to put beans.xml file > into the problematic JARs. People are having issues with this when > migrating to Glassfish 4 or Payara from Glassfish 3. > > With Payara server, we are thinking of creating an option in > server-specific app descriptor to disable CDI completely either for whole > application or just for specific modules. > > > I think it would make sense to consider some standardization of this > approach in CDI 2, as I've seen issues with this on stackoverflow also with > other app servers. Or is it already planned? > > Ondrej > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160315/69c35b63/attachment.html From struberg at yahoo.de Tue Mar 15 14:06:21 2016 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 15 Mar 2016 18:06:21 +0000 (UTC) Subject: [cdi-dev] Standrdization of option to disable CDI for all app modules in single file? In-Reply-To: References: Message-ID: <1437554126.362382.1458065181801.JavaMail.yahoo@mail.yahoo.com> In Apache OpenWebBeans we have a mode org.apache.webbeans.scanBeansXmlOnly See http://openwebbeans.apache.org/owbconfig.html Maybe Weld could implement something similar? LieGrue, strub On Tuesday, 15 March 2016, 18:20, Romain Manni-Bucau wrote: > > >Hi Ondrej, > > >would it be possible to push it on ee list too? Scanning is not limited to CDI and at EE level EJB, Servlet etc... can get the exact same issue. A global scanning config would benefit the whole platform and CDI could just reuse it when not in EE. > > > >Romain Manni-Bucau >@rmannibucau | Blog | Github | LinkedIn | Tomitriber > >2016-03-15 18:12 GMT+01:00 Ondrej Mih?lyi : > >Hi, >> >> >>Some Java EE 6 apps still have issues with implicit scanning, even though they don't use guava and sometimes it is not possible to put beans.xml file into the problematic JARs. People are having issues with this when migrating to Glassfish 4 or Payara from Glassfish 3. >> >> >>With Payara server, we are thinking of creating an option in server-specific app descriptor to disable CDI completely either for whole application or just for specific modules. >> >> I think it would make sense to consider some standardization of this approach in CDI 2, as I've seen issues with this on stackoverflow also with other app servers. Or is it already planned? >> >> >>Ondrej >> >>_______________________________________________ >>cdi-dev mailing list >>cdi-dev at 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 at 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. > > From ondrej.mihalyi at gmail.com Tue Mar 15 18:04:13 2016 From: ondrej.mihalyi at gmail.com (=?UTF-8?Q?Ondrej_Mih=C3=A1lyi?=) Date: Tue, 15 Mar 2016 23:04:13 +0100 Subject: [cdi-dev] Standrdization of option to disable CDI for all app modules in single file? In-Reply-To: References: Message-ID: Possted also on Java EE mailing list: https://java.net/projects/javaee-spec/lists/users/archive/2016-03/message/12 2016-03-15 18:19 GMT+01:00 Romain Manni-Bucau : > Hi Ondrej, > > would it be possible to push it on ee list too? Scanning is not limited to > CDI and at EE level EJB, Servlet etc... can get the exact same issue. A > global scanning config would benefit the whole platform and CDI could just > reuse it when not in EE. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-03-15 18:12 GMT+01:00 Ondrej Mih?lyi : > >> Hi, >> >> Some Java EE 6 apps still have issues with implicit scanning, even though >> they don't use guava and sometimes it is not possible to put beans.xml file >> into the problematic JARs. People are having issues with this when >> migrating to Glassfish 4 or Payara from Glassfish 3. >> >> With Payara server, we are thinking of creating an option in >> server-specific app descriptor to disable CDI completely either for whole >> application or just for specific modules. >> >> >> I think it would make sense to consider some standardization of this >> approach in CDI 2, as I've seen issues with this on stackoverflow also with >> other app servers. Or is it already planned? >> >> Ondrej >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160315/d93c8303/attachment.html From john.d.ament at gmail.com Tue Mar 15 18:06:34 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 15 Mar 2016 22:06:34 +0000 Subject: [cdi-dev] Standrdization of option to disable CDI for all app modules in single file? In-Reply-To: <1437554126.362382.1458065181801.JavaMail.yahoo@mail.yahoo.com> References: <1437554126.362382.1458065181801.JavaMail.yahoo@mail.yahoo.com> Message-ID: But if its an app server specific thing, I would expect the app server to support it no? Wildfly has a config, glassfish had a config last I looked (was a long while ago). John On Tue, Mar 15, 2016 at 2:06 PM Mark Struberg wrote: > In Apache OpenWebBeans we have a mode > > org.apache.webbeans.scanBeansXmlOnly > > See http://openwebbeans.apache.org/owbconfig.html > > > Maybe Weld could implement something similar? > > LieGrue, > strub > > > > On Tuesday, 15 March 2016, 18:20, Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > > > > > > > >Hi Ondrej, > > > > > >would it be possible to push it on ee list too? Scanning is not limited > to CDI and at EE level EJB, Servlet etc... can get the exact same issue. A > global scanning config would benefit the whole platform and CDI could just > reuse it when not in EE. > > > > > > > >Romain Manni-Bucau > >@rmannibucau | Blog | Github | LinkedIn | Tomitriber > > > >2016-03-15 18:12 GMT+01:00 Ondrej Mih?lyi : > > > >Hi, > >> > >> > >>Some Java EE 6 apps still have issues with implicit scanning, even > though they don't use guava and sometimes it is not possible to put > beans.xml file into the problematic JARs. People are having issues with > this when migrating to Glassfish 4 or Payara from Glassfish 3. > >> > >> > >>With Payara server, we are thinking of > creating an option in server-specific app descriptor to disable CDI > completely either for whole application or just for specific modules. > >> > >> I think it would make sense to consider some standardization of this > approach in CDI 2, as I've seen issues with this on stackoverflow also with > other app servers. Or is it already planned? > >> > >> > >>Ondrej > >> > >>_______________________________________________ > >>cdi-dev mailing list > >>cdi-dev at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160315/22bcb715/attachment-0001.html From rmannibucau at gmail.com Tue Mar 15 18:11:31 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 15 Mar 2016 23:11:31 +0100 Subject: [cdi-dev] Standrdization of option to disable CDI for all app modules in single file? In-Reply-To: References: <1437554126.362382.1458065181801.JavaMail.yahoo@mail.yahoo.com> Message-ID: tomee has something but makes applications not portable for a common use case so having something at EE level would be great. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-15 23:06 GMT+01:00 John D. Ament : > But if its an app server specific thing, I would expect the app server to > support it no? > Wildfly has a config, glassfish had a config last I looked (was a long while > ago). > > John > > > On Tue, Mar 15, 2016 at 2:06 PM Mark Struberg wrote: >> >> In Apache OpenWebBeans we have a mode >> >> org.apache.webbeans.scanBeansXmlOnly >> >> See http://openwebbeans.apache.org/owbconfig.html >> >> >> Maybe Weld could implement something similar? >> >> LieGrue, >> strub >> >> >> >> On Tuesday, 15 March 2016, 18:20, Romain Manni-Bucau >> wrote: >> >> >> > >> > >> >Hi Ondrej, >> > >> > >> >would it be possible to push it on ee list too? Scanning is not limited >> > to CDI and at EE level EJB, Servlet etc... can get the exact same issue. A >> > global scanning config would benefit the whole platform and CDI could just >> > reuse it when not in EE. >> > >> > >> > >> >Romain Manni-Bucau >> >@rmannibucau | Blog | Github | LinkedIn | Tomitriber >> > >> >2016-03-15 18:12 GMT+01:00 Ondrej Mih?lyi : >> > >> >Hi, >> >> >> >> >> >>Some Java EE 6 apps still have issues with implicit scanning, even >> though they don't use guava and sometimes it is not possible to put >> beans.xml file into the problematic JARs. People are having issues with >> this when migrating to Glassfish 4 or Payara from Glassfish 3. >> >> >> >> >> >>With Payara server, we are thinking of >> creating an option in server-specific app descriptor to disable CDI >> completely either for whole application or just for specific modules. >> >> >> >> I think it would make sense to consider some standardization of this >> >> approach in CDI 2, as I've seen issues with this on stackoverflow also with >> >> other app servers. Or is it already planned? >> >> >> >> >> >>Ondrej >> >> >> >>_______________________________________________ >> >>cdi-dev mailing list >> >>cdi-dev at 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 at 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 at 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. From ondrej.mihalyi at gmail.com Tue Mar 15 18:13:55 2016 From: ondrej.mihalyi at gmail.com (=?utf-8?Q?Ondrej_Mih=C3=A1lyi?=) Date: Tue, 15 Mar 2016 23:13:55 +0100 Subject: [cdi-dev] Standrdization of option to disable CDI for all appmodules in single file? In-Reply-To: References: <1437554126.362382.1458065181801.JavaMail.yahoo@mail.yahoo.com> Message-ID: <56e8893a.84c9c20a.9cb22.10eb@mx.google.com> My point is that it is not standardized. Another point is, that almost no app server provides an option to declare this inside the app archive (WAR). You need to set it through app server configuration, which is often error prone, if not unacceptable in certain scenarios. S pozdravom, Ondrej Mih?lyi ----- P?vodn? spr?va ----- Od: "John D. Ament" Odoslan?: ?15.?3.?2016 23:06 Komu: "Mark Struberg" ; "Romain Manni-Bucau" ; "Ondrej Mih?lyi" K?pia: "cdi-dev at lists.jboss.org" Predmet: Re: [cdi-dev] Standrdization of option to disable CDI for all appmodules in single file? But if its an app server specific thing, I would expect the app server to support it no? Wildfly has a config, glassfish had a config last I looked (was a long while ago). John On Tue, Mar 15, 2016 at 2:06 PM Mark Struberg wrote: In Apache OpenWebBeans we have a mode org.apache.webbeans.scanBeansXmlOnly See http://openwebbeans.apache.org/owbconfig.html Maybe Weld could implement something similar? LieGrue, strub On Tuesday, 15 March 2016, 18:20, Romain Manni-Bucau wrote: > > >Hi Ondrej, > > >would it be possible to push it on ee list too? Scanning is not limited to CDI and at EE level EJB, Servlet etc... can get the exact same issue. A global scanning config would benefit the whole platform and CDI could just reuse it when not in EE. > > > >Romain Manni-Bucau >@rmannibucau | Blog | Github | LinkedIn | Tomitriber > >2016-03-15 18:12 GMT+01:00 Ondrej Mih?lyi : > >Hi, >> >> >>Some Java EE 6 apps still have issues with implicit scanning, even though they don't use guava and sometimes it is not possible to put beans.xml file into the problematic JARs. People are having issues with this when migrating to Glassfish 4 or Payara from Glassfish 3. >> >> >>With Payara server, we are thinking of creating an option in server-specific app descriptor to disable CDI completely either for whole application or just for specific modules. >> >> I think it would make sense to consider some standardization of this approach in CDI 2, as I've seen issues with this on stackoverflow also with other app servers. Or is it already planned? >> >> >>Ondrej >> >>_______________________________________________ >>cdi-dev mailing list >>cdi-dev at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160315/3a9f3625/attachment.html From issues at jboss.org Wed Mar 16 03:58:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 16 Mar 2016 03:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177513#comment-13177513 ] Antoine Sabot-Durand commented on CDI-420: ------------------------------------------ Last discussion on the topic, lead us to reconsider how {{annotated}} mode works. I'm going to study the spec to check if it says something about type scanning for {{annotated}} mode. If it's not the case we could specify that this mode had to scan all types. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 16 04:04:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 16 Mar 2016 04:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177519#comment-13177519 ] Antoine Sabot-Durand commented on CDI-527: ------------------------------------------ List of proposed names so far: * AllowProxying * Passthrough * SupressUnproxyAbleResolution * ForceProxy * SuppressUnproxyableResolutionException * AllowFinalMethodProxying * SkipFinalMethodProxying * IgnoreFinalMethodProxying * SkipUnproxyableMethod * IgnoreUnproxyableMethod * PassOverUnproxyable * ByPassUnproxyable > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 16 04:04:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 16 Mar 2016 04:04:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177519#comment-13177519 ] Antoine Sabot-Durand edited comment on CDI-527 at 3/16/16 4:03 AM: ------------------------------------------------------------------- List of proposed names for the annotation so far: * AllowProxying * Passthrough * SupressUnproxyAbleResolution * ForceProxy * SuppressUnproxyableResolutionException * AllowFinalMethodProxying * SkipFinalMethodProxying * IgnoreFinalMethodProxying * SkipUnproxyableMethod * IgnoreUnproxyableMethod * PassOverUnproxyable * ByPassUnproxyable was (Author: antoinesabot-durand): List of proposed names so far: * AllowProxying * Passthrough * SupressUnproxyAbleResolution * ForceProxy * SuppressUnproxyableResolutionException * AllowFinalMethodProxying * SkipFinalMethodProxying * IgnoreFinalMethodProxying * SkipUnproxyableMethod * IgnoreUnproxyableMethod * PassOverUnproxyable * ByPassUnproxyable > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 16 04:06:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 16 Mar 2016 04:06:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177520#comment-13177520 ] Martin Kouba commented on CDI-420: ---------------------------------- The container discovers each Java class with a bean defining annotation in an implicit bean archive (12.4.1. Type discovery). And an archive which contains a beans.xml file with the bean-discovery-mode of {{annotated}} is an implicit bean archive (12.1. Bean archives). > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 16 04:22:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 16 Mar 2016 04:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177531#comment-13177531 ] Matej Novotny commented on CDI-527: ----------------------------------- +1 for IgnoreFinalMethodProxying Reasons: * there is no real proxying going on for final methods, so word like {{ignore}} is better than {{allow}} * mentions that this annotation relates to final methods, making it clear * another good fit is {{IgnoreUnproxyableMethod}}, though I deem {{IgnoreFinalMethodProxying}} better because it underlines that you aim to ignore the process of proxy creation (rather than ignoring the method) > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 16 06:06:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 16 Mar 2016 06:06:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177599#comment-13177599 ] Antoine Sabot-Durand commented on CDI-420: ------------------------------------------ you were faster than me [~mkouba] ;). So behavior of type discovery in annotated mode is well defined. The question is: is it better to introduce a new mode (and confusion) or change the behavior of {{annotated}} mode (what would be the real side effect). > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 16 15:58:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 16 Mar 2016 15:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178122#comment-13178122 ] Mark Struberg commented on CDI-420: ----------------------------------- Would be great if we could just fix 'annotated'. But my gut feeling is also that we need another mode. It's imo really well defined what 'annotated' does right now. So I'm not sure whether we can change it. Especially if we are allowed to change the case without any beans.xml... > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 17 05:38:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 17 Mar 2016 05:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-588) Adding missing annotation Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178303#comment-13178303 ] Martin Kouba commented on CDI-588: ---------------------------------- [~antoinesabot-durand] [~stefanutti] The problem with {{@Priority}} is that it is not part of SE (only EE). And so we would have to add another dependency to CDI API pom.xml. > Adding missing annotation Literals > ---------------------------------- > > Key: CDI-588 > URL: https://issues.jboss.org/browse/CDI-588 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Assignee: Martin Kouba > > We forgot literals for {{Inject}} and more questionably literals for: > * {{Observes}} and {{ObservesAsync}} > * {{Produces}} and {{Disposes}} > * {{Specializes}} > * {{TransientReference}} > * {{Vetoed}} > Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 17 05:43:00 2016 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Thu, 17 Mar 2016 05:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-588) Adding missing annotation Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178309#comment-13178309 ] Antonin Stefanutti commented on CDI-588: ---------------------------------------- That's what I was afraid at first though the {{@Priority}} annotation is defined in {{java.interceptor-api}} JAR which is already added in the CDI API POM: https://github.com/cdi-spec/cdi/blob/2.0-EDR2/api/pom.xml#L179-L182 > Adding missing annotation Literals > ---------------------------------- > > Key: CDI-588 > URL: https://issues.jboss.org/browse/CDI-588 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Assignee: Martin Kouba > > We forgot literals for {{Inject}} and more questionably literals for: > * {{Observes}} and {{ObservesAsync}} > * {{Produces}} and {{Disposes}} > * {{Specializes}} > * {{TransientReference}} > * {{Vetoed}} > Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 17 06:08:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 17 Mar 2016 06:08:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-588) Adding missing annotation Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178319#comment-13178319 ] Martin Kouba commented on CDI-588: ---------------------------------- Not really, {{javax.annotation.Priority}} is defined in {{javax.annotation-api}}. Some classes from this API are part of the JDK. Some are only part of EE API (Priority, ManagedBean). > Adding missing annotation Literals > ---------------------------------- > > Key: CDI-588 > URL: https://issues.jboss.org/browse/CDI-588 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Assignee: Martin Kouba > > We forgot literals for {{Inject}} and more questionably literals for: > * {{Observes}} and {{ObservesAsync}} > * {{Produces}} and {{Disposes}} > * {{Specializes}} > * {{TransientReference}} > * {{Vetoed}} > Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 17 06:17:00 2016 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Thu, 17 Mar 2016 06:17:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-588) Adding missing annotation Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178328#comment-13178328 ] Antonin Stefanutti commented on CDI-588: ---------------------------------------- Indeed, my mistake. {{java.interceptor.Interceptor.Priority}} is part of {{java.interceptor-api}}. So the question, is whether that's acceptable to add a dependency on {{javax.annotation-api}}. > Adding missing annotation Literals > ---------------------------------- > > Key: CDI-588 > URL: https://issues.jboss.org/browse/CDI-588 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Assignee: Martin Kouba > > We forgot literals for {{Inject}} and more questionably literals for: > * {{Observes}} and {{ObservesAsync}} > * {{Produces}} and {{Disposes}} > * {{Specializes}} > * {{TransientReference}} > * {{Vetoed}} > Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 17 06:30:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 17 Mar 2016 06:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-588) Adding missing annotation Literals In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178344#comment-13178344 ] Antoine Sabot-Durand commented on CDI-588: ------------------------------------------ Well, {{javax.interceptor.Interceptor.Priority}} is not the annotation but the inner class to {{@Interceptor}} containing constants for priority. The annotation {{javax.annotation.Priority}} is part of JSR 250 (commons annotations). Some of the annotations of this spec are present in SE put not {{@Priority}}. So yes, we'd have to had this spec as dependency to CDI if we want this literal. IMO I think it's not worth it for the moment. > Adding missing annotation Literals > ---------------------------------- > > Key: CDI-588 > URL: https://issues.jboss.org/browse/CDI-588 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Antoine Sabot-Durand > Assignee: Martin Kouba > > We forgot literals for {{Inject}} and more questionably literals for: > * {{Observes}} and {{ObservesAsync}} > * {{Produces}} and {{Disposes}} > * {{Specializes}} > * {{TransientReference}} > * {{Vetoed}} > Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 17 07:14:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 17 Mar 2016 07:14:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178367#comment-13178367 ] Antoine Sabot-Durand commented on CDI-527: ------------------------------------------ Good point [~manovotn] +1 for {{IgnoreFinalMethodProxying}} > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 17 08:00:09 2016 From: issues at jboss.org (Thomas Andraschko (JIRA)) Date: Thu, 17 Mar 2016 08:00:09 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178388#comment-13178388 ] Thomas Andraschko commented on CDI-527: --------------------------------------- +1 for IgnoreUnproxyableMethod*s* to be more generic. > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Thu Mar 17 12:25:05 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 17 Mar 2016 16:25:05 +0000 Subject: [cdi-dev] Please review PR 270 Message-ID: Hi guys, As we said during last meeting, we need to release an alpha of the API ASAP to help TCK team in their work. PR270 introduces a lot of new interfaces (and a class) so it will trigger a lot of code on TCK side. So if you have time to review it by the end of the week-end please do so. https://github.com/cdi-spec/cdi/pull/270 Thanks Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160317/430ea9c9/attachment.html From issues at jboss.org Fri Mar 18 06:15:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 18 Mar 2016 06:15:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-589) Programmatic lookup - add Instance.release() method In-Reply-To: References: Message-ID: Martin Kouba created CDI-589: -------------------------------- Summary: Programmatic lookup - add Instance.release() method Key: CDI-589 URL: https://issues.jboss.org/browse/CDI-589 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.2.Final Reporter: Martin Kouba Assignee: Martin Kouba * destroys {{@Dependent}} bean instances * ignores client proxies See also https://github.com/cdi-spec/cdi/pull/273. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 18 06:16:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 18 Mar 2016 06:16:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-589) Programmatic lookup - add Instance.release() method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-589: ----------------------------- Description: * destroys {{@Dependent}} bean instances obtained from the same {{Instance}} object * ignores client proxies See also https://github.com/cdi-spec/cdi/pull/273. was: * destroys {{@Dependent}} bean instances * ignores client proxies See also https://github.com/cdi-spec/cdi/pull/273. > Programmatic lookup - add Instance.release() method > --------------------------------------------------- > > Key: CDI-589 > URL: https://issues.jboss.org/browse/CDI-589 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > * destroys {{@Dependent}} bean instances obtained from the same {{Instance}} object > * ignores client proxies > See also https://github.com/cdi-spec/cdi/pull/273. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 18 09:52:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 18 Mar 2016 09:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-582) Configurable concurrency control for CDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179080#comment-13179080 ] Martin Kouba commented on CDI-582: ---------------------------------- http://lists.jboss.org/pipermail/cdi-dev/2016-February/007769.html > Configurable concurrency control for CDI > ---------------------------------------- > > Key: CDI-582 > URL: https://issues.jboss.org/browse/CDI-582 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 2.0-EDR1 > Reporter: Stephan Knitelius > > Currently the spec only defines, a non-configurable, concurrency control mechanism for conversation scope. All other build-in scopes remain unprotected, relaying on the developer. > It would be useful to introduce EJB Singleton style concurrency control for CDI scopes. > Allowing the developer to configure the concurrency behavior of ConversationScoped beans, and defining concurrency control for the other build-in scopes. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mnriem at gmail.com Sat Mar 19 10:49:39 2016 From: mnriem at gmail.com (Manfred Riem) Date: Sat, 19 Mar 2016 07:49:39 -0700 (MST) Subject: [cdi-dev] Merging JSR-330 into CDI Message-ID: <1458398979185-5712810.post@n5.nabble.com> Hi all, I wrote a little blog entry about a CDI wish I have and in essence it comes down to merging JSR-330 into the CDI specification as a sub spec. I realize there is history there, but to me it looks like the best course of action. I had some twitter exchanges about this and some folks are for, some are against. Note I think this is worth exploring as an idea, not something that necessarily needs to be in the current JSR, but definitely something that I think is worth to do at some point (sooner rather than later in my book). What do you think? Thanks! Kind regards, Manfred Riem -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html Sent from the CDI Development mailing list mailing list archive at Nabble.com. From reza_rahman at lycos.com Sat Mar 19 11:47:48 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sat, 19 Mar 2016 11:47:48 -0400 Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: <1458398979185-5712810.post@n5.nabble.com> References: <1458398979185-5712810.post@n5.nabble.com> Message-ID: <53531384-8F15-48C4-B697-D5BD7C40B464@lycos.com> I definitely think it's an idea worth exploring. It will strengthen CDI's hand further. It will be great if some of the confusingly redundant APIs like @Singleton could be deprecated in the process. BTW, it is really great to see you active in the community! > On Mar 19, 2016, at 10:49 AM, Manfred Riem wrote: > > Hi all, > > I wrote a little blog entry about a CDI wish I have and in essence it comes > down to merging JSR-330 into the CDI specification as a sub spec. I realize > there is history there, but to me it looks like the best course of action. > > I had some twitter exchanges about this and some folks are for, some are > against. > > Note I think this is worth exploring as an idea, not something that > necessarily needs to be in the current JSR, but definitely something that I > think is worth to do at some point (sooner rather than later in my book). > > What do you think? > > Thanks! > > Kind regards, > Manfred Riem > > > > -- > View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html > Sent from the CDI Development mailing list mailing list archive at Nabble.com. > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. From aalmiray at yahoo.com Sat Mar 19 11:57:01 2016 From: aalmiray at yahoo.com (aalmiray) Date: Sat, 19 Mar 2016 08:57:01 -0700 (MST) Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: <1458398979185-5712810.post@n5.nabble.com> References: <1458398979185-5712810.post@n5.nabble.com> Message-ID: <1458403021139-5712812.post@n5.nabble.com> How would this move affect existing implementations, such as Guice, Springframework, Dagger, Afterburner, Griffon, etc? These implementations rely on a tiny core (the small JSR-330 JAR file) and nothing more. What are the foreseeable consequences of such move (as a subspec)? Cheers, Andres -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810p5712812.html Sent from the CDI Development mailing list mailing list archive at Nabble.com. From reza_rahman at lycos.com Sat Mar 19 12:08:27 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sat, 19 Mar 2016 12:08:27 -0400 Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: <1458403021139-5712812.post@n5.nabble.com> References: <1458398979185-5712810.post@n5.nabble.com> <1458403021139-5712812.post@n5.nabble.com> Message-ID: <97E56505-161F-43B4-AEEF-9CA661F60C22@lycos.com> They could certainly support the smallest CDI module/profile. The way the proposal looks, it should be pretty tiny and almost just the same as JSR 330. > On Mar 19, 2016, at 11:57 AM, aalmiray wrote: > > How would this move affect existing implementations, such as Guice, > Springframework, Dagger, Afterburner, Griffon, etc? These implementations > rely on a tiny core (the small JSR-330 JAR file) and nothing more. > > What are the foreseeable consequences of such move (as a subspec)? > > Cheers, > Andres > > > > -- > View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810p5712812.html > Sent from the CDI Development mailing list mailing list archive at Nabble.com. > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. From mnriem at gmail.com Sat Mar 19 14:27:03 2016 From: mnriem at gmail.com (Manfred Riem) Date: Sat, 19 Mar 2016 13:27:03 -0500 Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: <53531384-8F15-48C4-B697-D5BD7C40B464@lycos.com> References: <1458398979185-5712810.post@n5.nabble.com> <53531384-8F15-48C4-B697-D5BD7C40B464@lycos.com> Message-ID: <99BFE4FF-5231-4AA5-A21F-B59C7AF96C55@gmail.com> I couldn't agree more ;) Thanks! Kind regards, Manfred Riem > On Mar 19, 2016, at 10:47 AM, Reza Rahman wrote: > > I definitely think it's an idea worth exploring. It will strengthen CDI's hand further. It will be great if some of the confusingly redundant APIs like @Singleton could be deprecated in the process. > > BTW, it is really great to see you active in the community! > >> On Mar 19, 2016, at 10:49 AM, Manfred Riem wrote: >> >> Hi all, >> >> I wrote a little blog entry about a CDI wish I have and in essence it comes >> down to merging JSR-330 into the CDI specification as a sub spec. I realize >> there is history there, but to me it looks like the best course of action. >> >> I had some twitter exchanges about this and some folks are for, some are >> against. >> >> Note I think this is worth exploring as an idea, not something that >> necessarily needs to be in the current JSR, but definitely something that I >> think is worth to do at some point (sooner rather than later in my book). >> >> What do you think? >> >> Thanks! >> >> Kind regards, >> Manfred Riem >> >> >> >> -- >> View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html >> Sent from the CDI Development mailing list mailing list archive at Nabble.com. >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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. From stephan at knitelius.com Sat Mar 19 15:33:48 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Sat, 19 Mar 2016 19:33:48 +0000 Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: <99BFE4FF-5231-4AA5-A21F-B59C7AF96C55@gmail.com> References: <1458398979185-5712810.post@n5.nabble.com> <53531384-8F15-48C4-B697-D5BD7C40B464@lycos.com> <99BFE4FF-5231-4AA5-A21F-B59C7AF96C55@gmail.com> Message-ID: If I understand you correctly, you are suggesting to move the JSR-330 annotations into a separate CDI module/profile, thereby semi-deprecating these. This would essentially open up the possibility of replacing @Named, etc... with CDI specific annotations. Certainly an interesting path to explore. Stephan On Sa., 19. M?rz 2016 at 19:27, Manfred Riem wrote: > I couldn't agree more ;) > > Thanks! > > Kind regards, > Manfred Riem > > > On Mar 19, 2016, at 10:47 AM, Reza Rahman wrote: > > > > I definitely think it's an idea worth exploring. It will strengthen > CDI's hand further. It will be great if some of the confusingly redundant > APIs like @Singleton could be deprecated in the process. > > > > BTW, it is really great to see you active in the community! > > > >> On Mar 19, 2016, at 10:49 AM, Manfred Riem wrote: > >> > >> Hi all, > >> > >> I wrote a little blog entry about a CDI wish I have and in essence it > comes > >> down to merging JSR-330 into the CDI specification as a sub spec. I > realize > >> there is history there, but to me it looks like the best course of > action. > >> > >> I had some twitter exchanges about this and some folks are for, some are > >> against. > >> > >> Note I think this is worth exploring as an idea, not something that > >> necessarily needs to be in the current JSR, but definitely something > that I > >> think is worth to do at some point (sooner rather than later in my > book). > >> > >> What do you think? > >> > >> Thanks! > >> > >> Kind regards, > >> Manfred Riem > >> > >> > >> > >> -- > >> View this message in context: > http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html > >> Sent from the CDI Development mailing list mailing list archive at > Nabble.com. > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/5c56b90a/attachment.html From mnriem at gmail.com Sat Mar 19 15:40:34 2016 From: mnriem at gmail.com (Manfred Riem) Date: Sat, 19 Mar 2016 14:40:34 -0500 Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: References: <1458398979185-5712810.post@n5.nabble.com> <53531384-8F15-48C4-B697-D5BD7C40B464@lycos.com> <99BFE4FF-5231-4AA5-A21F-B59C7AF96C55@gmail.com> Message-ID: Hi Stephan, I am suggesting that JSR-330 gets rolled into the CDI spec as a chapter as it currently stands. Anything beyond that is beyond the scope of the discussion/wish I have as that would then be decided by the combined EG. Thanks! King regards, Manfred Riem > On Mar 19, 2016, at 2:33 PM, Stephan Knitelius wrote: > > If I understand you correctly, you are suggesting to move the JSR-330 annotations into a separate CDI module/profile, thereby semi-deprecating these. > > This would essentially open up the possibility of replacing @Named, etc... with CDI specific annotations. > > Certainly an interesting path to explore. > > Stephan > > > On Sa., 19. M?rz 2016 at 19:27, Manfred Riem > wrote: > I couldn't agree more ;) > > Thanks! > > Kind regards, > Manfred Riem > > > On Mar 19, 2016, at 10:47 AM, Reza Rahman > wrote: > > > > I definitely think it's an idea worth exploring. It will strengthen CDI's hand further. It will be great if some of the confusingly redundant APIs like @Singleton could be deprecated in the process. > > > > BTW, it is really great to see you active in the community! > > > >> On Mar 19, 2016, at 10:49 AM, Manfred Riem > wrote: > >> > >> Hi all, > >> > >> I wrote a little blog entry about a CDI wish I have and in essence it comes > >> down to merging JSR-330 into the CDI specification as a sub spec. I realize > >> there is history there, but to me it looks like the best course of action. > >> > >> I had some twitter exchanges about this and some folks are for, some are > >> against. > >> > >> Note I think this is worth exploring as an idea, not something that > >> necessarily needs to be in the current JSR, but definitely something that I > >> think is worth to do at some point (sooner rather than later in my book). > >> > >> What do you think? > >> > >> Thanks! > >> > >> Kind regards, > >> Manfred Riem > >> > >> > >> > >> -- > >> View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html > >> Sent from the CDI Development mailing list mailing list archive at Nabble.com. > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/48cc3b6c/attachment-0001.html From aalmiray at yahoo.com Sat Mar 19 15:45:40 2016 From: aalmiray at yahoo.com (aalmiray) Date: Sat, 19 Mar 2016 12:45:40 -0700 (MST) Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: References: <1458398979185-5712810.post@n5.nabble.com> <53531384-8F15-48C4-B697-D5BD7C40B464@lycos.com> <99BFE4FF-5231-4AA5-A21F-B59C7AF96C55@gmail.com> Message-ID: <1458416740491-5712817.post@n5.nabble.com> Precisely my thoughts. Any changes in behavior / binary compatibility in JSR-330 must be discussed with the JSR-330 EG and stakeholders. This being said, what would be the real benefit (to both specs) of rolling JSR-330 as a subspec of CDI? Cheers, Andres -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810p5712817.html Sent from the CDI Development mailing list mailing list archive at Nabble.com. From stephan at knitelius.com Sat Mar 19 15:53:13 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Sat, 19 Mar 2016 19:53:13 +0000 Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: References: <1458398979185-5712810.post@n5.nabble.com> <53531384-8F15-48C4-B697-D5BD7C40B464@lycos.com> <99BFE4FF-5231-4AA5-A21F-B59C7AF96C55@gmail.com> Message-ID: Hi Manfred, sorry my replay was a bit out of context since, I was referring to Rezas last mail. As already discussed yesterday, this could proof difficult. Since there are other implementations based on JSR-330, most noticeably spring. What exactly are we looking to gain from integrating JSR-330? I agree it would be "cleaner", but maybe too much effort for too little gain. If we wanted greater control over those parts, maybe it would be better to move these parts into a separate module for backwards compatibility. Including new CDI owned annotations alongside the separated JSR-330, as and where sensible. Stephan On Sa., 19. M?rz 2016 at 20:40, Manfred Riem wrote: > Hi Stephan, > > I am suggesting that JSR-330 gets rolled into the CDI spec as a chapter as > it currently > stands. Anything beyond that is beyond the scope of the discussion/wish I > have as that > would then be decided by the combined EG. > > Thanks! > > King regards, > Manfred Riem > > > On Mar 19, 2016, at 2:33 PM, Stephan Knitelius > wrote: > > If I understand you correctly, you are suggesting to move the JSR-330 > annotations into a separate CDI module/profile, thereby semi-deprecating > these. > > This would essentially open up the possibility of replacing @Named, etc... > with CDI specific annotations. > > Certainly an interesting path to explore. > > Stephan > > > On Sa., 19. M?rz 2016 at 19:27, Manfred Riem wrote: > >> I couldn't agree more ;) >> >> Thanks! >> >> Kind regards, >> Manfred Riem >> >> > On Mar 19, 2016, at 10:47 AM, Reza Rahman >> wrote: >> > >> > I definitely think it's an idea worth exploring. It will strengthen >> CDI's hand further. It will be great if some of the confusingly redundant >> APIs like @Singleton could be deprecated in the process. >> > >> > BTW, it is really great to see you active in the community! >> > >> >> On Mar 19, 2016, at 10:49 AM, Manfred Riem wrote: >> >> >> >> Hi all, >> >> >> >> I wrote a little blog entry about a CDI wish I have and in essence it >> comes >> >> down to merging JSR-330 into the CDI specification as a sub spec. I >> realize >> >> there is history there, but to me it looks like the best course of >> action. >> >> >> >> I had some twitter exchanges about this and some folks are for, some >> are >> >> against. >> >> >> >> Note I think this is worth exploring as an idea, not something that >> >> necessarily needs to be in the current JSR, but definitely something >> that I >> >> think is worth to do at some point (sooner rather than later in my >> book). >> >> >> >> What do you think? >> >> >> >> Thanks! >> >> >> >> Kind regards, >> >> Manfred Riem >> >> >> >> >> >> >> >> -- >> >> View this message in context: >> http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html >> >> Sent from the CDI Development mailing list mailing list archive at >> Nabble.com . >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at 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 at 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 at 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. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/ced89eaa/attachment.html From stephan at knitelius.com Sat Mar 19 16:35:29 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Sat, 19 Mar 2016 20:35:29 +0000 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: <23FBC9B6-0B33-4B11-A5A3-AAF0F805528B@yahoo.de> Message-ID: I would certainly agree with the assertion that in general it's not advisable to execute a request with multiple threads and that usually single threaded execution is sufficient. However I don't think ignoring it is an option. Concurrent operations can be launched even from CDI beans. Yet we don't properly support context propagation nor a context spanning all threads launched from a request. I know that changing @requestScoped is probably out of the question, but at least we should consider adding a new context spanning all threads and defining a logical solution for context propagation that can be explained to the end user. On Fr., 11. M?rz 2016 at 17:17, Mark Struberg wrote: > Yes, but certain things in EE are assumed to be handled on a single > thread. And if you run on a servr then this is really not a blocker most > times. If I get many paralllel requests hitting my box then I do not need > async handling _that_ often. The whole overhead for setting up the new > thread, etc often heavily exceeds the benefits. > So I would not put too much energy into it? > > LieGrue, > strub > > > Am 11.03.2016 um 15:44 schrieb Reza Rahman : > > > > This is essentially in keeping with the minimalist nature of the EE > concurrency JSR. I believe most of it is left to vendors to do the right > thing for users. May be a good idea is this language can be tightened up. > > > >> On Mar 11, 2016, at 6:01 AM, Mark Struberg wrote: > >> E > >> From the servlet spec: > >> > >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web > Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of > Security Identity in EJBTM Calls? on page 15-176 are available only to > threads executing the initial request or when the request is dispatched to > the container via the AsyncContext.dispatch method. Java Enterprise Edition > features may be available to other threads operating directly on the > response object via the AsyncContext.start(Runnable) method.? > >> > >> check ?available only to threads executing the initial request? > >> > >> Also if you look at the servlet AsyncContext then all the wording is > written as MAY and not as MUST. > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau < > rmannibucau at gmail.com>: > >>> > >>> Hi Mark, > >>> > >>> think 2.3.3.4 states the opposite. > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>> > >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg : > >>> Back from JavaLand conference, so sorry for not kicking in earlier. > >>> > >>> I not quite get the argumentation chain. It?s that all triggered by > async servlet requests? And isn?t the servlet spec also saying that all the > request param etc may max be assigned to a single thread AT A TIME! > >>> > >>> Means that it might not be on multiple threads in parallel, but the > data is allowed to get moved from one thread to another (disapearing from > the first one), right? > >>> Would really need to dig into the wording of the async servlets spec > again, maybe has this in the back of his head? > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>> > >>> > >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < > rmannibucau at gmail.com>: > >>>> > >>>> Hi guys, > >>>> > >>>> following request scope thread and to center the discussion on the > thread safety part: do we work on this? > >>>> > >>>> Background: @RequestScoped is often used as a ThreadLocal instance > solution. A lot of SE or Batch implementations rely on it from what I saw > as well as async implementations reusing existing business logic with this > thread safety constraint. > >>>> > >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI > and implemenation and would avoid the headache we can have with > @RequestScoped. Will also remove the quite dark side of the spec regarding > servlet request and request scope since now we would have a more natural > solution for all of these situation so @RequestScoped goals wouldn't > collide as much. > >>>> > >>>> Questions: > >>>> - is it automatically started as request scoped is (JMS, @Async, > ...)? Alternative could be some configuration in beans.xml (merged accross > the app): > >>>> > >>>> > >>>> > >>>> > >>>> JMS > >>>> ASYNCHONOUS > >>>> > >>>> > >>>> > >>>> > >>>> - start/stop API (this is typically an API the user should be able to > control for its own threads) > >>>> - CDI 2.*0*? > >>>> > >>>> wdyt? > >>>> > >>>> Romain Manni-Bucau > >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/1e3adce7/attachment-0001.html From arjan.tijms at gmail.com Sat Mar 19 16:44:29 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Sat, 19 Mar 2016 21:44:29 +0100 Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: References: <1458398979185-5712810.post@n5.nabble.com> <53531384-8F15-48C4-B697-D5BD7C40B464@lycos.com> <99BFE4FF-5231-4AA5-A21F-B59C7AF96C55@gmail.com> Message-ID: Hi, On Saturday, March 19, 2016, Stephan Knitelius wrote: > Hi Manfred, > > sorry my replay was a bit out of context since, I was referring to Rezas > last mail. > > As already discussed yesterday, this could proof difficult. Since there > are other implementations based on JSR-330, most noticeably spring. Wound anything really change for other implementations technically? AtInject 1.0 will stay as it is, but newer versions of it will be done as sub-spec of CDI, right? If those other implementations do not want changes in AtInject then things can stay as they are, and if they do want changes they can ask the CDI EG, which is active. If it's a sub-spec, I guess just the sub-spec can be officially implemented (like Hibernate implemented just sub-spec JPA which was initially part of EJB). But have those other implementations ever asked for changes? Kind regards, Arjan Tijms > > What exactly are we looking to gain from integrating JSR-330? > > I agree it would be "cleaner", but maybe too much effort for too little > gain. > > If we wanted greater control over those parts, maybe it would be better to > move these parts into a separate module for backwards compatibility. > Including new CDI owned annotations alongside the separated JSR-330, as > and where sensible. > > Stephan > > > On Sa., 19. M?rz 2016 at 20:40, Manfred Riem > wrote: > >> Hi Stephan, >> >> I am suggesting that JSR-330 gets rolled into the CDI spec as a chapter >> as it currently >> stands. Anything beyond that is beyond the scope of the discussion/wish I >> have as that >> would then be decided by the combined EG. >> >> Thanks! >> >> King regards, >> Manfred Riem >> >> >> On Mar 19, 2016, at 2:33 PM, Stephan Knitelius > > wrote: >> >> If I understand you correctly, you are suggesting to move the JSR-330 >> annotations into a separate CDI module/profile, thereby semi-deprecating >> these. >> >> This would essentially open up the possibility of replacing @Named, >> etc... with CDI specific annotations. >> >> Certainly an interesting path to explore. >> >> Stephan >> >> >> On Sa., 19. M?rz 2016 at 19:27, Manfred Riem > > wrote: >> >>> I couldn't agree more ;) >>> >>> Thanks! >>> >>> Kind regards, >>> Manfred Riem >>> >>> > On Mar 19, 2016, at 10:47 AM, Reza Rahman >> > wrote: >>> > >>> > I definitely think it's an idea worth exploring. It will strengthen >>> CDI's hand further. It will be great if some of the confusingly redundant >>> APIs like @Singleton could be deprecated in the process. >>> > >>> > BTW, it is really great to see you active in the community! >>> > >>> >> On Mar 19, 2016, at 10:49 AM, Manfred Riem >> > wrote: >>> >> >>> >> Hi all, >>> >> >>> >> I wrote a little blog entry about a CDI wish I have and in essence it >>> comes >>> >> down to merging JSR-330 into the CDI specification as a sub spec. I >>> realize >>> >> there is history there, but to me it looks like the best course of >>> action. >>> >> >>> >> I had some twitter exchanges about this and some folks are for, some >>> are >>> >> against. >>> >> >>> >> Note I think this is worth exploring as an idea, not something that >>> >> necessarily needs to be in the current JSR, but definitely something >>> that I >>> >> think is worth to do at some point (sooner rather than later in my >>> book). >>> >> >>> >> What do you think? >>> >> >>> >> Thanks! >>> >> >>> >> Kind regards, >>> >> Manfred Riem >>> >> >>> >> >>> >> >>> >> -- >>> >> View this message in context: >>> http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html >>> >> Sent from the CDI Development mailing list mailing list archive at >>> Nabble.com . >>> >> _______________________________________________ >>> >> cdi-dev mailing list >>> >> cdi-dev at 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 at 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 at 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. >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/5ae8a87f/attachment.html From arjan.tijms at gmail.com Sat Mar 19 16:57:11 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Sat, 19 Mar 2016 21:57:11 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: <23FBC9B6-0B33-4B11-A5A3-AAF0F805528B@yahoo.de> Message-ID: Hi, On Saturday, March 19, 2016, Stephan Knitelius wrote: > I would certainly agree with the assertion that in general it's not > advisable to execute a request with multiple threads and that usually > single threaded execution is sufficient. > > However I don't think ignoring it is an option. Concurrent operations can > be launched even from CDI beans. Yet we don't properly support context > propagation nor a context spanning all threads launched from a request. That really sounds like a very useful proposal. Kinda like a session scope, but for a select group of threads. Like so many other things, logically you'd say such thing should be placed in the concurrency spec. Feels weird to put things in another less logical place just because there are no plans do a concurrency spec update. Kind regards, Arjan Tijms > > I know that changing @requestScoped is probably out of the question, but > at least we should consider adding a new context spanning all threads and > defining a logical solution for context propagation that can be explained > to the end user. > > > > On Fr., 11. M?rz 2016 at 17:17, Mark Struberg > wrote: > >> Yes, but certain things in EE are assumed to be handled on a single >> thread. And if you run on a servr then this is really not a blocker most >> times. If I get many paralllel requests hitting my box then I do not need >> async handling _that_ often. The whole overhead for setting up the new >> thread, etc often heavily exceeds the benefits. >> So I would not put too much energy into it? >> >> LieGrue, >> strub >> >> > Am 11.03.2016 um 15:44 schrieb Reza Rahman > >: >> > >> > This is essentially in keeping with the minimalist nature of the EE >> concurrency JSR. I believe most of it is left to vendors to do the right >> thing for users. May be a good idea is this language can be tightened up. >> > >> >> On Mar 11, 2016, at 6:01 AM, Mark Struberg > > wrote: >> >> E >> >> From the servlet spec: >> >> >> >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web >> Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of >> Security Identity in EJBTM Calls? on page 15-176 are available only to >> threads executing the initial request or when the request is dispatched to >> the container via the AsyncContext.dispatch method. Java Enterprise Edition >> features may be available to other threads operating directly on the >> response object via the AsyncContext.start(Runnable) method.? >> >> >> >> check ?available only to threads executing the initial request? >> >> >> >> Also if you look at the servlet AsyncContext then all the wording is >> written as MAY and not as MUST. >> >> >> >> LieGrue, >> >> strub >> >> >> >> >> >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau < >> rmannibucau at gmail.com >> >: >> >>> >> >>> Hi Mark, >> >>> >> >>> think 2.3.3.4 states the opposite. >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>> >> >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg > >: >> >>> Back from JavaLand conference, so sorry for not kicking in earlier. >> >>> >> >>> I not quite get the argumentation chain. It?s that all triggered by >> async servlet requests? And isn?t the servlet spec also saying that all the >> request param etc may max be assigned to a single thread AT A TIME! >> >>> >> >>> Means that it might not be on multiple threads in parallel, but the >> data is allowed to get moved from one thread to another (disapearing from >> the first one), right? >> >>> Would really need to dig into the wording of the async servlets spec >> again, maybe has this in the back of his head? >> >>> >> >>> LieGrue, >> >>> strub >> >>> >> >>> >> >>> >> >>> >> >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < >> rmannibucau at gmail.com >> >: >> >>>> >> >>>> Hi guys, >> >>>> >> >>>> following request scope thread and to center the discussion on the >> thread safety part: do we work on this? >> >>>> >> >>>> Background: @RequestScoped is often used as a ThreadLocal instance >> solution. A lot of SE or Batch implementations rely on it from what I saw >> as well as async implementations reusing existing business logic with this >> thread safety constraint. >> >>>> >> >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI >> and implemenation and would avoid the headache we can have with >> @RequestScoped. Will also remove the quite dark side of the spec regarding >> servlet request and request scope since now we would have a more natural >> solution for all of these situation so @RequestScoped goals wouldn't >> collide as much. >> >>>> >> >>>> Questions: >> >>>> - is it automatically started as request scoped is (JMS, @Async, >> ...)? Alternative could be some configuration in beans.xml (merged accross >> the app): >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> JMS >> >>>> ASYNCHONOUS >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> - start/stop API (this is typically an API the user should be able >> to control for its own threads) >> >>>> - CDI 2.*0*? >> >>>> >> >>>> wdyt? >> >>>> >> >>>> Romain Manni-Bucau >> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>>> _______________________________________________ >> >>>> cdi-dev mailing list >> >>>> cdi-dev at 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 at 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 at 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 at 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/e8dfc9e7/attachment-0001.html From stephan at knitelius.com Sat Mar 19 17:02:43 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Sat, 19 Mar 2016 21:02:43 +0000 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: <23FBC9B6-0B33-4B11-A5A3-AAF0F805528B@yahoo.de> Message-ID: Well as discussed in another mail, the concurrency spec is a bit ambiguous about context propagation, it's not explicitly forbidden. Would a new context also belong into the concurrency spec? On Sa., 19. M?rz 2016 at 21:57, arjan tijms wrote: > Hi, > > On Saturday, March 19, 2016, Stephan Knitelius > wrote: > >> I would certainly agree with the assertion that in general it's not >> advisable to execute a request with multiple threads and that usually >> single threaded execution is sufficient. >> >> However I don't think ignoring it is an option. Concurrent operations can >> be launched even from CDI beans. Yet we don't properly support context >> propagation nor a context spanning all threads launched from a request. > > > That really sounds like a very useful proposal. Kinda like a session > scope, but for a select group of threads. > > Like so many other things, logically you'd say such thing should be placed > in the concurrency spec. Feels weird to put things in another less logical > place just because there are no plans do a concurrency spec update. > > Kind regards, > Arjan Tijms > > > >> >> I know that changing @requestScoped is probably out of the question, but >> at least we should consider adding a new context spanning all threads and >> defining a logical solution for context propagation that can be explained >> to the end user. >> >> >> >> On Fr., 11. M?rz 2016 at 17:17, Mark Struberg wrote: >> >>> Yes, but certain things in EE are assumed to be handled on a single >>> thread. And if you run on a servr then this is really not a blocker most >>> times. If I get many paralllel requests hitting my box then I do not need >>> async handling _that_ often. The whole overhead for setting up the new >>> thread, etc often heavily exceeds the benefits. >>> So I would not put too much energy into it? >>> >>> LieGrue, >>> strub >>> >>> > Am 11.03.2016 um 15:44 schrieb Reza Rahman : >>> > >>> > This is essentially in keeping with the minimalist nature of the EE >>> concurrency JSR. I believe most of it is left to vendors to do the right >>> thing for users. May be a good idea is this language can be tightened up. >>> > >>> >> On Mar 11, 2016, at 6:01 AM, Mark Struberg wrote: >>> >> E >>> >> From the servlet spec: >>> >> >>> >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web >>> Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of >>> Security Identity in EJBTM Calls? on page 15-176 are available only to >>> threads executing the initial request or when the request is dispatched to >>> the container via the AsyncContext.dispatch method. Java Enterprise Edition >>> features may be available to other threads operating directly on the >>> response object via the AsyncContext.start(Runnable) method.? >>> >> >>> >> check ?available only to threads executing the initial request? >>> >> >>> >> Also if you look at the servlet AsyncContext then all the wording is >>> written as MAY and not as MUST. >>> >> >>> >> LieGrue, >>> >> strub >>> >> >>> >> >>> >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau < >>> rmannibucau at gmail.com>: >>> >>> >>> >>> Hi Mark, >>> >>> >>> >>> think 2.3.3.4 states the opposite. >>> >>> >>> >>> >>> >>> Romain Manni-Bucau >>> >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> >>> >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg : >>> >>> Back from JavaLand conference, so sorry for not kicking in earlier. >>> >>> >>> >>> I not quite get the argumentation chain. It?s that all triggered by >>> async servlet requests? And isn?t the servlet spec also saying that all the >>> request param etc may max be assigned to a single thread AT A TIME! >>> >>> >>> >>> Means that it might not be on multiple threads in parallel, but the >>> data is allowed to get moved from one thread to another (disapearing from >>> the first one), right? >>> >>> Would really need to dig into the wording of the async servlets spec >>> again, maybe has this in the back of his head? >>> >>> >>> >>> LieGrue, >>> >>> strub >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < >>> rmannibucau at gmail.com>: >>> >>>> >>> >>>> Hi guys, >>> >>>> >>> >>>> following request scope thread and to center the discussion on the >>> thread safety part: do we work on this? >>> >>>> >>> >>>> Background: @RequestScoped is often used as a ThreadLocal instance >>> solution. A lot of SE or Batch implementations rely on it from what I saw >>> as well as async implementations reusing existing business logic with this >>> thread safety constraint. >>> >>>> >>> >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI >>> and implemenation and would avoid the headache we can have with >>> @RequestScoped. Will also remove the quite dark side of the spec regarding >>> servlet request and request scope since now we would have a more natural >>> solution for all of these situation so @RequestScoped goals wouldn't >>> collide as much. >>> >>>> >>> >>>> Questions: >>> >>>> - is it automatically started as request scoped is (JMS, @Async, >>> ...)? Alternative could be some configuration in beans.xml (merged accross >>> the app): >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> JMS >>> >>>> ASYNCHONOUS >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> - start/stop API (this is typically an API the user should be able >>> to control for its own threads) >>> >>>> - CDI 2.*0*? >>> >>>> >>> >>>> wdyt? >>> >>>> >>> >>>> Romain Manni-Bucau >>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>>> _______________________________________________ >>> >>>> cdi-dev mailing list >>> >>>> cdi-dev at 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 at 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 at 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 at 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. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/6ff1f828/attachment.html From werner.keil at gmail.com Sat Mar 19 17:07:17 2016 From: werner.keil at gmail.com (Werner Keil) Date: Sat, 19 Mar 2016 22:07:17 +0100 Subject: [cdi-dev] Merging JSR-330 into CDI Message-ID: Keeping the few annotations like @Inject as they are should be also in CDI's interest, but as JSR 330 is final there is no EG. Unlike this EG and mailing list with great participation, there has never been too much of an EG even when 330 was active, it was more or less Bob and maybe a few participants in the mailing lists. That activity stopped in 2011, see https://groups.google.com/forum/?hl=de#!forum/atinject-observer, so the EG pretty much died 5 years ago. It seems reasonable and natural to do changes or tweaks as part of CDI. Werner On Sat, Mar 19, 2016 at 9:35 PM, wrote: > Send cdi-dev mailing list submissions to > cdi-dev at 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 at lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner at 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. Re: Merging JSR-330 into CDI (aalmiray) > 2. Re: Merging JSR-330 into CDI (Stephan Knitelius) > 3. Re: @ThreadScoped? (Stephan Knitelius) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 19 Mar 2016 12:45:40 -0700 (MST) > From: aalmiray > Subject: Re: [cdi-dev] Merging JSR-330 into CDI > To: cdi-dev at lists.jboss.org > Message-ID: <1458416740491-5712817.post at n5.nabble.com> > Content-Type: text/plain; charset=us-ascii > > Precisely my thoughts. Any changes in behavior / binary compatibility in > JSR-330 must be discussed with the JSR-330 EG and stakeholders. > > This being said, what would be the real benefit (to both specs) of rolling > JSR-330 as a subspec of CDI? > > Cheers, > Andres > > > > -- > View this message in context: > http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810p5712817.html > Sent from the CDI Development mailing list mailing list archive at > Nabble.com. > > > ------------------------------ > > Message: 2 > Date: Sat, 19 Mar 2016 19:53:13 +0000 > From: Stephan Knitelius > Subject: Re: [cdi-dev] Merging JSR-330 into CDI > To: Manfred Riem > Cc: cdi-dev at lists.jboss.org > Message-ID: > < > CAGMB8Y1pe60oOc35uA19MpmeEjUMLZGn39vPTofxS24_8gcnyg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Manfred, > > sorry my replay was a bit out of context since, I was referring to Rezas > last mail. > > As already discussed yesterday, this could proof difficult. Since there are > other implementations based on JSR-330, most noticeably spring. > > What exactly are we looking to gain from integrating JSR-330? > > I agree it would be "cleaner", but maybe too much effort for too little > gain. > > If we wanted greater control over those parts, maybe it would be better to > move these parts into a separate module for backwards compatibility. > Including new CDI owned annotations alongside the separated JSR-330, as and > where sensible. > > Stephan > > > On Sa., 19. M?rz 2016 at 20:40, Manfred Riem wrote: > > > Hi Stephan, > > > > I am suggesting that JSR-330 gets rolled into the CDI spec as a chapter > as > > it currently > > stands. Anything beyond that is beyond the scope of the discussion/wish I > > have as that > > would then be decided by the combined EG. > > > > Thanks! > > > > King regards, > > Manfred Riem > > > > > > On Mar 19, 2016, at 2:33 PM, Stephan Knitelius > > wrote: > > > > If I understand you correctly, you are suggesting to move the JSR-330 > > annotations into a separate CDI module/profile, thereby semi-deprecating > > these. > > > > This would essentially open up the possibility of replacing @Named, > etc... > > with CDI specific annotations. > > > > Certainly an interesting path to explore. > > > > Stephan > > > > > > On Sa., 19. M?rz 2016 at 19:27, Manfred Riem wrote: > > > >> I couldn't agree more ;) > >> > >> Thanks! > >> > >> Kind regards, > >> Manfred Riem > >> > >> > On Mar 19, 2016, at 10:47 AM, Reza Rahman > >> wrote: > >> > > >> > I definitely think it's an idea worth exploring. It will strengthen > >> CDI's hand further. It will be great if some of the confusingly > redundant > >> APIs like @Singleton could be deprecated in the process. > >> > > >> > BTW, it is really great to see you active in the community! > >> > > >> >> On Mar 19, 2016, at 10:49 AM, Manfred Riem wrote: > >> >> > >> >> Hi all, > >> >> > >> >> I wrote a little blog entry about a CDI wish I have and in essence it > >> comes > >> >> down to merging JSR-330 into the CDI specification as a sub spec. I > >> realize > >> >> there is history there, but to me it looks like the best course of > >> action. > >> >> > >> >> I had some twitter exchanges about this and some folks are for, some > >> are > >> >> against. > >> >> > >> >> Note I think this is worth exploring as an idea, not something that > >> >> necessarily needs to be in the current JSR, but definitely something > >> that I > >> >> think is worth to do at some point (sooner rather than later in my > >> book). > >> >> > >> >> What do you think? > >> >> > >> >> Thanks! > >> >> > >> >> Kind regards, > >> >> Manfred Riem > >> >> > >> >> > >> >> > >> >> -- > >> >> View this message in context: > >> > http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html > >> >> Sent from the CDI Development mailing list mailing list archive at > >> Nabble.com . > >> >> _______________________________________________ > >> >> cdi-dev mailing list > >> >> cdi-dev at 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 at 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 at 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. > >> > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/ced89eaa/attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Sat, 19 Mar 2016 20:35:29 +0000 > From: Stephan Knitelius > Subject: Re: [cdi-dev] @ThreadScoped? > To: Mark Struberg , Reza Rahman > > Cc: cdi-dev > Message-ID: > < > CAGMB8Y0_19L6-cZZS7AEVh+ye0bx6+S9tqNV35ixaWD3eT5uoA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I would certainly agree with the assertion that in general it's not > advisable to execute a request with multiple threads and that usually > single threaded execution is sufficient. > > However I don't think ignoring it is an option. Concurrent operations can > be launched even from CDI beans. Yet we don't properly support context > propagation nor a context spanning all threads launched from a request. > > I know that changing @requestScoped is probably out of the question, but at > least we should consider adding a new context spanning all threads and > defining a logical solution for context propagation that can be explained > to the end user. > > > > On Fr., 11. M?rz 2016 at 17:17, Mark Struberg wrote: > > > Yes, but certain things in EE are assumed to be handled on a single > > thread. And if you run on a servr then this is really not a blocker most > > times. If I get many paralllel requests hitting my box then I do not need > > async handling _that_ often. The whole overhead for setting up the new > > thread, etc often heavily exceeds the benefits. > > So I would not put too much energy into it? > > > > LieGrue, > > strub > > > > > Am 11.03.2016 um 15:44 schrieb Reza Rahman : > > > > > > This is essentially in keeping with the minimalist nature of the EE > > concurrency JSR. I believe most of it is left to vendors to do the right > > thing for users. May be a good idea is this language can be tightened up. > > > > > >> On Mar 11, 2016, at 6:01 AM, Mark Struberg wrote: > > >> E > > >> From the servlet spec: > > >> > > >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web > > Application Environment? on page 15-174 and Section 15.3.1, ?Propagation > of > > Security Identity in EJBTM Calls? on page 15-176 are available only to > > threads executing the initial request or when the request is dispatched > to > > the container via the AsyncContext.dispatch method. Java Enterprise > Edition > > features may be available to other threads operating directly on the > > response object via the AsyncContext.start(Runnable) method.? > > >> > > >> check ?available only to threads executing the initial request? > > >> > > >> Also if you look at the servlet AsyncContext then all the wording is > > written as MAY and not as MUST. > > >> > > >> LieGrue, > > >> strub > > >> > > >> > > >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau < > > rmannibucau at gmail.com>: > > >>> > > >>> Hi Mark, > > >>> > > >>> think 2.3.3.4 states the opposite. > > >>> > > >>> > > >>> Romain Manni-Bucau > > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > >>> > > >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg : > > >>> Back from JavaLand conference, so sorry for not kicking in earlier. > > >>> > > >>> I not quite get the argumentation chain. It?s that all triggered by > > async servlet requests? And isn?t the servlet spec also saying that all > the > > request param etc may max be assigned to a single thread AT A TIME! > > >>> > > >>> Means that it might not be on multiple threads in parallel, but the > > data is allowed to get moved from one thread to another (disapearing from > > the first one), right? > > >>> Would really need to dig into the wording of the async servlets spec > > again, maybe has this in the back of his head? > > >>> > > >>> LieGrue, > > >>> strub > > >>> > > >>> > > >>> > > >>> > > >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < > > rmannibucau at gmail.com>: > > >>>> > > >>>> Hi guys, > > >>>> > > >>>> following request scope thread and to center the discussion on the > > thread safety part: do we work on this? > > >>>> > > >>>> Background: @RequestScoped is often used as a ThreadLocal instance > > solution. A lot of SE or Batch implementations rely on it from what I saw > > as well as async implementations reusing existing business logic with > this > > thread safety constraint. > > >>>> > > >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI > > and implemenation and would avoid the headache we can have with > > @RequestScoped. Will also remove the quite dark side of the spec > regarding > > servlet request and request scope since now we would have a more natural > > solution for all of these situation so @RequestScoped goals wouldn't > > collide as much. > > >>>> > > >>>> Questions: > > >>>> - is it automatically started as request scoped is (JMS, @Async, > > ...)? Alternative could be some configuration in beans.xml (merged > accross > > the app): > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> JMS > > >>>> ASYNCHONOUS > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> - start/stop API (this is typically an API the user should be able > to > > control for its own threads) > > >>>> - CDI 2.*0*? > > >>>> > > >>>> wdyt? > > >>>> > > >>>> Romain Manni-Bucau > > >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > >>>> _______________________________________________ > > >>>> cdi-dev mailing list > > >>>> cdi-dev at 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 at 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 at 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 at 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. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/1e3adce7/attachment.html > > ------------------------------ > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 64, Issue 100 > **************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/50a5c54e/attachment-0001.html From stephan at knitelius.com Sat Mar 19 17:10:43 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Sat, 19 Mar 2016 21:10:43 +0000 Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: References: Message-ID: If it's possible, I am all for it. On Sa., 19. M?rz 2016 at 22:07, Werner Keil wrote: > Keeping the few annotations like @Inject as they are should be also in > CDI's interest, but as JSR 330 is final there is no EG. Unlike this EG and > mailing list with great participation, there has never been too much of an > EG even when 330 was active, it was more or less Bob and maybe a few > participants in the mailing lists. That activity stopped in 2011, see > https://groups.google.com/forum/?hl=de#!forum/atinject-observer, so the > EG pretty much died 5 years ago. > > It seems reasonable and natural to do changes or tweaks as part of CDI. > > Werner > > > On Sat, Mar 19, 2016 at 9:35 PM, wrote: > >> Send cdi-dev mailing list submissions to >> cdi-dev at 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 at lists.jboss.org >> >> You can reach the person managing the list at >> cdi-dev-owner at 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. Re: Merging JSR-330 into CDI (aalmiray) >> 2. Re: Merging JSR-330 into CDI (Stephan Knitelius) >> 3. Re: @ThreadScoped? (Stephan Knitelius) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sat, 19 Mar 2016 12:45:40 -0700 (MST) >> From: aalmiray >> Subject: Re: [cdi-dev] Merging JSR-330 into CDI >> To: cdi-dev at lists.jboss.org >> Message-ID: <1458416740491-5712817.post at n5.nabble.com> >> Content-Type: text/plain; charset=us-ascii > > >> >> Precisely my thoughts. Any changes in behavior / binary compatibility in >> JSR-330 must be discussed with the JSR-330 EG and stakeholders. >> >> This being said, what would be the real benefit (to both specs) of rolling >> JSR-330 as a subspec of CDI? >> >> Cheers, >> Andres >> >> >> >> -- >> View this message in context: >> http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810p5712817.html > > >> Sent from the CDI Development mailing list mailing list archive at >> Nabble.com. >> >> >> ------------------------------ >> >> Message: 2 >> Date: Sat, 19 Mar 2016 19:53:13 +0000 >> From: Stephan Knitelius >> Subject: Re: [cdi-dev] Merging JSR-330 into CDI >> To: Manfred Riem >> Cc: cdi-dev at lists.jboss.org >> Message-ID: >> < >> CAGMB8Y1pe60oOc35uA19MpmeEjUMLZGn39vPTofxS24_8gcnyg at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" > > >> >> Hi Manfred, >> >> sorry my replay was a bit out of context since, I was referring to Rezas >> last mail. >> >> As already discussed yesterday, this could proof difficult. Since there >> are >> other implementations based on JSR-330, most noticeably spring. >> >> What exactly are we looking to gain from integrating JSR-330? >> >> I agree it would be "cleaner", but maybe too much effort for too little >> gain. >> >> If we wanted greater control over those parts, maybe it would be better to >> move these parts into a separate module for backwards compatibility. >> Including new CDI owned annotations alongside the separated JSR-330, as >> and >> where sensible. >> >> Stephan >> >> >> On Sa., 19. M?rz 2016 at 20:40, Manfred Riem wrote: >> >> > Hi Stephan, >> > >> > I am suggesting that JSR-330 gets rolled into the CDI spec as a chapter >> as >> > it currently >> > stands. Anything beyond that is beyond the scope of the discussion/wish >> I >> > have as that >> > would then be decided by the combined EG. >> > >> > Thanks! >> > >> > King regards, >> > Manfred Riem >> > >> > >> > On Mar 19, 2016, at 2:33 PM, Stephan Knitelius >> > wrote: >> > >> > If I understand you correctly, you are suggesting to move the JSR-330 >> > annotations into a separate CDI module/profile, thereby semi-deprecating >> > these. >> > >> > This would essentially open up the possibility of replacing @Named, >> etc... >> > with CDI specific annotations. >> > >> > Certainly an interesting path to explore. >> > >> > Stephan >> > >> > >> > > On Sa., 19. M?rz 2016 at 19:27, Manfred Riem wrote: >> > >> >> I couldn't agree more ;) >> >> >> >> Thanks! >> >> >> >> Kind regards, >> >> Manfred Riem >> >> >> >> > On Mar 19, 2016, at 10:47 AM, Reza Rahman >> >> wrote: >> >> > >> >> > I definitely think it's an idea worth exploring. It will strengthen >> >> CDI's hand further. It will be great if some of the confusingly >> redundant >> >> APIs like @Singleton could be deprecated in the process. >> >> > >> >> > BTW, it is really great to see you active in the community! >> >> > >> >> >> On Mar 19, 2016, at 10:49 AM, Manfred Riem >> wrote: >> >> >> >> >> >> Hi all, >> >> >> >> >> >> I wrote a little blog entry about a CDI wish I have and in essence >> it >> >> comes >> >> >> down to merging JSR-330 into the CDI specification as a sub spec. I >> >> realize >> >> >> there is history there, but to me it looks like the best course of >> >> action. >> >> >> >> >> >> I had some twitter exchanges about this and some folks are for, some >> >> are >> >> >> against. >> >> >> >> >> >> Note I think this is worth exploring as an idea, not something that >> >> >> necessarily needs to be in the current JSR, but definitely something >> >> that I >> >> >> think is worth to do at some point (sooner rather than later in my >> >> book). >> >> >> >> >> >> What do you think? >> >> >> >> >> >> Thanks! >> >> >> >> >> >> Kind regards, >> >> >> Manfred Riem >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> View this message in context: >> >> >> http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html >> >> >> Sent from the CDI Development mailing list mailing list archive at >> > >> Nabble.com . > > >> >> >> _______________________________________________ >> >> >> cdi-dev mailing list >> >> >> cdi-dev at 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 at 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 at 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. >> >> >> > >> > >> > -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/ced89eaa/attachment-0001.html >> >> ------------------------------ >> >> Message: 3 >> Date: Sat, 19 Mar 2016 20:35:29 +0000 >> From: Stephan Knitelius >> Subject: Re: [cdi-dev] @ThreadScoped? >> To: Mark Struberg , Reza Rahman >> >> Cc: cdi-dev >> Message-ID: >> < >> CAGMB8Y0_19L6-cZZS7AEVh+ye0bx6+S9tqNV35ixaWD3eT5uoA at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> I would certainly agree with the assertion that in general it's not >> advisable to execute a request with multiple threads and that usually >> single threaded execution is sufficient. >> >> However I don't think ignoring it is an option. Concurrent operations can >> be launched even from CDI beans. Yet we don't properly support context >> propagation nor a context spanning all threads launched from a request. >> >> I know that changing @requestScoped is probably out of the question, but >> at >> least we should consider adding a new context spanning all threads and >> defining a logical solution for context propagation that can be explained >> to the end user. >> >> >> >> On Fr., 11. M?rz 2016 at 17:17, Mark Struberg wrote: >> >> > Yes, but certain things in EE are assumed to be handled on a single >> > thread. And if you run on a servr then this is really not a blocker most >> > times. If I get many paralllel requests hitting my box then I do not >> need >> > async handling _that_ often. The whole overhead for setting up the new >> > thread, etc often heavily exceeds the benefits. >> > So I would not put too much energy into it? >> > >> > LieGrue, >> > strub >> > >> > > Am 11.03.2016 um 15:44 schrieb Reza Rahman : >> > > >> > > This is essentially in keeping with the minimalist nature of the EE >> > concurrency JSR. I believe most of it is left to vendors to do the right >> > thing for users. May be a good idea is this language can be tightened >> up. >> > > >> > >> On Mar 11, 2016, at 6:01 AM, Mark Struberg >> wrote: >> > >> E >> > >> From the servlet spec: >> > >> >> > >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web >> > Application Environment? on page 15-174 and Section 15.3.1, >> ?Propagation of >> > Security Identity in EJBTM Calls? on page 15-176 are available only to >> > threads executing the initial request or when the request is dispatched >> to >> > the container via the AsyncContext.dispatch method. Java Enterprise >> Edition >> > features may be available to other threads operating directly on the >> > response object via the AsyncContext.start(Runnable) method.? >> > >> >> > >> check ?available only to threads executing the initial request? >> > >> >> > >> Also if you look at the servlet AsyncContext then all the wording is >> > written as MAY and not as MUST. >> > >> >> > >> LieGrue, >> > >> strub >> > >> >> > >> >> > >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau < >> > rmannibucau at gmail.com>: >> > >>> >> > >>> Hi Mark, >> > >>> >> > >>> think 2.3.3.4 states the opposite. >> > >>> >> > >>> >> > >>> Romain Manni-Bucau >> > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> > >>> >> > >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg : >> > >>> Back from JavaLand conference, so sorry for not kicking in earlier. >> > >>> >> > >>> I not quite get the argumentation chain. It?s that all triggered by >> > async servlet requests? And isn?t the servlet spec also saying that all >> the >> > request param etc may max be assigned to a single thread AT A TIME! >> > >>> >> > >>> Means that it might not be on multiple threads in parallel, but the >> > data is allowed to get moved from one thread to another (disapearing >> from >> > the first one), right? >> > >>> Would really need to dig into the wording of the async servlets spec >> > again, maybe has this in the back of his head? >> > >>> >> > >>> LieGrue, >> > >>> strub >> > >>> >> > >>> >> > >>> >> > >>> >> > >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < >> > rmannibucau at gmail.com>: >> > >>>> >> > >>>> Hi guys, >> > >>>> >> > >>>> following request scope thread and to center the discussion on the >> > thread safety part: do we work on this? >> > >>>> >> > >>>> Background: @RequestScoped is often used as a ThreadLocal instance >> > solution. A lot of SE or Batch implementations rely on it from what I >> saw >> > as well as async implementations reusing existing business logic with >> this >> > thread safety constraint. >> > >>>> >> > >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI >> > and implemenation and would avoid the headache we can have with >> > @RequestScoped. Will also remove the quite dark side of the spec >> regarding >> > servlet request and request scope since now we would have a more natural >> > solution for all of these situation so @RequestScoped goals wouldn't >> > collide as much. >> > >>>> >> > >>>> Questions: >> > >>>> - is it automatically started as request scoped is (JMS, @Async, >> > ...)? Alternative could be some configuration in beans.xml (merged >> accross >> > the app): >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> JMS >> > >>>> ASYNCHONOUS >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> - start/stop API (this is typically an API the user should be able >> to >> > control for its own threads) >> > >>>> - CDI 2.*0*? >> > >>>> >> > >>>> wdyt? >> > >>>> >> > >>>> Romain Manni-Bucau >> > >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > >> > >>>> _______________________________________________ >> > >>>> cdi-dev mailing list >> > >>>> cdi-dev at 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 at 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 at 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 at 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. >> > -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/1e3adce7/attachment.html >> >> ------------------------------ > > >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 64, Issue 100 >> **************************************** >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/9ba9cc30/attachment-0001.html From arjan.tijms at gmail.com Sat Mar 19 17:37:35 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Sat, 19 Mar 2016 22:37:35 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: <23FBC9B6-0B33-4B11-A5A3-AAF0F805528B@yahoo.de> Message-ID: Hi, On Sat, Mar 19, 2016 at 10:02 PM, Stephan Knitelius wrote: > Well as discussed in another mail, the concurrency spec is a bit ambiguous > about context propagation, it's not explicitly forbidden. > > Would a new context also belong into the concurrency spec? I think so. Such context is intended for concurrency (threading), and there's a strong precedent for that the spec that owns a concept defines the context. E.g. JTA defines the @Transactional context, JSF the @FlowScoped one, MVC @RedirectScoped, etc. Kind regards, Arjan Tijms > > On Sa., 19. M?rz 2016 at 21:57, arjan tijms wrote: > >> Hi, >> >> On Saturday, March 19, 2016, Stephan Knitelius >> wrote: >> >>> I would certainly agree with the assertion that in general it's not >>> advisable to execute a request with multiple threads and that usually >>> single threaded execution is sufficient. >>> >>> However I don't think ignoring it is an option. Concurrent operations >>> can be launched even from CDI beans. Yet we don't properly support context >>> propagation nor a context spanning all threads launched from a request. >> >> >> That really sounds like a very useful proposal. Kinda like a session >> scope, but for a select group of threads. >> >> Like so many other things, logically you'd say such thing should be >> placed in the concurrency spec. Feels weird to put things in another less >> logical place just because there are no plans do a concurrency spec update. >> >> Kind regards, >> Arjan Tijms >> >> >> >>> >>> I know that changing @requestScoped is probably out of the question, but >>> at least we should consider adding a new context spanning all threads and >>> defining a logical solution for context propagation that can be explained >>> to the end user. >>> >>> >>> >>> On Fr., 11. M?rz 2016 at 17:17, Mark Struberg wrote: >>> >>>> Yes, but certain things in EE are assumed to be handled on a single >>>> thread. And if you run on a servr then this is really not a blocker most >>>> times. If I get many paralllel requests hitting my box then I do not need >>>> async handling _that_ often. The whole overhead for setting up the new >>>> thread, etc often heavily exceeds the benefits. >>>> So I would not put too much energy into it? >>>> >>>> LieGrue, >>>> strub >>>> >>>> > Am 11.03.2016 um 15:44 schrieb Reza Rahman : >>>> > >>>> > This is essentially in keeping with the minimalist nature of the EE >>>> concurrency JSR. I believe most of it is left to vendors to do the right >>>> thing for users. May be a good idea is this language can be tightened up. >>>> > >>>> >> On Mar 11, 2016, at 6:01 AM, Mark Struberg >>>> wrote: >>>> >> E >>>> >> From the servlet spec: >>>> >> >>>> >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web >>>> Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of >>>> Security Identity in EJBTM Calls? on page 15-176 are available only to >>>> threads executing the initial request or when the request is dispatched to >>>> the container via the AsyncContext.dispatch method. Java Enterprise Edition >>>> features may be available to other threads operating directly on the >>>> response object via the AsyncContext.start(Runnable) method.? >>>> >> >>>> >> check ?available only to threads executing the initial request? >>>> >> >>>> >> Also if you look at the servlet AsyncContext then all the wording is >>>> written as MAY and not as MUST. >>>> >> >>>> >> LieGrue, >>>> >> strub >>>> >> >>>> >> >>>> >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau < >>>> rmannibucau at gmail.com>: >>>> >>> >>>> >>> Hi Mark, >>>> >>> >>>> >>> think 2.3.3.4 states the opposite. >>>> >>> >>>> >>> >>>> >>> Romain Manni-Bucau >>>> >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>> >>>> >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg : >>>> >>> Back from JavaLand conference, so sorry for not kicking in earlier. >>>> >>> >>>> >>> I not quite get the argumentation chain. It?s that all triggered by >>>> async servlet requests? And isn?t the servlet spec also saying that all the >>>> request param etc may max be assigned to a single thread AT A TIME! >>>> >>> >>>> >>> Means that it might not be on multiple threads in parallel, but the >>>> data is allowed to get moved from one thread to another (disapearing from >>>> the first one), right? >>>> >>> Would really need to dig into the wording of the async servlets >>>> spec again, maybe has this in the back of his head? >>>> >>> >>>> >>> LieGrue, >>>> >>> strub >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < >>>> rmannibucau at gmail.com>: >>>> >>>> >>>> >>>> Hi guys, >>>> >>>> >>>> >>>> following request scope thread and to center the discussion on the >>>> thread safety part: do we work on this? >>>> >>>> >>>> >>>> Background: @RequestScoped is often used as a ThreadLocal instance >>>> solution. A lot of SE or Batch implementations rely on it from what I saw >>>> as well as async implementations reusing existing business logic with this >>>> thread safety constraint. >>>> >>>> >>>> >>>> Proposal: providing a @ThreadScoped implementation is cheap for >>>> CDI and implemenation and would avoid the headache we can have with >>>> @RequestScoped. Will also remove the quite dark side of the spec regarding >>>> servlet request and request scope since now we would have a more natural >>>> solution for all of these situation so @RequestScoped goals wouldn't >>>> collide as much. >>>> >>>> >>>> >>>> Questions: >>>> >>>> - is it automatically started as request scoped is (JMS, @Async, >>>> ...)? Alternative could be some configuration in beans.xml (merged accross >>>> the app): >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> JMS >>>> >>>> ASYNCHONOUS >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> - start/stop API (this is typically an API the user should be able >>>> to control for its own threads) >>>> >>>> - CDI 2.*0*? >>>> >>>> >>>> >>>> wdyt? >>>> >>>> >>>> >>>> Romain Manni-Bucau >>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>> _______________________________________________ >>>> >>>> cdi-dev mailing list >>>> >>>> cdi-dev at 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 at 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 at 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 at 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. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/6e1d411f/attachment.html From struberg at yahoo.de Sun Mar 20 03:34:48 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 20 Mar 2016 07:34:48 +0000 (UTC) Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: References: Message-ID: <949312054.271440.1458459289057.JavaMail.yahoo@mail.yahoo.com> What are the benefits? I mean serious, what does CDI gain? I can at least tell you what it hurts: TL/DR: Instead of claiming HOW cool it would be please show WHAT you like to change. I like to see CODE to show possible benefits. Before that I don't waste any more energy, and you should neither. long version: 1.) A lot specs are currently worded to only need JSR-330 for users. That way they run fine with CDI, Spring, etc. E.g. JBatch, Bean-Validation, etc. What is wrong with that? 2.) What changes do you need in atinject? We had a few ideas and sent them to the JSR-330 EG a year ago. We had good discussions but none of our wishes was worked out because WE failed to make final suggestions! The atinject EG (Bob, J?rgen) has been responsive. At least MUCH more responsive than other EG leaders these days... So I fail to see why the atinject EG is 'inactive since 5 years'. That's just wrong information. 3.) We cannot simply take the javax.inject package and maintain it in CDI. It is forbidden to split a java package into multiple specs. 4.) We also cannot just amend the annotations and take them 'over'. That would require the EC to officially move the maintenance of atinject to the CDI EG. Or even requires a handover from the atinject EG. I'm not sure about that 5.) again: WHAT DO WE GAIN? I always hear claims that it would be oh so great. But then again: Show me an example what we would gain from it! Stop trashtalking but show CODE instead! 6.) Our CDI-2.0 roadmap is full of stuff we still need to deliver. The EG is busy as hell to get this done. You might add this to a CDI-3.0 wishlist, but that's it for now imo. 7.) The JSR-330 spec had an important political role back then. I know most people don't know that, but it's still great to have this little peace which managed to make peace. Not peace between Spring and EE as many people believe, back then it was more that it brought mainly peace between CDI and most of the rest of JavaEE EGs! Remember that we haven't been allowed to target Java SE in CDI-1.0? Remember that we were force to have the 'for Java Enterprise' in the spec name? Remember that we had big battles with EJB? No, then just take it as granted and let it rest... LieGrue, strub From struberg at yahoo.de Sun Mar 20 04:14:15 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 20 Mar 2016 08:14:15 +0000 (UTC) Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: <949312054.271440.1458459289057.JavaMail.yahoo@mail.yahoo.com> References: <949312054.271440.1458459289057.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1132969083.1409195.1458461655906.JavaMail.yahoo@mail.yahoo.com> I'll give you an example: Currently many specs refer to atinject but also to CDI, because they need to use @Nonbinding (e.g. in Qualifiers). Thus Antoine and I asked the atinject EG whether they might introduce a @Nonbinding annotation. During that I learned that annotations not available on the classpath will _not_ blow up but simply don't appear at Runtime in Class#getAnnotations() etc. Means if you don't have the cdi-api.jar on your classpath the @Nonbinding annotation just doesn't show up at Runtime. Since Spring and Guice seems to not need this feature it's all fine from a CDI pov. Imagine what it would have meant to us if we would have got a second @Nonbinding in the javax.inject packgae: we would have to duplicate all the code which currently handling @Nonbinding. And that was actually the most important requirement the CDI EG came up for atinject in the last 7 years. Thus before we continue any discussions and further rouse people I like to see clear ideas WHAT you like to get changed in atinject. LieGrue, strub > On Sunday, 20 March 2016, 8:35, Mark Struberg wrote: > > What are the benefits? > > > > I mean serious, what does CDI gain? > > > I can at least tell you what it hurts: > > TL/DR: Instead of claiming HOW cool it would be please show WHAT you like to > change. I like to see CODE to show possible benefits. Before that I don't > waste any more energy, and you should neither. > > > > long version: > > > 1.) A lot specs are currently worded to only need JSR-330 for users. That way > they run fine with CDI, Spring, etc. E.g. JBatch, Bean-Validation, etc. What is > wrong with that? > > 2.) What changes do you need in atinject? We had a few ideas and sent them to > the JSR-330 EG a year ago. We had good discussions but none of our wishes was > worked out because WE failed to make final suggestions! > The atinject EG (Bob, J?rgen) has been responsive. At least MUCH more responsive > than other EG leaders these days... So I fail to see why the atinject EG is > 'inactive since 5 years'. That's just wrong information. > > 3.) We cannot simply take the javax.inject package and maintain it in CDI. It is > forbidden to split a java package into multiple specs. > > 4.) We also cannot just amend the annotations and take them 'over'. That > would require the EC to officially move the maintenance of atinject to the CDI > EG. Or even requires a handover from the atinject EG. I'm not sure about > that > > 5.) again: WHAT DO WE GAIN? I always hear claims that it would be oh so great. > But then again: Show me an example what we would gain from it! Stop trashtalking > but show CODE instead! > > 6.) Our CDI-2.0 roadmap is full of stuff we still need to deliver. The EG is > busy as hell to get this done. You might add this to a CDI-3.0 wishlist, but > that's it for now imo. > > > > 7.) The JSR-330 spec had an important political role back then. I know most > people don't know that, but it's still great to have this little peace > which managed to make peace. Not peace between Spring and EE as many people > believe, back then it was more that it brought mainly peace between CDI and most > of the rest of JavaEE EGs! Remember that we haven't been allowed to target > Java SE in CDI-1.0? Remember that we were force to have the 'for Java > Enterprise' in the spec name? Remember that we had big battles with EJB? No, > then just take it as granted and let it rest... > > > > LieGrue, > strub > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > From arjan.tijms at gmail.com Sun Mar 20 06:12:26 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Sun, 20 Mar 2016 11:12:26 +0100 Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: <949312054.271440.1458459289057.JavaMail.yahoo@mail.yahoo.com> References: <949312054.271440.1458459289057.JavaMail.yahoo@mail.yahoo.com> Message-ID: On Sun, Mar 20, 2016 at 8:34 AM, Mark Struberg wrote: > 3.) We cannot simply take the javax.inject package and maintain it in CDI. > It is forbidden to split a java package into multiple specs. > Do you mean it's forbidden for a spec to own multiple packages, e.g. CDI owning both javax.enterprise and javax.inject, or a single package being owned by multiple specs, e.g. javax.inject being owned by both AtInject 1.0 and CDI 2/3.x? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160320/6a7317e8/attachment.html From struberg at yahoo.de Sun Mar 20 06:58:24 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 20 Mar 2016 10:58:24 +0000 (UTC) Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: References: Message-ID: <1882746963.1122772.1458471505137.JavaMail.yahoo@mail.yahoo.com> It's fine to have one spec own multiple packages. But one package shall not get maintained by multiple specs. Think about how sealed jars or OSGi should handle this -> technically broken and also not allowed by the JCP rules. Thus before we seriously think about that we need to know what features we like to get from JSR-330. I mean I'm really happy to have all this enthusiasm, but in the end it needs to turn into real progress. There are sooo many pull requests waiting to get reviewed first! * CDI-SE needs a total rework for example * the Builders need a review etc LieGrue, strub On Sunday, 20 March 2016, 11:12, arjan tijms wrote: > > >On Sun, Mar 20, 2016 at 8:34 AM, Mark Struberg wrote: > >3.) We cannot simply take the javax.inject package and maintain it in CDI. It is forbidden to split a java package into multiple specs. >> > > >Do you mean it's forbidden for a spec to own multiple packages, e.g. CDI owning both javax.enterprise and javax.inject, or a single package being owned by multiple specs, e.g. javax.inject being owned by both AtInject 1.0 and CDI 2/3.x? > > From arjan.tijms at gmail.com Sun Mar 20 09:47:24 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Sun, 20 Mar 2016 14:47:24 +0100 Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: <1882746963.1122772.1458471505137.JavaMail.yahoo@mail.yahoo.com> References: <1882746963.1122772.1458471505137.JavaMail.yahoo@mail.yahoo.com> Message-ID: On Sun, Mar 20, 2016 at 11:58 AM, Mark Struberg wrote: > It's fine to have one spec own multiple packages. But one package shall > not get maintained by multiple specs. > > Think about how sealed jars or OSGi should handle this -> technically > broken and also not allowed by the JCP rules. > Okay, and then it just concerns the package itself, right? Not any parent packages. As javax.security as parent package is shared by both JASPIC and JACC, while the parent itself is proposed for JSR 375. Kind regards, Arjan Tijms > > > Thus before we seriously think about that we need to know what features we > like to get from JSR-330. > > I mean I'm really happy to have all this enthusiasm, but in the end it > needs to turn into real progress. > > > There are sooo many pull requests waiting to get reviewed first! > > * CDI-SE needs a total rework for example > * the Builders need a review > > etc > > > LieGrue, > strub > > > On Sunday, 20 March 2016, 11:12, arjan tijms > wrote: > > > > > >On Sun, Mar 20, 2016 at 8:34 AM, Mark Struberg wrote: > > > >3.) We cannot simply take the javax.inject package and maintain it in > CDI. It is forbidden to split a java package into multiple specs. > >> > > > > > >Do you mean it's forbidden for a spec to own multiple packages, e.g. CDI > owning both javax.enterprise and javax.inject, or a single package being > owned by multiple specs, e.g. javax.inject being owned by both AtInject 1.0 > and CDI 2/3.x? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160320/b7343440/attachment.html From mnriem at gmail.com Sun Mar 20 13:36:04 2016 From: mnriem at gmail.com (Manfred Riem) Date: Sun, 20 Mar 2016 12:36:04 -0500 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: <23FBC9B6-0B33-4B11-A5A3-AAF0F805528B@yahoo.de> Message-ID: <45FD6B6F-BFBD-4AAF-98FA-D626EF4F7819@gmail.com> Why is changing @RequestScoped out of the question? From my perspective when an AsyncContext is started the request is still there. It is just being served by a different thread. Certainly there is a need to work with the Servlet EG to figure out how to transfer ?ownership? to the AsyncContext. Anyway my 2 cents Thanks! Kind regards, Manfred Riem > On Mar 19, 2016, at 3:35 PM, Stephan Knitelius wrote: > > I would certainly agree with the assertion that in general it's not advisable to execute a request with multiple threads and that usually single threaded execution is sufficient. > > However I don't think ignoring it is an option. Concurrent operations can be launched even from CDI beans. Yet we don't properly support context propagation nor a context spanning all threads launched from a request. > > I know that changing @requestScoped is probably out of the question, but at least we should consider adding a new context spanning all threads and defining a logical solution for context propagation that can be explained to the end user. > > > > On Fr., 11. M?rz 2016 at 17:17, Mark Struberg > wrote: > Yes, but certain things in EE are assumed to be handled on a single thread. And if you run on a servr then this is really not a blocker most times. If I get many paralllel requests hitting my box then I do not need async handling _that_ often. The whole overhead for setting up the new thread, etc often heavily exceeds the benefits. > So I would not put too much energy into it? > > LieGrue, > strub > > > Am 11.03.2016 um 15:44 schrieb Reza Rahman >: > > > > This is essentially in keeping with the minimalist nature of the EE concurrency JSR. I believe most of it is left to vendors to do the right thing for users. May be a good idea is this language can be tightened up. > > > >> On Mar 11, 2016, at 6:01 AM, Mark Struberg > wrote: > >> E > >> From the servlet spec: > >> > >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of Security Identity in EJBTM Calls? on page 15-176 are available only to threads executing the initial request or when the request is dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition features may be available to other threads operating directly on the response object via the AsyncContext.start(Runnable) method.? > >> > >> check ?available only to threads executing the initial request? > >> > >> Also if you look at the servlet AsyncContext then all the wording is written as MAY and not as MUST. > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau >: > >>> > >>> Hi Mark, > >>> > >>> think 2.3.3.4 states the opposite. > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>> > >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg >: > >>> Back from JavaLand conference, so sorry for not kicking in earlier. > >>> > >>> I not quite get the argumentation chain. It?s that all triggered by async servlet requests? And isn?t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! > >>> > >>> Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? > >>> Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>> > >>> > >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau >: > >>>> > >>>> Hi guys, > >>>> > >>>> following request scope thread and to center the discussion on the thread safety part: do we work on this? > >>>> > >>>> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. > >>>> > >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. > >>>> > >>>> Questions: > >>>> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): > >>>> > >>>> > >>>> > >>>> > >>>> JMS > >>>> ASYNCHONOUS > >>>> > >>>> > >>>> > >>>> > >>>> - start/stop API (this is typically an API the user should be able to control for its own threads) > >>>> - CDI 2.*0*? > >>>> > >>>> wdyt? > >>>> > >>>> Romain Manni-Bucau > >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160320/511f7205/attachment-0001.html From reza_rahman at lycos.com Sun Mar 20 14:23:02 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 20 Mar 2016 14:23:02 -0400 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: <45FD6B6F-BFBD-4AAF-98FA-D626EF4F7819@gmail.com> References: <23FBC9B6-0B33-4B11-A5A3-AAF0F805528B@yahoo.de> <45FD6B6F-BFBD-4AAF-98FA-D626EF4F7819@gmail.com> Message-ID: As discussed elsewhere in this EG, even in the most pessimistic reading of the current spec, all that would be needed is a flag on the existing annotation. It's not out of the question at all. > On Mar 20, 2016, at 1:36 PM, Manfred Riem wrote: > > Why is changing @RequestScoped out of the question? > > From my perspective when an AsyncContext is started the request is still there. > > It is just being served by a different thread. > > Certainly there is a need to work with the Servlet EG to figure out how to transfer ?ownership? to the AsyncContext. > > Anyway my 2 cents > > Thanks! > > Kind regards, > Manfred Riem > >> On Mar 19, 2016, at 3:35 PM, Stephan Knitelius wrote: >> >> I would certainly agree with the assertion that in general it's not advisable to execute a request with multiple threads and that usually single threaded execution is sufficient. >> >> However I don't think ignoring it is an option. Concurrent operations can be launched even from CDI beans. Yet we don't properly support context propagation nor a context spanning all threads launched from a request. >> >> I know that changing @requestScoped is probably out of the question, but at least we should consider adding a new context spanning all threads and defining a logical solution for context propagation that can be explained to the end user. >> >> >> >>> On Fr., 11. M?rz 2016 at 17:17, Mark Struberg wrote: >>> Yes, but certain things in EE are assumed to be handled on a single thread. And if you run on a servr then this is really not a blocker most times. If I get many paralllel requests hitting my box then I do not need async handling _that_ often. The whole overhead for setting up the new thread, etc often heavily exceeds the benefits. >>> So I would not put too much energy into it? >>> >>> LieGrue, >>> strub >>> >>> > Am 11.03.2016 um 15:44 schrieb Reza Rahman : >>> > >>> > This is essentially in keeping with the minimalist nature of the EE concurrency JSR. I believe most of it is left to vendors to do the right thing for users. May be a good idea is this language can be tightened up. >>> > >>> >> On Mar 11, 2016, at 6:01 AM, Mark Struberg wrote: >>> >> E >>> >> From the servlet spec: >>> >> >>> >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of Security Identity in EJBTM Calls? on page 15-176 are available only to threads executing the initial request or when the request is dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition features may be available to other threads operating directly on the response object via the AsyncContext.start(Runnable) method.? >>> >> >>> >> check ?available only to threads executing the initial request? >>> >> >>> >> Also if you look at the servlet AsyncContext then all the wording is written as MAY and not as MUST. >>> >> >>> >> LieGrue, >>> >> strub >>> >> >>> >> >>> >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau : >>> >>> >>> >>> Hi Mark, >>> >>> >>> >>> think 2.3.3.4 states the opposite. >>> >>> >>> >>> >>> >>> Romain Manni-Bucau >>> >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> >>> >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg : >>> >>> Back from JavaLand conference, so sorry for not kicking in earlier. >>> >>> >>> >>> I not quite get the argumentation chain. It?s that all triggered by async servlet requests? And isn?t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! >>> >>> >>> >>> Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? >>> >>> Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? >>> >>> >>> >>> LieGrue, >>> >>> strub >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau : >>> >>>> >>> >>>> Hi guys, >>> >>>> >>> >>>> following request scope thread and to center the discussion on the thread safety part: do we work on this? >>> >>>> >>> >>>> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. >>> >>>> >>> >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. >>> >>>> >>> >>>> Questions: >>> >>>> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> JMS >>> >>>> ASYNCHONOUS >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> - start/stop API (this is typically an API the user should be able to control for its own threads) >>> >>>> - CDI 2.*0*? >>> >>>> >>> >>>> wdyt? >>> >>>> >>> >>>> Romain Manni-Bucau >>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>>> _______________________________________________ >>> >>>> cdi-dev mailing list >>> >>>> cdi-dev at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160320/2cdebe8d/attachment.html From struberg at yahoo.de Sun Mar 20 15:38:26 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 20 Mar 2016 19:38:26 +0000 (UTC) Subject: [cdi-dev] Merging JSR-330 into CDI In-Reply-To: References: Message-ID: <1275246498.1543640.1458502707241.JavaMail.yahoo@mail.yahoo.com> >Okay, and then it just concerns the package itself, right? Not any parent packages. As javax.security as parent package is shared by both JASPIC and JACC, while the parent itself is proposed for JSR 375. Yes, at least as far as I understood. LieGrue, strub On Sunday, 20 March 2016, 20:34, arjan tijms wrote: > > >On Sun, Mar 20, 2016 at 11:58 AM, Mark Struberg wrote: > >It's fine to have one spec own multiple packages. But one package shall not get maintained by multiple specs. >> >>Think about how sealed jars or OSGi should handle this -> technically broken and also not allowed by the JCP rules. >> > > >Okay, and then it just concerns the package itself, right? Not any parent packages. As javax.security as parent package is shared by both JASPIC and JACC, while the parent itself is proposed for JSR 375. > > >Kind regards, >Arjan Tijms > > > > >> >>Thus before we seriously think about that we need to know what features we like to get from JSR-330. >> >>I mean I'm really happy to have all this enthusiasm, but in the end it needs to turn into real progress. >> >> >>There are sooo many pull requests waiting to get reviewed first! >> >>* CDI-SE needs a total rework for example >>* the Builders need a review >> >>etc >> >> >>LieGrue, >>strub >> >> >> >>On Sunday, 20 March 2016, 11:12, arjan tijms wrote: >>> >>> >>>On Sun, Mar 20, 2016 at 8:34 AM, Mark Struberg wrote: >>> >>>3.) We cannot simply take the javax.inject package and maintain it in CDI. It is forbidden to split a java package into multiple specs. >>>> >>> >>> >>>Do you mean it's forbidden for a spec to own multiple packages, e.g. CDI owning both javax.enterprise and javax.inject, or a single package being owned by multiple specs, e.g. javax.inject being owned by both AtInject 1.0 and CDI 2/3.x? >>> >>> >> > > > > From struberg at yahoo.de Sun Mar 20 15:39:55 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 20 Mar 2016 19:39:55 +0000 (UTC) Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: Message-ID: <286126104.1590047.1458502796161.JavaMail.yahoo@mail.yahoo.com> A scope annotation cannot have a flag. LieGrue, strub On Sunday, 20 March 2016, 20:25, Reza Rahman wrote: > > >As discussed elsewhere in this EG, even in the most pessimistic reading of the current spec, all that would be needed is a flag on the existing annotation. It's not out of the question at all. > >On Mar 20, 2016, at 1:36 PM, Manfred Riem wrote: > > >Why is changing @RequestScoped out of the question? >> >> >>From my perspective when an AsyncContext is started the request is still there. >> >> >>It is just being served by a different thread. >> >> >>Certainly there is a need to work with the Servlet EG to figure out how to transfer ?ownership? to the AsyncContext. >> >> >>Anyway my 2 cents >> >> >>Thanks! >> >> >>Kind regards, >>Manfred Riem >> >> >>On Mar 19, 2016, at 3:35 PM, Stephan Knitelius wrote: >>> >>>I would certainly agree with the assertion that in general it's not advisable to execute a request with multiple threads and that usually single threaded execution is sufficient. >>> >>>However I don't think ignoring it is an option. Concurrent operations can be launched even from CDI beans. Yet we don't properly support context propagation nor a context spanning all threads launched from a request. >>> >>>I know that changing @requestScoped is probably out of the question, but at least we should consider adding a new context spanning all threads and defining a logical solution for context propagation that can be explained to the end user. >>> >>> >>> >>> >>>On Fr., 11. M?rz 2016 at 17:17, Mark Struberg wrote: >>> >>>Yes, but certain things in EE are assumed to be handled on a single thread. And if you run on a servr then this is really not a blocker most times. If I get many paralllel requests hitting my box then I do not need async handling _that_ often. The whole overhead for setting up the new thread, etc often heavily exceeds the benefits. >>>>So I would not put too much energy into it? >>>> >>>>LieGrue, >>>>strub >>>> >>>>> Am 11.03.2016 um 15:44 schrieb Reza Rahman : >>>>> >>>>> This is essentially in keeping with the minimalist nature of the EE concurrency JSR. I believe most of it is left to vendors to do the right thing for users. May be a good idea is this language can be tightened up. >>>>> >>>>>> On Mar 11, 2016, at 6:01 AM, Mark Struberg wrote: >>>>>> E >>>>>> From the servlet spec: >>>>>> >>>>>> ?Java Enterprise Edition features such as Section 15.2.2, ?Web Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of Security Identity in EJBTM Calls? on page 15-176 are available only to threads executing the initial request or when the request is dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition features may be available to other threads operating directly on the response object via the AsyncContext.start(Runnable) method.? >>>>>> >>>>>> check ?available only to threads executing the initial request? >>>>>> >>>>>> Also if you look at the servlet AsyncContext then all the wording is written as MAY and not as MUST. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau : >>>>>>> >>>>>>> Hi Mark, >>>>>>> >>>>>>> think 2.3.3.4 states the opposite. >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>> >>>>>>> 2016-03-10 19:43 GMT+01:00 Mark Struberg : >>>>>>> Back from JavaLand conference, so sorry for not kicking in earlier. >>>>>>> >>>>>>> I not quite get the argumentation chain. It?s that all triggered by async servlet requests? And isn?t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! >>>>>>> >>>>>>> Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? >>>>>>> Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau : >>>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> following request scope thread and to center the discussion on the thread safety part: do we work on this? >>>>>>>> >>>>>>>> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. >>>>>>>> >>>>>>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. >>>>>>>> >>>>>>>> Questions: >>>>>>>> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> JMS >>>>>>>> ASYNCHONOUS >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - start/stop API (this is typically an API the user should be able to control for its own threads) >>>>>>>> - CDI 2.*0*? >>>>>>>> >>>>>>>> wdyt? >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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. > > From rmannibucau at gmail.com Sun Mar 20 15:47:38 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 20 Mar 2016 20:47:38 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: <286126104.1590047.1458502796161.JavaMail.yahoo@mail.yahoo.com> References: <286126104.1590047.1458502796161.JavaMail.yahoo@mail.yahoo.com> Message-ID: Le 20 mars 2016 20:40, "Mark Struberg" a ?crit : > > A scope annotation cannot have a flag. > Why? Technically it can > LieGrue, > strub > > > > > On Sunday, 20 March 2016, 20:25, Reza Rahman wrote: > > > > > > > >As discussed elsewhere in this EG, even in the most pessimistic reading of the current spec, all that would be needed is a flag on the existing annotation. It's not out of the question at all. > > > >On Mar 20, 2016, at 1:36 PM, Manfred Riem wrote: > > > > > >Why is changing @RequestScoped out of the question? > >> > >> > >>From my perspective when an AsyncContext is started the request is still there. > >> > >> > >>It is just being served by a different thread. > >> > >> > >>Certainly there is a need to work with the Servlet EG to figure out how to transfer ?ownership? to the AsyncContext. > >> > >> > >>Anyway my 2 cents > >> > >> > >>Thanks! > >> > >> > >>Kind regards, > >>Manfred Riem > >> > >> > >>On Mar 19, 2016, at 3:35 PM, Stephan Knitelius wrote: > >>> > >>>I would certainly agree with the assertion that in general it's not advisable to execute a request with multiple threads and that usually single threaded execution is sufficient. > >>> > >>>However I don't think ignoring it is an option. Concurrent operations can be launched even from CDI beans. Yet we don't properly support context propagation nor a context spanning all threads launched from a request. > >>> > >>>I know that changing @requestScoped is probably out of the question, but at least we should consider adding a new context spanning all threads and defining a logical solution for context propagation that can be explained to the end user. > >>> > >>> > >>> > >>> > >>>On Fr., 11. M?rz 2016 at 17:17, Mark Struberg wrote: > >>> > >>>Yes, but certain things in EE are assumed to be handled on a single thread. And if you run on a servr then this is really not a blocker most times. If I get many paralllel requests hitting my box then I do not need async handling _that_ often. The whole overhead for setting up the new thread, etc often heavily exceeds the benefits. > >>>>So I would not put too much energy into it? > >>>> > >>>>LieGrue, > >>>>strub > >>>> > >>>>> Am 11.03.2016 um 15:44 schrieb Reza Rahman : > >>>>> > >>>>> This is essentially in keeping with the minimalist nature of the EE concurrency JSR. I believe most of it is left to vendors to do the right thing for users. May be a good idea is this language can be tightened up. > >>>>> > >>>>>> On Mar 11, 2016, at 6:01 AM, Mark Struberg wrote: > >>>>>> E > >>>>>> From the servlet spec: > >>>>>> > >>>>>> ?Java Enterprise Edition features such as Section 15.2.2, ?Web Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of Security Identity in EJBTM Calls? on page 15-176 are available only to threads executing the initial request or when the request is dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition features may be available to other threads operating directly on the response object via the AsyncContext.start(Runnable) method.? > >>>>>> > >>>>>> check ?available only to threads executing the initial request? > >>>>>> > >>>>>> Also if you look at the servlet AsyncContext then all the wording is written as MAY and not as MUST. > >>>>>> > >>>>>> LieGrue, > >>>>>> strub > >>>>>> > >>>>>> > >>>>>>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau < rmannibucau at gmail.com>: > >>>>>>> > >>>>>>> Hi Mark, > >>>>>>> > >>>>>>> think 2.3.3.4 states the opposite. > >>>>>>> > >>>>>>> > >>>>>>> Romain Manni-Bucau > >>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>>>>>> > >>>>>>> 2016-03-10 19:43 GMT+01:00 Mark Struberg : > >>>>>>> Back from JavaLand conference, so sorry for not kicking in earlier. > >>>>>>> > >>>>>>> I not quite get the argumentation chain. It?s that all triggered by async servlet requests? And isn?t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! > >>>>>>> > >>>>>>> Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? > >>>>>>> Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? > >>>>>>> > >>>>>>> LieGrue, > >>>>>>> strub > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < rmannibucau at gmail.com>: > >>>>>>>> > >>>>>>>> Hi guys, > >>>>>>>> > >>>>>>>> following request scope thread and to center the discussion on the thread safety part: do we work on this? > >>>>>>>> > >>>>>>>> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. > >>>>>>>> > >>>>>>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. > >>>>>>>> > >>>>>>>> Questions: > >>>>>>>> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> JMS > >>>>>>>> ASYNCHONOUS > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> - start/stop API (this is typically an API the user should be able to control for its own threads) > >>>>>>>> - CDI 2.*0*? > >>>>>>>> > >>>>>>>> wdyt? > >>>>>>>> > >>>>>>>> Romain Manni-Bucau > >>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>>>>>>> _______________________________________________ > >>>>>>>> cdi-dev mailing list > >>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160320/4c6fe50f/attachment-0001.html From struberg at yahoo.de Sun Mar 20 16:04:56 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 20 Mar 2016 20:04:56 +0000 (UTC) Subject: [cdi-dev] @ThreadScoped? References: <547833271.1600791.1458504297129.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <547833271.1600791.1458504297129.JavaMail.yahoo@mail.yahoo.com> See Bean#getScope() and BeanManager#getContext() Just uses Class and no Annotation instance. Lgm -------------------------------------------- On Sun, 20/3/16, Romain Manni-Bucau wrote: Subject: Re: [cdi-dev] @ThreadScoped? To: "Mark Struberg" Cc: cdi-dev at lists.jboss.org, "Reza Rahman" Date: Sunday, 20 March, 2016, 20:47 Le 20 mars 2016 20:40, "Mark Struberg" a ?crit : > > A scope annotation cannot have a flag. > Why? Technically it can > LieGrue, > strub > > > > > On Sunday, 20 March 2016, 20:25, Reza Rahman wrote: > > > > > > > >As discussed elsewhere in this EG, even in the most pessimistic reading of the current spec, all that would be needed is a flag on the existing annotation. It's not out of the question at all. > > > >On Mar 20, 2016, at 1:36 PM, Manfred Riem wrote: > > > > > >Why is changing @RequestScoped out of the question? > >> > >> > >>From my perspective when an AsyncContext is started the request is still there. > >> > >> > >>It is just being served by a different thread. > >> > >> > >>Certainly there is a need to work with the Servlet EG to figure out how to transfer ?ownership? to the AsyncContext. > >> > >> > >>Anyway my 2 cents > >> > >> > >>Thanks! > >> > >> > >>Kind regards, > >>Manfred Riem > >> > >> > >>On Mar 19, 2016, at 3:35 PM, Stephan Knitelius wrote: > >>> > >>>I would certainly agree with the assertion that in general it's not advisable to execute a request with multiple threads and that usually single threaded execution is sufficient. > >>> > >>>However I don't think ignoring it is an option. Concurrent operations can be launched even from CDI beans. Yet we don't properly support context propagation nor a context spanning all threads launched from a request. > >>> > >>>I know that changing @requestScoped is probably out of the question, but at least we should consider adding a new context spanning all threads and defining a logical solution for context propagation that can be explained to the end user. > >>> > >>> > >>> > >>> > >>>On Fr., 11. M?rz 2016 at 17:17, Mark Struberg wrote: > >>> > >>>Yes, but certain things in EE are assumed to be handled on a single thread. And if you run on a servr then this is really not a blocker most times. If I get many paralllel requests hitting my box then I do not need async handling _that_ often. The whole overhead for setting up the new thread, etc often heavily exceeds the benefits. > >>>>So I would not put too much energy into it? > >>>> > >>>>LieGrue, > >>>>strub > >>>> > >>>>> Am 11.03.2016 um 15:44 schrieb Reza Rahman : > >>>>> > >>>>> This is essentially in keeping with the minimalist nature of the EE concurrency JSR. I believe most of it is left to vendors to do the right thing for users. May be a good idea is this language can be tightened up. > >>>>> > >>>>>> On Mar 11, 2016, at 6:01 AM, Mark Struberg wrote: > >>>>>> E > >>>>>> From the servlet spec: > >>>>>> > >>>>>> ?Java Enterprise Edition features such as Section 15.2.2, ?Web Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of Security Identity in EJBTM Calls? on page 15-176 are available only to threads executing the initial request or when the request is dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition features may be available to other threads operating directly on the response object via the AsyncContext.start(Runnable) method.? > >>>>>> > >>>>>> check ?available only to threads executing the initial request? > >>>>>> > >>>>>> Also if you look at the servlet AsyncContext then all the wording is written as MAY and not as MUST. > >>>>>> > >>>>>> LieGrue, > >>>>>> strub > >>>>>> > >>>>>> > >>>>>>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau < rmannibucau at gmail.com>: > >>>>>>> > >>>>>>> Hi Mark, > >>>>>>> > >>>>>>> think 2.3.3.4 states the opposite. > >>>>>>> > >>>>>>> > >>>>>>> Romain Manni-Bucau > >>>>>>> @rmannibucau |? Blog | Github | LinkedIn | Tomitriber > >>>>>>> > >>>>>>> 2016-03-10 19:43 GMT+01:00 Mark Struberg : > >>>>>>> Back from JavaLand conference, so sorry for not kicking in earlier. > >>>>>>> > >>>>>>> I not quite get the argumentation chain. It?s that all triggered by async servlet requests? And isn?t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! > >>>>>>> > >>>>>>> Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? > >>>>>>> Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? > >>>>>>> > >>>>>>> LieGrue, > >>>>>>> strub > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < rmannibucau at gmail.com>: > >>>>>>>> > >>>>>>>> Hi guys, > >>>>>>>> > >>>>>>>> following request scope thread and to center the discussion on the thread safety part: do we work on this? > >>>>>>>> > >>>>>>>> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. > >>>>>>>> > >>>>>>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. > >>>>>>>> > >>>>>>>> Questions: > >>>>>>>> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>??? > >>>>>>>>? ???JMS > >>>>>>>>? ???ASYNCHONOUS > >>>>>>>>??? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> - start/stop API (this is typically an API the user should be able to control for its own threads) > >>>>>>>> - CDI 2.*0*? > >>>>>>>> > >>>>>>>> wdyt? > >>>>>>>> > >>>>>>>> Romain Manni-Bucau > >>>>>>>> @rmannibucau |? Blog | Github | LinkedIn | Tomitriber > >>>>>>>> _______________________________________________ > >>>>>>>> cdi-dev mailing list > >>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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. From mnriem at gmail.com Sun Mar 20 16:11:28 2016 From: mnriem at gmail.com (Manfred Riem) Date: Sun, 20 Mar 2016 15:11:28 -0500 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: <286126104.1590047.1458502796161.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1C7A99A6-63E8-4BC8-B689-49B0B784BE58@gmail.com> Hi, Or @AsyncScoped that extends the @RequestScoped so folks can use it to annotate a bean that DOES need to propagate to an AsyncContext. Thanks! Kind regards, Manfred Riem > On Mar 20, 2016, at 2:47 PM, Romain Manni-Bucau wrote: > > > Le 20 mars 2016 20:40, "Mark Struberg" > a ?crit : > > > > A scope annotation cannot have a flag. > > > > Why? Technically it can > > > LieGrue, > > strub > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160320/4bae5144/attachment.html From rmannibucau at gmail.com Sun Mar 20 16:12:41 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 20 Mar 2016 21:12:41 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: <547833271.1600791.1458504297129.JavaMail.yahoo@mail.yahoo.com> References: <547833271.1600791.1458504297129.JavaMail.yahoo.ref@mail.yahoo.com> <547833271.1600791.1458504297129.JavaMail.yahoo@mail.yahoo.com> Message-ID: Le 20 mars 2016 21:07, "Mark Struberg" a ?crit : > > See Bean#getScope() and BeanManager#getContext() > > Just uses Class and no Annotation instance. > That's ok I think. Since 1.2 you can get meta from any bean and find it if needee but i most of cases the context will see the bean and will not need it. Would also break the Annotated contravt if true. > Lgm > > > -------------------------------------------- > On Sun, 20/3/16, Romain Manni-Bucau wrote: > > Subject: Re: [cdi-dev] @ThreadScoped? > To: "Mark Struberg" > Cc: cdi-dev at lists.jboss.org, "Reza Rahman" > Date: Sunday, 20 March, 2016, 20:47 > > Le 20 mars 2016 20:40, > "Mark Struberg" > a ?crit : > > > > A scope > annotation cannot have a flag. > > > > Why? Technically it can > > > LieGrue, > > strub > > > > > > > > > > > On Sunday, 20 March 2016, 20:25, Reza Rahman > wrote: > > > > > > > > > > > > >As discussed > elsewhere in this EG, even in the most pessimistic > reading > of the current spec, all that would > be needed is a flag on the existing > annotation. It's not out of the question at > all. > > > > > >On > Mar 20, 2016, at 1:36 PM, Manfred Riem > wrote: > > > > > > > > > >Why is changing @RequestScoped > out of the question? > > >> > > >> > > >>From > my perspective when an AsyncContext is started the request > is > still there. > > > >> > > >> > > > >>It is just being served by a different thread. > > >> > > >> > > >>Certainly there is a need to work > with the Servlet EG to figure out how > to > transfer ?ownership? to the AsyncContext. > > >> > > >> > > >>Anyway my 2 cents > > >> > > >> > > >>Thanks! > > > >> > > >> > > > >>Kind regards, > > >>Manfred > Riem > > >> > > > >> > > >>On Mar 19, 2016, at > 3:35 PM, Stephan Knitelius > wrote: > > >>> > > >>>I would certainly agree with > the assertion that in general it's not > advisable to execute a request with multiple > threads and that usually > single threaded > execution is sufficient. > > > >>> > > >>>However I > don't think ignoring it is an option. Concurrent > operations > can be launched even from CDI > beans. Yet we don't properly support context > propagation nor a context spanning all threads > launched from a request. > > > >>> > > >>>I know that > changing @requestScoped is probably out of the question, > but at least we should consider adding a new > context spanning all threads > and defining a > logical solution for context propagation that can be > explained to the end user. > > > >>> > > >>> > > >>> > > > >>> > > >>>On Fr., 11. > M?rz 2016 at 17:17, Mark Struberg > wrote: > > >>> > > >>>Yes, but certain things in EE > are assumed to be handled on a single > thread. And if you run on a servr then this is > really not a blocker most > times. If I get > many paralllel requests hitting my box then I do not need > async handling _that_ often. The whole overhead > for setting up the new > thread, etc often > heavily exceeds the benefits. > > > >>>>So I would not put too much energy into > it? > > >>>> > > >>>>LieGrue, > > >>>>strub > > > >>>> > > >>>>> > Am 11.03.2016 um 15:44 schrieb Reza Rahman : > > >>>>> > > > >>>>> This is essentially in keeping with the > minimalist nature of the EE > concurrency JSR. > I believe most of it is left to vendors to do the right > thing for users. May be a good idea is this > language can be tightened up. > > > >>>>> > > > >>>>>> On Mar 11, 2016, at 6:01 AM, Mark > Struberg > wrote: > > > >>>>>> E > > > >>>>>> From the servlet spec: > > >>>>>> > > >>>>>> ?Java > Enterprise Edition features such as Section 15.2.2, > ?Web > Application Environment? on page > 15-174 and Section 15.3.1, ?Propagation of > Security Identity in EJBTM Calls? on page > 15-176 are available only to > threads > executing the initial request or when the request is > dispatched to > the container via the > AsyncContext.dispatch method. Java Enterprise Edition > features may be available to other threads > operating directly on the > response object > via the AsyncContext.start(Runnable) method.? > > >>>>>> > > >>>>>> check > ?available only to threads executing the initial > request? > > >>>>>> > > >>>>>> Also if you look > at the servlet AsyncContext then all the wording > is written as MAY and not as MUST. > > >>>>>> > > >>>>>> LieGrue, > > >>>>>> strub > > >>>>>> > > >>>>>> > > >>>>>>> Am 10.03.2016 > um 19:52 schrieb Romain Manni-Bucau < > rmannibucau at gmail.com>: > > >>>>>>> > > >>>>>>> Hi Mark, > > >>>>>>> > > >>>>>>> think 2.3.3.4 > states the opposite. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Romain Manni-Bucau > > >>>>>>> @rmannibucau > | Blog | Github | LinkedIn | Tomitriber > > >>>>>>> > > >>>>>>> 2016-03-10 > 19:43 GMT+01:00 Mark Struberg : > > >>>>>>> Back from > JavaLand conference, so sorry for not kicking in > earlier. > > > >>>>>>> > > > >>>>>>> I not quite get the > argumentation chain. It?s that all triggered > by async servlet requests? And isn?t the > servlet spec also saying that all > the > request param etc may max be assigned to a single thread AT > A TIME! > > >>>>>>> > > >>>>>>> Means that it > might not be on multiple threads in parallel, but > the data is allowed to get moved from one > thread to another (disapearing > from the > first one), right? > > > >>>>>>> Would really need to dig into > the wording of the async servlets > spec > again, maybe has this in the back of his head? > > >>>>>>> > > >>>>>>> LieGrue, > > >>>>>>> strub > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>> Am > 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < > rmannibucau at gmail.com>: > > >>>>>>>> > > >>>>>>>> Hi > guys, > > > >>>>>>>> > > > >>>>>>>> following request scope > thread and to center the discussion on > the > thread safety part: do we work on this? > > > >>>>>>>> > > > >>>>>>>> Background: @RequestScoped > is often used as a ThreadLocal > instance > solution. A lot of SE or Batch implementations rely on it > from > what I saw as well as async > implementations reusing existing business logic > with this thread safety constraint. > > >>>>>>>> > > >>>>>>>> Proposal: > providing a @ThreadScoped implementation is cheap for > CDI and implemenation and would avoid the > headache we can have with > @RequestScoped. > Will also remove the quite dark side of the spec > regarding > servlet request and request scope > since now we would have a more natural > solution for all of these situation so > @RequestScoped goals wouldn't > collide as > much. > > > >>>>>>>> > > > >>>>>>>> Questions: > > >>>>>>>> - is it > automatically started as request scoped is (JMS, @Async, > ...)? Alternative could be some configuration > in beans.xml (merged accross > the app): > > >>>>>>>> > > >>>>>>>> > > > > >>>>>>>> > > > >>>>>>>> > > >>>>>>>> > JMS > > >>>>>>>> > ASYNCHONOUS > > > >>>>>>>> > > >>>>>>>> > > > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> - > start/stop API (this is typically an API the user should > be > able to control for its own threads) > > >>>>>>>> - CDI > 2.*0*? > > > >>>>>>>> > > > >>>>>>>> wdyt? > > > >>>>>>>> > > > >>>>>>>> Romain Manni-Bucau > > >>>>>>>> > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > >>>>>>>> > _______________________________________________ > > >>>>>>>> cdi-dev > mailing list > > > >>>>>>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160320/560f320e/attachment-0001.html From struberg at yahoo.de Sun Mar 20 16:25:31 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 20 Mar 2016 20:25:31 +0000 (UTC) Subject: [cdi-dev] @ThreadScoped? References: <217911838.1577969.1458505531205.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <217911838.1577969.1458505531205.JavaMail.yahoo@mail.yahoo.com> I'd say we could move a request context from EXCLUSIVE threadA to EXCLUSIVE threadA. But we cannot make the same request scoped Bean accessible from multiple Threads at the same time. Lgm -------------------------------------------- On Sun, 20/3/16, Manfred Riem wrote: Subject: Re: [cdi-dev] @ThreadScoped? To: "Stephan Knitelius" Cc: "Mark Struberg" , "Reza Rahman" , "cdi-dev" Date: Sunday, 20 March, 2016, 18:36 Why is changing @RequestScoped out of the question? From my perspective when an AsyncContext is started the request is still there. It is just being served by a different thread. Certainly there is a need to work with the Servlet EG to figure out how to transfer ?ownership? to the AsyncContext. Anyway my 2 cents Thanks! Kind regards, Manfred Riem > On Mar 19, 2016, at 3:35 PM, Stephan Knitelius wrote: > > I would certainly agree with the assertion that in general it's not advisable to execute a request with multiple threads and that usually single threaded execution is sufficient. > > However I don't think ignoring it is an option. Concurrent operations can be launched even from CDI beans. Yet we don't properly support context propagation nor a context spanning all threads launched from a request. > > I know that changing @requestScoped is probably out of the question, but at least we should consider adding a new context spanning all threads and defining a logical solution for context propagation that can be explained to the end user. > > > > On Fr., 11. M?rz 2016 at 17:17, Mark Struberg > wrote: > Yes, but certain things in EE are assumed to be handled on a single thread. And if you run on a servr then this is really not a blocker most times. If I get many paralllel requests hitting my box then I do not need async handling _that_ often. The whole overhead for setting up the new thread, etc often heavily exceeds the benefits. > So I would not put too much energy into it? > > LieGrue, > strub > > > Am 11.03.2016 um 15:44 schrieb Reza Rahman >: > > > > This is essentially in keeping with the minimalist nature of the EE concurrency JSR. I believe most of it is left to vendors to do the right thing for users. May be a good idea is this language can be tightened up. > > > >> On Mar 11, 2016, at 6:01 AM, Mark Struberg > wrote: > >> E > >> From the servlet spec: > >> > >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of Security Identity in EJBTM Calls? on page 15-176 are available only to threads executing the initial request or when the request is dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition features may be available to other threads operating directly on the response object via the AsyncContext.start(Runnable) method.? > >> > >> check ?available only to threads executing the initial request? > >> > >> Also if you look at the servlet AsyncContext then all the wording is written as MAY and not as MUST. > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau >: > >>> > >>> Hi Mark, > >>> > >>> think 2.3.3.4 states the opposite. > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau |? Blog | Github | LinkedIn | Tomitriber > >>> > >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg >: > >>> Back from JavaLand conference, so sorry for not kicking in earlier. > >>> > >>> I not quite get the argumentation chain. It?s that all triggered by async servlet requests? And isn?t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! > >>> > >>> Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? > >>> Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>> > >>> > >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau >: > >>>> > >>>> Hi guys, > >>>> > >>>> following request scope thread and to center the discussion on the thread safety part: do we work on this? > >>>> > >>>> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. > >>>> > >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. > >>>> > >>>> Questions: > >>>> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): > >>>> > >>>> > >>>> > >>>>??? > >>>>? ???JMS > >>>>? ???ASYNCHONOUS > >>>>??? > >>>> > >>>> > >>>> > >>>> - start/stop API (this is typically an API the user should be able to control for its own threads) > >>>> - CDI 2.*0*? > >>>> > >>>> wdyt? > >>>> > >>>> Romain Manni-Bucau > >>>> @rmannibucau |? Blog | Github | LinkedIn | Tomitriber > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at 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 at 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 at 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 at 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 at 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. From rmannibucau at gmail.com Sun Mar 20 16:34:39 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 20 Mar 2016 21:34:39 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: <217911838.1577969.1458505531205.JavaMail.yahoo@mail.yahoo.com> References: <217911838.1577969.1458505531205.JavaMail.yahoo.ref@mail.yahoo.com> <217911838.1577969.1458505531205.JavaMail.yahoo@mail.yahoo.com> Message-ID: Le 20 mars 2016 21:28, "Mark Struberg" a ?crit : > > I'd say we could move a request context from EXCLUSIVE threadA to EXCLUSIVE threadA. > > But we cannot make the same request scoped Bean accessible from multiple Threads at the same time. > +1 for it > Lgm > > > -------------------------------------------- > On Sun, 20/3/16, Manfred Riem wrote: > > Subject: Re: [cdi-dev] @ThreadScoped? > To: "Stephan Knitelius" > Cc: "Mark Struberg" , "Reza Rahman" < reza_rahman at lycos.com>, "cdi-dev" > Date: Sunday, 20 March, 2016, 18:36 > > Why is changing > @RequestScoped out of the question? > > From my perspective when an AsyncContext is > started the request is still there. > > It is just being served by a different > thread. > > Certainly there is > a need to work with the Servlet EG to figure out how to > transfer ?ownership? to the AsyncContext. > > Anyway my 2 cents > > Thanks! > > Kind regards, > Manfred Riem > > > On Mar 19, 2016, at 3:35 > PM, Stephan Knitelius > wrote: > > > > I would > certainly agree with the assertion that in general it's > not advisable to execute a request with multiple threads and > that usually single threaded execution is sufficient. > > > > However I don't > think ignoring it is an option. Concurrent operations can be > launched even from CDI beans. Yet we don't properly > support context propagation nor a context spanning all > threads launched from a request. > > > > I know that changing @requestScoped is > probably out of the question, but at least we should > consider adding a new context spanning all threads and > defining a logical solution for context propagation that can > be explained to the end user. > > > > > > > > On Fr., 11. M?rz 2016 at 17:17, Mark > Struberg > > wrote: > > Yes, but certain things in EE > are assumed to be handled on a single thread. And if you run > on a servr then this is really not a blocker most times. If > I get many paralllel requests hitting my box then I do not > need async handling _that_ often. The whole overhead for > setting up the new thread, etc often heavily exceeds the > benefits. > > So I would not put too much > energy into it? > > > > > LieGrue, > > strub > > > > > Am 11.03.2016 um 15:44 schrieb Reza > Rahman >: > > > > > > This is > essentially in keeping with the minimalist nature of the EE > concurrency JSR. I believe most of it is left to vendors to > do the right thing for users. May be a good idea is this > language can be tightened up. > > > > > >> On Mar 11, 2016, at 6:01 AM, Mark > Struberg > > wrote: > > >> E > > > >> From the servlet spec: > > > >> > > >> ?Java Enterprise > Edition features such as Section 15.2.2, ?Web Application > Environment? on page 15-174 and Section 15.3.1, > ?Propagation of Security Identity in EJBTM Calls? on > page 15-176 are available only to threads executing the > initial request or when the request is dispatched to the > container via the AsyncContext.dispatch method. Java > Enterprise Edition features may be available to other > threads operating directly on the response object via the > AsyncContext.start(Runnable) method.? > > > >> > > >> check ?available > only to threads executing the initial request? > > >> > > >> > Also if you look at the servlet AsyncContext then all the > wording is written as MAY and not as MUST. > > >> > > >> > LieGrue, > > >> strub > > >> > > >> > > >>> Am 10.03.2016 um 19:52 > schrieb Romain Manni-Bucau >: > > >>> > > > >>> Hi Mark, > > >>> > > >>> think 2.3.3.4 states the > opposite. > > >>> > > >>> > > > >>> Romain Manni-Bucau > > > >>> @rmannibucau | Blog | Github | LinkedIn | > Tomitriber > > >>> > > >>> 2016-03-10 19:43 GMT+01:00 > Mark Struberg >: > > >>> Back from JavaLand > conference, so sorry for not kicking in earlier. > > >>> > > > >>> I not quite get the argumentation chain. It?s > that all triggered by async servlet requests? And isn?t > the servlet spec also saying that all the request param etc > may max be assigned to a single thread AT A TIME! > > >>> > > > >>> Means that it might not be on multiple threads > in parallel, but the data is allowed to get moved from one > thread to another (disapearing from the first one), > right? > > >>> Would really need > to dig into the wording of the async servlets spec again, > maybe has this in the back of his head? > > > >>> > > >>> LieGrue, > > >>> strub > > > >>> > > >>> > > >>> > > > >>> > > >>>> Am > 08.03.2016 um 14:43 schrieb Romain Manni-Bucau >: > > >>>> > > > >>>> Hi guys, > > > >>>> > > >>>> > following request scope thread and to center the discussion > on the thread safety part: do we work on this? > > >>>> > > > >>>> Background: @RequestScoped is often used as > a ThreadLocal instance solution. A lot of SE or Batch > implementations rely on it from what I saw as well as async > implementations reusing existing business logic with this > thread safety constraint. > > > >>>> > > >>>> > Proposal: providing a @ThreadScoped implementation is cheap > for CDI and implemenation and would avoid the headache we > can have with @RequestScoped. Will also remove the quite > dark side of the spec regarding servlet request and request > scope since now we would have a more natural solution for > all of these situation so @RequestScoped goals wouldn't > collide as much. > > >>>> > > >>>> Questions: > > >>>> - is it automatically > started as request scoped is (JMS, @Async, ...)? Alternative > could be some configuration in beans.xml (merged accross the > app): > > >>>> > > >>>> > > >>>> > > > >>>> > > >>>> > JMS > > >>>> > ASYNCHONOUS > > > >>>> > > >>>> > > >>>> > > >>>> > > > >>>> - start/stop API (this is typically an API > the user should be able to control for its own threads) > > >>>> - CDI 2.*0*? > > >>>> > > > >>>> wdyt? > > > >>>> > > >>>> > Romain Manni-Bucau > > >>>> > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > >>>> > _______________________________________________ > > >>>> cdi-dev mailing list > > >>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160320/33b3e542/attachment-0001.html From arjan.tijms at gmail.com Sun Mar 20 16:37:16 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Sun, 20 Mar 2016 21:37:16 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: <45FD6B6F-BFBD-4AAF-98FA-D626EF4F7819@gmail.com> References: <23FBC9B6-0B33-4B11-A5A3-AAF0F805528B@yahoo.de> <45FD6B6F-BFBD-4AAF-98FA-D626EF4F7819@gmail.com> Message-ID: On Sun, Mar 20, 2016 at 6:36 PM, Manfred Riem wrote: > Why is changing @RequestScoped out of the question? > > From my perspective when an AsyncContext is started the request is still > there. > > It is just being served by a different thread. > With just AsyncContext the original request thread can end and a new thread can write to the response. Both of them can access the request object after the AsyncContext has been handed to the second thread. But the second thread is not necessarily "connected" to anything, is it? It's just any random thread that gets the AsyncContext object passed in. Would it work here if there was a public CDI API available to activate the request scope (and session scope possibly) from a given instance of ServletRequest? Regardless, this is a slightly different problem from when a given request thread submits work to a Concurrency spec executor. Kind regards, Arjan Tijms > > Certainly there is a need to work with the Servlet EG to figure out how to > transfer ?ownership? to the AsyncContext. > > Anyway my 2 cents > > Thanks! > > Kind regards, > Manfred Riem > > On Mar 19, 2016, at 3:35 PM, Stephan Knitelius > wrote: > > I would certainly agree with the assertion that in general it's not > advisable to execute a request with multiple threads and that usually > single threaded execution is sufficient. > > However I don't think ignoring it is an option. Concurrent operations can > be launched even from CDI beans. Yet we don't properly support context > propagation nor a context spanning all threads launched from a request. > > I know that changing @requestScoped is probably out of the question, but > at least we should consider adding a new context spanning all threads and > defining a logical solution for context propagation that can be explained > to the end user. > > > > On Fr., 11. M?rz 2016 at 17:17, Mark Struberg wrote: > >> Yes, but certain things in EE are assumed to be handled on a single >> thread. And if you run on a servr then this is really not a blocker most >> times. If I get many paralllel requests hitting my box then I do not need >> async handling _that_ often. The whole overhead for setting up the new >> thread, etc often heavily exceeds the benefits. >> So I would not put too much energy into it? >> >> LieGrue, >> strub >> >> > Am 11.03.2016 um 15:44 schrieb Reza Rahman : >> > >> > This is essentially in keeping with the minimalist nature of the EE >> concurrency JSR. I believe most of it is left to vendors to do the right >> thing for users. May be a good idea is this language can be tightened up. >> > >> >> On Mar 11, 2016, at 6:01 AM, Mark Struberg wrote: >> >> E >> >> From the servlet spec: >> >> >> >> ?Java Enterprise Edition features such as Section 15.2.2, ?Web >> Application Environment? on page 15-174 and Section 15.3.1, ?Propagation of >> Security Identity in EJBTM Calls? on page 15-176 are available only to >> threads executing the initial request or when the request is dispatched to >> the container via the AsyncContext.dispatch method. Java Enterprise Edition >> features may be available to other threads operating directly on the >> response object via the AsyncContext.start(Runnable) method.? >> >> >> >> check ?available only to threads executing the initial request? >> >> >> >> Also if you look at the servlet AsyncContext then all the wording is >> written as MAY and not as MUST. >> >> >> >> LieGrue, >> >> strub >> >> >> >> >> >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau < >> rmannibucau at gmail.com>: >> >>> >> >>> Hi Mark, >> >>> >> >>> think 2.3.3.4 states the opposite. >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>> >> >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg : >> >>> Back from JavaLand conference, so sorry for not kicking in earlier. >> >>> >> >>> I not quite get the argumentation chain. It?s that all triggered by >> async servlet requests? And isn?t the servlet spec also saying that all the >> request param etc may max be assigned to a single thread AT A TIME! >> >>> >> >>> Means that it might not be on multiple threads in parallel, but the >> data is allowed to get moved from one thread to another (disapearing from >> the first one), right? >> >>> Would really need to dig into the wording of the async servlets spec >> again, maybe has this in the back of his head? >> >>> >> >>> LieGrue, >> >>> strub >> >>> >> >>> >> >>> >> >>> >> >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < >> rmannibucau at gmail.com>: >> >>>> >> >>>> Hi guys, >> >>>> >> >>>> following request scope thread and to center the discussion on the >> thread safety part: do we work on this? >> >>>> >> >>>> Background: @RequestScoped is often used as a ThreadLocal instance >> solution. A lot of SE or Batch implementations rely on it from what I saw >> as well as async implementations reusing existing business logic with this >> thread safety constraint. >> >>>> >> >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI >> and implemenation and would avoid the headache we can have with >> @RequestScoped. Will also remove the quite dark side of the spec regarding >> servlet request and request scope since now we would have a more natural >> solution for all of these situation so @RequestScoped goals wouldn't >> collide as much. >> >>>> >> >>>> Questions: >> >>>> - is it automatically started as request scoped is (JMS, @Async, >> ...)? Alternative could be some configuration in beans.xml (merged accross >> the app): >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> JMS >> >>>> ASYNCHONOUS >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> - start/stop API (this is typically an API the user should be able >> to control for its own threads) >> >>>> - CDI 2.*0*? >> >>>> >> >>>> wdyt? >> >>>> >> >>>> Romain Manni-Bucau >> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>>> _______________________________________________ >> >>>> cdi-dev mailing list >> >>>> cdi-dev at 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 at 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 at 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 at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160320/7e846129/attachment.html From struberg at yahoo.de Sun Mar 20 16:51:59 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 20 Mar 2016 20:51:59 +0000 (UTC) Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: Message-ID: <152484317.1572735.1458507120226.JavaMail.yahoo@mail.yahoo.com> I think the current spec wording already defines what happens in that case. At least there are TCK tests for it. LieGrue, strub On Sunday, 20 March 2016, 21:37, arjan tijms wrote: > >On Sun, Mar 20, 2016 at 6:36 PM, Manfred Riem wrote: > >Why is changing @RequestScoped out of the question? >> >> >>From my perspective when an AsyncContext is started the request is still there. >> >> >>It is just being served by a different thread. > > >With just AsyncContext the original request thread can end and a new thread can write to the response. Both of them can access the request object after the AsyncContext has been handed to the second thread. But the second thread is not necessarily "connected" to anything, is it? It's just any random thread that gets the AsyncContext object passed in. > > > >Would it work here if there was a public CDI API available to activate the request scope (and session scope possibly) from a given instance of ServletRequest? > > >Regardless, this is a slightly different problem from when a given request thread submits work to a Concurrency spec executor. > > >Kind regards, >Arjan Tijms > > From struberg at yahoo.de Sun Mar 20 17:03:05 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 20 Mar 2016 21:03:05 +0000 (UTC) Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: Message-ID: <981913821.1564901.1458507785589.JavaMail.yahoo@mail.yahoo.com> Sorry for my brevity. Was on a cellphone only. My point is: Context#get(Bean) and Bean only has getScope() which looks like public Class getScope(); Thus having something like @RequestScoped(allowMultithreads=true) public class BlaBlaController {..} would get represented by a Bean which could only return RequestScoped.class. There is simply no way to return the "allowMultithreads=true" information somewhere as we only deal with Classes. The same applies to BeanManager#getContext(): public Context getContext(Class scope); No Annotation but Class, you see? -> Currently there is no way to evaluate an additional attribute on a scope annotation. And thus section 2.4.2 of the CDI specification also clearly states "A scope type must not have any attributes. If a scope type has attributes non-portable behavior results." roger? LieGrue, strub On Sunday, 20 March 2016, 21:12, Romain Manni-Bucau wrote: > >Le 20 mars 2016 21:07, "Mark Struberg" a ?crit : >> >> See Bean#getScope() and BeanManager#getContext() >> >> Just uses Class and no Annotation instance. >> >That's ok I think. Since 1.2 you can get meta from any bean and find it if needee but i most of cases the context will see the bean and will not need it. >Would also break the Annotated contravt if true. >> Lgm >> >> From rmannibucau at gmail.com Sun Mar 20 17:13:35 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 20 Mar 2016 22:13:35 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: <981913821.1564901.1458507785589.JavaMail.yahoo@mail.yahoo.com> References: <981913821.1564901.1458507785589.JavaMail.yahoo@mail.yahoo.com> Message-ID: Le 20 mars 2016 22:03, "Mark Struberg" a ?crit : > > > > Sorry for my brevity. Was on a cellphone only. > > > My point is: Context#get(Bean) and Bean only has getScope() which looks like > > public Class getScope(); > > Thus having something like > > @RequestScoped(allowMultithreads=true) > public class BlaBlaController {..} > > would get represented by a Bean which could only return RequestScoped.class. > There is simply no way to return the "allowMultithreads=true" information somewhere as we only deal with Classes. > > The same applies to BeanManager#getContext(): > > public Context getContext(Class scope); > Not related to me since the context should handle it and not the bean manager. > > No Annotation but Class, you see? > > -> Currently there is no way to evaluate an additional attribute on a scope annotation. > > > And thus section 2.4.2 of the CDI specification also clearly states > "A scope type must not have any attributes. If a scope type has attributes non-portable behavior results." > Nothing we cant change and worde case change the flag to an own annotation and it works which prooves it is not really relevant and it would work. > roger? > > LieGrue, > strub > > > > > On Sunday, 20 March 2016, 21:12, Romain Manni-Bucau wrote: > > > >Le 20 mars 2016 21:07, "Mark Struberg" a ?crit : > >> > >> See Bean#getScope() and BeanManager#getContext() > >> > >> Just uses Class and no Annotation instance. > >> > >That's ok I think. Since 1.2 you can get meta from any bean and find it if needee but i most of cases the context will see the bean and will not need it. > >Would also break the Annotated contravt if true. > >> Lgm > >> > >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160320/a53c561b/attachment.html From arjan.tijms at gmail.com Sun Mar 20 17:21:00 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Sun, 20 Mar 2016 22:21:00 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: <152484317.1572735.1458507120226.JavaMail.yahoo@mail.yahoo.com> References: <152484317.1572735.1458507120226.JavaMail.yahoo@mail.yahoo.com> Message-ID: If you pass an AsyncContext to a random other thread (which is not necessarily container managed), then the fact that code in this other thread gets hold of this context, doesn't set up the TLS stuff needed for @RequestScoped etc, does it? If so, how would this technically work? This is different from container managed threads which get work submitted to it (like Concurrency spec executor service and @Asynchronous). They have an opportunity to set up and tear down the contexts before and after working on the unit respectively. For the AsyncContext case, what about something like the following in the thread that in whatever way gets hold of the AsyncContext beanmanager.initScope(RequestScoped.class, request); or with a guard: beanmanager.initScopeIfNotActive(RequestScoped.class, request); Would that work? On Sun, Mar 20, 2016 at 9:51 PM, Mark Struberg wrote: > I think the current spec wording already defines what happens in that > case. At least there are TCK tests for it. > > LieGrue, > strub > > > > > On Sunday, 20 March 2016, 21:37, arjan tijms > wrote: > > > > >On Sun, Mar 20, 2016 at 6:36 PM, Manfred Riem wrote: > > > >Why is changing @RequestScoped out of the question? > >> > >> > >>From my perspective when an AsyncContext is started the request is still > there. > >> > >> > >>It is just being served by a different thread. > > > > > >With just AsyncContext the original request thread can end and a new > thread can write to the response. Both of them can access the request > object after the AsyncContext has been handed to the second thread. But the > second thread is not necessarily "connected" to anything, is it? It's just > any random thread that gets the AsyncContext object passed in. > > > > > > > >Would it work here if there was a public CDI API available to activate > the request scope (and session scope possibly) from a given instance of > ServletRequest? > > > > > >Regardless, this is a slightly different problem from when a given > request thread submits work to a Concurrency spec executor. > > > > > >Kind regards, > >Arjan Tijms > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160320/7eed42aa/attachment.html From struberg at yahoo.de Sun Mar 20 17:21:11 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 20 Mar 2016 21:21:11 +0000 (UTC) Subject: [cdi-dev] @ThreadScoped? In-Reply-To: References: Message-ID: <114546338.1593774.1458508871556.JavaMail.yahoo@mail.yahoo.com> But the Context only gets the information from the Bean. And that only returns a Class. The Context just has no clue what the parameter for that very impl was. And it also cannot simply ask the Class#getAnnotations() as this would break all Extensions inbetween. Not quite sure how you imagine this should work. LieGrue, strub On Sunday, 20 March 2016, 22:13, Romain Manni-Bucau wrote: >Le 20 mars 2016 22:03, "Mark Struberg" a ?crit : >> >> >> >> Sorry for my brevity. Was on a cellphone only. >> >> >> My point is: Context#get(Bean) and Bean only has getScope() which looks like >> >> public Class getScope(); >> >> Thus having something like >> >> @RequestScoped(allowMultithreads=true) >> public class BlaBlaController {..} >> >> would get represented by a Bean which could only return RequestScoped.class. >> There is simply no way to return the "allowMultithreads=true" information somewhere as we only deal with Classes. >> >> The same applies to BeanManager#getContext(): >> >> public Context getContext(Class scope); >> >Not related to me since the context should handle it and not the bean manager. >> >> No Annotation but Class, you see? >> >> -> Currently there is no way to evaluate an additional attribute on a scope annotation. >> >> >> And thus section 2.4.2 of the CDI specification also clearly states >> "A scope type must not have any attributes. If a scope type has attributes non-portable behavior results." >> >Nothing we cant change and worde case change the flag to an own annotation and it works which prooves it is not really relevant and it would work. > > >> roger? >> >> LieGrue, >> strub >> >> >> >> >> On Sunday, 20 March 2016, 21:12, Romain Manni-Bucau wrote: >> > >> >Le 20 mars 2016 21:07, "Mark Struberg" a ?crit : >> >> >> >> See Bean#getScope() and BeanManager#getContext() >> >> >> >> Just uses Class and no Annotation instance. >> >> >> >That's ok I think. Since 1.2 you can get meta from any bean and find it if needee but i most of cases the context will see the bean and will not need it. >> >Would also break the Annotated contravt if true. >> >> Lgm >> >> >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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. > > From rmannibucau at gmail.com Sun Mar 20 17:34:58 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 20 Mar 2016 22:34:58 +0100 Subject: [cdi-dev] @ThreadScoped? In-Reply-To: <114546338.1593774.1458508871556.JavaMail.yahoo@mail.yahoo.com> References: <114546338.1593774.1458508871556.JavaMail.yahoo@mail.yahoo.com> Message-ID: Le 20 mars 2016 22:21, "Mark Struberg" a ?crit : > > But the Context only gets the information from the Bean. And that only returns a Class. The Context just has no clue what the parameter for that very impl was. And it also cannot simply ask the Class#getAnnotations() as this would break all Extensions inbetween. > Not quite sure how you imagine this should work. > Annotated can be retrieved now and scopes shouldnt be needed before after the validation so sounds good to me. > > LieGrue, > strub > Agree with Arjan we need a context.run(Runnable/Supplier) to have something user friendly. > > > On Sunday, 20 March 2016, 22:13, Romain Manni-Bucau wrote: > >Le 20 mars 2016 22:03, "Mark Struberg" a ?crit : > >> > >> > >> > >> Sorry for my brevity. Was on a cellphone only. > >> > >> > >> My point is: Context#get(Bean) and Bean only has getScope() which looks like > >> > >> public Class getScope(); > >> > >> Thus having something like > >> > >> @RequestScoped(allowMultithreads=true) > >> public class BlaBlaController {..} > >> > >> would get represented by a Bean which could only return RequestScoped.class. > >> There is simply no way to return the "allowMultithreads=true" information somewhere as we only deal with Classes. > >> > >> The same applies to BeanManager#getContext(): > >> > >> public Context getContext(Class scope); > >> > >Not related to me since the context should handle it and not the bean manager. > >> > >> No Annotation but Class, you see? > >> > >> -> Currently there is no way to evaluate an additional attribute on a scope annotation. > >> > >> > >> And thus section 2.4.2 of the CDI specification also clearly states > >> "A scope type must not have any attributes. If a scope type has attributes non-portable behavior results." > >> > >Nothing we cant change and worde case change the flag to an own annotation and it works which prooves it is not really relevant and it would work. > > > > > >> roger? > >> > >> LieGrue, > >> strub > >> > >> > >> > >> > >> On Sunday, 20 March 2016, 21:12, Romain Manni-Bucau < rmannibucau at gmail.com> wrote: > >> > > >> >Le 20 mars 2016 21:07, "Mark Struberg" a ?crit : > >> >> > >> >> See Bean#getScope() and BeanManager#getContext() > >> >> > >> >> Just uses Class and no Annotation instance. > >> >> > >> >That's ok I think. Since 1.2 you can get meta from any bean and find it if needee but i most of cases the context will see the bean and will not need it. > >> >Would also break the Annotated contravt if true. > >> >> Lgm > >> >> > >> >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at 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. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160320/2011a080/attachment-0001.html From issues at jboss.org Mon Mar 21 07:47:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 21 Mar 2016 07:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-590) Provide a way to produce any type in a producer In-Reply-To: References: Message-ID: Romain Manni-Bucau created CDI-590: -------------------------------------- Summary: Provide a way to produce any type in a producer Key: CDI-590 URL: https://issues.jboss.org/browse/CDI-590 Project: CDI Specification Issues Issue Type: Epic Reporter: Romain Manni-Bucau Note: this is a follow up "adding generic producers to CDI 2.0?" thread on the list It is common to rely on a subsystem (another IoC, a coercing system, ...) to produce values. Today a producer can't say "I produce anything in a safe" manner. Idea would be for injection point aware producers with a qualifier to producer Object and match all types. It needs another flag (can be in @Qualifier or another annotation it is not really important) to say "I produce safely any type". I did a PoC on github: https://github.com/rmannibucau/generic-producer-cdi but think it can be a nice feature of CDI 2.0 since it would avoid users to have to dig into extensions for several simple cases (configuration, bridge to other IoC...) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 21 08:31:01 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Mon, 21 Mar 2016 08:31:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-560) A bean archive does not have to contain a beans.xml file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179790#comment-13179790 ] Tomas Remes commented on CDI-560: --------------------------------- This issue can be closed or resolved. > A bean archive does not have to contain a beans.xml file > -------------------------------------------------------- > > Key: CDI-560 > URL: https://issues.jboss.org/browse/CDI-560 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 2.0-EDR1 > Environment: Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > An archive which: > contains a beans.xml file with the bean-discovery-mode of none, or, > contains an extension and no beans.xml file > is not a bean archive. > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0 (proposed) > > > Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > {quote} > An archive which: > * contains a beans.xml file with the bean-discovery-mode of none, or, > * contains an extension and no beans.xml file > is not a bean archive. > {quote} > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Tue Mar 22 03:49:58 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 22 Mar 2016 07:49:58 +0000 Subject: [cdi-dev] Canceling meeting Message-ID: H guys, I have to cancel the meeting today. Please continue reviewing the open PR, especially PR 270. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160322/02f31c6a/attachment.html From issues at jboss.org Tue Mar 22 06:13:02 2016 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Tue, 22 Mar 2016 06:13:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-590) Provide a way to produce any type in a producer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180400#comment-13180400 ] Antonin Stefanutti commented on CDI-590: ---------------------------------------- I've been facing that need as well in a number of extensions. Ideally, there would be a way to declare producer for parameterized types that contain bounded wildcard type parameters. A way to provide a set of return types that can guarantee type safe resolution at deployment time would be great as well. > Provide a way to produce any type in a producer > ----------------------------------------------- > > Key: CDI-590 > URL: https://issues.jboss.org/browse/CDI-590 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Note: this is a follow up "adding generic producers to CDI 2.0?" thread on the list > It is common to rely on a subsystem (another IoC, a coercing system, ...) to produce values. Today a producer can't say "I produce anything in a safe" manner. > Idea would be for injection point aware producers with a qualifier to producer Object and match all types. > It needs another flag (can be in @Qualifier or another annotation it is not really important) to say "I produce safely any type". > I did a PoC on github: https://github.com/rmannibucau/generic-producer-cdi but think it can be a nice feature of CDI 2.0 since it would avoid users to have to dig into extensions for several simple cases (configuration, bridge to other IoC...) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 06:19:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 22 Mar 2016 06:19:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-591) Easy way to get an interceptor model In-Reply-To: References: Message-ID: Romain Manni-Bucau created CDI-591: -------------------------------------- Summary: Easy way to get an interceptor model Key: CDI-591 URL: https://issues.jboss.org/browse/CDI-591 Project: CDI Specification Issues Issue Type: Epic Reporter: Romain Manni-Bucau Since CDI 1.1 we can get the intercepted Bean but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior. {code} @Inject @Intercepted AnnotatedType type; @Inject @Intercepted AnnotatedMethod method; {code} would be great Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 06:30:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 22 Mar 2016 06:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-591) Easy way to get an interceptor model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180410#comment-13180410 ] Martin Kouba commented on CDI-591: ---------------------------------- So are the interceptor bindings the only info you're interested in? If so, there is CDI-468 already. > Easy way to get an interceptor model > ------------------------------------ > > Key: CDI-591 > URL: https://issues.jboss.org/browse/CDI-591 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Since CDI 1.1 we can get the intercepted Bean but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior. > {code} > @Inject > @Intercepted > AnnotatedType type; > @Inject > @Intercepted > AnnotatedMethod method; > {code} > would be great > Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 06:31:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 22 Mar 2016 06:31:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-468) Extend javax.interceptor.InvocationContext In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-468: ----------------------------- Fix Version/s: 2.0 (discussion) > Extend javax.interceptor.InvocationContext > ------------------------------------------ > > Key: CDI-468 > URL: https://issues.jboss.org/browse/CDI-468 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Arne Limburg > Fix For: 2.0 (discussion) > > > Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly. > I propose to extend the javax.interceptor.InvocationContext interface with a method > public Annotation getInterceptorBinding() or > public A getInterceptorBinding(Class type) > The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 06:33:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 22 Mar 2016 06:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-591) Easy way to get an interceptor model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180411#comment-13180411 ] Romain Manni-Bucau commented on CDI-591: ---------------------------------------- No, needs both the annotated method and type. The binding is the obvious interesting thing but often there are companion annotations the interceptor needs to read. Workaround today is to use the bean manager to "create" the annotated type and filter methods to find it but this is not fluent and as easy as it could. > Easy way to get an interceptor model > ------------------------------------ > > Key: CDI-591 > URL: https://issues.jboss.org/browse/CDI-591 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Since CDI 1.1 we can get the intercepted Bean but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior. > {code} > @Inject > @Intercepted > AnnotatedType type; > @Inject > @Intercepted > AnnotatedMethod method; > {code} > would be great > Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 06:39:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 22 Mar 2016 06:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-591) Easy way to get an interceptor model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180417#comment-13180417 ] Martin Kouba commented on CDI-591: ---------------------------------- Hm, then I don't understand why not use {{InvocationContext.getMethod()}} (using {{BeanManager.createAnnotatedType()}} does not guarantee you will work with the AT processed by extensions anyway). > Easy way to get an interceptor model > ------------------------------------ > > Key: CDI-591 > URL: https://issues.jboss.org/browse/CDI-591 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Since CDI 1.1 we can get the intercepted Bean but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior. > {code} > @Inject > @Intercepted > AnnotatedType type; > @Inject > @Intercepted > AnnotatedMethod method; > {code} > would be great > Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 06:42:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 22 Mar 2016 06:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-591) Easy way to get an interceptor model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180424#comment-13180424 ] Romain Manni-Bucau commented on CDI-591: ---------------------------------------- ic.getMethod() uses reflection and not the Annotated model so you can miss part of the model. createAnnotatedType() doesn't guarantee anything but is the best we can do today without requiring to write an extension which would make interceptor API super complicated compared to what is desired on the end user side. > Easy way to get an interceptor model > ------------------------------------ > > Key: CDI-591 > URL: https://issues.jboss.org/browse/CDI-591 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Since CDI 1.1 we can get the intercepted Bean but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior. > {code} > @Inject > @Intercepted > AnnotatedType type; > @Inject > @Intercepted > AnnotatedMethod method; > {code} > would be great > Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 08:21:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 22 Mar 2016 08:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-590) Provide a way to produce any type in a producer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180500#comment-13180500 ] Martin Kouba commented on CDI-590: ---------------------------------- I'm not sure I understand the use case. Do you want to declare a producer method whose set of bean types will not be derived from the return type? A more general description would be great. > Provide a way to produce any type in a producer > ----------------------------------------------- > > Key: CDI-590 > URL: https://issues.jboss.org/browse/CDI-590 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Note: this is a follow up "adding generic producers to CDI 2.0?" thread on the list > It is common to rely on a subsystem (another IoC, a coercing system, ...) to produce values. Today a producer can't say "I produce anything in a safe" manner. > Idea would be for injection point aware producers with a qualifier to producer Object and match all types. > It needs another flag (can be in @Qualifier or another annotation it is not really important) to say "I produce safely any type". > I did a PoC on github: https://github.com/rmannibucau/generic-producer-cdi but think it can be a nice feature of CDI 2.0 since it would avoid users to have to dig into extensions for several simple cases (configuration, bridge to other IoC...) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 08:33:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 22 Mar 2016 08:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-590) Provide a way to produce any type in a producer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180514#comment-13180514 ] Romain Manni-Bucau commented on CDI-590: ---------------------------------------- [~mkouba] yes. Suppose you have a configuration library or another IoC you want to integrate with for instance. In such cases you often have SuperFrameworkFactory.getBean(Type, Annotation, OtherParamLibSpecific) and you just can to call this building the parameters from the InjectionPoint. Today the only solution with CDI is to build an extension where you would just produce the bean and ensure it is not ambiguous using a qualifier. > Provide a way to produce any type in a producer > ----------------------------------------------- > > Key: CDI-590 > URL: https://issues.jboss.org/browse/CDI-590 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Note: this is a follow up "adding generic producers to CDI 2.0?" thread on the list > It is common to rely on a subsystem (another IoC, a coercing system, ...) to produce values. Today a producer can't say "I produce anything in a safe" manner. > Idea would be for injection point aware producers with a qualifier to producer Object and match all types. > It needs another flag (can be in @Qualifier or another annotation it is not really important) to say "I produce safely any type". > I did a PoC on github: https://github.com/rmannibucau/generic-producer-cdi but think it can be a nice feature of CDI 2.0 since it would avoid users to have to dig into extensions for several simple cases (configuration, bridge to other IoC...) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 08:33:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 22 Mar 2016 08:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-590) Provide a way to produce any type in a producer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180515#comment-13180515 ] Matej Novotny commented on CDI-590: ----------------------------------- I don't really like this idea. It feels 'hacky' and it could also contradict the type-safe approach. If I got it right, the idea is to have this producer: {code} @Produces @MyProducerQualifier // this Qualifier has some annotation saying it is 'generic' public Object create() { // do some work and return Object } {code} and then for this one producer to have the following injections: {code} @Inject @MyProducerQualifier String string; @Inject @MyProducerQualifier Integer int; {code} Could you give a more specific use-case showing where this would make sense (or even better, be neccessary)? > Provide a way to produce any type in a producer > ----------------------------------------------- > > Key: CDI-590 > URL: https://issues.jboss.org/browse/CDI-590 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Note: this is a follow up "adding generic producers to CDI 2.0?" thread on the list > It is common to rely on a subsystem (another IoC, a coercing system, ...) to produce values. Today a producer can't say "I produce anything in a safe" manner. > Idea would be for injection point aware producers with a qualifier to producer Object and match all types. > It needs another flag (can be in @Qualifier or another annotation it is not really important) to say "I produce safely any type". > I did a PoC on github: https://github.com/rmannibucau/generic-producer-cdi but think it can be a nice feature of CDI 2.0 since it would avoid users to have to dig into extensions for several simple cases (configuration, bridge to other IoC...) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 08:38:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 22 Mar 2016 08:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-590) Provide a way to produce any type in a producer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180518#comment-13180518 ] Romain Manni-Bucau commented on CDI-590: ---------------------------------------- [~manovotn] configuration is a very common use case cause you often rely on a library which already does the conversion and sometimes even map a complex type. Also if you integrate with Spring, Pico, Guice, ... you need that or you have to write an extension which is not as trivial as it should. Rephrased this case handles CDI-X integration in a generic manner and in a simple way compared to have to 1. scan the X library beans (thing you can't do sometimes) 2. create a XBean 3. register bean you *suppose* you will need (you obviously miss the programmatic lookup approach). > Provide a way to produce any type in a producer > ----------------------------------------------- > > Key: CDI-590 > URL: https://issues.jboss.org/browse/CDI-590 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Note: this is a follow up "adding generic producers to CDI 2.0?" thread on the list > It is common to rely on a subsystem (another IoC, a coercing system, ...) to produce values. Today a producer can't say "I produce anything in a safe" manner. > Idea would be for injection point aware producers with a qualifier to producer Object and match all types. > It needs another flag (can be in @Qualifier or another annotation it is not really important) to say "I produce safely any type". > I did a PoC on github: https://github.com/rmannibucau/generic-producer-cdi but think it can be a nice feature of CDI 2.0 since it would avoid users to have to dig into extensions for several simple cases (configuration, bridge to other IoC...) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 09:27:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 22 Mar 2016 09:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-590) Provide a way to produce any type in a producer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180584#comment-13180584 ] Matej Novotny commented on CDI-590: ----------------------------------- [~rmannibucau] got it now, or at least I hope so. Thanks for clarification. It is indeed an interesting idea and certainly matches the use-case. Although leaving the type-safe check on user side (since it will be handled in producers) might yield...various results :) > Provide a way to produce any type in a producer > ----------------------------------------------- > > Key: CDI-590 > URL: https://issues.jboss.org/browse/CDI-590 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Note: this is a follow up "adding generic producers to CDI 2.0?" thread on the list > It is common to rely on a subsystem (another IoC, a coercing system, ...) to produce values. Today a producer can't say "I produce anything in a safe" manner. > Idea would be for injection point aware producers with a qualifier to producer Object and match all types. > It needs another flag (can be in @Qualifier or another annotation it is not really important) to say "I produce safely any type". > I did a PoC on github: https://github.com/rmannibucau/generic-producer-cdi but think it can be a nice feature of CDI 2.0 since it would avoid users to have to dig into extensions for several simple cases (configuration, bridge to other IoC...) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 09:29:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 22 Mar 2016 09:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-590) Provide a way to produce any type in a producer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180588#comment-13180588 ] Martin Kouba commented on CDI-590: ---------------------------------- Now I think I understand the concept. However, a type-safe approach - custom producer per type, reusing the same qualifier annotation (something similar to DeltaSpike {{ConfigProperty}}) - seems more suitable for the configuration use case. The integration with other DI frameworks is a different story... > Provide a way to produce any type in a producer > ----------------------------------------------- > > Key: CDI-590 > URL: https://issues.jboss.org/browse/CDI-590 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Note: this is a follow up "adding generic producers to CDI 2.0?" thread on the list > It is common to rely on a subsystem (another IoC, a coercing system, ...) to produce values. Today a producer can't say "I produce anything in a safe" manner. > Idea would be for injection point aware producers with a qualifier to producer Object and match all types. > It needs another flag (can be in @Qualifier or another annotation it is not really important) to say "I produce safely any type". > I did a PoC on github: https://github.com/rmannibucau/generic-producer-cdi but think it can be a nice feature of CDI 2.0 since it would avoid users to have to dig into extensions for several simple cases (configuration, bridge to other IoC...) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 09:35:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 22 Mar 2016 09:35:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-590) Provide a way to produce any type in a producer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180593#comment-13180593 ] Romain Manni-Bucau commented on CDI-590: ---------------------------------------- [~mkouba] deltaspike example is not really relevant there cause it doesn't support a lot of types. Just use PropertyEditor API and deltaspike producers wouldn't work anymore and that's just a trivial case. If you use tamaya, Tamaya has its own coercing system which wouldnt fit CDI very well without that feature IMO. > Provide a way to produce any type in a producer > ----------------------------------------------- > > Key: CDI-590 > URL: https://issues.jboss.org/browse/CDI-590 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Note: this is a follow up "adding generic producers to CDI 2.0?" thread on the list > It is common to rely on a subsystem (another IoC, a coercing system, ...) to produce values. Today a producer can't say "I produce anything in a safe" manner. > Idea would be for injection point aware producers with a qualifier to producer Object and match all types. > It needs another flag (can be in @Qualifier or another annotation it is not really important) to say "I produce safely any type". > I did a PoC on github: https://github.com/rmannibucau/generic-producer-cdi but think it can be a nice feature of CDI 2.0 since it would avoid users to have to dig into extensions for several simple cases (configuration, bridge to other IoC...) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 10:50:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 22 Mar 2016 10:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-590) Provide a way to produce any type in a producer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180679#comment-13180679 ] Martin Kouba commented on CDI-590: ---------------------------------- bq. it doesn't support a lot of types I thought a custom producer for any type [can be implemented|https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigProperty.java#L78]. bq. Just use PropertyEditor API... I don't know what do you mean. Probably {{java.beans.PropertyEditor}}? bq. Tamaya has its own coercing system which wouldnt fit CDI very well... For Tamaya I think it would be more meaningful to create a producer for {{org.apache.tamaya.Configuration}}. But I understand that it would be nice to leverage {{PropertyConverter}} and produce configuration properties directly. Look, I'm not against this feature! I'm just trying to identify all pros and cons ;-) > Provide a way to produce any type in a producer > ----------------------------------------------- > > Key: CDI-590 > URL: https://issues.jboss.org/browse/CDI-590 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Note: this is a follow up "adding generic producers to CDI 2.0?" thread on the list > It is common to rely on a subsystem (another IoC, a coercing system, ...) to produce values. Today a producer can't say "I produce anything in a safe" manner. > Idea would be for injection point aware producers with a qualifier to producer Object and match all types. > It needs another flag (can be in @Qualifier or another annotation it is not really important) to say "I produce safely any type". > I did a PoC on github: https://github.com/rmannibucau/generic-producer-cdi but think it can be a nice feature of CDI 2.0 since it would avoid users to have to dig into extensions for several simple cases (configuration, bridge to other IoC...) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 09:41:01 2016 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Wed, 23 Mar 2016 09:41:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated CDI-473: ----------------------------------- Fix Version/s: 2.0 (discussion) > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > Fix For: 2.0 (discussion) > > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 09:44:00 2016 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Wed, 23 Mar 2016 09:44:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181297#comment-13181297 ] Antonin Stefanutti commented on CDI-473: ---------------------------------------- That request should ideally be moved forward as part of bringing better Java SE support in CDI 2.0. > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > Fix For: 2.0 (discussion) > > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 09:54:00 2016 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Wed, 23 Mar 2016 09:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181310#comment-13181310 ] Antonio Goncalves commented on CDI-473: --------------------------------------- At the last face to face we even mentioned being able to startup, shutdown and prioritize bean initialization. For example : {code} @ApplicationScoped @Startup @Priority(1000) public class Foo { @PostConstruct public void m() { } } {code} Or even do : {code} @ApplicationScoped public class Foo { @Startup public void init() { } @Shutdown public void clear() { } } {code} > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > Fix For: 2.0 (discussion) > > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 10:02:02 2016 From: issues at jboss.org (Claus Ibsen (JIRA)) Date: Wed, 23 Mar 2016 10:02:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181329#comment-13181329 ] Claus Ibsen commented on CDI-473: --------------------------------- > That request should ideally be moved forward as part of bringing better Java SE support in CDI 2.0. +1 Yeah I would love to see CDI 2.0 being able to do all the needed stuff on plain Java SE. There is a lot of movement to MSA and plain old java main apps. So lets try to make CDI 2.0 the best DI library for that. Its almost there. > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > Fix For: 2.0 (discussion) > > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 11:06:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 23 Mar 2016 11:06:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-592) Consider adding ObserverMethod.notify() method which also accepts EventMetadata In-Reply-To: References: Message-ID: Martin Kouba created CDI-592: -------------------------------- Summary: Consider adding ObserverMethod.notify() method which also accepts EventMetadata Key: CDI-592 URL: https://issues.jboss.org/browse/CDI-592 Project: CDI Specification Issues Issue Type: Feature Request Components: Events Reporter: Martin Kouba Fix For: 2.0 (discussion) {code:java} // Make the original method also default so that new impls don't need to implement two methods default void notify(T event) { // No-op } // The container should always call this method... default void notify(T event, EventMetadata metadata) { notify(event); } {code} This should not break existing implementations. The truth is a custom impl will not be forced to implement any {{notify()}} method. But I think the benefits are worth it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 23 21:22:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 23 Mar 2016 21:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181651#comment-13181651 ] John Ament commented on CDI-473: -------------------------------- I'm a bit puzzled about start up needs to be honest. Typically when bringing up something like this, I have a single start up entry point. That one entry point starts components in the right order. While it would be cool to have the container start things in the right order, its sometimes considered to be voodoo magic for that to happen in an unclear way, as well as question the testability of such a process. > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > Fix For: 2.0 (discussion) > > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 03:27:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 24 Mar 2016 03:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181687#comment-13181687 ] Martin Kouba commented on CDI-473: ---------------------------------- [~meetoblivion] [~stefanutti] [~davsclaus] [~agoncal] So this the best we can do today, right? And in 2.0 it should be possible to add {{@Priority}} to the observer method... {code:java} @ApplicationScoped public class Initializer { @Inject private Service1 service1; @Inject private Service2 service2; void init(@Observes @Initialized(ApplicationScoped.class) Object event) { } @PostConstruct void postConstruct() { service1.start(); service2.start(); } } {code} > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > Fix For: 2.0 (discussion) > > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 04:12:02 2016 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Thu, 24 Mar 2016 04:12:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181698#comment-13181698 ] Antonin Stefanutti commented on CDI-473: ---------------------------------------- [~mkouba] indeed. Ordering is an extension of the use case, but often you just need: {code} @Startup @ApplicationScoped public class Foo { @PostConstruct public void init() { //... } } {code} This would be an equivalent to Spring that eagerly pre-instantiates all singleton beans at startup. It would be very useful in Java SE so that you can bind the lifecycle of beans that deal for example with external resources, pools, executors to that of the container. In Java EE, these tend to be resources managed by the application containers as opposed to Java SE. A number of extensions already do it (Camel CDI for example to start endpoints, consumers, ...). But it looks like the need exists at application developer level as well. > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > Fix For: 2.0 (discussion) > > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 05:22:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 24 Mar 2016 05:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181733#comment-13181733 ] Mark Struberg commented on CDI-473: ----------------------------------- TL;DR: imo we don't need any @Startup here for the long explanation: *) As Jozef already explained there is @Observers @Initialized(ApplicationScoped.class). *) [~meetoblivion] good point, but one could check that in the code easily. (if bla==null..) *) the @Startup + @Postconstruct has one HUGE downside: As JSR-250 defines a bean must only be made available _after_ PostConstruct did finish. That means that no other bean we call us before the init is finished. That causes tons of problems, e.g. defeats circular injection (which proxies usually solve), the boot order etc. THAT was the reason why EJB had to introduce the whole depends-on stuff in the first place. And it is really ugly and hard to get right. With the eventing solution it's pretty smooth. The only 'problem' currently in this area that the @Initialized and @Destroyed events for ApplicationScoped does NOT reflect the real lifecycle of the ApplicationContext. [1] [1] for those who like to dig deeper: All CDI Extensions are defined to be available as @ApplicationScoped beans. Thus the ApplicationContext hast to be available right after the CDI extensions get loaded, means way before we even fire the first @BeforeBeanDiscovery event. And the ApplicationContext must also exist until the last CDI Extension got the @BeforeShutdown event. In OWB we first fire the @Destroyed(ApplicationContext.class) then destroy the 'user' beans and only then fire all the BeforeShutdown. And only after that we really destroy the ApplicationContext. Not sure if Weld does something similar, but that's what worked best so far... > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > Fix For: 2.0 (discussion) > > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 05:54:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 24 Mar 2016 05:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181752#comment-13181752 ] Martin Kouba commented on CDI-473: ---------------------------------- The other problem with {{@Initialized/@Destroyed(ApplicationScoped.class)}} is that different EE modules usually receive different payloads, e.g. web modules receive a concrete {{ServletContext}}, EJB modules any {{Object}}. So there might be multiple events with different timing. I know it's only relevant for EARs, but still might complicate things. {{BeforeShutdown}} must be fired after all contexts are destroyed. It's true the container must provide a bean of scope {{@ApplicationScoped}} for each extension so it sounds like a contradiction. But in Weld we have a special handling of extension observer methods where contexts do not have to be active. > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > Fix For: 2.0 (discussion) > > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 08:53:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 24 Mar 2016 08:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-546) Constant for default observer priority In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-546: ----------------------------- Fix Version/s: 2.0 (discussion) > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Priority: Minor > Fix For: 2.0 (discussion) > > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 09:11:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 24 Mar 2016 09:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc In-Reply-To: References: Message-ID: Martin Kouba created CDI-593: -------------------------------- Summary: Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc Key: CDI-593 URL: https://issues.jboss.org/browse/CDI-593 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba * javadoc would definitely deserve some more info * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and implementing this interface is globally enabled) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 09:11:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 24 Mar 2016 09:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-593: ----------------------------- Fix Version/s: 2.0 (discussion) > Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc > ------------------------------------------------------------------------------------ > > Key: CDI-593 > URL: https://issues.jboss.org/browse/CDI-593 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > * javadoc would definitely deserve some more info > * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and implementing this interface is globally enabled) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 09:17:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 24 Mar 2016 09:17:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-546) Constant for default observer priority In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181917#comment-13181917 ] Martin Kouba commented on CDI-546: ---------------------------------- I believe we should place the constant on the {{javax.enterprise.inject.spi.ObserverMethod}}. > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Priority: Minor > Fix For: 2.0 (discussion) > > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 09:44:00 2016 From: issues at jboss.org (Mark Paluch (JIRA)) Date: Thu, 24 Mar 2016 09:44:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-546) Constant for default observer priority In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181939#comment-13181939 ] Mark Paluch commented on CDI-546: --------------------------------- Without a MR of JSR250 (for {{@Priority}}) the whole priority story is no fun at all. > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Priority: Minor > Fix For: 2.0 (discussion) > > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 25 12:20:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 25 Mar 2016 12:20:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-594) Instance#destroy should be linked to Instance instance which has been used for the creation In-Reply-To: References: Message-ID: Romain Manni-Bucau created CDI-594: -------------------------------------- Summary: Instance#destroy should be linked to Instance instance which has been used for the creation Key: CDI-594 URL: https://issues.jboss.org/browse/CDI-594 Project: CDI Specification Issues Issue Type: Epic Affects Versions: 1.2.Final Reporter: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 25 12:24:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 25 Mar 2016 12:24:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-594) Instance#destroy should be linked to Instance instance which has been used for the creation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated CDI-594: ----------------------------------- Description: We suppose we have an injection of type Instance. {code} // adapted from javaee7-samples repo Instance select = instance.select(new AnnotationLiteral() {}); Greeting anotherBean = select.get(); assertThat(anotherBean, instanceOf(SimpleGreeting.class)); select.destroy(anotherBean); {code} This version of code is working well and not ambiguous but the original one (next snippet) is currently ambiguous and I think it shouldn't even work: {code} Greeting anotherBean = instance.select(new AnnotationLiteral() {}).get(); assertThat(anotherBean, instanceOf(SimpleGreeting.class)); instance.destroy(anotherBean); {code} The difference is this time the destroy is called on an instance which can be different from the producing instance. For symmetry I think it should be explicitly mentionned the root instance doesn't have to support it and that the destruction should happen with the creation instance Instance. The rational behind that is to be symmetric and to allow to have untracked instances and not hold memory in a useless manner and not require ref counting which would be the alternative specification solution I think and can create issue if the code relies on Instance in a less atomic manner. > Instance#destroy should be linked to Instance instance which has been used for the creation > ------------------------------------------------------------------------------------------- > > Key: CDI-594 > URL: https://issues.jboss.org/browse/CDI-594 > Project: CDI Specification Issues > Issue Type: Epic > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > We suppose we have an injection of type Instance. > {code} > // adapted from javaee7-samples repo > Instance select = instance.select(new AnnotationLiteral() {}); > Greeting anotherBean = select.get(); > assertThat(anotherBean, instanceOf(SimpleGreeting.class)); > select.destroy(anotherBean); > {code} > This version of code is working well and not ambiguous but the original one (next snippet) is currently ambiguous and I think it shouldn't even work: > {code} > Greeting anotherBean = instance.select(new AnnotationLiteral() {}).get(); > assertThat(anotherBean, instanceOf(SimpleGreeting.class)); > instance.destroy(anotherBean); > {code} > The difference is this time the destroy is called on an instance which can be different from the producing instance. For symmetry I think it should be explicitly mentionned the root instance doesn't have to support it and that the destruction should happen with the creation instance Instance. The rational behind that is to be symmetric and to allow to have untracked instances and not hold memory in a useless manner and not require ref counting which would be the alternative specification solution I think and can create issue if the code relies on Instance in a less atomic manner. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.d.ament at gmail.com Tue Mar 29 15:51:37 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 29 Mar 2016 19:51:37 +0000 Subject: [cdi-dev] No meeting today? Message-ID: I was on IRC a few minutes late, but looked like there was no meeting. Was it canceled? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160329/48067242/attachment.html From stephan at knitelius.com Tue Mar 29 15:57:54 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Tue, 29 Mar 2016 19:57:54 +0000 Subject: [cdi-dev] No meeting today? In-Reply-To: References: Message-ID: Missed it today, Europe switched to day lights saving time on Sunday, so its UTC+2 now. Transcript is here here: http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2016/cdi-dev.2016-03-29-16.02.log.html On Tue, 29 Mar 2016 at 21:52 John D. Ament wrote: > I was on IRC a few minutes late, but looked like there was no meeting. > Was it canceled? > > John > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160329/f33f1174/attachment-0001.html From antoine at sabot-durand.net Thu Mar 31 10:38:56 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 31 Mar 2016 14:38:56 +0000 Subject: [cdi-dev] PR review and Hangout meeting Message-ID: Hi all, During last meeting we discuss about making some meeting with hangout to be more efficient with the current PR. We could setup a meeting Tuesday evening to replace our IRC meeting (6:00 pm CEST) or any other day of the week (and later if necessary), but this meeting will be useless if you don't have time to review the open PR. So let me know if the slot is ok for you regarding availability and review capacity before. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160331/2f575d3b/attachment.html From antoine at sabot-durand.net Thu Mar 31 10:41:52 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 31 Mar 2016 14:41:52 +0000 Subject: [cdi-dev] Closing PR 270 to open a fresher one Message-ID: Hi, PR 270, related to metadata builder api (CDI-558) had became too complicated in its history. With a major new contribution from Martin on the feature, I decided to close the PR and reopen it tomorrow (after some rework in the spec and javadoc). Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160331/3d962e18/attachment.html