[cdi-dev] Contexts behavior in SE and Async Event for EDR1
Antoine Sabot-Durand
antoine at sabot-durand.net
Tue Jun 23 03:13:32 EDT 2015
If we plan to release an impl for edr1 we have to decide its behavior IMO.
But I agree with you, it shouldn't take this time to do it.
Le mar. 23 juin 2015 à 08:28, Jozef Hartinger <jharting at redhat.com> a
écrit :
> 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 at sabot-durand.net>:
> >>
> >> 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 at 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 at redhat.com
> >>> <mailto:jharting at 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 at yahoo.de
> >>>> <mailto: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 <mailto: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 <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.
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > 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 <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
> >> _______________________________________________
> >> 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/20150623/48643ff0/attachment-0001.html
More information about the cdi-dev
mailing list