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

Am 19.06.2015 um 15:50 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: I dont think defining all cases works. Why not letting user handling their lifecyle? Le 19 juin 2015 14:08, "Jozef Hartinger" <jharting(a)redhat.com&gt; a écrit : I am talking aNbout: * remote method invocations * @Asynchronous method invocation * @Timeout method invocation * MDB message delivery * @PostConstruct callback invocation all of which are portable. We can expand the definition for other "tasks" that make sense, e.g. async observer notification. On 06/19/2015 02:59 PM, Romain Manni-Bucau wrote: > Looks like you miss the main point. The usage is not portable most of the time. Cant we make it portable? > > Le 19 juin 2015 13:57, "Jozef Hartinger" <jharting(a)redhat.com&gt; a écrit : > I agree with Martin and Mark. @RequestScoped already is used as a > general purpose task-bound scope. This covers, but is not limited to, > HTTP request. On the other hand @SessionScoped and @ConversationScoped > are only defined to be available for HTTP requests. > > On 06/19/2015 08:43 AM, Antoine Sabot-Durand wrote: > > 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. > > _______________________________________________ > 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.