If we plan to release an impl for edr1 we have to decide its behavior IMO. But I agree with you, it shouldn't take this time to do it.
Le mar. 23 juin 2015 à 08:28, Jozef Hartinger <jharting@redhat.com> a écrit :
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@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@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@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@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@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@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@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@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@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@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@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@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.