[cdi-dev] On @RequestScoped hack
Jozef Hartinger
jharting at redhat.com
Wed Jun 24 09:26:45 EDT 2015
On 06/24/2015 11:51 AM, Antoine Sabot-Durand wrote:
> 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.
The request context part.
> 2) What will be the request and application context behavior in the RI?
Depends on the spec mostly.
For the application context it IMHO makes sense to be have a single
storage shared across threads that starts once CDI is booted and shuts
down with it.
For @RequestScoped there is no natural notion of a request in plain Java
SE. It's the user that needs to set the boundaries of a task that the
@RequestScope is supposed to represent. This can be done using Weld API
and hopefully using ContextControl soon. In the meantime I see no point
in blurring this with magical contexts that try to guess what the use wants.
>
> Le mer. 24 juin 2015 à 11:41, Romain Manni-Bucau
> <rmannibucau at gmail.com <mailto: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 <mailto: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 <mailto: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 <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.
>
>
> _______________________________________________
> 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/4bdd7d62/attachment-0001.html
More information about the cdi-dev
mailing list