[cdi-dev] RequestScope Life Cycle

Romain Manni-Bucau rmannibucau at gmail.com
Tue Mar 8 10:47:59 EST 2016


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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/9bb6a436/attachment-0001.html 


More information about the cdi-dev mailing list