I'm in favour of having the request context active during async event
delivery. I.e. each notification will have it's own request context. The
name of the context is not perfect but it would be consistent with other
parts of the spec (@PostConstruct, EJB async, MDB, web service, ...). As
I already said - HTTP-specific contexts should not be active during
async delivery.
WRT @ThreadScoped - I don't think it's a good name. A better name would
be @TaskScoped. We have a similar context in Weld SE but it needs some
revision [1]. I'm not sure whether it would deserve to become/inspire a
new built-in context though.
Martin
[1]
Jozef, Martin,
What is your POV on that ?
Antoine
> Le 18 juin 2015 à 20:37, Mark Struberg <struberg(a)yahoo.de> a écrit :
>
> 1.) The whole point is that @RequestScoped is NOT a web context!
>
> Otherwise it would _not_ be active in JMS etc…
> And that was not an accident but intentional.
>
> 2.) And no, different async threads will _never_ get the same request context…
>
>
> 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?
>
>
> LieGrue,
> strub
>
>
>> Am 18.06.2015 um 15:13 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com>:
>>
>> Hi
>>
>> 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.
>>
>> 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.
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
>>
>> 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand
<antoine(a)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
>>
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.
>
>
> _______________________________________________
> 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.