[cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage

[Antoine Sabot-Durand (JIRA)]

    [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119614#comment-13119614 ] 

Antoine Sabot-Durand commented on CDI-563:
------------------------------------------

{quote}bq. I'm not sure to follow him there, especially when CompletionStage has a dependency on CompletableFuture with the toCompletableFuture() method
It's kind of a strange dependency, intended probably as a compatibility/interoperation feature. However, implementations are not required to support this conversion.{quote}
I'm not sure, but I think we should, since it's the only way to access the {{get()}} method to allow user to wait for the outcome...
{quote}
I don't think {{ForkJoinPool.commonPool()}} is a good fit for Java EE. But it's ok for Java SE.
{quote}

+1

{quote}I'm for:
* having {{CompletionStage}} in the CDI API{quote}

Yes we also agree here.

{quote}* declaring explicitly that *the stage's default asynchronous execution facility is not defined*, in other words it is implementor and environment specific
{quote}
My favorite option as well ;). I'm just not sure where to add it in the chapter

{quote}* declaring explicitly that *the context propagation is not guaranteed for ANY execution* (default execution, default async execution and custom async via a supplied Executor)
{quote}

Regarding propagation, I thought that the mention in [10.5.3. Observer method invocation context|http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#observer_method_invocation_context], was explicit enough:

bq. If the observer method is asynchronous, it is called in a new lifecycle contexts, a new transaction context but the same security context as the invocation of Event.fireAsync().

What do you think we should add?


> 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)