If we plan to release an impl for edr1 we have to decide its behavior IMO. But I agree with you, it shouldn't take this time to do it. <br><div class="gmail_quote">Le mar. 23 juin 2015 à 08:28, Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Given that we plan on adding ContextControl to the spec, which deals<br>
with this much better, why even bother figuring out and specifying a<br>
temporary solution for the meantime?<br>
<br>
On 06/23/2015 07:20 AM, Mark Struberg wrote:<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>
><br>
> LieGrue,<br>
> strub<br>
><br>
>> Am 22.06.2015 um 14:52 schrieb Antoine Sabot-Durand <<a href="mailto:antoine@sabot-durand.net" target="_blank">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" target="_blank">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>
>> 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>
>>> 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>
>> 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" 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>
</blockquote></div>