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

Mark Struberg struberg at yahoo.de
Fri Jun 19 12:43:26 EDT 2015


+1 :)

LieGrue,
strub


> Am 19.06.2015 um 18:34 schrieb Romain Manni-Bucau <rmannibucau at gmail.com>:
> 
> Guess we reach the point we say the same thing differently so let switch to how we get this new API in the final version?
> Le 19 juin 2015 17:31, "Mark Struberg" <struberg at yahoo.de> a écrit :
> Well, CdiCtrl is on the way. The missing part is ContextControl. But we need to find a better solution as I’m not yet perfectly happy with what we have in DeltaSpike. That is also the reason why it’s not yet in EDR1. But I agree that it surely should be in the Final CDI-2.0 release!
> That doesn’t change the fact that the RequestContext should be available by default. At least for now (where we have no ContextCtrl).
> 
> LieGrue,
> strub
> 
> 
> > Am 19.06.2015 um 18:26 schrieb Romain Manni-Bucau <rmannibucau at gmail.com>:
> >
> > @Mark: said shortly cdictrl should go in the spec. Allowing to write an request scoped executor service should be possible for frameworks
> >
> > Le 19 juin 2015 17:21, "Mark Struberg" <struberg at yahoo.de> a écrit :
> > Romain, I think I totally lost you. Which part of it is not portable? Do you have any example?
> >
> > LieGrue,
> > strub
> >
> >
> >
> > > Am 19.06.2015 um 14:59 schrieb Romain Manni-Bucau <rmannibucau at gmail.com>:
> > >
> > > Looks like you miss the main point. The usage is not portable most of the time. Cant we make it portable?
> > >
> > > Le 19 juin 2015 13:57, "Jozef Hartinger" <jharting at redhat.com> a écrit :
> > > I agree with Martin and Mark. @RequestScoped already is used as a
> > > general purpose task-bound scope. This covers, but is not limited to,
> > > HTTP request. On the other hand @SessionScoped and @ConversationScoped
> > > are only defined to be available for HTTP requests.
> > >
> > > On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote:
> > > > 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.
> > >
> > > _______________________________________________
> > > 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.
> >
> 




More information about the cdi-dev mailing list