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(a)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(a)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(a)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(a)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.