[cdi-dev] Some more thoughts on async events

José Paumard jose.paumard at gmail.com
Tue Mar 24 15:59:10 EDT 2015

Hi all,

We had many discussions on this very hot topic. We really need to come with
a good pattern, since a lot of people are expecting async features in CDI

So far, we have a fireAsync(...) on the firing side and an opt-in element
on the observer side, to prevent accidental async call of an observer that
needs to be called in the context of a transaction (for instance).

Having to add this opt-in element on all our legacy observers will be very
tedious, so we need to come with a better pattern here.

We could add some information in the beans.xml, that would affect all the
observers of the bean archive. Something that would tell "this bean archive
globally supports asynchronous calls", that would act as a global opt-in.
Then we also need a mean to opt-out observers one by one, because we'll
have to deal with exceptions to this global rule.

Of course it could be done in the other way round: a global opt-out (bean
archive-wise) and individual opt-ins.

If there is no beans.xml, or a beans.xml without this information, the
default behavior would be "asynch is not supported" for backward
compatibility reasons.

This individual opt-in / opt-out then becomes an override to a global rule
set in the beans.xml, or defaulted to "async not supported". It can be
expressed in the beans.xml itself, or with annotations on the observers. To
deal with the potential incompatibility of adding an attribute to the
existing @Observes annotation, we could propose a new annotation, something
like @AsyncSupported(true) for instance.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150324/a1cc90c8/attachment.html 

More information about the cdi-dev mailing list