[cdi-dev] Async event proposal

[Antoine Sabot-Durand]

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


Le ven. 5 juin 2015 à 08:49, Jozef Hartinger <jharting at redhat.com> a écrit :

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150605/aeba6b78/attachment.html