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
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@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@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@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@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@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.