Given that we plan on adding ContextControl to the spec, which deals
with this much better, why even bother figuring out and specifying a
temporary solution for the meantime?
On 06/23/2015 07:20 AM, Mark Struberg wrote:
+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.
LieGrue,
strub
> Am 22.06.2015 um 14:52 schrieb Antoine Sabot-Durand
<antoine(a)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(a)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(a)redhat.com
>> <mailto:jharting@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(a)yahoo.de
>>> <mailto:struberg@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(a)gmail.com <mailto: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(a)sabot-durand.net
<mailto: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(a)lists.jboss.org <mailto: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(a)lists.jboss.org <mailto: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(a)lists.jboss.org <mailto: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(a)lists.jboss.org <mailto: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(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.
>>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> 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.