<div dir="ltr">Agree with Jozef. This looks like we are asking users to review something we know we'll not keep. Sounds very wrong even if the motivation is "no time to do it right before the release". We can just mention we'll be able to handle req scope manually but that it is not yet final/done.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">2015-06-24 11:25 GMT+02:00 Jozef Hartinger <span dir="ltr"><<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/24/2015 11:10 AM, Mark Struberg wrote:<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>
</span><span class="">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>
><br>
</span><span class="">>> * 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>
</span>We are talking about an early draft. Users cannot and shouldn't really<br>
rely on anything in the draft as chances are it is going to change.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a 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 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>
</div></div></blockquote></div><br></div>