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 | Blog | Github | LinkedIn | Tomitriber 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.

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 | Blog | Github | LinkedIn | Tomitriber >> >> 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.

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 >>>> >: >>>> >>> >>>> >>> 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 >>>> >: >>>> >>>>>>>> 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.

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. > >

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. >

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 >> > 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.

I am honestly not sure this will break much since the existing definition is sufficiently ambiguous. If we really have to have different semantics, it's far better to just have a flag on existing annotations rather than introduce a whole new mostly duplicate API set. On Mar 8, 2016, at 11:46 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: 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. > > _______________________________________________ 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.

On Mar 8, 2016, at 10: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 | Blog | Github | LinkedIn | Tomitriber > > 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 | Blog | Github | LinkedIn | Tomitriber >>> >>> 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 | Blog | Github | LinkedIn | Tomitriber >>>>>>> >>>>>>> 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.

On Mar 8, 2016, at 12:06 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: created https://issues.jboss.org/browse/CDI-587, I'm not sure if there is a public link to this thread but would be great to link it in the issue if possible. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-08 18:03 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: > You have it right. > > This is going to be hard enough for HTTP request but at least the Servlet container is fully in control of the underlying connection so determining when a request ends can be reliably detected. It's much harder for MDB, WebSocket, etc with async involved in possibly many Java EE APIs (but it's not impossible). > > That being said, just getting it working correctly for HTTP request is a huge step forward. > >> On Mar 8, 2016, at 10:55 AM, Stephan Knitelius <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 | Blog | Github | LinkedIn | Tomitriber >>> >>> 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 | Blog | Github | LinkedIn | Tomitriber >>>>> >>>>> 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 | Blog | Github | LinkedIn | Tomitriber >>>>>>>>> >>>>>>>>> 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.