I agree. The EDR is supposed to be a draft for review. It’s not supposed to be production ready.

Add a note saying “OPEN ISSUE: We need to provide the ability to start the request scope”.

In Weld, you can add a release note saying how to do it in Weld.

On 24 Jun 2015, at 10:38, Romain Manni-Bucau <rmannibucau@gmail.com> wrote:

What happen if we say nothing? will not hurt later IMHO


Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber

2015-06-24 16:28 GMT+02:00 Antoine Sabot-Durand <antoine@sabot-durand.net>:
Ok, but now in the chapter I have mention for Session Scope and conversation Scope not being active in SE. Wouldn't it be strange to have no mention of Request Scope or should we make a "temp hack" saying that session scope is not active...

Le mer. 24 juin 2015 à 16:22, Jozef Hartinger <jharting@redhat.com> a écrit :
Depends on the spec mostly.

For @RequestScoped there is no natural notion of a request in plain Java
SE. It's the user that needs to set the boundaries of a task that the
@RequestScope is supposed to represent. This can be done using Weld API
and hopefully using ContextControl soon. In the meantime I see no point
in blurring this with magical contexts that try to guess what the use wants.

That means that the context is not active by default but can be
controlled using the API.

On 06/24/2015 03:56 PM, Antoine Sabot-Durand wrote:
> Jozef,
>
> Sorry my question wasn't precise enough. What will be the Request
> Context behavior in your implementation of EDR1 ?


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