Re: [cdi-dev] On @RequestScoped hack

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(a)sabot-durand.net&gt; 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(a)yahoo.de&gt; 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(a)redhat.com&gt;: >> > >> > 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(a)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(a)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(a)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.