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.

Hi Romain, Thanks for your feedback Le 25 mars 2015 à 15:00, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a écrit : few comments inline 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-25 14:45 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; : > 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 > > I'm not sure. A framework will not use fireAsync() for its existing base (CDI 1.x) but for new usages I think it will if relevant cause there is yet no observer out there. Perhaps but we cannot speculate on that. Given the very open observer resolution rules we have (an observer on Object with default qualifier will be called for all events), user can break things without knowing it > 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 > > +1, also means async observers are useless with java 8 isn't it? Nope. Observer are not standard java invocation: you call one fire() and will trigger an unknown number of observer. If you want to have feedback on async observer (are they all complete) you need to add these async mechanism in the event bus. Having a bunch of standard observe launching async operation thru CompletableFuture API without any mean of sending feedback will be a total mess IMO. > 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. > > should work (like @Resource for JavaEE 6 I think which was missing lookup()) but still need double activation which looks to me like EJB 2 :s Yes, I add the same example in mind, but I never experimented old EE 6 code running on EE 7 with @Resource usage. I’m going to do some test to know if this option is realistic. > 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 > > -1, you orignial statement is support of async and not async observation, seems it breaks this to me. I agree, could be more confusing than good. For me it’s like a). having @Async on a method (or here @ObserveAsync in an observer) let user think that it will async without anything else needed. > 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. > > Any test using j8 to get async features without anything in CDI framework have been done? Think it is smooth enough finally and avoid to mess up CDI, allows to wait for a real async solution if needed at spec level (concurreny utilities maybe) and doesn't prevent users to use asynchronism in a proper way (compared to what we can do at framework level, ie have composition for instance). No need for test for standard async operation, it will work on SE and in EE we’ll just have to use concurrency utilities to get a managed executor. Regarding these operation the question will be do we introduce syntaxic sugar to add support in CDI (an annotation to replace 2 or 3 lines of code), right now I’d be tempted to answer “no” but I may missed specific use case like async interceptors. Again, the question here is for Async in event: as we don’t have hand on observers invocation we have to enhance the event engine to support this async behavior in order to get feedback of these async operations. > 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. >

Le 25 mars 2015 à 20:28, Mark Paluch <mpaluch(a)paluch.biz&gt; a écrit : Hi Antoine, thanks for your input and this summary. I placed my comments inline. Best regards, Mark > Am 25.03.2015 um 14:45 schrieb Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: > > 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 +1 CDI 2.0 without async events seems a no-go > > > 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() +1 on fireAsync fireAsync triggers always asynchronous event processing. Currently we’re talking about interference between observers, but there are lots of other ways to do nasty things (e.g. modifying the payload from the firing thread). Any caller expects a method returning CompletionStage returning instantly, before any work is done. This leads to the point that disabling async on legacy observers would lead that fireAsync would return after those legacy observers are processed.

> > > 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 > I would add another case which might help to clarify @Priority as well: 1. fire with @Observers: same behavior as CDI 1.x 2. fireAsync with @Observes: observers are processed in any order in sequence but in a different thread

- nothing new until now - 3. fireAsync with @Observers and @Concurrent (obviously not async to prevent confusion): Observers carrying @Concurrent are running concurrently to each other (that’s the double-opt in case). Observers not having @Concurrent are handled like point 2. observer methods are not allowed to to have both, @Priority and @Concurrent 4. fire with @Observes and @Concurrent: Ability to use fire with some level of async. The behavior on the caller side does not change, fire waits until all observer method invocations are finished We should think also about ProcessObserverMethod. That’s the place where you can override any priority/(async|concurrent) settings and perhaps even the asyncSupported flag. This sort of opt-out is maybe sufficient. Now what happens, if asyncSupported=false and fireAsync? How about just skipping the observer?

> > 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…) This feels like a dirty hack and in the end you can’t tell how your application will behave.

> > 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.