[cdi-dev] On @RequestScoped hack

Wed Jun 24 05:51:46 EDT 2015

So Jozef,

1) do you suggest to remove only the request context part or all chapter 14
(https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#contexts_se),
which could make more sense.
2) What will be the request and application context behavior in the RI?

Le mer. 24 juin 2015 à 11:41, Romain Manni-Bucau <rmannibucau at gmail.com> a
écrit :

> @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/9cb0e727/attachment.html 