[cdi-dev] What about @AsyncObserves ?

[Antoine Sabot-Durand]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/b8761614/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/b8761614/attachment.bin