Re: [cdi-dev] RequestScope Life Cycle

is a flag an option? @RequestScoped(inherited = true) 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 17:44 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; : > 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 <rmannibucau(a)gmail.com&gt; > 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 <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 17:00 GMT+01:00 Paul Benedict <pbenedict(a)apache.org&gt;: >> >>> 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&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 | 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. >>>> >>> >>> >> _______________________________________________ >> 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. > >