[cdi-dev] Contexts behavior in SE and Async Event for EDR1
Martin Kouba
mkouba at redhat.com
Mon Jun 22 07:26:57 EDT 2015
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
More information about the cdi-dev
mailing list