[cdi-dev] inheritance of cdi scopes
Romain Manni-Bucau
rmannibucau at gmail.com
Mon Mar 7 03:49:23 EST 2016
"
Tasks that are submitted to a managed instance of ExecutorService may still
be running after the lifecycle of the submitting component. Therefore, CDI
beans with a scope of @RequestScoped, @SessionScoped, or
@ConversationScoped are not recommended to use as tasks as it cannot be
guaranteed that the tasks will complete before the CDI context is
destroyed.
"
States that the context is not inherited, is that what you mean?
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-07 5:57 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
> The specification currently references pretty much all the major CDI
> scopes specifically with the issue of propagation and lifecycle in mind.
> Please see section 2.3.
>
> On Mar 6, 2016, at 11:53 PM, Mark Struberg <struberg at yahoo.de> wrote:
> Specifically
>
> The containers mimic ejb for propagation for a good reason!
> No session e.g. , new TX, etc
>
> Sadly the concurrency utilis only mention @ApplicationScoped, so the
> Request Context not only doesn't get propagated (which is good), but also
> doesn't get set up (which is crap).
>
> LieGrue,
> Strub
>
> Am 06.03.2016 um 23:03 schrieb John D. Ament <john.d.ament at gmail.com>:
>
> I agree, in a sense, with what you're saying. There's nothing in this
> spec that says it wouldn't be propagated. However, there's nothing in this
> spec that states clearly that CDI contexts are propagated.
>
> If you look at the RI, the RI only seems to propagate transaction state.
> Considering the age of the spec, I'm not surprised to see that. The worst
> part is that right now, outside of the ASF, all other EE7 impls seem to be
> using the RI for concurrency.
>
> I'm fairly certain that from this spec's standpoint, the only thing that's
> actually propagated is the transaction.
>
> John
>
> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman <reza_rahman at lycos.com> wrote:
>
>> I am re-reading the spec end to end again right now. So far it seems I
>> have remembered everything correctly.
>>
>> You should read over section 2.3. What it is saying is that a container
>> implementing the Java EE concurrency utilities should ensure whatever
>> contextual information is needed for managed components to work correctly
>> should be propagated automatically. For the correct implementation of CDI
>> scopes, this should also mean any currently active scopes. The section you
>> are referring to is basically implying that thinking that it is possible to
>> use these scoped beans in tasks (albeit not reliably since beans could go
>> out of scope before the thread finishes - for example if the request ends).
>>
>> This does not have anything to do with the context service per se. The
>> context service is an SPI of sorts to allow end user developers to do for
>> their own applications what the container does behind the scenes for
>> managed component context propagation.
>>
>> I'll read over the entire spec to see if there is anything to contradict
>> this. If that's not the case what Romain is describing is most likely an
>> implementation specific bug that did not take into account CDI scope
>> propagation.
>>
>> On Mar 6, 2016, at 4:23 PM, John D. Ament <john.d.ament at gmail.com> wrote:
>>
>> 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.
>>
>> _______________________________________________
>> 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/20160307/e93640e1/attachment-0001.html
More information about the cdi-dev
mailing list