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

Given that we plan on adding ContextControl to the spec, which deals with this much better, why even bother figuring out and specifying a temporary solution for the meantime? On 06/23/2015 07:20 AM, Mark Struberg wrote: > +1. Imo this is the best we can do until we have a proper ContextControl in place. Otherwise many users would not be able to reuse existing libs in SE. > > LieGrue, > strub > >> Am 22.06.2015 um 14:52 schrieb Antoine Sabot-Durand < antoine(a)sabot-durand.net&gt;: >> >> Sorry Martin, I don't agree >> >> For me there are 2 scenarios for EDR1 : >> >> 1) Request context is never active in SE (the one I started with). >> 2) Request context is always active to provide a behavior similar than Java EE. Yes that probably mean that Request context will be like another application context. >> >> Having something in the middle, even if it could make sense at the sec level would be totality puzzling from users POV (why I have a request context in an async event and not in a sync ? why in a postconstruct and when I use my bean later). >> >> Again that wouldn't be the final behavior since we should work on CDI-530 but it could ease the work review of the community. >> >> Personally I think that we should go for 1) only if we are sure that CDI-530 won't give possibility to user to have an active request context which I hope won't be the case. >> >> Antoine >> >> Le lun. 22 juin 2015 à 13:27, Martin Kouba <mkouba(a)redhat.com&gt; a écrit : >> Dne 22.6.2015 v 13:15 Antoine Sabot-Durand napsal(a): >>> "Should be active". It was one of the subject of this email >> To make it clear - the request context will not be active all the >> time... I mean it makes sense to have it active during @PostConstruct >> invocation and async delivery. Or in case of an emebedded servlet >> container running as a part of a CDI SE app (something like DropWizard), >> during servlet requests processing. But not all the time like >> application context is... >> >>> Le lun. 22 juin 2015 à 12:48, Jozef Hartinger <jharting(a)redhat.com >>> <mailto:jharting@redhat.com>> a écrit : >>> >>> What does "Requestcontext should be up in Java SE" mean exactly? >>> >>> >>> On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: >>>> To synthetize: >>>> >>>> - Requestcontext will be active during async events >>>> - To be consistent, Requestcontext should be up in Java SE >>>> - Other HTTP context (eception application) will be inactive >>>> >>>> This will clarified later, with context control ticket CDI-530 >>>> >>>> I produce the EDR1 today and go back to you. >>>> >>>> Antoine >>>> >>>> >>>> Le sam. 20 juin 2015 à 22:26, Mark Struberg <struberg(a)yahoo.de >>>> <mailto:struberg@yahoo.de>> a écrit : >>>> >>>> The Request context is not needed by the eventing system >>>> itself. But tons of usercode around needs the requestcontext >>>> to be set up and active. This is the default for almost every >>>> spec definedmanaged bean invocation. So we should rather not >>>> change this for async events neither. If we change this then >>>> you could not reuse lots of existing code in your new async >>>> observer. >>>> >>>> The lifecycle is rather easy to define: it starts shortly >>>> before the async method (including >>>> interceptors/decorators/etc) gets started and ends afterwards. >>>> >>>> LieGrue, >>>> strub >>>> >>>> > Am 20.06.2015 um 00:51 schrieb Anatole Tresch >>>> <atsticks(a)gmail.com <mailto:atsticks@gmail.com>>: >>>> > >>>> > Hi all, >>>> > >>>> > for me the question is: do we need a RequestContext? We have >>>> the Event payload, which is shared (and AFAIK also still >>>> mutable) and can be used to represent the common context as >>>> well, for both synch or asynch event cases. Adding a parallel >>>> "context" does not necessarily make things easier IMO, because >>>> you have to exactly define what a request in that sense is, >>>> when does it start, where does it end, how it is >>>> propagated/stacked etc. So my question is: what is the benefit >>>> of defining the request scope additional to the event payload >>>> already in place? >>>> > >>>> > Anatole >>>> > >>>> > >>>> > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand >>>> <antoine(a)sabot-durand.net <mailto:antoine@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(a)lists.jboss.org <mailto:cdi-dev@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. >>>> > >>>> > >>>> > >>>> > -- >>>> > Anatole Tresch >>>> > Java Engineer & Architect, JSR Spec Lead >>>> > Glärnischweg 10 >>>> > CH - 8620 Wetzikon >>>> > >>>> > Switzerland, Europe Zurich, GMT+1 >>>> > Twitter: @atsticks >>>> > Blogs: http://javaremarkables.blogspot.ch/ >>>> > Google: atsticks >>>> > Mobile +41-76 344 62 79 >>>> > _______________________________________________ >>>> > cdi-dev mailing list >>>> > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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(a)lists.jboss.org <mailto:cdi-dev@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(a)lists.jboss.org <mailto:cdi-dev@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(a)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. >>> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)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.