Thanks Martin<br><br>And about request context activation in java SE (for edr1 scope) ?<br><div class="gmail_quote">Le ven. 19 juin 2015 à 08:14, Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm in favour of having the request context active during async event<br>
delivery. I.e. each notification will have it's own request context. The<br>
name of the context is not perfect but it would be consistent with other<br>
parts of the spec (@PostConstruct, EJB async, MDB, web service, ...). As<br>
I already said - HTTP-specific contexts should not be active during<br>
async delivery.<br>
<br>
WRT @ThreadScoped - I don't think it's a good name. A better name would<br>
be @TaskScoped. We have a similar context in Weld SE but it needs some<br>
revision [1]. I'm not sure whether it would deserve to become/inspire a<br>
new built-in context though.<br>
<br>
Martin<br>
<br>
[1]<br>
<a href="https://issues.jboss.org/browse/WELD-1905" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/WELD-1905</a><br>
<br>
Dne 19.6.2015 v 08:43 Antoine Sabot-Durand napsal(a):<br>
> Jozef, Martin,<br>
><br>
><br>
> What is your POV on that ?<br>
><br>
> Antoine<br>
><br>
><br>
>> Le 18 juin 2015 à 20:37, Mark Struberg <<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>> a écrit :<br>
>><br>
>> 1.) The whole point is that @RequestScoped is NOT a web context!<br>
>><br>
>> Otherwise it would _not_ be active in JMS etc…<br>
>> And that was not an accident but intentional.<br>
>><br>
>> 2.) And no, different async threads will _never_ get the same request context…<br>
>><br>
>><br>
>> 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?<br>
>><br>
>><br>
>> LieGrue,<br>
>> strub<br>
>><br>
>><br>
>>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>>:<br>
>>><br>
>>> Hi<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>><br>
>>><br>
>>> Romain Manni-Bucau<br>
>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber<br>
>>><br>
>>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand <<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 (other than application context ) in SE and during Async Event for EDR1.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<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><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>
>>> 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>
>> 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>