<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 19 Mar 2015, at 15:54, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" class="">rmannibucau@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div></div></div></div></div></div><div class="gmail_quote">2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand <span dir="ltr" class=""><<a href="mailto:antoine@sabot-durand.net" target="_blank" class="">antoine@sabot-durand.net</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 19 mars 2015 à 15:51, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank" class="">rmannibucau@gmail.com</a>> a écrit :</div><span class=""><br class=""><div class=""><div dir="ltr" class="">sounds like a quick and dirty solution to me. @Async will arrive</div></div></span></blockquote><div class=""><br class=""></div><div class="">Yes like in “Async is coming” ;)</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""> - 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 class=""><br class=""></div></span><div class="">and if we add an @Async in our spec you think it’s better ?</div><span class=""><br class=""></span></div></div></blockquote><div class=""><br class=""></div><div class="">no we agree </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Do we really want this feature at this price?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">#1 requested feature by users.</div><span class=""><br class=""></span></div></div></blockquote><div class=""><br class=""></div><div class="">not a reason to mess up the spec IMO. One of the best feature of EE is its stability, here I think we break this basic rule knowing it which doesn't sound professional from my window.</div><div class=""><br class=""></div><div class="">This feature is important but already doable today - I guess all vendors provide a solution so business wise you are not blocked and you can even stay portable with very few code (even no code in EE).</div><div class=""><br class=""></div><div class="">Other point is defining a more appropriated API is surely needed interacting with the @async/threading spec. EE concurrency spec has something which could help in context propagation if spec is updated: <a href="http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html" class="">http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html</a></div><div class=""><br class=""></div><div class="">can be a way to get context propagation but manually this way it is a "use it at your own risk" solution which is the best can do.</div></div></div></div></div></blockquote><div><br class=""></div><div>I agree, we shouldn’t deliver this as currently proposed. What about adding SPI hooks to the core, so that e.g. DeltaSpike could implement something over the top that allows the nice programming model. We can then adopt in to the spec in 2.1?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">If yes <b style="font-size:12.8000001907349px" class="">AsyncObserves </b><span style="font-size:12.8000001907349px" class="">sounds an acceptable compromise but still will mess up the API IMO.</span></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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 class=""><div class="h5"><br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">agree, both are intermediary states probably which is not satisfying. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class="h5"><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br clear="all" class=""><div class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""><span style="font-size:small" class="">Romain Manni-Bucau</span><br class=""><a href="https://twitter.com/rmannibucau" target="_blank" class="">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com/" target="_blank" class="">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank" class="">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank" class="">LinkedIn</a> | <a href="http://www.tomitribe.com/" target="_blank" class="">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br class=""><div class="gmail_quote">2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand <span dir="ltr" class=""><<a href="mailto:antoine@sabot-durand.net" target="_blank" class="">antoine@sabot-durand.net</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Hi guys,<div class=""><br class=""></div><div class=""><br class=""></div><div class="">So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility.</div><div class="">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 class=""><br class=""></div><div class=""><div class="">So it would be</div><div class=""><br class=""></div><div class="">public void myObserver(<b class="">@AsyncObserves</b> payload) {}</div><div class=""><br class=""></div><div class="">instead of</div><div class=""><br class=""></div><div class=""><b class="">@Async</b></div><div class="">public void myObserver(@Observes payload) {}</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Pros :</div><div class="">- 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 class="">- it could have new members related to async behavior (context propagation, concurrent scenario, etc…)</div><div class="">- As it won’t be in legacy code no risk to see old observers called asynchronously </div><div class=""><br class=""></div><div class="">Cons :</div><div class="">- Still not clear for users when fire() is called to see @AsyncObserves launched synchronously</div><div class="">- Yet another annotation added</div><div class=""><br class=""></div><div class="">wdyt ?</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Antoine</div></font></span></div><br class="">_______________________________________________<br class="">
cdi-dev mailing list<br class="">
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank" class="">cdi-dev@lists.jboss.org</a><br class="">
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br class="">
<br class="">
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" class="">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 class=""></blockquote></div><br class=""></div>
</div></blockquote></div></div></div><br class=""></div></blockquote></div><br class=""></div></div>
_______________________________________________<br class="">cdi-dev mailing list<br class=""><a href="mailto:cdi-dev@lists.jboss.org" class="">cdi-dev@lists.jboss.org</a><br class="">https://lists.jboss.org/mailman/listinfo/cdi-dev<br class=""><br class="">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.</div></blockquote></div><br class=""></body></html>