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.

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.

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. >

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.

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 <mailto:jharting@redhat.com>> 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 <mailto:struberg@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 <mailto:rmannibucau@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 <mailto:antoine@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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.

Am 19.06.2015 um 14:57 schrieb Jozef Hartinger <jharting(a)redhat.com&gt;: 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.

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.

Am 19.06.2015 um 18:26 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: @Mark: said shortly cdictrl should go in the spec. Allowing to write an request scoped executor service should be possible for frameworks Le 19 juin 2015 17:21, "Mark Struberg" <struberg(a)yahoo.de&gt; a écrit : Romain, I think I totally lost you. Which part of it is not portable? Do you have any example? LieGrue, strub > Am 19.06.2015 um 14:59 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: > > 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.

Am 19.06.2015 um 18:34 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: Guess we reach the point we say the same thing differently so let switch to how we get this new API in the final version? Le 19 juin 2015 17:31, "Mark Struberg" <struberg(a)yahoo.de&gt; a écrit : Well, CdiCtrl is on the way. The missing part is ContextControl. But we need to find a better solution as I’m not yet perfectly happy with what we have in DeltaSpike. That is also the reason why it’s not yet in EDR1. But I agree that it surely should be in the Final CDI-2.0 release! That doesn’t change the fact that the RequestContext should be available by default. At least for now (where we have no ContextCtrl). LieGrue, strub > Am 19.06.2015 um 18:26 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: > > @Mark: said shortly cdictrl should go in the spec. Allowing to write an request scoped executor service should be possible for frameworks > > Le 19 juin 2015 17:21, "Mark Struberg" <struberg(a)yahoo.de&gt; a écrit : > Romain, I think I totally lost you. Which part of it is not portable? Do you have any example? > > LieGrue, > strub > > > > > Am 19.06.2015 um 14:59 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: > > > > 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. >

Am 20.06.2015 um 00:51 schrieb Anatole Tresch <atsticks(a)gmail.com&gt;: Hi all, for me the question is: do we need a RequestContext? We have the Event payload, which is shared (and AFAIK also still mutable) and can be used to represent the common context as well, for both synch or asynch event cases. Adding a parallel "context" does not necessarily make things easier IMO, because you have to exactly define what a request in that sense is, when does it start, where does it end, how it is propagated/stacked etc. So my question is: what is the benefit of defining the request scope additional to the event payload already in place? Anatole 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. -- Anatole Tresch Java Engineer & Architect, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon Switzerland, Europe Zurich, GMT+1 Twitter: @atsticks Blogs: http://javaremarkables.blogspot.ch/ Google: atsticks Mobile +41-76 344 62 79 _______________________________________________ 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.

To synthetize: - Requestcontext will be active during async events - To be consistent, Requestcontext should be up in Java SE - Other HTTP context (eception application) will be inactive This will clarified later, with context control ticket CDI-530 I produce the EDR1 today and go back to you. Antoine Le sam. 20 juin 2015 à 22:26, Mark Struberg <struberg(a)yahoo.de <mailto:struberg@yahoo.de>> a écrit : The Request context is not needed by the eventing system itself. But tons of usercode around needs the requestcontext to be set up and active. This is the default for almost every spec definedmanaged bean invocation. So we should rather not change this for async events neither. If we change this then you could not reuse lots of existing code in your new async observer. The lifecycle is rather easy to define: it starts shortly before the async method (including interceptors/decorators/etc) gets started and ends afterwards. LieGrue, strub > Am 20.06.2015 um 00:51 schrieb Anatole Tresch <atsticks(a)gmail.com <mailto:atsticks@gmail.com>>: > > Hi all, > > for me the question is: do we need a RequestContext? We have the Event payload, which is shared (and AFAIK also still mutable) and can be used to represent the common context as well, for both synch or asynch event cases. Adding a parallel "context" does not necessarily make things easier IMO, because you have to exactly define what a request in that sense is, when does it start, where does it end, how it is propagated/stacked etc. So my question is: what is the benefit of defining the request scope additional to the event payload already in place? > > Anatole > > > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@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 <mailto:cdi-dev@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. > > > > -- > Anatole Tresch > Java Engineer & Architect, JSR Spec Lead > Glärnischweg 10 > CH - 8620 Wetzikon > > Switzerland, Europe Zurich, GMT+1 > Twitter: @atsticks > Blogs: http://javaremarkables.blogspot.ch/ > Google: atsticks > Mobile +41-76 344 62 79 > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@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.

"Should be active". It was one of the subject of this email

Le lun. 22 juin 2015 à 12:48, Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com>> a écrit : What does "Requestcontext should be up in Java SE" mean exactly? On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: > To synthetize: > > - Requestcontext will be active during async events > - To be consistent, Requestcontext should be up in Java SE > - Other HTTP context (eception application) will be inactive > > This will clarified later, with context control ticket CDI-530 > > I produce the EDR1 today and go back to you. > > Antoine > > > Le sam. 20 juin 2015 à 22:26, Mark Struberg <struberg(a)yahoo.de > <mailto:struberg@yahoo.de>> a écrit : > > The Request context is not needed by the eventing system > itself. But tons of usercode around needs the requestcontext > to be set up and active. This is the default for almost every > spec definedmanaged bean invocation. So we should rather not > change this for async events neither. If we change this then > you could not reuse lots of existing code in your new async > observer. > > The lifecycle is rather easy to define: it starts shortly > before the async method (including > interceptors/decorators/etc) gets started and ends afterwards. > > LieGrue, > strub > > > Am 20.06.2015 um 00:51 schrieb Anatole Tresch > <atsticks(a)gmail.com <mailto:atsticks@gmail.com>>: > > > > Hi all, > > > > for me the question is: do we need a RequestContext? We have > the Event payload, which is shared (and AFAIK also still > mutable) and can be used to represent the common context as > well, for both synch or asynch event cases. Adding a parallel > "context" does not necessarily make things easier IMO, because > you have to exactly define what a request in that sense is, > when does it start, where does it end, how it is > propagated/stacked etc. So my question is: what is the benefit > of defining the request scope additional to the event payload > already in place? > > > > Anatole > > > > > > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand > <antoine(a)sabot-durand.net <mailto:antoine@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 <mailto:cdi-dev@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. > > > > > > > > -- > > Anatole Tresch > > Java Engineer & Architect, JSR Spec Lead > > Glärnischweg 10 > > CH - 8620 Wetzikon > > > > Switzerland, Europe Zurich, GMT+1 > > Twitter: @atsticks > > Blogs: http://javaremarkables.blogspot.ch/ > > Google: atsticks > > Mobile +41-76 344 62 79 > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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.

Sorry Martin, I don't agree For me there are 2 scenarios for EDR1 : 1) Request context is never active in SE (the one I started with). 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. 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). 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. 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. Antoine Le lun. 22 juin 2015 à 13:27, Martin Kouba <mkouba(a)redhat.com <mailto:mkouba@redhat.com>> a écrit : Dne 22.6.2015 v 13:15 Antoine Sabot-Durand napsal(a): > "Should be active". It was one of the subject of this email To make it clear - the request context will not be active all the time... I mean it makes sense to have it active during @PostConstruct invocation and async delivery. Or in case of an emebedded servlet container running as a part of a CDI SE app (something like DropWizard), during servlet requests processing. But not all the time like application context is... > Le lun. 22 juin 2015 à 12:48, Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com> > <mailto:jharting@redhat.com <mailto:jharting@redhat.com>>> a écrit : > > What does "Requestcontext should be up in Java SE" mean exactly? > > > On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: >> To synthetize: >> >> - Requestcontext will be active during async events >> - To be consistent, Requestcontext should be up in Java SE >> - Other HTTP context (eception application) will be inactive >> >> This will clarified later, with context control ticket CDI-530 >> >> I produce the EDR1 today and go back to you. >> >> Antoine >> >> >> Le sam. 20 juin 2015 à 22:26, Mark Struberg <struberg(a)yahoo.de <mailto:struberg@yahoo.de> >> <mailto:struberg@yahoo.de <mailto:struberg@yahoo.de>>> a écrit : >> >> The Request context is not needed by the eventing system >> itself. But tons of usercode around needs the requestcontext >> to be set up and active. This is the default for almost every >> spec definedmanaged bean invocation. So we should rather not >> change this for async events neither. If we change this then >> you could not reuse lots of existing code in your new async >> observer. >> >> The lifecycle is rather easy to define: it starts shortly >> before the async method (including >> interceptors/decorators/etc) gets started and ends afterwards. >> >> LieGrue, >> strub >> >> > Am 20.06.2015 um 00:51 schrieb Anatole Tresch >> <atsticks(a)gmail.com <mailto:atsticks@gmail.com> <mailto:atsticks@gmail.com <mailto:atsticks@gmail.com>>>: >> > >> > Hi all, >> > >> > for me the question is: do we need a RequestContext? We have >> the Event payload, which is shared (and AFAIK also still >> mutable) and can be used to represent the common context as >> well, for both synch or asynch event cases. Adding a parallel >> "context" does not necessarily make things easier IMO, because >> you have to exactly define what a request in that sense is, >> when does it start, where does it end, how it is >> propagated/stacked etc. So my question is: what is the benefit >> of defining the request scope additional to the event payload >> already in place? >> > >> > Anatole >> > >> > >> > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand >> <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net> <mailto:antoine@sabot-durand.net <mailto:antoine@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 <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@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. >> > >> > >> > >> > -- >> > Anatole Tresch >> > Java Engineer & Architect, JSR Spec Lead >> > Glärnischweg 10 >> > CH - 8620 Wetzikon >> > >> > Switzerland, Europe Zurich, GMT+1 >> > Twitter: @atsticks >> > Blogs: http://javaremarkables.blogspot.ch/ >> > Google: atsticks >> > Mobile +41-76 344 62 79 >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic

+1. Imo this is the best we can do until we have a proper ContextControl

> >> the Event payload, which is shared (and AFAIK also still > >> mutable) and can be used to represent the common context as > >> well, for both synch or asynch event cases. Adding a parallel > >> "context" does not necessarily make things easier IMO,

> >> you have to exactly define what a request in that sense is, > >> when does it start, where does it end, how it is > >> propagated/stacked etc. So my question is: what is the

> >> SE (making it a new Application Context). I’m not found of

Given that we plan on adding ContextControl to the spec, which deals with this much better, why even bother figuring out and specifying a temporary solution for the meantime? On 06/23/2015 07:20 AM, Mark Struberg wrote: > +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. > > LieGrue, > strub > >> Am 22.06.2015 um 14:52 schrieb Antoine Sabot-Durand < antoine(a)sabot-durand.net&gt;: >> >> Sorry Martin, I don't agree >> >> For me there are 2 scenarios for EDR1 : >> >> 1) Request context is never active in SE (the one I started with). >> 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. >> >> 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). >> >> 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. >> >> 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. >> >> Antoine >> >> Le lun. 22 juin 2015 à 13:27, Martin Kouba <mkouba(a)redhat.com&gt; a écrit : >> Dne 22.6.2015 v 13:15 Antoine Sabot-Durand napsal(a): >>> "Should be active". It was one of the subject of this email >> To make it clear - the request context will not be active all the >> time... I mean it makes sense to have it active during @PostConstruct >> invocation and async delivery. Or in case of an emebedded servlet >> container running as a part of a CDI SE app (something like DropWizard), >> during servlet requests processing. But not all the time like >> application context is... >> >>> Le lun. 22 juin 2015 à 12:48, Jozef Hartinger <jharting(a)redhat.com >>> <mailto:jharting@redhat.com>> a écrit : >>> >>> What does "Requestcontext should be up in Java SE" mean exactly? >>> >>> >>> On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote: >>>> To synthetize: >>>> >>>> - Requestcontext will be active during async events >>>> - To be consistent, Requestcontext should be up in Java SE >>>> - Other HTTP context (eception application) will be inactive >>>> >>>> This will clarified later, with context control ticket CDI-530 >>>> >>>> I produce the EDR1 today and go back to you. >>>> >>>> Antoine >>>> >>>> >>>> Le sam. 20 juin 2015 à 22:26, Mark Struberg <struberg(a)yahoo.de >>>> <mailto:struberg@yahoo.de>> a écrit : >>>> >>>> The Request context is not needed by the eventing system >>>> itself. But tons of usercode around needs the requestcontext >>>> to be set up and active. This is the default for almost every >>>> spec definedmanaged bean invocation. So we should rather not >>>> change this for async events neither. If we change this then >>>> you could not reuse lots of existing code in your new async >>>> observer. >>>> >>>> The lifecycle is rather easy to define: it starts shortly >>>> before the async method (including >>>> interceptors/decorators/etc) gets started and ends afterwards. >>>> >>>> LieGrue, >>>> strub >>>> >>>> > Am 20.06.2015 um 00:51 schrieb Anatole Tresch >>>> <atsticks(a)gmail.com <mailto:atsticks@gmail.com>>: >>>> > >>>> > Hi all, >>>> > >>>> > for me the question is: do we need a RequestContext? We have >>>> the Event payload, which is shared (and AFAIK also still >>>> mutable) and can be used to represent the common context as >>>> well, for both synch or asynch event cases. Adding a parallel >>>> "context" does not necessarily make things easier IMO, because >>>> you have to exactly define what a request in that sense is, >>>> when does it start, where does it end, how it is >>>> propagated/stacked etc. So my question is: what is the benefit >>>> of defining the request scope additional to the event payload >>>> already in place? >>>> > >>>> > Anatole >>>> > >>>> > >>>> > 2015-06-18 15:10 GMT+02:00 Antoine Sabot-Durand >>>> <antoine(a)sabot-durand.net <mailto:antoine@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 <mailto:cdi-dev@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. >>>> > >>>> > >>>> > >>>> > -- >>>> > Anatole Tresch >>>> > Java Engineer & Architect, JSR Spec Lead >>>> > Glärnischweg 10 >>>> > CH - 8620 Wetzikon >>>> > >>>> > Switzerland, Europe Zurich, GMT+1 >>>> > Twitter: @atsticks >>>> > Blogs: http://javaremarkables.blogspot.ch/ >>>> > Google: atsticks >>>> > Mobile +41-76 344 62 79 >>>> > _______________________________________________ >>>> > cdi-dev mailing list >>>> > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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. >>> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> _______________________________________________ >> 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.