[cdi-dev] Contexts behavior in SE and Async Event for EDR1
Jozef Hartinger
jharting at redhat.com
Mon Jun 22 14:30:31 EDT 2015
Can you in detail describe the semantics of what you propose? So far
I've found it quite vague.
On 06/22/2015 02:52 PM, Antoine Sabot-Durand wrote:
> 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
> <mailto: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>
> > <mailto: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>
> >> <mailto: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>
> <mailto: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> <mailto: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> <mailto: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> <mailto: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>
> <mailto: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>
> <mailto: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.
> >
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150622/123fb380/attachment-0001.html
More information about the cdi-dev
mailing list