<p dir="ltr"><br>
Le 23 juin 2015 07:21, "Mark Struberg" <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>> a écrit :<br>
><br>
> +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.<br>
></p>
<p dir="ltr">This is true but not sure I get what prevent us to add a ContextControl *now*?</p>
<p dir="ltr">> LieGrue,<br>
> strub<br>
><br>
> > Am 22.06.2015 um 14:52 schrieb Antoine Sabot-Durand <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>>:<br>
> ><br>
> > Sorry Martin, I don't agree<br>
> ><br>
> > For me there are 2 scenarios for EDR1 :<br>
> ><br>
> > 1) Request context is never active in SE (the one I started with).<br>
> > 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.<br>
> ><br>
> > 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).<br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > Antoine<br>
> ><br>
> > Le lun. 22 juin 2015 à 13:27, Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>> a écrit :<br>
> > Dne 22.6.2015 v 13:15 Antoine Sabot-Durand napsal(a):<br>
> > > "Should be active". It was one of the subject of this email<br>
> ><br>
> > To make it clear - the request context will not be active all the<br>
> > time... I mean it makes sense to have it active during @PostConstruct<br>
> > invocation and async delivery. Or in case of an emebedded servlet<br>
> > container running as a part of a CDI SE app (something like DropWizard),<br>
> > during servlet requests processing. But not all the time like<br>
> > application context is...<br>
> ><br>
> > > Le lun. 22 juin 2015 à 12:48, Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a><br>
> > > <mailto:<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>>> a écrit :<br>
> > ><br>
> > > What does "Requestcontext should be up in Java SE" mean exactly?<br>
> > ><br>
> > ><br>
> > > On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote:<br>
> > >> To synthetize:<br>
> > >><br>
> > >> - Requestcontext will be active during async events<br>
> > >> - To be consistent, Requestcontext should be up in Java SE<br>
> > >> - Other HTTP context (eception application) will be inactive<br>
> > >><br>
> > >> This will clarified later, with context control ticket CDI-530<br>
> > >><br>
> > >> I produce the EDR1 today and go back to you.<br>
> > >><br>
> > >> Antoine<br>
> > >><br>
> > >><br>
> > >> Le sam. 20 juin 2015 à 22:26, Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a><br>
> > >> <mailto:<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>>> a écrit :<br>
> > >><br>
> > >> The Request context is not needed by the eventing system<br>
> > >> itself. But tons of usercode around needs the requestcontext<br>
> > >> to be set up and active. This is the default for almost every<br>
> > >> spec definedmanaged bean invocation. So we should rather not<br>
> > >> change this for async events neither. If we change this then<br>
> > >> you could not reuse lots of existing code in your new async<br>
> > >> observer.<br>
> > >><br>
> > >> The lifecycle is rather easy to define: it starts shortly<br>
> > >> before the async method (including<br>
> > >> interceptors/decorators/etc) gets started and ends afterwards.<br>
> > >><br>
> > >> LieGrue,<br>
> > >> strub<br>
> > >><br>
> > >> > Am 20.06.2015 um 00:51 schrieb Anatole Tresch<br>
> > >> <<a href="mailto:atsticks@gmail.com">atsticks@gmail.com</a> <mailto:<a href="mailto:atsticks@gmail.com">atsticks@gmail.com</a>>>:<br>
> > >> ><br>
> > >> > Hi all,<br>
> > >> ><br>
> > >> > for me the question is: do we need a RequestContext? We have<br>
> > >> the Event payload, which is shared (and AFAIK also still<br>
> > >> mutable) and can be used to represent the common context as<br>
> > >> well, for both synch or asynch event cases. Adding a parallel<br>
> > >> "context" does not necessarily make things easier IMO, because<br>
> > >> you have to exactly define what a request in that sense is,<br>
> > >> when does it start, where does it end, how it is<br>
> > >> propagated/stacked etc. So my question is: what is the benefit<br>
> > >> of defining the request scope additional to the event payload<br>
> > >> already in place?<br>
> > >> ><br>
> > >> > Anatole<br>
> > >> ><br>
> > >> ><br>
> > >> > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand<br>
> > >> <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a> <mailto:<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>>>:<br>
> > >> > Hi guys,<br>
> > >> ><br>
> > >> > We should finally decide how to manage normal scope context<br>
> > >> (other than application context ) in SE and during Async Event<br>
> > >> for EDR1.<br>
> > >> ><br>
> > >> > Having only RequestContext active during async event as<br>
> > >> Martin suggest in the PR makes sense and would be consistent<br>
> > >> with its behavior during async EJB call.<br>
> > >> ><br>
> > >> > Mark asked twice to activate Request Context all the time in<br>
> > >> SE (making it a new Application Context). I’m not found of it,<br>
> > >> but I’ml not the only one to decide here.<br>
> > >> ><br>
> > >> > What is you feeling about this ?<br>
> > >> ><br>
> > >> > Antoine<br>
> > >> ><br>
> > >> > _______________________________________________<br>
> > >> > cdi-dev mailing list<br>
> > >> > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> > >> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> > >> ><br>
> > >> > Note that for all code provided on this list, the provider<br>
> > >> licenses the code under the Apache License, Version 2<br>
> > >> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all<br>
> > >> other ideas provided on this list, the provider waives all<br>
> > >> patent and other intellectual property rights inherent in such<br>
> > >> information.<br>
> > >> ><br>
> > >> ><br>
> > >> ><br>
> > >> > --<br>
> > >> > Anatole Tresch<br>
> > >> > Java Engineer & Architect, JSR Spec Lead<br>
> > >> > Glärnischweg 10<br>
> > >> > CH - 8620 Wetzikon<br>
> > >> ><br>
> > >> > Switzerland, Europe Zurich, GMT+1<br>
> > >> > Twitter: @atsticks<br>
> > >> > Blogs: <a href="http://javaremarkables.blogspot.ch/">http://javaremarkables.blogspot.ch/</a><br>
> > >> > Google: atsticks<br>
> > >> > Mobile +41-76 344 62 79<br>
> > >> > _______________________________________________<br>
> > >> > cdi-dev mailing list<br>
> > >> > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> > >> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> > >> ><br>
> > >> > Note that for all code provided on this list, the provider<br>
> > >> licenses the code under the Apache License, Version 2<br>
> > >> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all<br>
> > >> other ideas provided on this list, the provider waives all<br>
> > >> patent and other intellectual property rights inherent in such<br>
> > >> information.<br>
> > >><br>
> > >><br>
> > >> _______________________________________________<br>
> > >> cdi-dev mailing list<br>
> > >> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> > >> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> > >><br>
> > >> Note that for all code provided on this list, the provider<br>
> > >> licenses the code under the Apache License, Version 2<br>
> > >> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all<br>
> > >> other ideas provided on this list, the provider waives all<br>
> > >> patent and other intellectual property rights inherent in such<br>
> > >> information.<br>
> > >><br>
> > >><br>
> > >><br>
> > >> _______________________________________________<br>
> > >> cdi-dev mailing list<br>
> > >> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> > >> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> > >><br>
> > >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
> > ><br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > cdi-dev mailing list<br>
> > > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> > ><br>
> > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
> > ><br>
> ><br>
> > --<br>
> > Martin Kouba<br>
> > Software Engineer<br>
> > Red Hat, Czech Republic<br>
> > _______________________________________________<br>
> > cdi-dev mailing list<br>
> > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> ><br>
> > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
><br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.</p>