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@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.