8:45 a.m.
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