[cdi-dev] RequestScope Life Cycle
Romain Manni-Bucau
rmannibucau at gmail.com
Tue Mar 8 12:11:59 EST 2016
Thanks Reza
updated the jira
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
2016-03-08 18:08 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
> You can get a link from the CDI spec site. Just browse.
>
> Sent from my iPhone
>
> On Mar 8, 2016, at 12:06 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
> created https://issues.jboss.org/browse/CDI-587, I'm not sure if there is
> a public link to this thread but would be great to link it in the issue if
> possible.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2016-03-08 18:03 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
>
>> You have it right.
>>
>> This is going to be hard enough for HTTP request but at least the Servlet
>> container is fully in control of the underlying connection so determining
>> when a request ends can be reliably detected. It's much harder for MDB,
>> WebSocket, etc with async involved in possibly many Java EE APIs (but it's
>> not impossible).
>>
>> That being said, just getting it working correctly for HTTP request is a
>> huge step forward.
>>
>> On Mar 8, 2016, at 10:55 AM, Stephan Knitelius <stephan at knitelius.com>
>> wrote:
>>
>> I am not sure I am following you 100%.
>>
>> For me a request is anything which comes into the context of the
>> application. No matter if it comes in via Servlet, WebSockets, JMS, Remote
>> EJB, etc...
>>
>> The request scope should be propagated to all asynchronous operations
>> launched within that call, terminating it when all request associated
>> asynchronous operations are completed.
>>
>> Knitti
>>
>>
>>
>> On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau <rmannibucau at gmail.com>
>> wrote:
>>
>>> Yes (just making clear it is servlet related asynchronism - ie
>>> AsyncContext#complete() is called and listeners are completed - to avoid
>>> the ambiguity of @Async, JMS etc.. where request scope is now)
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> <http://rmannibucau.wordpress.com> | Github
>>> <https://github.com/rmannibucau> | LinkedIn
>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>> <http://www.tomitribe.com>
>>>
>>> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius <stephan at knitelius.com>:
>>>
>>>>
>>>>
>>>> So the proposal would be to enable propagation of request scope to
>>>> asynchronous threads and keep it alive until all concurrent processes
>>>> referencing it are completed?
>>>>
>>>> On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau <rmannibucau at gmail.com>
>>>> wrote:
>>>>
>>>>> will try to not hijack this thread and create another one for thread
>>>>> scope ;).
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>>>> <http://rmannibucau.wordpress.com> | Github
>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>>> <http://www.tomitribe.com>
>>>>>
>>>>> 2016-03-08 14:30 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
>>>>>
>>>>>> Your mention of thread local scope is interesting indeed. We had just
>>>>>> such a scope in Resin called @ThreadScoped, completely separate from
>>>>>> @RequestScoped. As memory serves though even in Resin we basically
>>>>>> implemented @RequestScoped as thread local scope.
>>>>>>
>>>>>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> 2016-03-08 14:08 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
>>>>>>
>>>>>>> I never assume anything related to HTTP requests are ever thread
>>>>>>> safe. I don't know many folks that would make that assumption either. I
>>>>>>> think this consideration is not a significant one. The spec, docs and
>>>>>>> tutorials out there are pretty clear about the fact that none of the CDI
>>>>>>> scopes are really thread safe in the way EJBs are.
>>>>>>>
>>>>>>>
>>>>>> It is one of the main usage of request scoped in practise. It doesn't
>>>>>> come from HTTP side but since it is used this way in several other places
>>>>>> (like batch) it is now assumed everywhere. It has even been promoted by
>>>>>> several CDI projects so sadly it is to be taken into account now even if I
>>>>>> agree it is not the state we should be at today. If changed - servlet
>>>>>> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I
>>>>>> guess CDI can work on this - it should be made very explicit in the spec
>>>>>> and we should study a "thread local scope" replacement to fill the gap and
>>>>>> propose a solution to this practise judged abusive.
>>>>>>
>>>>>>
>>>>>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau <
>>>>>>> rmannibucau at gmail.com> wrote:
>>>>>>>
>>>>>>> In TomEE we restart/stop it around most of hooks including the
>>>>>>> runnable passed to start(Runnable) of the AsyncContext but keeping the now
>>>>>>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the
>>>>>>> startAsync() call sadly). This passes CDI TCK but for the particular
>>>>>>> request scope I would be happy to clarify it is actually bound to the
>>>>>>> request and just reuse the same instances. In term of side effects it would
>>>>>>> breaks the current thread safety users assume (with reason or not) but I
>>>>>>> have no real clue if it would really breaks apps or not.
>>>>>>>
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>>>>>> <http://rmannibucau.wordpress.com> | Github
>>>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>>>>> <http://www.tomitribe.com>
>>>>>>>
>>>>>>> 2016-03-08 13:33 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
>>>>>>>
>>>>>>>> Let's hope some of the implementors weigh in on this some time soon.
>>>>>>>>
>>>>>>>> I could write some tests on this but I would have no idea if I
>>>>>>>> would have uncovered a bug given the ambiguity of the current spec text.
>>>>>>>>
>>>>>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms <arjan.tijms at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman <reza_rahman at lycos.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Reading over the CDI spec definition for request scoped beans, I
>>>>>>>>> am a tad confused. When are request scoped beans being destroyed right now?
>>>>>>>>> Are they just bound to the Servlet request thread and destroyed as soon as
>>>>>>>>> the service method returns?
>>>>>>>>
>>>>>>>>
>>>>>>>> In case of a Servlet request (request scoped beans are also tied to
>>>>>>>> other kinds of "requests"), it's indeed not clear. In practice it looks
>>>>>>>> like the moment between the first ServletRequestListener#requestInitialized
>>>>>>>> and ServletRequestListener#requestDestroyed.
>>>>>>>>
>>>>>>>> The exact scope is troublesome for security too, since in most
>>>>>>>> severs the request scope (and session scope and application scope) is
>>>>>>>> active when a SAM is called (the SAM gets an HttpServletRequest after all),
>>>>>>>> but this is not the case in all servers. E.g. in Liberty the RequestScope
>>>>>>>> starts AFTER a SAM is called.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Arjan Tijms
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> In case of asynchronous Servlets, are they kept around until the
>>>>>>>>> real HTTP request actually completes the same way the underlying HTTP
>>>>>>>>> connection is kept around? Or is that too difficult because it would
>>>>>>>>> require integration at a very low level with the Servlet implementation?
>>>>>>>>>
>>>>>>>>> There's some language around asynchronous completion right now but
>>>>>>>>> it's not very clear what actually happens. Does the onComplete, etc
>>>>>>>>> asynchronous callback basically create new request scoped instances?
>>>>>>>>>
>>>>>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman <reza_rahman at lycos.com>
>>>>>>>>> wrote:
>>>>>>>>> >
>>>>>>>>> > Even in the most conservative reading of this, the spec is
>>>>>>>>> clearly not disallowing it.
>>>>>>>>> >
>>>>>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg <struberg at yahoo.de>
>>>>>>>>> wrote:
>>>>>>>>> >>
>>>>>>>>> >> The question is whether the spec does allow us to do it. And if
>>>>>>>>> other containers consequently do it as well.
>>>>>>>>> >>
>>>>>>>>> >> If it does then I will implement it in TomEE.
>>>>>>>>> >>
>>>>>>>>> >> LieGrue,
>>>>>>>>> >> strub
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman <
>>>>>>>>> reza_rahman at lycos.com>:
>>>>>>>>> >>>
>>>>>>>>> >>> What this is saying is that it is not recommended to use them
>>>>>>>>> because of the possible life-cycle mismatch. If they are not supposed to
>>>>>>>>> work at all, the specification would have simply stated it won't work.
>>>>>>>>> >>>
>>>>>>>>> >>> Anyway personally I have no reason to further discuss this.
>>>>>>>>> I'm going to try to find a way to get this done for developers sooner
>>>>>>>>> rather than later. If TomEE does not want to do it, too bad for developers.
>>>>>>>>> >>>
>>>>>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau <
>>>>>>>>> rmannibucau at gmail.com> wrote:
>>>>>>>>> >>>>
>>>>>>>>> >>>> "
>>>>>>>>> >>>> Tasks that are submitted to a managed instance of
>>>>>>>>> ExecutorService may still be running after the lifecycle of the submitting
>>>>>>>>> component. Therefore, CDI beans with a scope of @RequestScoped,
>>>>>>>>> @SessionScoped, or @ConversationScoped are not recommended to use as tasks
>>>>>>>>> as it cannot be guaranteed that the tasks will complete before the CDI
>>>>>>>>> context is destroyed.
>>>>>>>>> >>>> "
>>>>>>>>> >>>>
>>>>>>>>> >>>> States that the context is not inherited, is that what you
>>>>>>>>> mean?
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> Romain Manni-Bucau
>>>>>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
>>>>>>>>> >>>>
>>>>>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman <reza_rahman at lycos.com
>>>>>>>>> >:
>>>>>>>>> >>>> The specification currently references pretty much all the
>>>>>>>>> major CDI scopes specifically with the issue of propagation and lifecycle
>>>>>>>>> in mind. Please see section 2.3.
>>>>>>>>> >>>>
>>>>>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg <
>>>>>>>>> struberg at yahoo.de> wrote:
>>>>>>>>> >>>>> Specifically
>>>>>>>>> >>>>> The containers mimic ejb for propagation for a good reason!
>>>>>>>>> >>>>> No session e.g. , new TX, etc
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Sadly the concurrency utilis only mention
>>>>>>>>> @ApplicationScoped, so the Request Context not only doesn't get propagated
>>>>>>>>> (which is good), but also doesn't get set up (which is crap).
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> LieGrue,
>>>>>>>>> >>>>> Strub
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament <
>>>>>>>>> john.d.ament at gmail.com>:
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> I agree, in a sense, with what you're saying. There's
>>>>>>>>> nothing in this spec that says it wouldn't be propagated. However, there's
>>>>>>>>> nothing in this spec that states clearly that CDI contexts are propagated.
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> If you look at the RI, the RI only seems to propagate
>>>>>>>>> transaction state. Considering the age of the spec, I'm not surprised to
>>>>>>>>> see that. The worst part is that right now, outside of the ASF, all other
>>>>>>>>> EE7 impls seem to be using the RI for concurrency.
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the
>>>>>>>>> only thing that's actually propagated is the transaction.
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> John
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman <
>>>>>>>>> reza_rahman at lycos.com> wrote:
>>>>>>>>> >>>>>> I am re-reading the spec end to end again right now. So far
>>>>>>>>> it seems I have remembered everything correctly.
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> You should read over section 2.3. What it is saying is that
>>>>>>>>> a container implementing the Java EE concurrency utilities should ensure
>>>>>>>>> whatever contextual information is needed for managed components to work
>>>>>>>>> correctly should be propagated automatically. For the correct
>>>>>>>>> implementation of CDI scopes, this should also mean any currently active
>>>>>>>>> scopes. The section you are referring to is basically implying that
>>>>>>>>> thinking that it is possible to use these scoped beans in tasks (albeit not
>>>>>>>>> reliably since beans could go out of scope before the thread finishes - for
>>>>>>>>> example if the request ends).
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> This does not have anything to do with the context service
>>>>>>>>> per se. The context service is an SPI of sorts to allow end user developers
>>>>>>>>> to do for their own applications what the container does behind the scenes
>>>>>>>>> for managed component context propagation.
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> I'll read over the entire spec to see if there is anything
>>>>>>>>> to contradict this. If that's not the case what Romain is describing is
>>>>>>>>> most likely an implementation specific bug that did not take into account
>>>>>>>>> CDI scope propagation.
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament <
>>>>>>>>> john.d.ament at gmail.com> wrote:
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> Reza,
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> I read through the concurrency utils spec. Was there a
>>>>>>>>> specific section you had in mind? The only references to CDI were near the
>>>>>>>>> beginning warning users to not use Request/Session scoped beans as tasks
>>>>>>>>> since the outer most context may be destroyed before the work is done.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> I have a feeling what you're referring to is the context
>>>>>>>>> service:
>>>>>>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> If that's the case, then basically this should work OOTB
>>>>>>>>> right?
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> Task task = new MyTask();
>>>>>>>>> >>>>>>> task = contextService.createContextualProxy(task,
>>>>>>>>> Task.class);
>>>>>>>>> >>>>>>> executor.submit(task);
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> // now magically the context should be prop'd?
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> Is that about right?
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> John
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman <
>>>>>>>>> reza_rahman at lycos.com> wrote:
>>>>>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text
>>>>>>>>> in detail? What does it say about managed component context propagation?
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> Without actually doing that further discussing this is
>>>>>>>>> just taking shots in the dark. As an implementer it should not surprise you
>>>>>>>>> that this might simply be a bug because the person implementing the
>>>>>>>>> concurrency utilities for the EE runtime was not told about what to copy
>>>>>>>>> over into the new thread for CDI to work correctly.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau <
>>>>>>>>> rmannibucau at gmail.com> wrote:
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman <
>>>>>>>>> reza_rahman at lycos.com>:
>>>>>>>>> >>>>>>>> As far as I know this is precisely the sort of thing that
>>>>>>>>> the EE concurrency spec is intended for. It is supposed to copy over
>>>>>>>>> everything from the underlying thread local context into the new thread for
>>>>>>>>> all EE managed components to function. Since CDI beans are also EE
>>>>>>>>> container managed, it also applies to CDI beans as well. The EE vendor is
>>>>>>>>> supposed to make sure this works properly.
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> I don't think the concurrency utilities specifically
>>>>>>>>> lists APIs for which thread context propagation should work. If this
>>>>>>>>> doesn't work in a specific implementation it's most likely because they
>>>>>>>>> didn't take CDI into account in their own EE concurrency implementation.
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> That's what I wanted/would like. CDI TCK breaks it quite
>>>>>>>>> easily and @RequestScoped which is *used* today is sadly a
>>>>>>>>> @ThreadLocalScoped badly named. So to solve it we would need another scope
>>>>>>>>> as I mentionned several times on this list 100% matching servlet instances
>>>>>>>>> lifecycles (on a pure CDI side we have the same issue for sessions which
>>>>>>>>> are recycled during a request, the session scope is corrupted *by spec* in
>>>>>>>>> term of user behavior).
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>>> On Mar 6, 2016, at 2:45 PM, John D. Ament <
>>>>>>>>> john.d.ament at gmail.com> wrote:
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> The section of the spec you link to makes no references
>>>>>>>>> to threads. 6.3 makes some notes about normal scopes and threads, and
>>>>>>>>> specifically says that a context is bound to one or more threads.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> I think what's happened is that over the years, people
>>>>>>>>> have simply bound HTTP Request == single thread, but when async processing
>>>>>>>>> was introduced no one thought to clarify that the spawning of a child
>>>>>>>>> thread from the original HTTP request retains the parent's context.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> This is another requested feature, but looks more like a
>>>>>>>>> bug or gap in the spec.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> John
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau <
>>>>>>>>> rmannibucau at gmail.com> wrote:
>>>>>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman <
>>>>>>>>> reza_rahman at lycos.com>:
>>>>>>>>> >>>>>>>>> Let's see. I suspect the specification text for EE
>>>>>>>>> concurrency is generic enough for implementations to also be able to cover
>>>>>>>>> CDI scopes or any other Java EE API context propagation needs. This means
>>>>>>>>> the issue needs to be solved at the individual implementation level.
>>>>>>>>> Changing anything in the spec is probably just unnecessary ceremony in this
>>>>>>>>> case.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> Then 1. concurrency- utility can't be reliable for "EE"
>>>>>>>>> users, 2. CDI still prevent it to work since it would violate the spec to
>>>>>>>>> propagate it while request scope is bound to another thread (
>>>>>>>>> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context
>>>>>>>>> handles async listener but not the main AsyncContext part).
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>>> On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau <
>>>>>>>>> rmannibucau at gmail.com> wrote:
>>>>>>>>> >>>>>>>>>>
>>>>>>>>> >>>>>>>>>>
>>>>>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman <
>>>>>>>>> reza_rahman at lycos.com>:
>>>>>>>>> >>>>>>>>>> This frankly surprises me. I'll check the specification
>>>>>>>>> text. This might indeed just be an implementation bug. The EE concurrency
>>>>>>>>> utilities are supposed to be copying all relevant context. If this is an
>>>>>>>>> issue than it has to be that it is not copying enough of the HTTP request
>>>>>>>>> context for CDI to work.
>>>>>>>>> >>>>>>>>>>
>>>>>>>>> >>>>>>>>>>
>>>>>>>>> >>>>>>>>>> The issue is not technical since I got it working but
>>>>>>>>> needed to reverse. From my understanding ee concurrency utilities was done
>>>>>>>>> in a time CDI was not there so it just ignored it somehow and it hasnt been
>>>>>>>>> updated when integrated to the spec. Now with the wording of the CDI - and
>>>>>>>>> TCK - it is impossible to make it working since request scope is bound the
>>>>>>>>> thre request thread - and not the request. Side note: same applies to
>>>>>>>>> session scope and conversation.
>>>>>>>>> >>>>>>>>>>
>>>>>>>>> >>>>>>>>>> Surely the Red Hat folks can quickly shed some light
>>>>>>>>> here since they implement essentially this whole stack?
>>>>>>>>> >>>>>>>>>>
>>>>>>>>> >>>>>>>>>>> On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau <
>>>>>>>>> rmannibucau at gmail.com> wrote:
>>>>>>>>> >>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman <
>>>>>>>>> reza_rahman at lycos.com>:
>>>>>>>>> >>>>>>>>>>> Can you kindly try to make the example a bit simpler?
>>>>>>>>> It's important to make the case for how likely this is supposed to occur in
>>>>>>>>> most business applications.
>>>>>>>>> >>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>> Also, other than making sure that the executor service
>>>>>>>>> is propagating thread local request contexts correctly what other solution
>>>>>>>>> are you proposing? Did you check the specification? How sure are you that
>>>>>>>>> this isn't simply an implementation bug?
>>>>>>>>> >>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>> As far as I know the executor service is supposed to
>>>>>>>>> be preserving all relevant parts of the EE context?
>>>>>>>>> >>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>> Not in concurrency-utilities for EE at least. That was
>>>>>>>>> the first impl I did then Mark pointed out it was violating CDI spec and
>>>>>>>>> request scope definition. There is a kind of contracdiction there cause
>>>>>>>>> concurrency-utilities doesn't integrate with CDI at all but we can also see
>>>>>>>>> it the opposite way: CDI doesn't provide any way to propagate a context in
>>>>>>>>> another thread. Both point of view are valid so we need to see where we
>>>>>>>>> tackle it.
>>>>>>>>> >>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau <
>>>>>>>>> rmannibucau at gmail.com> wrote:
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>> does
>>>>>>>>> https://gist.github.com/rmannibucau/d55fce47b001185dca3e help?
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>> Idea is to give an API to make:
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>> public void complete() {
>>>>>>>>> >>>>>>>>>>>> try {
>>>>>>>>> >>>>>>>>>>>> asyncContext.complete();
>>>>>>>>> >>>>>>>>>>>> } finally {
>>>>>>>>> >>>>>>>>>>>> auditContext.end();
>>>>>>>>> >>>>>>>>>>>> }
>>>>>>>>> >>>>>>>>>>>> }
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>> working without hacky and almost impossible context
>>>>>>>>> pushing (cause of injections nature you are not supposed to know what to
>>>>>>>>> push in the context when going async).
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> >>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>> 2016-03-06 16:40 GMT+01:00 Reza Rahman <
>>>>>>>>> reza_rahman at lycos.com>:
>>>>>>>>> >>>>>>>>>>>> Can you kindly share an annotated code example of the
>>>>>>>>> proposed solution so we can all follow and discuss this?
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>> On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau <
>>>>>>>>> rmannibucau at gmail.com> wroteshar:
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>>> Hi guys,
>>>>>>>>> >>>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>>> spoke on concurrency utilities about the ability to
>>>>>>>>> inherit a cdi scope. Idea is to follow request scope more than cdi spec
>>>>>>>>> allows. First thought it was a concurrency utilities thing but Reza
>>>>>>>>> mentionned can be a CDI one so here it is.
>>>>>>>>> >>>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>>> Sample:
>>>>>>>>> >>>>>>>>>>>>> In a servlet i get MyBean which is @RequestScoped, I
>>>>>>>>> do some set on it. The i go async (AsyncContext) and trigger a task in
>>>>>>>>> another thread. It would be neat - and mandatory in some case by the loose
>>>>>>>>> coupling nature of CDI - to get the *same* MyBean *instance* in this
>>>>>>>>> thread. With a direct dependency you can easily use message passing pattern
>>>>>>>>> - but you loose the loose coupling cause you need to know until which level
>>>>>>>>> you unwrap, think t principal case which has 2-3 proxies!. However in
>>>>>>>>> practice you have a lot of undirect dependencies, in particular with
>>>>>>>>> enterprise concerns (auditing, security...) so you can't really do it
>>>>>>>>> easily/naturally.
>>>>>>>>> >>>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>>> Bonus:
>>>>>>>>> >>>>>>>>>>>>> One very verbose way is to be able to kind of
>>>>>>>>> push/pop an existing context in a thread - wrappers doing it on a
>>>>>>>>> Runnable/Consumer/Function/... would be neat.
>>>>>>>>> >>>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>>> Question:
>>>>>>>>> >>>>>>>>>>>>> Would CDI handle it in 2.0?
>>>>>>>>> >>>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>>> Side note: this is really about the fact to reuse a
>>>>>>>>> "context context" (its current instances map) in another thread the more
>>>>>>>>> transparently possible and match the user vision more than a technical
>>>>>>>>> question for now.
>>>>>>>>> >>>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> >>>>>>>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
>>>>>>>>> >>>>>>>>>>>>> _______________________________________________
>>>>>>>>> >>>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>> >>>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>>> Note that for all code provided on this list, the
>>>>>>>>> provider licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>> _______________________________________________
>>>>>>>>> >>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>> >>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>>> Note that for all code provided on this list, the
>>>>>>>>> provider licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>> _______________________________________________
>>>>>>>>> >>>>>>>>>>> cdi-dev mailing list
>>>>>>>>> >>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>>>>>>>>>
>>>>>>>>> >>>>>>>>>>> Note that for all code provided on this list, the
>>>>>>>>> provider licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>>>>>>>>>
>>>>>>>>> >>>>>>>>>> _______________________________________________
>>>>>>>>> >>>>>>>>>> cdi-dev mailing list
>>>>>>>>> >>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>>>>>>>>
>>>>>>>>> >>>>>>>>>> Note that for all code provided on this list, the
>>>>>>>>> provider licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> _______________________________________________
>>>>>>>>> >>>>>>>>> cdi-dev mailing list
>>>>>>>>> >>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> Note that for all code provided on this list, the
>>>>>>>>> provider licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>>>>>>>> _______________________________________________
>>>>>>>>> >>>>>>>>> cdi-dev mailing list
>>>>>>>>> >>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> Note that for all code provided on this list, the
>>>>>>>>> provider licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> _______________________________________________
>>>>>>>>> >>>>>>>> cdi-dev mailing list
>>>>>>>>> >>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> Note that for all code provided on this list, the
>>>>>>>>> provider licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>>>>>> _______________________________________________
>>>>>>>>> >>>>>>> cdi-dev mailing list
>>>>>>>>> >>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> Note that for all code provided on this list, the provider
>>>>>>>>> licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>>>>>> _______________________________________________
>>>>>>>>> >>>>>>> cdi-dev mailing list
>>>>>>>>> >>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> Note that for all code provided on this list, the provider
>>>>>>>>> licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>>>>> _______________________________________________
>>>>>>>>> >>>>>> cdi-dev mailing list
>>>>>>>>> >>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> Note that for all code provided on this list, the provider
>>>>>>>>> licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>>>>> _______________________________________________
>>>>>>>>> >>>>>> cdi-dev mailing list
>>>>>>>>> >>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> Note that for all code provided on this list, the provider
>>>>>>>>> licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>>>
>>>>>>>>> >>>> _______________________________________________
>>>>>>>>> >>>> cdi-dev mailing list
>>>>>>>>> >>>> cdi-dev at lists.jboss.org
>>>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>>
>>>>>>>>> >>>> Note that for all code provided on this list, the provider
>>>>>>>>> licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>> _______________________________________________
>>>>>>>>> >>> cdi-dev mailing list
>>>>>>>>> >>> cdi-dev at lists.jboss.org
>>>>>>>>> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> >>>
>>>>>>>>> >>> Note that for all code provided on this list, the provider
>>>>>>>>> licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>> >>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> cdi-dev mailing list
>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>> Note that for all code provided on this list, the provider
>>>>>>>>> licenses the code under the Apache License, Version 2 (
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>> Note that for all code provided on this list, the provider licenses
>>>>>>>> the code under the Apache License, Version 2 (
>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>>> intellectual property rights inherent in such information.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>> Note that for all code provided on this list, the provider licenses
>>>>>>> the code under the Apache License, Version 2 (
>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>>> intellectual property rights inherent in such information.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>> Note that for all code provided on this list, the provider licenses
>>>>>> the code under the Apache License, Version 2 (
>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>> intellectual property rights inherent in such information.
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>> Note that for all code provided on this list, the provider licenses
>>>>> the code under the Apache License, Version 2 (
>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>> provided on this list, the provider waives all patent and other
>>>>> intellectual property rights inherent in such information.
>>>>
>>>>
>>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/0abf5685/attachment-0001.html
More information about the cdi-dev
mailing list