Le 19 mars 2015 à 15:51, Romain Manni-Bucau <rmannibucau@gmail.com> a écrit :

sounds like a quick and dirty solution to me. @Async will arrive

- maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually).

Do we really want this feature at this price?

If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO.

Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber

2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand <antoine@sabot-durand.net>:

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.