Re: [cdi-dev] RequestScope Life Cycle

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(a)knitelius.com&gt; 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 <rmannibucau(a)gmail.com&gt; > 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 <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-08 16:21 GMT+01:00 Stephan Knitelius <stephan(a)knitelius.com&gt;: >> >>> >>> >>> 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(a)gmail.com&gt; >>> wrote: >>> >>>> will try to not hijack this thread and create another one for thread >>>> scope ;). >>>> >>>> >>>> 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-08 14:30 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >>>> >>>>> 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(a)gmail.com&gt; >>>>> wrote: >>>>> >>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >>>>> >>>>>> 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(a)gmail.com&gt; 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 <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-08 13:33 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >>>>>> >>>>>>> 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 <arjan.tijms(a)gmail.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman <reza_rahman(a)lycos.com&gt; >>>>>>> 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(a)lycos.com&gt; >>>>>>>> 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(a)yahoo.de&gt; >>>>>>>> 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(a)lycos.com&gt;: >>>>>>>> >>> >>>>>>>> >>> 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(a)gmail.com&gt; 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(a)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(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 | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> 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 | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>> >>>>>>>>>>>>> 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. >>>>>>>> >> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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. >