Re: [cdi-dev] What about @AsyncObserves ?

Hi guys, So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. 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 ? So it would be public void myObserver(*@AsyncObserves* payload) {} instead of *@Async* public void myObserver(@Observes payload) {} Pros : - it’s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one - it could have new members related to async behavior (context propagation, concurrent scenario, etc…) - As it won’t be in legacy code no risk to see old observers called asynchronously Cons : - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously - Yet another annotation added wdyt ? Antoine _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.