<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="">Hi all,<div class=""><br class=""></div><div class=""><br class=""></div><div class="">You may have missed the proposal I sent in this PR <a href="https://github.com/cdi-spec/cdi/pull/250" class="">https://github.com/cdi-spec/cdi/pull/250</a>.</div><div class=""><br class=""></div><div class="">It gathers most facts we agreed on regarding async events but I had to make some choices that could be discussed t have a consistent a real proposal:</div><div class=""><br class=""></div><div class="">1) Introducing @ObservesAsync</div><div class=""><br class=""></div><div class="">I won’t go back on the discussion around backward compatibility for Asyc Event. If you want &nbsp;read a sum up on it please go there:&nbsp;<a href="http://cdi-development-mailing-list.1064426.n5.nabble.com/Previously-on-Double-end-async-events-activation-tp5711284.html" class="">http://cdi-development-mailing-list.1064426.n5.nabble.com/Previously-on-Double-end-async-events-activation-tp5711284.html</a></div><div class=""><br class=""></div><div class="">We had 4 solutions to activate async on the observer side. I removed the ones bringing modification to @Observes annotation, removed the @Async solution since I didn’t want to to introduce such a generic annotation in CDI and the place to put it elsewhere in Java EE is not obvious. That would let us @AsyncSupported and @ObservesAsync solutions. I kept @ObservesAsync because it’s simpler for user to have only one annotation to activate this feature and because @AsyncSupport didn’t seems to have other application than activating async on observer.</div><div class=""><br class=""></div><div class="">I think form an user pov it’s the less worst solution to support this double activation requirement</div><div class=""><br class=""></div><div class="">2) Restricting fireAsync to ObservesAsync</div><div class=""><br class=""></div><div class="">Following the logic in 1 my draft restrict fireAsync call to only notify ObservesAsync observers. As we introduce a new feature and don’t want to break previously existing one I found this approach less confusing for our users. If we’re not happy with this restriction we could add parameter to fireAsync to target synchronous observer as well, but I really think we should consider this default behavior…</div><div class=""><br class=""></div><div class="">3) Change fireAsync signature</div><div class=""><br class=""></div><div class="">In our initial proposal fireAsync basic signature was</div><div class=""><br class=""></div><div class="">&lt;U&nbsp;extends&nbsp;T&gt; CompletionStage&lt;U&gt; fireAsync(U event);<br class=""><br class="">I simplified the signature with &nbsp;</div><div class=""><br class=""></div><div class="">CompletionStage&lt;void&gt; fireAsync (U event);</div><div class=""><br class=""></div><div class="">As the original fire method returns void I found confusing to return anything something letting think that a value (different than a status) was obtained from the observers notification.</div><div class=""><br class=""></div><div class="">As Jozef pointed there are aspect lacking to the proposal. I plan to add a solution to solve multiple exception and need proposal for Invocation context definition and mention for thread safety.</div><div class=""><br class=""></div><div class="">So help and feedback are welcome.</div><div class=""><br class=""></div><div class="">Antoine</div><div class=""><br class=""></div></body></html>