I am talking about:
* 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
<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.