<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 12 Mar 2015, at 12:56, Antoine Sabot-Durand <<a href="mailto:antoine@sabot-durand.net" class="">antoine@sabot-durand.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi all,<div class=""><br class=""></div><div class="">I compiled all the feedback and decision we took regarding async events and updated the Google Doc : <a href="https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing" class="">https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing</a></div><div class=""><br class=""></div><div class="">The following point stays open. I’d like to close them (if possible) during the next meeting on Tuesday</div><div class=""><br class=""></div><div class="">1) Async delivery mechanism (comment by Jozef)</div><div class="">Should we write in the spec about how threads for events delivery should be used? Personally I’d rather not: I think this should be let to implementation, the specification should only describe the expected behavior (concurrency or not). now I may have missed something.</div><div class=""><br class=""></div><div class="">2) Exception Handling (comment by Jozef)</div><div class="">I didn’t write anything about exception and we should decide what happens if an exception occurs in an observer during async event dispatch. I think that it shouldn’t impact other observers and that we should stick to the way CompletionStage API works today.</div><div class=""><br class=""></div><div class="">3) Async event activation on both ends</div><div class="">We all agree that we need to explicitly fire event asynchronously on the producer side (fireAsync()). The discussion in 8.1 is about adding a way to accept async call on the consumer (observer) side.</div><div class="">a) As events are often triggered in other parts of the application than the parts that consume them (most CDI framework lib fire events foe end user code) preventing user to decide if an observer can be called asynchronously could lead to issues and will prevent library developper to use fireAsync() (in a defensive coding approach).</div></div></div></blockquote><div><br class=""></div><div>Why?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">b) On the other hand, when placed in the same application, it’ll be very confusing for user to have to fireAsync() and enable async observer to activate this new feature.</div><div class=""><br class=""></div><div class="">I propose an opt-out approach. We add ‘asyncSupported' member to ‘@Observes' annotation with ‘true’ as default value. So in case of b) the end user won’t have to explicitly activate async on observer and i case of a) user detecting issue coming from async treatment of an event can explicitly declares one or more observer not compatible with async resolution with @Observes(asyncSupported=False)</div></div></div></blockquote><div><br class=""></div><div>That’s really messy.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">4) Support observer ordering with async events</div><div class="">I think we should keep event ordering for synchronous event and ignore this feature in async event. I don’t see obvious use case to be async and ordered.</div><div class=""><br class=""></div><div class="">5) Context propagation</div><div class=""> I understand that propagating contexts in async event would impact easily context API. My only concern here is to be define async event to keep this feature possible.</div><div class=""><br class=""></div><div class="">If I forgot points please comment this mail and the doc so we can take final decision during next meeting.</div><div class=""><br class=""></div><div class="">Thank you</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Antoine</div><div class=""><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>