[cdi-dev] Contexts behavior in SE and Async Event for EDR1

Antoine Sabot-Durand antoine at sabot-durand.net
Fri Jun 19 03:26:34 EDT 2015


Thanks Martin

And about request context activation in java SE (for edr1 scope) ?
Le ven. 19 juin 2015 à 08:14, Martin Kouba <mkouba at redhat.com> a écrit :

> I'm in favour of having the request context active during async event
> delivery. I.e. each notification will have it's own request context. The
> name of the context is not perfect but it would be consistent with other
> parts of the spec (@PostConstruct, EJB async, MDB, web service, ...). As
> I already said - HTTP-specific contexts should not be active during
> async delivery.
>
> WRT @ThreadScoped - I don't think it's a good name. A better name would
> be @TaskScoped. We have a similar context in Weld SE but it needs some
> revision [1]. I'm not sure whether it would deserve to become/inspire a
> new built-in context though.
>
> Martin
>
> [1]
> https://issues.jboss.org/browse/WELD-1905
>
> Dne 19.6.2015 v 08:43 Antoine Sabot-Durand napsal(a):
> > Jozef, Martin,
> >
> >
> > What is your POV on that ?
> >
> > Antoine
> >
> >
> >> Le 18 juin 2015 à 20:37, Mark Struberg <struberg at yahoo.de> a écrit :
> >>
> >> 1.) The whole point is that @RequestScoped is NOT a web context!
> >>
> >> Otherwise it would _not_ be active in JMS etc…
> >> And that was not an accident but intentional.
> >>
> >> 2.) And no, different async threads will _never_ get the same request
> context…
> >>
> >>
> >> 3.) no @RequestScoped is a sub-part of a @ThreadScoped. Otherwise you
> would get the same context for 2 JMS invocations which get (randomly)
> executed on the same worker thread. Got me?
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau <
> rmannibucau at gmail.com>:
> >>>
> >>> Hi
> >>>
> >>> I wouldn't activate any "web" scope by default, in particular for
> async events where I think most of the time it will not be used. Next
> feature request will be to inherit the scope between async threads....and
> here I guess we agree it will not go very far.
> >>>
> >>> Side note: using request scope where actually a thread scope is needed
> is a pain, maybe time to add a thread scoped with an accessible manual
> activation. Would make "batches", "timers" etc easy to impl/integrate.
> >>>
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >>>
> >>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand <
> antoine at sabot-durand.net>:
> >>> Hi guys,
> >>>
> >>> We should finally decide how to manage normal scope context (other
> than application context ) in SE and during Async Event for EDR1.
> >>>
> >>> Having only RequestContext active during async event  as Martin
> suggest in the PR makes sense and would be consistent with its behavior
> during async EJB call.
> >>>
> >>> Mark asked twice to activate Request Context all the time in SE
> (making it a new Application Context). I’m not found of it, but I’ml not
> the only one to decide here.
> >>>
> >>> What is you feeling about this ?
> >>>
> >>> Antoine
> >>>
> >>> _______________________________________________
> >>> 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/20150619/5d437cc0/attachment.html 


More information about the cdi-dev mailing list