You may have missed the proposal I sent in this PR https://github.com/cdi-spec/cdi/pull/250.

It gathers most facts we agreed on regarding async events but I had to make some choices that could be discussed t have a consistent a real proposal:

1) Introducing @ObservesAsync

I won’t go back on the discussion around backward compatibility for Asyc Event. If you want  read a sum up on it please go there: http://cdi-development-mailing-list.1064426.n5.nabble.com/Previously-on-Double-end-async-events-activation-tp5711284.html

We had 4 solutions to activate async on the observer side. I removed the ones bringing modification to @Observes annotation, removed the @Async solution since I didn’t want to to introduce such a generic annotation in CDI and the place to put it elsewhere in Java EE is not obvious. That would let us @AsyncSupported and @ObservesAsync solutions. I kept @ObservesAsync because it’s simpler for user to have only one annotation to activate this feature and because @AsyncSupport didn’t seems to have other application than activating async on observer.

I think form an user pov it’s the less worst solution to support this double activation requirement

2) Restricting fireAsync to ObservesAsync

Following the logic in 1 my draft restrict fireAsync call to only notify ObservesAsync observers. As we introduce a new feature and don’t want to break previously existing one I found this approach less confusing for our users. If we’re not happy with this restriction we could add parameter to fireAsync to target synchronous observer as well, but I really think we should consider this default behavior…

3) Change fireAsync signature

In our initial proposal fireAsync basic signature was

<U extends T> CompletionStage<U> fireAsync(U event);

I simplified the signature with  

CompletionStage<void> fireAsync (U event);

As the original fire method returns void I found confusing to return anything something letting think that a value (different than a status) was obtained from the observers notification.

As Jozef pointed there are aspect lacking to the proposal. I plan to add a solution to solve multiple exception and need proposal for Invocation context definition and mention for thread safety.

So help and feedback are welcome.

Antoine