Re: [cdi-dev] inheritance of cdi scopes

This is fair, although probably rare in practice. The utilities I do think mostly assume a read-only context that does not change from thread to thread. On Mar 6, 2016, at 5:23 PM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: Also keep in mind that the request scoped instances are mostly not thread safe. Lg, Strub Am 06.03.2016 um 20:15 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: 2016-03-06 19:42 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: > This frankly surprises me. I'll check the specification text. This might > indeed just be an implementation bug. The EE concurrency utilities are > supposed to be copying all relevant context. If this is an issue than it > has to be that it is not copying enough of the HTTP request context for CDI > to work. > > The issue is not technical since I got it working but needed to reverse. From my understanding ee concurrency utilities was done in a time CDI was not there so it just ignored it somehow and it hasnt been updated when integrated to the spec. Now with the wording of the CDI - and TCK - it is impossible to make it working since request scope is bound the thre request thread - and not the request. Side note: same applies to session scope and conversation. > Surely the Red Hat folks can quickly shed some light here since they > implement essentially this whole stack? > > On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; > wrote: > > 2016-03-06 19:20 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: > >> Can you kindly try to make the example a bit simpler? It's important to >> make the case for how likely this is supposed to occur in most business >> applications. >> >> Also, other than making sure that the executor service is propagating >> thread local request contexts correctly what other solution are you >> proposing? Did you check the specification? How sure are you that this >> isn't simply an implementation bug? >> >> As far as I know the executor service is supposed to be preserving all >> relevant parts of the EE context? >> >> > Not in concurrency-utilities for EE at least. That was the first impl I > did then Mark pointed out it was violating CDI spec and request scope > definition. There is a kind of contracdiction there cause > concurrency-utilities doesn't integrate with CDI at all but we can also see > it the opposite way: CDI doesn't provide any way to propagate a context in > another thread. Both point of view are valid so we need to see where we > tackle it. > > >> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; >> wrote: >> >> does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help? >> >> Idea is to give an API to make: >> >> public void complete() { >> try { >> asyncContext.complete(); >> } finally { >> auditContext.end(); >> } >> } >> >> working without hacky and almost impossible context pushing (cause of >> injections nature you are not supposed to know what to push in the context >> when going async). >> >> >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <http://rmannibucau.wordpress.com> | Github >> <https://github.com/rmannibucau> | LinkedIn >> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >> <http://www.tomitribe.com> >> >> 2016-03-06 16:40 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >> >>> Can you kindly share an annotated code example of the proposed solution >>> so we can all follow and discuss this? >>> >>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; >>> wroteshar: >>> >>> Hi guys, >>> >>> spoke on concurrency utilities about the ability to inherit a cdi >>> scope. Idea is to follow request scope more than cdi spec allows. First >>> thought it was a concurrency utilities thing but Reza mentionned can be a >>> CDI one so here it is. >>> >>> Sample: >>> In a servlet i get MyBean which is @RequestScoped, I do some set on it. >>> The i go async (AsyncContext) and trigger a task in another thread. It >>> would be neat - and mandatory in some case by the loose coupling nature of >>> CDI - to get the *same* MyBean *instance* in this thread. With a direct >>> dependency you can easily use message passing pattern - but you loose the >>> loose coupling cause you need to know until which level you unwrap, think t >>> principal case which has 2-3 proxies!. However in practice you have a lot >>> of undirect dependencies, in particular with enterprise concerns (auditing, >>> security...) so you can't really do it easily/naturally. >>> >>> Bonus: >>> One very verbose way is to be able to kind of push/pop an existing >>> context in a thread - wrappers doing it on a Runnable/Consumer/Function/... >>> would be neat. >>> >>> Question: >>> Would CDI handle it in 2.0? >>> >>> Side note: this is really about the fact to reuse a "context context" >>> (its current instances map) in another thread the more transparently >>> possible and match the user vision more than a technical question for now. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >>> <http://www.tomitribe.com> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.