<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 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><div class=""><br class=""></div><div class="">Antoine</div></body></html>