3:08 a.m.
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
1:49 a.m.
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/o...
This of course assumes mutable event payloads are supported.
12:43 p.m.
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(a)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/o...
This of course assumes mutable event payloads are supported.
6:39 a.m.
I like the idea of returning the event payload but it would be inconsistent
with the existing fire(U event) method. Am I right, that changing the old
fire method in the same way is not an option?
Regards,
Thorben
--
*Thorben Janssen*
@thjanssen123 <https://twitter.com/thjanssen123>
www.thoughts-on-java.org
2015-06-05 19:43 GMT+02:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net>:
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(a)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/o...
>
> This of course assumes mutable event payloads are supported.
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
3491
days inactive
3493
days old
3 comments
3 participants
participants (3)
-
Antoine Sabot-Durand -
Jozef Hartinger -
Thorben Janssen