]
Antoine Sabot-Durand commented on CDI-563:
------------------------------------------
I'm not sure to get your point.
We are using API (and impl) provided by Java 8. Async event behavior won't be more
confusing than this standard API.
Regarding context propagation as we said we won't support it, I don't think
it'll be a problem
Event.fireAsync() - clarify the usage of the returned
CompletionStage
---------------------------------------------------------------------
Key: CDI-563
URL:
https://issues.jboss.org/browse/CDI-563
Project: CDI Specification Issues
Issue Type: Clarification
Components: Events
Affects Versions: 2.0-EDR1
Reporter: Martin Kouba
So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple
exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc
is too general. However, the {{CompletionStage}} itself does not define an unambiguous
contract for its methods. E.g. what thread is used to execute a given callback? Or
what's the _"stage's default asynchronous execution facility"_? I
believe this is left on implementors. In Weld 3.0 Alpha we're using
{{CompletableFuture}} under the hood, and its more concrete in this area, e.g.:
{quote}
* Actions supplied for dependent completions of _non-async_ methods may be performed by
the thread that completes the current CompletableFuture, or by any other caller of a
completion method.
{quote}
So as a result, if an async delivery is finished before a sync dependent action is
registered, the callback is executed in the caller thread:
{code:java}
event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might
be executed in a caller thread or in a different thread!"));
{code}
And this might be confusing. Especially from the context propagation point of view. I
think the spec should clarify the contract of a returned {{CompletionStage}}.