[cdi-dev] inheritance of cdi scopes
Romain Manni-Bucau
rmannibucau at gmail.com
Mon Mar 7 05:30:29 EST 2016
2016-03-07 11:27 GMT+01:00 Stephan Knitelius <stephan at knitelius.com>:
> >>"
> >>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?
>
> Sounds more like a warning that the CDI context may be destroyed prior to
> completion of the asynchronous task. Therefor we might be able to clear
> this up on the CDI side, by keeping contexts alive as long as they are
> associated with > 1 executing threads.
>
>
means the context is not bound to (controlled by) this thread so the
behavior is undefined. Also this *only* converns submitted tasks and not
injections used inside the task so:
es.submit(() -> { reqScopedInstance.doSomeWork(); }); is not under this
statement at all.
>
> On Mon, 7 Mar 2016 at 09:50 Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>> "
>> 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.
>>>
>>
>> _______________________________________________
>> 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/850fb65a/attachment-0001.html
More information about the cdi-dev
mailing list