<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Can you in detail describe the semantics of what you propose? So far
I've found it quite vague.<br>
<br>
<div class="moz-cite-prefix">On 06/22/2015 02:52 PM, Antoine
Sabot-Durand wrote:<br>
</div>
<blockquote
cite="mid:CABu-YBQWQZJ-Y2Gsh+Ks_Cn800GRUomO3GmbYQWYRmR8XeRCqg@mail.gmail.com"
type="cite">
<div dir="ltr">Sorry Martin, I don't agree<br>
<br>
<div>For me there are 2 scenarios for EDR1 : </div>
<div><br>
</div>
<div>1) Request context is never active in SE (the one I started
with).</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Antoine </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Le lun. 22 juin 2015 à 13:27, Martin Kouba <<a
moz-do-not-send="true" href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Dne
22.6.2015 v 13:15 Antoine Sabot-Durand napsal(a):<br>
> "Should be active". It was one of the subject of this
email<br>
<br>
To make it clear - the request context will not be active all
the<br>
time... I mean it makes sense to have it active during
@PostConstruct<br>
invocation and async delivery. Or in case of an emebedded
servlet<br>
container running as a part of a CDI SE app (something like
DropWizard),<br>
during servlet requests processing. But not all the time like<br>
application context is...<br>
<br>
> Le lun. 22 juin 2015 à 12:48, Jozef Hartinger <<a
moz-do-not-send="true" href="mailto:jharting@redhat.com"
target="_blank">jharting@redhat.com</a><br>
> <mailto:<a moz-do-not-send="true"
href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>>>
a écrit :<br>
><br>
> What does "Requestcontext should be up in Java SE"
mean exactly?<br>
><br>
><br>
> On 06/22/2015 11:26 AM, Antoine Sabot-Durand wrote:<br>
>> To synthetize:<br>
>><br>
>> - Requestcontext will be active during async
events<br>
>> - To be consistent, Requestcontext should be up
in Java SE<br>
>> - Other HTTP context (eception application) will
be inactive<br>
>><br>
>> This will clarified later, with context control
ticket CDI-530<br>
>><br>
>> I produce the EDR1 today and go back to you.<br>
>><br>
>> Antoine<br>
>><br>
>><br>
>> Le sam. 20 juin 2015 à 22:26, Mark Struberg <<a
moz-do-not-send="true" href="mailto:struberg@yahoo.de"
target="_blank">struberg@yahoo.de</a><br>
>> <mailto:<a moz-do-not-send="true"
href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>>>
a écrit :<br>
>><br>
>> The Request context is not needed by the
eventing system<br>
>> itself. But tons of usercode around needs the
requestcontext<br>
>> to be set up and active. This is the default
for almost every<br>
>> spec definedmanaged bean invocation. So we
should rather not<br>
>> change this for async events neither. If we
change this then<br>
>> you could not reuse lots of existing code in
your new async<br>
>> observer.<br>
>><br>
>> The lifecycle is rather easy to define: it
starts shortly<br>
>> before the async method (including<br>
>> interceptors/decorators/etc) gets started and
ends afterwards.<br>
>><br>
>> LieGrue,<br>
>> strub<br>
>><br>
>> > Am 20.06.2015 um 00:51 schrieb Anatole
Tresch<br>
>> <<a moz-do-not-send="true"
href="mailto:atsticks@gmail.com" target="_blank">atsticks@gmail.com</a>
<mailto:<a moz-do-not-send="true"
href="mailto:atsticks@gmail.com" target="_blank">atsticks@gmail.com</a>>>:<br>
>> ><br>
>> > Hi all,<br>
>> ><br>
>> > for me the question is: do we need a
RequestContext? We have<br>
>> the Event payload, which is shared (and AFAIK
also still<br>
>> mutable) and can be used to represent the
common context as<br>
>> well, for both synch or asynch event cases.
Adding a parallel<br>
>> "context" does not necessarily make things
easier IMO, because<br>
>> you have to exactly define what a request in
that sense is,<br>
>> when does it start, where does it end, how it
is<br>
>> propagated/stacked etc. So my question is:
what is the benefit<br>
>> of defining the request scope additional to
the event payload<br>
>> already in place?<br>
>> ><br>
>> > Anatole<br>
>> ><br>
>> ><br>
>> > 2015-06-18 15:10 GMT+02:00 Antoine
Sabot-Durand<br>
>> <<a moz-do-not-send="true"
href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>
<mailto:<a moz-do-not-send="true"
href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>>>:<br>
>> > Hi guys,<br>
>> ><br>
>> > We should finally decide how to manage
normal scope context<br>
>> (other than application context ) in SE and
during Async Event<br>
>> for EDR1.<br>
>> ><br>
>> > Having only RequestContext active during
async event as<br>
>> Martin suggest in the PR makes sense and
would be consistent<br>
>> with its behavior during async EJB call.<br>
>> ><br>
>> > Mark asked twice to activate Request
Context all the time in<br>
>> SE (making it a new Application Context). I’m
not found of it,<br>
>> but I’ml not the only one to decide here.<br>
>> ><br>
>> > What is you feeling about this ?<br>
>> ><br>
>> > Antoine<br>
>> ><br>
>> >
_______________________________________________<br>
>> > cdi-dev mailing list<br>
>> > <a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>
<mailto:<a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
>> > <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>> ><br>
>> > Note that for all code provided on this
list, the provider<br>
>> licenses the code under the Apache License,
Version 2<br>
>> (<a moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all<br>
>> other ideas provided on this list, the
provider waives all<br>
>> patent and other intellectual property rights
inherent in such<br>
>> information.<br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Anatole Tresch<br>
>> > Java Engineer & Architect, JSR Spec
Lead<br>
>> > Glärnischweg 10<br>
>> > CH - 8620 Wetzikon<br>
>> ><br>
>> > Switzerland, Europe Zurich, GMT+1<br>
>> > Twitter: @atsticks<br>
>> > Blogs: <a moz-do-not-send="true"
href="http://javaremarkables.blogspot.ch/" rel="noreferrer"
target="_blank">http://javaremarkables.blogspot.ch/</a><br>
>> > Google: atsticks<br>
>> > Mobile +41-76 344 62 79<br>
>> >
_______________________________________________<br>
>> > cdi-dev mailing list<br>
>> > <a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>
<mailto:<a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
>> > <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>> ><br>
>> > Note that for all code provided on this
list, the provider<br>
>> licenses the code under the Apache License,
Version 2<br>
>> (<a moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all<br>
>> other ideas provided on this list, the
provider waives all<br>
>> patent and other intellectual property rights
inherent in such<br>
>> information.<br>
>><br>
>><br>
>>
_______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>
<mailto:<a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list,
the provider<br>
>> licenses the code under the Apache License,
Version 2<br>
>> (<a moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all<br>
>> other ideas provided on this list, the
provider waives all<br>
>> patent and other intellectual property rights
inherent in such<br>
>> information.<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>
<mailto:<a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the
provider licenses the code under the Apache License, Version 2
(<a moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all other ideas provided on this list, the provider waives
all patent and other intellectual property rights inherent in
such information.<br>
><br>
><br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the
provider licenses the code under the Apache License, Version 2
(<a moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all other ideas provided on this list, the provider waives
all patent and other intellectual property rights inherent in
such information.<br>
><br>
<br>
--<br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>