[cdi-dev] Contexts behavior in SE and Async Event for EDR1
Romain Manni-Bucau
rmannibucau at gmail.com
Tue Jun 23 02:10:10 EDT 2015
Le 23 juin 2015 07:21, "Mark Struberg" <struberg at yahoo.de> a écrit :
>
> +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.
>
This is true but not sure I get what prevent us to add a ContextControl
*now*?
> 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.
>
>
> _______________________________________________
> 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/4505f4ba/attachment-0001.html
More information about the cdi-dev
mailing list