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

[Romain Manni-Bucau]

I dont think defining all cases works. Why not letting user handling their
lifecyle?
Le 19 juin 2015 14:08, "Jozef Hartinger" <jharting at redhat.com> a écrit :

>  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 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> 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>:
>> >>>
>> >>> 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>:
>> >>> 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
>> >>> 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.
>> >>
>> >> _______________________________________________
>> >> 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.
>>
>> _______________________________________________
>> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150619/8b15e8f7/attachment.html