[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy... ] 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_me...], 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? -- This message was sent by Atlassian JIRA (v6.4.11#64026)