[cdi-dev] inheritance of cdi scopes

Sun Mar 6 17:50:45 EST 2016

Le 6 mars 2016 21:30, "Reza Rahman" <reza_rahman at lycos.com> a écrit :
>
> Have you actually looked at the EE concurrency spec text in detail? What
does it say about managed component context propagation?
>

Yep

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

Not sure where you go with that. Even if you want ro read - which is more
than ambiguous and up to impl so not portable in any case - that request
context is correctly handled, same use case is broken if you keep the
servlet synchronous and trigger an async task from there using CU. There
CDI clearly states the request scope is destroyed and in practise likely
before the async task ends so the issue is real.

> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
wrote:
>
>>
>> 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 |  Blog | Github | LinkedIn | Tomitriber
>>>>>>>>>>>
>>>>>>>>>>> 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 |  Blog | Github | LinkedIn | Tomitriber
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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.
>>
>>
>
> _______________________________________________
> 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/bba61c6a/attachment-0001.html 