Re: [cdi-dev] RequestScope Life Cycle

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