[cdi-dev] RequestScope Life Cycle
Paul Benedict
pbenedict at apache.org
Tue Mar 8 11:00:04 EST 2016
I agree with Stephan. Since the introduction of asynchronous processing in
Servlet 3.1, the 1:1 assumption between request-thread has been removed. A
"request" should not be synonymous with a single thread anymore; but the
entire request operation.
Cheers,
Paul
On Tue, Mar 8, 2016 at 9: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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/f7ba3301/attachment-0001.html
More information about the cdi-dev
mailing list