Re: [cdi-dev] Previously on "Double end async events activation"

Hi all, This mail is quite long, but if you want to catch up on this double end activation for async event and bring your help on this point, you should take the 10 mn to read it and make your feedback. We’ve been talking of this for more thant on month now, so it’s normal that reflection and proposition take a few lines to synthesize Discussion is going back to solution avoiding this double activation stuff for async event. To avoid explaining again why we should care and the solution we already explore here is a small wrap up of previous episodes : 1) Why is it important to take time on this? Some of you may find we already spend too many time on this question, but remember. Async events are the 1st requested stuff from the community. It has been asked for a long time (Jira ticket is CDI-4). We didn’t provided a solution for CDI 1.1 so now people are waiting this feature and they probably hope it’ll be nicely designed. To make short : if we don’t deliver users will be very disappointed, if we propose a lousy solution people will be very critic. I know that it’s better to not deliver than delivering something we are not happy with, but we really should be careful here 2) Why this double activation is needed? For the producer (fire()) side it’s rather obvious : we cannot magically change all synchronous event call to async. We need an handle on the work in progress (so a new method signature with CompletionStage), the payload mutation mechanism would break as all transactional events. So there’s no debate on fireAsync() On the Observer side, the reason is for backward compatibility. CDI events are a great way to cross boundary of our own code and activate unknown code at runtime in another piece of the app (another jar) that we don’t own. This other code can be a framework, a code developed by an other team in a big project or a legacy jar that we don’t want to touch. Imagine the following use cases (all code running on CDI 2) a) I’m compiling in CDI 1.x and one of the Jar (framework for instance) already migrated to CDI 2.0 firing async event where it use to fire sync events. Without activation on the observer side, I have all the chance to see my observer break. And if I decide to upgrade to CDI 2.0 I must have a way to activate / deactivate async call on given observers b) I’m compiling in CDI 2.0 but use jar1 in CDI 1.0 and jar2 in CDI 2.0 coming from other teams. jar2 and jar1 are old related piece of code communicating the event. The guys in jar2 had time to migrate to CDI 2.0 and switch most fire() to fireAsync(). Observer in jar1 will be called asynchronously if the default is to have async activated for all observer. I agree that these example looks like corner case but the side effect will be that no framework developper will switch to fireAsync() to prevent these issues and we’ll have an adoption problem. More than that as we are designing a Java EE specification we are committed to backward compatibility and cannot change behavior of old code, like it would do

3) Implementing this observer activation I’m listing here all the solution to deal with this requirement. For some of them I’ll add the reason we won’t adopt it or my feeling about it a) Adding or using an @Async annotation : @Async public void myObserver(@Observes Object payload) {} Personally I don’t want to add @Async to or @Asynchronous to CDI, it feels too much like an EJB-ification of the spec. If we go that way we should work to add this to Commons Annotation (simpler for CDI SE) or concurrent utilities (more consistent but not CDI SE friendly since we’ll have to get this dependency in SE). As we’ll already have to wrk on Commons Annotation for @Priority (allowing it on parameter for event ordering), it could make sens to focus our effort here. This @Async annotation could be used for async operation if we decide to add this support to CDI. The downside of this annotation is the confusion it can bring to people thinking that it will be sufficient to have an Async observer. The second objection is the confusion if we decide to not add async support operation in CDI (since it’s nearly out of the bow in Java 8). Some people won’t understand why @Async is used only on event

b) Having an @AsyncSupported annotation @AsyncSupported(true) public void myObserver(@Observes Object payload) {} An observer without this annotation will be considered having @AsyncSupported(false) by default Very similar to previous solution but rather different semantically. It doesn’t give the impression that it’s activating async behavior but it allows it. The boolean value (true by default) could be a solution if we find a nice way to activate async observer by default for our jars (code we own) and provide an opt out solution for the few observer that wouldn’t support it. Personally I don’t have issue to add this annotation to CDI since it’s more configuration than activation c) Adding a member to @Observes public void myObserver(@Observes(asyncSupported=true) Object payload) The good part of it is that it prevent us to add a new annotation. The major drawback is linking issue with oCDI 1.x code (with old @Observes) running on CDI 2.0. to my knowledge, nobody tested that so far but anyway it’s a risk.

d) Add an @ObserveAsync annotation public void myObserver(@ObserveAsync Object payload) {} As we have backward compatibility issue, introducing a brand new type of observer instead of adding annotation on observer or modifying existing @Observes annotation, could be an idea. We could imagine having specific async config in this annotation (scope to propagate if we decide to support this feature). The main downside of this is the introduction of another annotation to observe event and the confusion for user when using fire() and waiting @ObserveAsync event launch asynchronously

4) What about changing default behavior for the local jar? Idea launched by some of us. We could extend the chosen scenario by activating AsyncSupport by default on all observer on the current jar (BDA). Since the main backward compatibility issue is linked to have different CDI jar from different owners and version we could give local control to the user for his own code and jars. That could be done in beans.xml like we did for bean-discovery with an async-event attributes for instance or in code by a config annotation or event in extension (but we probably should expose the BDA concept in SPI if we go that way…) 5)Conclusion: Now you have the whole picture. If I missed things, tell me. If you like an idea please tell it, if you have a new idea or a different POV, feel free to speak.

Thanks for reading. Antoine _______________________________________________ cdi-dev mailing list cdi-dev(a)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.