[cdi-dev] inheritance of cdi scopes
John D. Ament
john.d.ament at gmail.com
Sun Mar 6 16:23:35 EST 2016
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/ContextService.html
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 at lycos.com> 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 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 <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.
>>
>
> _______________________________________________
> 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/79a34729/attachment-0001.html
More information about the cdi-dev
mailing list