<div dir="ltr">Hi all, <div><br></div><div>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 2.0. </div><div><br></div><div>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). </div><div><br></div><div>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. </div><div><br></div><div>We could add some information in the beans.xml, that would affect all the observers of the bean archive. Something that would tell &quot;this bean archive globally supports asynchronous calls&quot;, that would act as a global opt-in. Then we also need a mean to opt-out observers one by one, because we&#39;ll have to deal with exceptions to this global rule. </div><div><br></div><div><div>Of course it could be done in the other way round: a global opt-out (bean archive-wise) and individual opt-ins. </div></div><div><br></div><div>If there is no beans.xml, or a beans.xml without this information, the default behavior would be &quot;asynch is not supported&quot; for backward compatibility reasons. </div><div><br></div><div>This individual opt-in / opt-out then becomes an override to a global rule set in the beans.xml, or defaulted to &quot;async not supported&quot;. 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. </div><div><br></div><div>José</div><div><div><br></div>-- <br><div class="gmail_signature"><br></div>
</div></div>