[cdi-dev] On @RequestScoped hack

[Mark Struberg]

No of course not, but we should imo _always_ deliver something something ‚real‘ and never anything which comes from an ivorytower and cannot be used in reality.


> Will their apps work even if their
> @RequestScoped beans start behaving like singletons?

It doesn’t. It’s more like ’@ThreadScoped’ in that case…

LieGrue,
strub

> Am 24.06.2015 um 11:25 schrieb Jozef Hartinger <jharting at redhat.com>:
> 
> 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.