[cdi-dev] On @RequestScoped hack

[Jozef Hartinger]

Hi all,

unfortunately I did not make it to the meeting yesterday. After reading 
the transcript I found out that the @RequestScoped hack is still being 
added to the EDR. What do I mean by "@RequestScoped hack"?
By that I am referring to the following part of the spec:

"
In Java SE:
The request scope is active during any method invocation.
The request context is destroyed when the container is shut down.
"

This is vague, almost undefined and not correctly implementable. Most 
importantly, everyone seems to agree that it would be a bad idea for 
this to end up in the final spec. Instead, it is supposed to be replaced 
entirely by ContextControl API (https://issues.jboss.org/browse/CDI-530) 
post EDR1.

Yet, we are adding this hack to EDR1 for the meantime. Why? The only 
argument to back this was "supporting existing libraries and applications".

That seems reasonable, doesn't it? Well, no. Antoine took a detailed 
look into probably the most prominent CDI library - DeltaSpike. Yes, you 
can find @RequestScoped beans in DeltaSpike. You can find Servlet 
artifact producers, JSF view root and navigation handlers, etc. And 
that's it. Nothing one could really use outside of the EE stack.

That's not a coincidence. When a user marks a bean as @RequestScoped we 
can assume they do it for a reason. The reason most likely would be to 
scope the state per "task" (often HTTP request processing) and isolate 
the state from the state of other tasks. That's very different from the 
@Singleton-like behavior that the @RequestScoped hack adds. Therefore, 
even if a library exists that relies on @RequestScoped it is not going 
to work properly anyway. The @RequestScoped hack just suppresses a fast 
failure and trades it for weird state inconsistencies later.

Another part of the argument is "existing applications". More specifically:

"struberg: well, I have a few customers with 10k++ classes. And some 
core components use it heavily"

Does the @RequestScoped hack really address customers' problem? Remember 
that the @RequestScoped hack is planned to be temporary and replaced 
with proper context control post EDR1.
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?
Probably not, right?

And then we have early adopters of CDI 2.0. Why should they be exposed 
to magical hacks that we know are going to disappear later?

And let's not forget that:
* CDI implementations already have their own APIs for controlling 
contexts that can be used if needed
* A CDI implementation may add such hack by itself - no need to have it 
the spec temporarily

Therefore, I cannot see a single reason for polluting the spec with 
temporary hacks.

Jozef