November 2016 - cdi-dev - Jboss List Archives

by Antoine Sabot-Durand

Hi All, Just to remind you the coming step for CDI 2.0 specification: - Nov 30th : feature freeze. After this date we'll only work on spec clarification that have no impact on RI or TCK (unless an error is found in specified new features). Name of added API may change after a full review of new features - Early December: release of CDI 2.0 Beta1 API - Mid December: release of Weld 3.0.0 Beta1 and TCK beta - Early January: start of the release process Official release is still targeted to end of January as planned. Antoine

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-650) Introduce asynchronous event notification options

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-650?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-650: ---------------------------------- The idea is to define "typesafe portable options" (only {{NotificationOptions.getExecutor()}} for CDI 2.0) and still allow the implementations to support non-portable/non-standardized options (by means of {{NotificationOptions.get()}}). > Introduce asynchronous event notification options > ------------------------------------------------- > > Key: CDI-650 > URL: https://issues.jboss.org/browse/CDI-650 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 .Final > > > Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout. > Therefore, I suggest to introduce {{NotificationOptions}} interface: > {code:java} > public interface NotificationOptions { > Executor getExecutor(); > // Implementation-specific options > Object get(String optionName); > } > {code} > and change the method signature to: > {code:java} > CompletionStage fireAsync(U event, NotificationOptions options); > {code} > In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g. > {code:java} > Duration getTimeout(); > {code} > instead of adding more and more params to {{Event.fireAsync()}}. > We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.: > {code:java} > void fireEvents(Event event, Executor executor) { > event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor)); > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-650) Introduce asynchronous event notification options

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-650?page=com.atlassian.jira.plugin.sy... ] Emily Jiang commented on CDI-650: --------------------------------- With the introduction of NotificationOptions, the emitter can put more info inside to instruct the container. We will have to spec for each individual properties, right? Otherwise, the application is not portable any more, as Weld might react different from OWB on treating the NotificationOptions info. I might totally misunderstand you. > Introduce asynchronous event notification options > ------------------------------------------------- > > Key: CDI-650 > URL: https://issues.jboss.org/browse/CDI-650 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 .Final > > > Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout. > Therefore, I suggest to introduce {{NotificationOptions}} interface: > {code:java} > public interface NotificationOptions { > Executor getExecutor(); > // Implementation-specific options > Object get(String optionName); > } > {code} > and change the method signature to: > {code:java} > CompletionStage fireAsync(U event, NotificationOptions options); > {code} > In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g. > {code:java} > Duration getTimeout(); > {code} > instead of adding more and more params to {{Event.fireAsync()}}. > We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.: > {code:java} > void fireEvents(Event event, Executor executor) { > event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor)); > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-650) Introduce asynchronous event notification options

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-650?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-650: ---------------------------------- This info is not intended for observer methods (receiver part). This is merely a hint for the container, i.e. allows the event "emitter" to configure async events delivery. And right now, the only portable option is the {{Executor}} used for observer method execution. A user can either use the convenient static methods ({{NotificationOptions.ofExecutor()}}, {{NotificationOptions.builder()}}) and the default impl or provide a custom impl. > Introduce asynchronous event notification options > ------------------------------------------------- > > Key: CDI-650 > URL: https://issues.jboss.org/browse/CDI-650 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 .Final > > > Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout. > Therefore, I suggest to introduce {{NotificationOptions}} interface: > {code:java} > public interface NotificationOptions { > Executor getExecutor(); > // Implementation-specific options > Object get(String optionName); > } > {code} > and change the method signature to: > {code:java} > CompletionStage fireAsync(U event, NotificationOptions options); > {code} > In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g. > {code:java} > Duration getTimeout(); > {code} > instead of adding more and more params to {{Event.fireAsync()}}. > We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.: > {code:java} > void fireEvents(Event event, Executor executor) { > event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor)); > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-650) Introduce asynchronous event notification options

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-650?page=com.atlassian.jira.plugin.sy... ] Emily Jiang commented on CDI-650: --------------------------------- On event receiving side, how an user can get hold of this NotificationOption, which is an interface? Will this be part of observation such as EventMetaData? After getting hold of it, what the receiver is supposed to do? > Introduce asynchronous event notification options > ------------------------------------------------- > > Key: CDI-650 > URL: https://issues.jboss.org/browse/CDI-650 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 .Final > > > Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout. > Therefore, I suggest to introduce {{NotificationOptions}} interface: > {code:java} > public interface NotificationOptions { > Executor getExecutor(); > // Implementation-specific options > Object get(String optionName); > } > {code} > and change the method signature to: > {code:java} > CompletionStage fireAsync(U event, NotificationOptions options); > {code} > In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g. > {code:java} > Duration getTimeout(); > {code} > instead of adding more and more params to {{Event.fireAsync()}}. > We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.: > {code:java} > void fireEvents(Event event, Executor executor) { > event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor)); > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-652) Introduce example of InterceptionFactory usage in 11.7. Apply interceptor programmatically

by Tomas Remes (JIRA)

Tomas Remes created CDI-652: ------------------------------- Summary: Introduce example of InterceptionFactory usage in 11.7. Apply interceptor programmatically Key: CDI-652 URL: https://issues.jboss.org/browse/CDI-652 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Tomas Remes This new feature would deserve some example in related chapter IMO: -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-652) Introduce example of InterceptionFactory usage in 11.7. Apply interceptor programmatically

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/CDI-652?page=com.atlassian.jira.plugin.sy... ] Tomas Remes updated CDI-652: ---------------------------- Fix Version/s: 2.0 .Final > Introduce example of InterceptionFactory usage in 11.7. Apply interceptor programmatically > ------------------------------------------------------------------------------------------ > > Key: CDI-652 > URL: https://issues.jboss.org/browse/CDI-652 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > This new feature would deserve some example in related chapter IMO: -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-651) Add convenient Instance.isResolvable()

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-651?page=com.atlassian.jira.plugin.sy... ] Emily Jiang commented on CDI-651: --------------------------------- +1 > Add convenient Instance.isResolvable() > -------------------------------------- > > Key: CDI-651 > URL: https://issues.jboss.org/browse/CDI-651 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 .Final > > > Returns true if satisfied ({{Instance.isUnsatisfied() == false}}) and NOT ambiguous ({{Instance.isAmbiguous() == false}}). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-651) Add convenient Instance.isResolvable()

by Martin Kouba (JIRA)

Martin Kouba created CDI-651: -------------------------------- Summary: Add convenient Instance.isResolvable() Key: CDI-651 URL: https://issues.jboss.org/browse/CDI-651 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Martin Kouba Assignee: Martin Kouba Fix For: 2.0 .Final Returns true if satisfied ({{Instance.isUnsatisfied() == false}}) and NOT ambiguous ({{Instance.isAmbiguous() == false}}). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-589) Enhance programmatic lookup

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-589?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-589: ----------------------------- Fix Version/s: 2.1 (Discussion) > Enhance programmatic lookup > --------------------------- > > Key: CDI-589 > URL: https://issues.jboss.org/browse/CDI-589 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.1 (Discussion) > > > The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). > The new proposal is to enhance {{Instance}} similarly as Weld API does: > https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/in... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2016