Le 19 mars 2015 à 15:51, Romain Manni-Bucau
<rmannibucau(a)gmail.com> a écrit :
sounds like a quick and dirty solution to me. @Async will arrive
Yes like in “Async is coming” ;)
- 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).
and if we add an @Async in our spec you think it’s better ?
Do we really want this feature at this price?
#1 requested feature by users.
If yes AsyncObserves sounds an acceptable compromise but still will
mess up the API IMO.
The question is “Is it more or less messy than @Async @Observes?" I don’t know… It
has pros and cons as I listed...
Romain Manni-Bucau
@rmannibucau <
https://twitter.com/rmannibucau> | Blog
<
http://rmannibucau.wordpress.com/> | Github <
https://github.com/rmannibucau>
| LinkedIn <
https://www.linkedin.com/in/rmannibucau> | Tomitriber
<
http://www.tomitribe.com/>
2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net
<mailto: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(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/cdi-dev
<
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
<
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.