Agree with Jozef. This looks like we are asking users to review something we know we'll not keep. Sounds very wrong even if the motivation is "no time to do it right before the release". We can just mention we'll be able to handle req scope manually but that it is not yet final/done.

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

2015-06-24 11:25 GMT+02:00 Jozef Hartinger <>:
On 06/24/2015 11:10 AM, Mark Struberg wrote:
>> Does the @RequestScoped hack really address customers' problem?
> Yes it does. In the final spec a programmer could programmatically enable the request context and ends it again IF he needs it. But today he cannot. And many users code really needs it. So the only thing we can do TODAY is to enable it by default.
Are those customers planning to migrate to EDR1 implementation (Weld
Alpha probably) before the spec gets context control? Do they expect to
take their "10k++ class" Java EE applications, throw the EE container
out entirely and run the *unmodified* application in a plain Java SE
environment with CDI SE? Will their apps work even if their
@RequestScoped beans start behaving like singletons?
>> * A CDI implementation may add such hack by itself - no need to have it
>> the spec temporarily
> Well that is an option but the users then cannot rely on it.
We are talking about an early draft. Users cannot and shouldn't really
rely on anything in the draft as chances are it is going to change.
cdi-dev mailing list

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.