+1 . So far the spec has been listing the situations in which a particular context is active. Not in which it is inactive. We should carry on with that IMO.

On 06/24/2015 04:38 PM, Romain Manni-Bucau 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 ?