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

[Martin Kouba]

Dne 19.6.2015 v 14:59 Romain Manni-Bucau napsal(a):
> Looks like you miss the main point. The usage is not portable most of
> the time. Cant we make it portable?

What do you mean with "portable" here? Could you explain please?

>
> Le 19 juin 2015 13:57, "Jozef Hartinger" <jharting at redhat.com
> <mailto:jharting at 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 at yahoo.de
>     <mailto:struberg at 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 at gmail.com <mailto:rmannibucau at 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 at sabot-durand.net <mailto:antoine at 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 at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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 at 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