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

Fri Jun 19 12:34:36 EDT 2015

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