<div dir="ltr"><div>I see the situation as being : <br></div><div>- CDI 1.x : I call event.fireEvent(...), there is an observer that is called. Currently it is called in the same thread. </div><div>- CDI 2.0 : I call event.fireEvent(...), there is an observer that is called. It will be called in the same thread. </div><div><br></div><div>So what is the backward compatibility issue here ? From what I understand it just works the same. </div><div><br></div><div>José</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-19 17:19 GMT+01:00 Antoine Sabot-Durand <span dir="ltr"><<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>The killer argument is that nobody succeed to provide a way to prevent opt-in and keep backward compaibility. The problem comes from the fact that producer and consumer can be in different jar compiled with different version of CDI and running on CDI 2.0 preventing using opt-out.</div><div>If you have the solution without opt-in I’m all ears.</div><div><br></div><br><div><blockquote type="cite"><div>Le 19 mars 2015 à 16:52, José Paumard <<a href="mailto:jose.paumard@gmail.com" target="_blank">jose.paumard@gmail.com</a>> a écrit :</div><div><div class="h5"><br><div><div dir="ltr">> <span style="font-size:12.8000001907349px">So it seems impossible to avoid opt-in on the observer side</span><div><span style="font-size:12.8000001907349px">What is the "killer" argument for that ? </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">José</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand <span dir="ltr"><<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>Le 19 mars 2015 à 15:51, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>> a écrit :</div><span><br><div><div dir="ltr">sounds like a quick and dirty solution to me. @Async will arrive</div></div></span></blockquote><div><br></div><div>Yes like in “Async is coming” ;)</div><span><br><blockquote type="cite"><div><div dir="ltr"> - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually).</div></div></blockquote><div><br></div></span><div>and if we add an @Async in our spec you think it’s better ?</div><span><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Do we really want this feature at this price?</div></div></div></blockquote><div><br></div></span><div>#1 requested feature by users.</div><span><br><blockquote type="cite"><div><div dir="ltr"><div>If yes <b style="font-size:12.8000001907349px">AsyncObserves </b><span style="font-size:12.8000001907349px">sounds an acceptable compromise but still will mess up the API IMO.</span></div></div></div></blockquote><div><br></div></span><div>The question is “Is it more or less messy than @Async @Observes?" I don’t know… It has pros and cons as I listed... </div><div><div><br><blockquote type="cite"><div><div class="gmail_extra"><br clear="all"><div><div><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-03-19 15:36 GMT+01:00 Antoine Sabot-Durand <span dir="ltr"><<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi guys,<div><br></div><div><br></div><div>So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility.</div><div>Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don’t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ?</div><div><br></div><div><div>So it would be</div><div><br></div><div>public void myObserver(<b>@AsyncObserves</b> payload) {}</div><div><br></div><div>instead of</div><div><br></div><div><b>@Async</b></div><div>public void myObserver(@Observes payload) {}</div></div><div><br></div><div><br></div><div>Pros :</div><div>- it’s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one</div><div>- it could have new members related to async behavior (context propagation, concurrent scenario, etc…)</div><div>- As it won’t be in legacy code no risk to see old observers called asynchronously </div><div><br></div><div>Cons :</div><div>- Still not clear for users when fire() is called to see @AsyncObserves launched synchronously</div><div>- Yet another annotation added</div><div><br></div><div>wdyt ?</div><span><font color="#888888"><div><br></div><div>Antoine</div></font></span></div><br>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" 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" 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><br></div>
</div></blockquote></div></div></div><br></div><br>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" 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" 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><br><br clear="all"><div><br></div>-- <br><div><div><a href="http://blog.paumard.org/" target="_blank">Java le soir</a> <a href="http://blog.paumard.org/cours-tutoriaux/" target="_blank">Cours Java en ligne</a></div><div><a href="http://twitter.com/#!/JosePaumard" target="_blank">Twitter</a> <a href="http://www.parisjug.org/" target="_blank">Paris JUG</a> <a href="http://www.devoxx.fr/" target="_blank">Devoxx France</a></div><div>M : <a href="tel:%2B33%206%2076%2082%2091%2047" value="+33676829147" target="_blank">+33 6 76 82 91 47</a></div></div>
</div>
</div></div></div></blockquote></div><br></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div><a href="http://blog.paumard.org" target="_blank">Java le soir</a> <a href="http://blog.paumard.org/cours-tutoriaux/" target="_blank">Cours Java en ligne</a></div><div><a href="http://twitter.com/#!/JosePaumard" target="_blank">Twitter</a> <a href="http://www.parisjug.org" target="_blank">Paris JUG</a> <a href="http://www.devoxx.fr" target="_blank">Devoxx France</a></div><div>M : +33 6 76 82 91 47</div></div>
</div>