[
https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy...
]
Antoine Sabot-Durand commented on CDI-563:
------------------------------------------
{quote}bq. What do you think we should add?
I don't like the wording "called in a new lifecycle contexts". What exactly
does it mean? Maybe we should just rephrase this.{quote}
I'm not a big fan of this wording either. But it came from discussion with Jozef, and
the fact that for the sake of non-denormalize the spec we shouldn't repeat what is
said in [
6.7|http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#builtin_contexts]:
bq. The context associated with a built-in normal scope propagates across local,
synchronous Java method calls. The context does not propagate across remote method
invocations or to asynchronous processes.
Perhaps we could find a way to have a clearer phrase pointing to this assertion. It lets
the possibility for a third party to create a normal scope supporting propagation.
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}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)