Yes Jozef,
As said multiple times we cannot prevent users to mute payload in async events but they should know that it's their responsibility to do so (no concurrency or thread safety guaranteed by us).
I have no problem to revert this. My idea was to be consistent with synchronous observer returning void.
I also feared that returning an handle on the payload could confuse users, making them think that we manage concurrency and thread safety on the payload when we don't do it.
Now, adding the payload to the async pipeline coule make sense...
Antoine
On 06/04/2015 10:08 AM, Antoine Sabot-Durand wrote:
> 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.
The reason for the original signature was that it allows the event
payload to be processed further once all the observers finish. This is
useful in the common pattern where you fire a mutable event, let the
(possibly unknown) observers contribute to the result by mutating the
payload, and then work with the payload when all finish. See e.g.
https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/experimental/event/async/complex/ComplexAsyncEventTest.java#L74
This of course assumes mutable event payloads are supported.