inheritance of cdi scopes

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Stephan Knitelius
Just as with any other scope, outside of conversation, developers would have to deal with these issues when using request scoped beans in asynchronous contexts.

All the more reason to introduce configurable @Singleton style concurrent access control.

Knitti
On So., 6. März 2016 at 23:24, Mark Struberg <[hidden email]> wrote:
Also keep in mind that the request scoped instances are mostly not thread safe.
Lg,
Strub

Am 06.03.2016 um 20:15 schrieb Romain Manni-Bucau <[hidden email]>:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

arjan tijms
In reply to this post by John D. Ament
On Sun, Mar 6, 2016 at 11:03 PM, John D. Ament <[hidden email]> wrote:
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 pretty sure that JEUS (from TMaxSoft) uses its own independent implementation. 




 

_______________________________________________
cdi-dev mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Stephan Knitelius
In reply to this post by Reza Rahman
Agree on should be mostly read-only thread safe operations.

In practice I have seen fair number of projects misuse request scope as a replacement for stateless session bean.

Knitti
On So., 6. März 2016 at 23:33, Reza Rahman <[hidden email]> wrote:
This is fair, although probably rare in practice. The utilities I do think mostly assume a read-only context that does not change from thread to thread.

On Mar 6, 2016, at 5:23 PM, Mark Struberg <[hidden email]> wrote:

Also keep in mind that the request scoped instances are mostly not thread safe.
Lg,
Strub

Am 06.03.2016 um 20:15 schrieb Romain Manni-Bucau <[hidden email]>:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Romain Manni-Bucau
In reply to this post by Reza Rahman


Le 6 mars 2016 21:30, "Reza Rahman" <[hidden email]> 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 <[hidden email]> wrote:
>
>>
>> 2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
>>>
>>> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>
>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
>>>>>>
>>>>>> 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 <[hidden email]> wrote:
>>>>>>
>>>>>>>
>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
>>>>>>>>
>>>>>>>> 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 <[hidden email]> wrote:
>>>>>>>>
>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
>>>>>>>>>>
>>>>>>>>>> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>>>>>>>>
>>>>>>>>>>>> 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 <[hidden email]> 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
>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>> 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
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>> [hidden email]
>>> 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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Reza Rahman
I've read through the spec page to page yet one more time. I don't see anything that suggests this is anything more than a bug in a likely poorly implemented RI and TCK. I'll test this case along with other things that should also work like the security, JNDI and EJB contexts.

I'll file bugs accordingly and see if I can get them fixed. I am unlikely to use this in a justification for a revision of EE concurrency. Frankly other than fixing the bugs and maybe adding a few more associated TCK tests I see no reason to change the spec text any further. It already states or implies that these things should be working. If we end up launching a revision I'll consider adding clarifying text as a low priority task.

For me, this is the end of the line on this one for now.

On Mar 6, 2016, at 5:50 PM, Romain Manni-Bucau <[hidden email]> wrote:


Le 6 mars 2016 21:30, "Reza Rahman" <[hidden email]> 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 <[hidden email]> wrote:
>
>>
>> 2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
>>>
>>> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>
>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
>>>>>>
>>>>>> 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 <[hidden email]> wrote:
>>>>>>
>>>>>>>
>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
>>>>>>>>
>>>>>>>> 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 <[hidden email]> wrote:
>>>>>>>>
>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
>>>>>>>>>>
>>>>>>>>>> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>>>>>>>>
>>>>>>>>>>>> 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 <[hidden email]> 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
>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>> 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
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>> [hidden email]
>>> 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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Mark Struberg
In reply to this post by arjan tijms
SAP is using owb afaik.

Lg,
Strub

Am 06.03.2016 um 23:34 schrieb arjan tijms <[hidden email]>:

On Sun, Mar 6, 2016 at 11:03 PM, John D. Ament <[hidden email]> wrote:
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 pretty sure that JEUS (from TMaxSoft) uses its own independent implementation. 




 
_______________________________________________
cdi-dev mailing list
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Mark Struberg
In reply to this post by Stephan Knitelius
Nope, @RequestScoped beans are in practice almost never thread safe. Think about request scoped EntityManagers etc. 

Lg,
Strub

Am 06.03.2016 um 23:40 schrieb Stephan Knitelius <[hidden email]>:

Agree on should be mostly read-only thread safe operations.

In practice I have seen fair number of projects misuse request scope as a replacement for stateless session bean.

Knitti
On So., 6. März 2016 at 23:33, Reza Rahman <[hidden email]> wrote:
This is fair, although probably rare in practice. The utilities I do think mostly assume a read-only context that does not change from thread to thread.

On Mar 6, 2016, at 5:23 PM, Mark Struberg <[hidden email]> wrote:

Also keep in mind that the request scoped instances are mostly not thread safe.
Lg,
Strub

Am 06.03.2016 um 20:15 schrieb Romain Manni-Bucau <[hidden email]>:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Mark Struberg
In reply to this post by John D. Ament
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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> wrote:
2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Reza Rahman
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> wrote:
2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Romain Manni-Bucau
"
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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> wrote:
2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Stephan Knitelius
>>"
>>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.   


On Mon, 7 Mar 2016 at 09:50 Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> wrote:
2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Romain Manni-Bucau

2016-03-07 11:27 GMT+01:00 Stephan Knitelius <[hidden email]>:
>>"
>>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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> wrote:
2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Reza Rahman
In reply to this post by Romain Manni-Bucau
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> wrote:
2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Romain Manni-Bucau
2016-03-07 14:06 GMT+01:00 Reza Rahman <[hidden email]>:
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.


It is not stated so not supported, that's the way EE works whatever you think (if you doubt just use any of the SHOULD features in 2 servers ;)).
 
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.


This is not the point. I'm for getting it done but the spec states the opposite since it ignores not submitting instances completely and it states that submitting ones are not expected to work very clearly in the previous quote (not being deterministic means it doesn't work).

However the issue is wider than concurrency-utilities so even if you manage to get it done for this spec users can still face this issue. If I follow a context start/stop API is possible for 2.0 so question is really: should this API get inheritance or not.
 
On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> wrote:
2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Reza Rahman
There are way too many cases I can cite of the spec saying something is optional but good implementations doing what is actually right. Even in the worst reading of this, that is exactly what is happening here.

On Mar 7, 2016, at 8:12 AM, Romain Manni-Bucau <[hidden email]> wrote:

2016-03-07 14:06 GMT+01:00 Reza Rahman <[hidden email]>:
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.


It is not stated so not supported, that's the way EE works whatever you think (if you doubt just use any of the SHOULD features in 2 servers ;)).
 
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.


This is not the point. I'm for getting it done but the spec states the opposite since it ignores not submitting instances completely and it states that submitting ones are not expected to work very clearly in the previous quote (not being deterministic means it doesn't work).

However the issue is wider than concurrency-utilities so even if you manage to get it done for this spec users can still face this issue. If I follow a context start/stop API is possible for 2.0 so question is really: should this API get inheritance or not.
 
On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> wrote:
2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Romain Manni-Bucau

2016-03-07 14:40 GMT+01:00 Reza Rahman <[hidden email]>:
There are way too many cases I can cite of the spec saying something is optional but good implementations doing what is actually right. Even in the worst reading of this, that is exactly what is happening here.


Reza take one day and re-read it with a not oriented eye: the spec states it shouldnt work. Let also ignore the concurrency utility for one moment since it covers only 50% of the cases and show me where the spec states it should be covered please.
 
On Mar 7, 2016, at 8:12 AM, Romain Manni-Bucau <[hidden email]> wrote:

2016-03-07 14:06 GMT+01:00 Reza Rahman <[hidden email]>:
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.


It is not stated so not supported, that's the way EE works whatever you think (if you doubt just use any of the SHOULD features in 2 servers ;)).
 
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.


This is not the point. I'm for getting it done but the spec states the opposite since it ignores not submitting instances completely and it states that submitting ones are not expected to work very clearly in the previous quote (not being deterministic means it doesn't work).

However the issue is wider than concurrency-utilities so even if you manage to get it done for this spec users can still face this issue. If I follow a context start/stop API is possible for 2.0 so question is really: should this API get inheritance or not.
 
On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> wrote:
2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Reza Rahman
I hate to tell you this, but I would recommend the same. I have read this many, many times over months because I think this is an important API. There is a big difference between pointing out possible issues with incorrect use of a feature and outright forbidding a feature. This is merely a warning on what could happen if a feature is misused.

On Mar 7, 2016, at 8:42 AM, Romain Manni-Bucau <[hidden email]> wrote:


2016-03-07 14:40 GMT+01:00 Reza Rahman <[hidden email]>:
There are way too many cases I can cite of the spec saying something is optional but good implementations doing what is actually right. Even in the worst reading of this, that is exactly what is happening here.


Reza take one day and re-read it with a not oriented eye: the spec states it shouldnt work. Let also ignore the concurrency utility for one moment since it covers only 50% of the cases and show me where the spec states it should be covered please.
 
On Mar 7, 2016, at 8:12 AM, Romain Manni-Bucau <[hidden email]> wrote:

2016-03-07 14:06 GMT+01:00 Reza Rahman <[hidden email]>:
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.


It is not stated so not supported, that's the way EE works whatever you think (if you doubt just use any of the SHOULD features in 2 servers ;)).
 
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.


This is not the point. I'm for getting it done but the spec states the opposite since it ignores not submitting instances completely and it states that submitting ones are not expected to work very clearly in the previous quote (not being deterministic means it doesn't work).

However the issue is wider than concurrency-utilities so even if you manage to get it done for this spec users can still face this issue. If I follow a context start/stop API is possible for 2.0 so question is really: should this API get inheritance or not.
 
On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> wrote:
2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:


2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> wrote:

2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Mark Struberg
In reply to this post by Reza Rahman
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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]>:
>> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>
>>>>>>
>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman <[hidden email]>:
>>>>>> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman <[hidden email]>:
>>>>>>> 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 <[hidden email]> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman <[hidden email]>:
>>>>>>>> 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 <[hidden email]> wrote:
>>>>>>>>
>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman <[hidden email]>:
>>>>>>>>> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>>>>>> 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 <[hidden email]> 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
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> 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
>>>>>>>>> [hidden email]
>>>>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> 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
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> 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
>>>> [hidden email]
>>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Mark Struberg
In reply to this post by Romain Manni-Bucau

> Am 07.03.2016 um 14:12 schrieb Romain Manni-Bucau <[hidden email]>:
>
> This is not the point. I'm for getting it done but the spec states the opposite since it ignores not submitting instances completely and it states that submitting ones are not expected to work very clearly in the previous quote (not being deterministic means it doesn't work).


Romain has a point :/
It’s not just left out, it seems to be explicitly marked as non-portable.
That should be amended in the concurrency-utils spec.
And even better: it should explicitly be defined that @RequestScoped works.
Of course I can live with all vendors agree that it should work. Better than nothing.

LieGrue,
strub
_______________________________________________
cdi-dev mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance of cdi scopes

Reza Rahman
I've already noted this to the JIRA for the issue. If we can we will add it as further clarification. I don't think it's a necessary step to moving forward.

> On Mar 7, 2016, at 10:09 AM, Mark Struberg <[hidden email]> wrote:
>
>
>> Am 07.03.2016 um 14:12 schrieb Romain Manni-Bucau <[hidden email]>:
>>
>> This is not the point. I'm for getting it done but the spec states the opposite since it ignores not submitting instances completely and it states that submitting ones are not expected to work very clearly in the previous quote (not being deterministic means it doesn't work).
>
>
> Romain has a point :/
> It’s not just left out, it seems to be explicitly marked as non-portable.
> That should be amended in the concurrency-utils spec.
> And even better: it should explicitly be defined that @RequestScoped works.
> Of course I can live with all vendors agree that it should work. Better than nothing.
>
> LieGrue,
> strub
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> 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
[hidden email]
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.
123