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

[Antoine Sabot-Durand]

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 at 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 at 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 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.
> >
> >
> >
> > --
> > 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 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/20150622/b1c47316/attachment-0001.html