[cdi-dev] On @RequestScoped hack

Wed Jun 24 05:40:54 EDT 2015

@Antoine: didnt complain about the in progress status. Just prefer as Jozef
to not put something we ll revert which will lock us as @New did but in a
worse manner. Said otherwise better to not do than doing it wrong knowing
it is wrong.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-06-24 11:39 GMT+02:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

> 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.
>>>
>>
> _______________________________________________
> 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/72db1a2c/attachment-0001.html 