[cdi-dev] RequestScope Life Cycle
Romain Manni-Bucau
rmannibucau at gmail.com
Tue Mar 8 11:46:12 EST 2016
is a flag an option? @RequestScoped(inherited = true)
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 17:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:
> As we already discussed during async event debate, we really should think
> about propagating normal scopes to be align on servlet and prepare CDI for
> reactive programming.
> We can't break the way existing built-in normal scopes work today (no
> propagating and ApplicationScoped being shared) but nothing prevent us to
> introduce new normal scope supporting propagation (@AsyncRequestScoped for
> instance).
>
> Le mar. 8 mars 2016 à 17:38, Romain Manni-Bucau <rmannibucau at gmail.com> a
> écrit :
>
>> For Servlet 3.1 I don't have much doubts on the beneficial side but for
>> the other cases I'm sure it would break a lot of code written on EE 6 or 7
>> where @RequestScoped beans have been used as thread local intances. So
>> typically a HTTP request or JMS message calling an @Asynchronous EJB would
>> break apps if you decide to propagate the context now. Same for websockets
>> - which still don't have a scope - but in a lighter way since it is not yet
>> mainstream.
>>
>> Even if such change makes sense it shouldn't be done
>> without widely asking users to acknowledge it. Doing it is much more work
>> and wider than the original mail so maybe it should be discussed in two
>> steps.
>>
>>
>> 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 17:00 GMT+01:00 Paul Benedict <pbenedict at apache.org>:
>>
>>> 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.
>>>>
>>>
>>>
>> _______________________________________________
>> 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/de72032f/attachment-0001.html
More information about the cdi-dev
mailing list