[cdi-dev] inheritance of cdi scopes
Romain Manni-Bucau
rmannibucau at gmail.com
Sun Mar 6 15:06:59 EST 2016
2016-03-06 20:59 GMT+01:00 Reza Rahman <reza_rahman at 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 at gmail.com> 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 at gmail.com>
> wrote:
>
>> 2016-03-06 20:25 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
>>
>>> 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 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.
>>>
>> _______________________________________________
>> 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/99a1122f/attachment-0001.html
More information about the cdi-dev
mailing list