<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
My suggestion would be to not specify any temporary hack in the spec
(and revert that part of the PR). Address this properly with
CDI-530.<br>
<br>
<div class="moz-cite-prefix">On 06/24/2015 11:31 AM, Antoine
Sabot-Durand wrote:<br>
</div>
<blockquote
cite="mid:CABu-YBRM5N0g8fG1dhD4fmqt4ZDM-N_MnCpx40PazfQBBoONFQ@mail.gmail.com"
type="cite">
<div dir="ltr">Jozef,
<div><br>
</div>
<div>I think I really got your disagreement on that point. You
repeated it many times.</div>
<div><br>
</div>
<div>My point and the question I keep asking to you is "what is
your suggestion?".</div>
<div>Personally I see 5 solutions here:</div>
<div><br>
</div>
<div>1) Don't do anything since there's no alternative solution</div>
<div>2) Change the wording regarding request scope activation in
something like "is active from the initialization of the
container until its shutdown"</div>
<div>3) Give the same behavior than application scope request
scope is shared</div>
<div>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</div>
<div>5) Don't specify anything</div>
<div><br>
</div>
<div>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 ?</div>
<div><br>
</div>
<div>thanks</div>
<div><br>
</div>
<div>Antoine </div>
<div><span style="line-height:1.5;font-size:13.1999998092651px"> </span><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Le mer. 24 juin 2015 à 11:13, Mark Struberg <<a
moz-do-not-send="true" href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Jozef, read
the rest of the meeting minutes as well. Throne and I enlisted
dozen of REAL use cases where it is needed.<br>
<br>
> Does the @RequestScoped hack really address customers'
problem?<br>
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.<br>
<br>
> * A CDI implementation may add such hack by itself - no
need to have it<br>
> the spec temporarily<br>
Well that is an option but the users then cannot rely on it.<br>
<br>
<br>
And no, it is perfectly implementable as it is worded right
now.<br>
<br>
LieGrue,<br>
strub<br>
<br>
<br>
> Am 24.06.2015 um 10:50 schrieb Jozef Hartinger <<a
moz-do-not-send="true" href="mailto:jharting@redhat.com"
target="_blank">jharting@redhat.com</a>>:<br>
><br>
> Hi all,<br>
><br>
> unfortunately I did not make it to the meeting yesterday.
After reading<br>
> the transcript I found out that the @RequestScoped hack
is still being<br>
> added to the EDR. What do I mean by "@RequestScoped
hack"?<br>
> By that I am referring to the following part of the spec:<br>
><br>
> "<br>
> In Java SE:<br>
> The request scope is active during any method invocation.<br>
> The request context is destroyed when the container is
shut down.<br>
> "<br>
><br>
> This is vague, almost undefined and not correctly
implementable. Most<br>
> importantly, everyone seems to agree that it would be a
bad idea for<br>
> this to end up in the final spec. Instead, it is supposed
to be replaced<br>
> entirely by ContextControl API (<a moz-do-not-send="true"
href="https://issues.jboss.org/browse/CDI-530"
rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-530</a>)<br>
> post EDR1.<br>
><br>
> Yet, we are adding this hack to EDR1 for the meantime.
Why? The only<br>
> argument to back this was "supporting existing libraries
and applications".<br>
><br>
> That seems reasonable, doesn't it? Well, no. Antoine took
a detailed<br>
> look into probably the most prominent CDI library -
DeltaSpike. Yes, you<br>
> can find @RequestScoped beans in DeltaSpike. You can find
Servlet<br>
> artifact producers, JSF view root and navigation
handlers, etc. And<br>
> that's it. Nothing one could really use outside of the EE
stack.<br>
><br>
> That's not a coincidence. When a user marks a bean as
@RequestScoped we<br>
> can assume they do it for a reason. The reason most
likely would be to<br>
> scope the state per "task" (often HTTP request
processing) and isolate<br>
> the state from the state of other tasks. That's very
different from the<br>
> @Singleton-like behavior that the @RequestScoped hack
adds. Therefore,<br>
> even if a library exists that relies on @RequestScoped it
is not going<br>
> to work properly anyway. The @RequestScoped hack just
suppresses a fast<br>
> failure and trades it for weird state inconsistencies
later.<br>
><br>
> Another part of the argument is "existing applications".
More specifically:<br>
><br>
> "struberg: well, I have a few customers with 10k++
classes. And some<br>
> core components use it heavily"<br>
><br>
> Does the @RequestScoped hack really address customers'
problem? Remember<br>
> that the @RequestScoped hack is planned to be temporary
and replaced<br>
> with proper context control post EDR1.<br>
> Are those customers planning to migrate to EDR1
implementation (Weld<br>
> Alpha probably) before the spec gets context control? Do
they expect to<br>
> take their "10k++ class" Java EE applications, throw the
EE container<br>
> out entirely and run the *unmodified* application in a
plain Java SE<br>
> environment with CDI SE? Will their apps work even if
their<br>
> @RequestScoped beans start behaving like singletons?<br>
> Probably not, right?<br>
><br>
> And then we have early adopters of CDI 2.0. Why should
they be exposed<br>
> to magical hacks that we know are going to disappear
later?<br>
><br>
> And let's not forget that:<br>
> * CDI implementations already have their own APIs for
controlling<br>
> contexts that can be used if needed<br>
> * A CDI implementation may add such hack by itself - no
need to have it<br>
> the spec temporarily<br>
><br>
> Therefore, I cannot see a single reason for polluting the
spec with<br>
> temporary hacks.<br>
><br>
> Jozef<br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the
provider licenses the code under the Apache License, Version 2
(<a moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all other ideas provided on this list, the provider waives
all patent and other intellectual property rights inherent in
such information.<br>
<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider
licenses the code under the Apache License, Version 2 (<a
moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all other ideas provided on this list, the provider waives
all patent and other intellectual property rights inherent in
such information.<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>