Re: [cdi-dev] inheritance of cdi scopes

>" >Tasks that are submitted to a managed instance of ExecutorService may

>" States that the context is not inherited, is that what you mean?

" 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 <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2016-03-07 5:57 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: > 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(a)yahoo.de&gt; 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(a)gmail.com&gt;: > > 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(a)lycos.com&gt; 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(a)gmail.com&gt; >> 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/ContextSe... >> >> 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(a)lycos.com&gt; >> 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(a)gmail.com&gt; >>> wrote: >>> >>> >>> 2016-03-06 20:59 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >>> >>>> 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(a)gmail.com&gt; >>>> 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(a)gmail.com&gt; wrote: >>>> >>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >>>>> >>>>>> 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(a)gmail.com&gt; wrote: >>>>>> >>>>>> >>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >>>>>> >>>>>>> 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(a)gmail.com&gt; wrote: >>>>>>> >>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >>>>>>> >>>>>>>> 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(a)gmail.com&gt; 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 <https://twitter.com/rmannibucau> | Blog >>>>>>>> <http://rmannibucau.wordpress.com> | Github >>>>>>>> <https://github.com/rmannibucau> | LinkedIn >>>>>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >>>>>>>> <http://www.tomitribe.com> >>>>>>>> >>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >>>>>>>> >>>>>>>>> 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(a)gmail.com&gt; 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 <https://twitter.com/rmannibucau> | Blog >>>>>>>>> <http://rmannibucau.wordpress.com> | Github >>>>>>>>> <https://github.com/rmannibucau> | LinkedIn >>>>>>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >>>>>>>>> <http://www.tomitribe.com> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> cdi-dev mailing list >>>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>> >>>>>>>>> Note that for all code provided on this list, the provider >>>>>>>>> licenses the code under the Apache License, Version 2 ( >>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>>>>> ideas provided on this list, the provider waives all patent and other >>>>>>>>> intellectual property rights inherent in such information. >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> cdi-dev mailing list >>>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>> >>>>>>>>> Note that for all code provided on this list, the provider >>>>>>>>> licenses the code under the Apache License, Version 2 ( >>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>>>>> ideas provided on this list, the provider waives all patent and other >>>>>>>>> intellectual property rights inherent in such information. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> >>>>>>>> Note that for all code provided on this list, the provider >>>>>>>> licenses the code under the Apache License, Version 2 ( >>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>>>> ideas provided on this list, the provider waives all patent and other >>>>>>>> intellectual property rights inherent in such information. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>>>> Note that for all code provided on this list, the provider licenses >>>>>>> the code under the Apache License, Version 2 ( >>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>>> ideas provided on this list, the provider waives all patent and other >>>>>>> intellectual property rights inherent in such information. >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses >>>>>> the code under the Apache License, Version 2 ( >>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>> ideas provided on this list, the provider waives all patent and other >>>>>> intellectual property rights inherent in such information. >>>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses >>>>> the code under the Apache License, Version 2 ( >>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>> ideas provided on this list, the provider waives all patent and other >>>>> intellectual property rights inherent in such information. >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses >>>> the code under the Apache License, Version 2 ( >>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>> provided on this list, the provider waives all patent and other >>>> intellectual property rights inherent in such information. >>>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.