[cdi-dev] On @RequestScoped hack

Wed Jun 24 05:39:10 EDT 2015

Romain,

CDI-26 was open 4,5 years ago. Obviously working on the whole stuff in one
shot didn't made it. To get out of the dead end I didn't see other solution
than to cut the features in smaller pieces. That's why it's not finished
and I intend to explain it in my blog post. As I'll explain that the EDR is
for testing not early adoption.

Le mer. 24 juin 2015 à 11:31, Antoine Sabot-Durand <antoine at sabot-durand.net>
a écrit :

> 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> 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>:
>> >
>> > 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
>> > 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
>> 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/e1e141fe/attachment.html 