[cdi-dev] On @RequestScoped hack

Wed Jun 24 06:07:55 EDT 2015

the issue isnot hqving something temporary but something temporary and
really different from the final solution we seem to all desire.

Stupid question surely but qsking it qnyway: cant we add a ContextControl
taken from deltaspike in the EDR and the refine it? sounds like a closer
solution than activating a scope then removing this.

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 12:04 GMT+02:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

> Ok, let me phrase it again: "the EDR is not a partial spec, feature in it
> can be amend, changed or totally removed". It's main purpose is to have our
> end users feedback.
> This idea of having a temporary specified part was introduced nearly 2
> months ago and was discussed many time... Would have been nice to have this
> discussion before doing the work.
>
>
> 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/f1544a8d/attachment-0001.html 