<div dir="ltr">Sorry Martin, I don't agree<br><br><div>For me there are 2 scenarios for EDR1 : </div><div><br></div><div>1) Request context is never active in SE (the one I started with).</div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Antoine </div></div><br><div class="gmail_quote"><div dir="ltr">Le lun. 22 juin 2015 à 13:27, Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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" target="_blank">jharting@redhat.com</a><br>
> <mailto:<a href="mailto:jharting@redhat.com" target="_blank">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" target="_blank">struberg@yahoo.de</a><br>
>> <mailto:<a href="mailto:struberg@yahoo.de" target="_blank">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" target="_blank">atsticks@gmail.com</a> <mailto:<a href="mailto:atsticks@gmail.com" target="_blank">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" target="_blank">antoine@sabot-durand.net</a> <mailto:<a href="mailto:antoine@sabot-durand.net" target="_blank">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" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
>> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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/" rel="noreferrer" target="_blank">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" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
>> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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" target="_blank">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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>
</blockquote></div>