<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Thanks Jozef,</div><div class=""><br class=""></div><div class="">You’re right. The best solution would be to prove that this doesn’t break backward compatibility. I had the same feeling than you but I’d like the majority of us to agree with this approach.</div><div class=""><br class=""></div><div class="">Antoine</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">Le 3 févr. 2015 à 09:39, Jozef Hartinger <<a href="mailto:jharting@redhat.com" class="">jharting@redhat.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
We should enumerate all the arguments supporting async flag on an
observer. So far I have only seen one:<br class="">
<br class="">
- an observer accessing @RequestScoped state would no longer be able
to do so since it would be run in a worker thread<br class="">
<br class="">
I am eager to hear more arguments as this single one may not be
enough to justify the observer-async-flag design decision.<br class="">
<br class="">
Remember that introducing fireAsync() itself does not break any
existing application because existing applications are using fire().
It's when an existing application / library is modified to use
fireAsync() when the problem may occur. Such change should not be
done blindly. As with any other change, an author should consider
possible consequences of the change. Clearly documenting the fact
that fireAsync() processing is done in a different thread with a
different @RequestScoped state may be sufficient.<br class="">
<br class="">
Jozef<br class="">
<br class="">
<div class="moz-cite-prefix">On 02/02/2015 03:43 PM, Antoine
Sabot-Durand wrote:<br class="">
</div>
<blockquote cite="mid:03610812-D29F-44AE-B130-B36E23153796@sabot-durand.net" type="cite" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
Hi all,
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><a moz-do-not-send="true" href="https://issues.jboss.org/browse/CDI-499" class="">https://issues.jboss.org/browse/CDI-499</a> comes
after a lot of discussion about async events.</div>
<div class=""><br class="">
</div>
<div class="">I think the solution exposed here is quite
satisfying, yet the idea to need to activate async behaviour on
the observer side doesn’t please a lot of us. It’ll be confusing
for users to have to activate async from the firing end and
consuming end to see it work :-(.</div>
<div class=""><br class="">
</div>
<div class="">I’d like to see alternative proposal to have this
new feature as user friendly as possible and keep the
retro-compatibility aspect. We should find a better solution on
our next meeting on wednesday.</div>
<div class=""><br class="">
</div>
<div class="">Antoine</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
cdi-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a class="moz-txt-link-freetext" href="http://www.apache.org/licenses/LICENSE-2.0.html">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.</pre>
</blockquote>
<br class="">
</div>
</div></blockquote></div><br class=""></body></html>