Even in the most conservative reading of this, the spec is clearly not disallowing it.
On Mar 7, 2016, at 10:05 AM, Mark Struberg <struberg(a)yahoo.de>
wrote:
The question is whether the spec does allow us to do it. And if other containers
consequently do it as well.
If it does then I will implement it in TomEE.
LieGrue,
strub
> Am 07.03.2016 um 14:06 schrieb Reza Rahman <reza_rahman(a)lycos.com>:
>
> What this is saying is that it is not recommended to use them because of the possible
life-cycle mismatch. If they are not supposed to work at all, the specification would have
simply stated it won't work.
>
> Anyway personally I have no reason to further discuss this. I'm going to try to
find a way to get this done for developers sooner rather than later. If TomEE does not
want to do it, too bad for developers.
>
>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau <rmannibucau(a)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 | Blog | Github | LinkedIn | Tomitriber
>>
>> 2016-03-07 5:57 GMT+01:00 Reza Rahman <reza_rahman(a)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(a)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(a)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(a)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(a)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/ContextSe...
>>>>>
>>>>> 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(a)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(a)gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman
<reza_rahman(a)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(a)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(a)gmail.com> wrote:
>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman
<reza_rahman(a)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(a)gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman
<reza_rahman(a)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(a)gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman
<reza_rahman(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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.