[cdi-dev] On @RequestScoped hack

Wed Jun 24 05:37:54 EDT 2015

My suggestion would be to not specify any temporary hack in the spec 
(and revert that part of the PR). Address this properly with CDI-530.

On 06/24/2015 11:31 AM, Antoine Sabot-Durand wrote:
> Jozef,
>
> I think I really got your disagreement on that point. You repeated it 
> many times.
>
> My point and the question I keep asking to you is "what is your 
> suggestion?".
> Personally I see 5 solutions here:
>
> 1) Don't do anything since there's no alternative solution
> 2) Change the wording regarding request scope activation in something 
> like "is active from the initialization of the container until its 
> shutdown"
> 3) Give the same behavior than application scope request scope is shared
> 4) Revert and say that Request Scope is not active in SE. But it's 
> also a hack since we'll change it with CDI-530
> 5) Don't specify anything
>
> I guess that you're choice is 4 or 5, but I may be wrong again, so why 
> not tell us what you'd like to see and save us some time ?
>
> thanks
>
> Antoine
>
>
>
> Le mer. 24 juin 2015 à 11:13, Mark Struberg <struberg at yahoo.de 
> <mailto:struberg at yahoo.de>> a écrit :
>
>     Jozef, read the rest of the meeting minutes as well. Throne and I
>     enlisted dozen of REAL use cases where it is needed.
>
>     > 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.
>
>     > * 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.
>
>
>     And no, it is perfectly implementable as it is worded right now.
>
>     LieGrue,
>     strub
>
>
>     > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger
>     <jharting at redhat.com <mailto:jharting at redhat.com>>:
>     >
>     > 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
>     > _______________________________________________
>     > cdi-dev mailing list
>     > cdi-dev at lists.jboss.org <mailto:cdi-dev at 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.
>
>
>     _______________________________________________
>     cdi-dev mailing list
>     cdi-dev at lists.jboss.org <mailto:cdi-dev at 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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150624/1e83925e/attachment-0001.html 