[cdi-dev] inheritance of cdi scopes

Sun Mar 6 14:45:24 EST 2016

So what's stopping us from allowing request scope propagation?

Alternatively we could introduce a new scope sharing state for all
asynchronous threads that where spawned within a request,
@AsynchronousScoped?

Thereby request scope could remain bound to the thread.
On So., 6. März 2016 at 20:26, Reza Rahman <reza_rahman at lycos.com> wrote:

> 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.
>
> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>
> 2016-03-06 19:42 GMT+01:00 Reza Rahman <reza_rahman at 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 at gmail.com>
>> wrote:
>>
>> 2016-03-06 19:20 GMT+01:00 Reza Rahman <reza_rahman at 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 at gmail.com>
>>> 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 at lycos.com>:
>>>
>>>> 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 at gmail.com>
>>>> 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 at 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 at 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 at 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 at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/d3c49db3/attachment.html 