<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=""><div class="">Hi Sven,</div><div class=""><br class=""></div><div class="">We could figure something like that. During last meeting I proposed this (extracted from the log)</div><div class=""><br class=""></div><div class=""><pre style="white-space: pre-wrap; widows: 1;" class=""><span class="tm" style="color: rgb(0, 112, 32);">17:42:51</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> could we imagine something based on bean archive version
<a name="l-115" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:43:27</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <Jose_P></span> the question of the contexts should be treated separately imho
<a name="l-116" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:44:15</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> having async behavior as I proposed only if bean archive are explicitly stated at version 2.x ?
<a name="l-117" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:44:33</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <jharting></span> that would eliminate implicit bean archives
<a name="l-118" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:44:52</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> yes I know jharting
<a name="l-119" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:44:57</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> :-(
<a name="l-120" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:45:53</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> imagine you have this AsyncSupported member
<a name="l-121" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:45:58</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> with an enum value
<a name="l-122" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:46:15</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> auto,true,false
<a name="l-123" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:46:23</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> default value is at auto
<a name="l-124" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:46:47</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> if you explictly says that your BA is version 2.0
<a name="l-125" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:46:49</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> auto is like true
<a name="l-126" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:46:57</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> if not it's like false
<a name="l-127" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:47:04</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> and you'll have to opt-in
<a name="l-128" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:48:00</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> I see you frowning accros the connection jharting ;)
<a name="l-129" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:48:51</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> so for implicit BA you'll have to opt-in
<a name="l-130" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:49:48</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> for explicit BA with version 2.0 you'll have nothing to do to have async (you can still opt-in)
<a name="l-131" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:50:02</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> and can opt-out for a given observer
<a name="l-132" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:50:32</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> I'm not sure about the user friendness of this solution ;)
<a name="l-133" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:51:07</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <jharting></span> it's pretty complicated
<a name="l-134" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:51:15</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <th_janssen></span> I was just wondering how to explain the different behaviour based on some version number :D
<a name="l-135" class=""></a><span class="tm" style="color: rgb(0, 112, 32);">17:51:35</span><span class="nk" style="color: rgb(6, 40, 115); font-weight: bold;"> <antoine_sd></span> I agree</pre><div class=""><br class=""></div></div><div class="">On the paper that could be a good solution, but implicit bean archive add too much complexity here. The only solution would have an easy way to know if a bean archive was compiled with CDI 2.0 API… Having a specific annotation for Async Observer is probably a more standard solution... </div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">Le 19 mars 2015 à 22:37, Sven Linstaedt <<a href="mailto:sven.linstaedt@gmail.com" class="">sven.linstaedt@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Could this opt-in/opt-out problem be defaulted with a new beans.xml version? So older bean archive's observers will be handled synchronously even when the event is triggered asynchronously and the "newer" bean archive's observer will be triggered async, if the caller fired the event async?</span></div><div class=""><br class=""></div><div class="">BR, Sven <br class=""><br class="">-- sent by phone</div><div class=""><br class="">Am 19.03.2015 um 17:19 schrieb Antoine Sabot-Durand <<a href="mailto:antoine@sabot-durand.net" class="">antoine@sabot-durand.net</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">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 class="">If you have the solution without opt-in I’m all ears.</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 19 mars 2015 à 16:52, José Paumard <<a href="mailto:jose.paumard@gmail.com" class="">jose.paumard@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">> <span style="font-size:12.8000001907349px" class="">So it seems impossible to avoid opt-in on the observer side</span><div class=""><span style="font-size:12.8000001907349px" class="">What is the "killer" argument for that ? </span></div><div class=""><span style="font-size:12.8000001907349px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8000001907349px" class="">José</span></div></div><div class="gmail_extra"><br class=""><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:0 0 0 .8ex;border-left:1px #ccc 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=""><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=""><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=""><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:0 0 0 .8ex;border-left:1px #ccc 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><br class="">_______________________________________________<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="">
<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=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature"><div class=""><a href="http://blog.paumard.org/" target="_blank" class="">Java le soir</a> <a href="http://blog.paumard.org/cours-tutoriaux/" target="_blank" class="">Cours Java en ligne</a></div><div class=""><a href="http://twitter.com/#!/JosePaumard" target="_blank" class="">Twitter</a> <a href="http://www.parisjug.org/" target="_blank" class="">Paris JUG</a> <a href="http://www.devoxx.fr/" target="_blank" class="">Devoxx France</a></div><div class="">M : +33 6 76 82 91 47</div></div>
</div>
</div></blockquote></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">cdi-dev mailing list</span><br class=""><span class=""><a href="mailto:cdi-dev@lists.jboss.org" class="">cdi-dev@lists.jboss.org</a></span><br class=""><span class=""><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" class="">https://lists.jboss.org/mailman/listinfo/cdi-dev</a></span><br class=""><span class=""></span><br class=""><span 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" 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.</span></div></blockquote></div></div></blockquote></div><br class=""></body></html>