October 2015 - cdi-dev - Jboss List Archives

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

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-563: ------------------------------------------ My first idea was to go directly for {{CompletableFuture}} in our API (methods return type, etc...). [~jharting] raised concerns about using an impl where an API exist (I agreed with him) and features in CompletableFuture that we might not allow our users to have access to (I'm not sure to follow him there, especially when {{CompletionStage}} has a dependency on {{CompletableFuture}} with the {{toCompletableFuture()}} method). So even if we won't expose CompletableFuture in our API for good practices, we won't reimplement what was nicely done in JDK8 and will use {{CompletableFuture}} under the hood. That's why I dont think we can say CDI will be an implementor of {{CompletionStage}}, we will be a user of {{CompletableFuture}} thru its main interface. The only open question, IMO, is about default {{Executor}} used in {{CompletableFuture}} (based on fork/join if I'm not mistaken). [~mkouba], you're probably the best person to know if this default Executor is the best for us or if we should use our own {{Executor}} (CompletableFuture has methods to override default executor). So, unless I missed something, either we specify the behavior from default Executor in {{completableFuture}} or define ours. The user will always have the possibility to use her own Executor with the dedicated {{fireAsync()}} method. > 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)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-541: ---------------------------------- +1 For this proposal. > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-547) Resolving sync/async observer methods

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-547: ---------------------------------- +1 WRT confusion - I don't see a problem anymore, my previous comment was created in the time when {{fire()}} was used for async events as well (EDR1). > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Jozef Hartinger > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.ED...] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

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

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-563: ---------------------------------- Ok, so first the CompletionStage API itself does not define the behavior completely. E.g. "default asynchronous execution facility" is left on implementors - and CDI is de facto an implementor. If we don't state anything it's unspecified. And I don't believe this part of the spec should be a place for experiments. Re context propagation - that's just the one of the clarifications I'm talking about. I think that if we don't specify anything, users would expect contexts to always work. > 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)

9 years, 2 months

1
0
0 / 0

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

by Antoine Sabot-Durand (JIRA)

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

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-541: ------------------------------------------ I suggest that we support ordering in Async Event. The idea behind async event is not to optimize asynchronous treatment but to allow people to fire and forget (or deal later) an event. Now that we decide to split async from sync obervers invocation, confusion there won't be confusion on th topic Providing ordering for async add more feature and helps build more use case for end users. Implementation would be free to use multi thread for events sharing the same priority. > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-547) Resolving sync/async observer methods

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-547: ------------------------------------------ IMO {{resolveObserverMethods}} should be "synchronous agnostic". The idea behind this method is to provide a way perform TypeSafe resolution for observers. In JDK8 it's quite easy to filter the returned set to get sync or async if it's needed. Regarding confusion, as this method is reserved to advanced developers I don't see it as a real issue. > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Jozef Hartinger > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.ED...] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

Adding Lambdas as CDI beans

by David Blevins

In brainstorming mode about fun that could be made possible with Java 8 and Java EE. Question in my mind is: is there some way we could make it possible for Lambdas or Method Refs to be CDI beans? It goes against the grain obviously as CDI creation is very much a “Don’t call us, we’ll call you” kind of thing. The VM dynamically creates a wrapper object around the Lambda or method reference and it implements the given interface. To make it work, there would need to be some non-producer method way of saying “put this thing in the context with these qualifiers”. Imagine a method somewhere that would allow you to: public <T> void addObserver(java.util.function.Consumer<T> observer, Annotation... qualifiers); Then you could take advantage as follows: final List<URI> uris = new ArrayList<>(); // @Observes URI addObserver((Consumer<URI>) uris::add); // @Observes Thread addObserver(Runtime.getRuntime()::addShutdownHook); // @Observes Runnable addObserver((Consumer<Runnable>) Executors.newFixedThreadPool(3)::submit); // @Observes URI addObserver((Consumer<URI>) System.out::println, new AnnotationLiteral<Fine>() { }); // @Observes Handler final Logger logger = Logger.getLogger("somewhere"); addObserver(logger::addHandler); // add handlers via event // @Observes @Fine String addObserver((Consumer<String>) logger::fine, new AnnotationLiteral<Fine>() {}); } -David

9 years, 2 months

1
0
0 / 0

Spec with TCK assertion

by Antoine Sabot-Durand

Hi all, In case you missed it, I released the new version of spec including TCK assertion: http://www.cdi-spec.org/news/2015/10/15/Learn-CDI-with-TCK/ Thanks again to Tomas who did a smart job here Antoine

9 years, 2 months

2
1
0 / 0

[JBoss JIRA] (CDI-160) Split specification into "core" and "Java EE integration"

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-160?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-160: ------------------------------------- Fix Version/s: 2.0-EDR1 (was: 2.0 (proposed)) > Split specification into "core" and "Java EE integration" > --------------------------------------------------------- > > Key: CDI-160 > URL: https://issues.jboss.org/browse/CDI-160 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Antoine Sabot-Durand > Priority: Critical > Fix For: 2.0-EDR1 > > > In order to better support implementations of CDI such as Weld SE, Errai, and OpenWebBeans which are currently not certifiable by JSR-299 (as they don't implement any of the Java EE integrations) we should split the spec into core and Java EE integrations, and offer two modes within the TCK as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2015