Re: [cdi-dev] Contexts behavior in SE and Async Event for EDR1

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] https://issues.jboss.org/browse/WELD-1905 Dne 19.6.2015 v 08:43 Antoine Sabot-Durand napsal(a): > Jozef, Martin, > > > What is your POV on that ? > > Antoine > > >> Le 18 juin 2015 à 20:37, Mark Struberg <struberg(a)yahoo.de&gt; 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&gt;: >>> >>> 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&gt;: >>> 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. >