[cdi-dev] inheritance of cdi scopes
arjan tijms
arjan.tijms at gmail.com
Tue Mar 8 03:16:28 EST 2016
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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/3e04d684/attachment-0001.html
More information about the cdi-dev
mailing list