[cdi-dev] Async event proposal

Hi all, You may have missed the proposal I sent in this PR https://github.com/cdi-spec/cdi/pull/250 <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-D... <http://cdi-development-mailing-list.1064426.n5.nabble.com/Previously-on-D... 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