[JBoss JIRA] (CDI-499) Firing events asynchronously
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand edited comment on CDI-499 at 1/21/15 9:44 AM:
-------------------------------------------------------------------
{quote}
- So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
I think a call to fireAsync() should be processed asynchronously by all observers. But I have the feeling that it is in contradiction with this statement
{quote}
...
{quote}
{color:blue}
For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer
{color}
What exactly are the reasons for this? I can think of one:
- observer method injecting a @RequestScoped (or similar) bean
Are there other arguments for this?
{quote}
I'm not very happy with this approach as well : It could bring confusion for end user. This possible backward compatibility issue was raised by [~meetoblivion] or [~struberg] during last IRC meeting. I'd be glad to have a better solution here.
{quote}
{color:blue}
3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously
{color}
How's that different from Event.fire()?
{quote}
probably none ;). How did you handle that in Weld Alpha [~jharting]?
was (Author: antoinesabot-durand):
{quote}
- So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
I think a call to fireAsync() should be processed asynchronously by all observers. But I have the feeling that it is in contradiction with this statement
...
{quote}For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer{quote}
What exactly are the reasons for this? I can think of one:
- observer method injecting a @RequestScoped (or similar) bean
Are there other arguments for this?
{quote}
I'm not very happy with this approach as well : It could bring confusion for end user. This possible backward compatibility issue was raised by [~meetoblivion] or [~struberg] during last IRC meeting. I'd be glad to have a better solution here.
{quote}
{quote}3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously{quote}
How's that different from Event.fire()?
{quote}
probably none ;). How did you handle that in Weld Alpha [~jharting]?
> Firing events asynchronously
> -----------------------------
>
> Key: CDI-499
> URL: https://issues.jboss.org/browse/CDI-499
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is:
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (CDI-499) Firing events asynchronously
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-499:
------------------------------------------
{quote}
- So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
I think a call to fireAsync() should be processed asynchronously by all observers. But I have the feeling that it is in contradiction with this statement
...
{quote}For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer{quote}
What exactly are the reasons for this? I can think of one:
- observer method injecting a @RequestScoped (or similar) bean
Are there other arguments for this?
{quote}
I'm not very happy with this approach as well : It could bring confusion for end user. This possible backward compatibility issue was raised by [~meetoblivion] or [~struberg] during last IRC meeting. I'd be glad to have a better solution here.
{quote}
{quote}3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously{quote}
How's that different from Event.fire()?
{quote}
probably none ;). How did you handle that in Weld Alpha [~jharting]?
> Firing events asynchronously
> -----------------------------
>
> Key: CDI-499
> URL: https://issues.jboss.org/browse/CDI-499
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is:
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata injection for EE components
by Martin Kouba (JIRA)
Martin Kouba created CDI-500:
--------------------------------
Summary: Clarify @Intercepted Bean metadata injection for EE components
Key: CDI-500
URL: https://issues.jboss.org/browse/CDI-500
Project: CDI Specification Issues
Issue Type: Clarification
Components: Interceptors
Affects Versions: 1.2.Final
Reporter: Martin Kouba
It's not clear what should happen when an interceptor with {{@Intercepted Bean}} metadata is associated with an EE component.
See the CDI spec, "5.5.8. Bean metadata":
{quote}
Additionally, the container must provide beans allowing interceptors and decorators to obtain information about the beans they intercept and decorate:
* a bean with scope @Dependent, qualifier @Intercepted and type Bean which can be injected into any interceptor instance, and
* ...
{quote}
However, most EE components must also support the use of CDI interceptors. See also the Java EE 7 spec, "EE.5.2.5 Annotations and Injection":
{quote}
The component classes listed in Table EE.5-1 with support level "Standard"
all support Java EE resource injection, as well as PostConstruct and PreDestroy callbacks. In addition, if CDI is enabled—which it is by default—these classes also support CDI injection, as described in Section EE.5.24, "Support for Dependency Injection", and the use of interceptors.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (CDI-499) Firing events asynchronously
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-499:
-------------------------------------
{quote}For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer{quote}
What exactly are the reasons for this? I can think of one:
- observer method injecting a @RequestScoped (or similar) bean
Are there other arguments for this?
{quote}3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously{quote}
How's that different from Event.fire()?
> Firing events asynchronously
> -----------------------------
>
> Key: CDI-499
> URL: https://issues.jboss.org/browse/CDI-499
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is:
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (CDI-499) Firing events asynchronously
by José Paumard (JIRA)
[ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy... ]
José Paumard commented on CDI-499:
----------------------------------
2 things :
- So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
I think a call to fireAsync() should be processed asynchronously by all observers. But I have the feeling that it is in contradiction with this statement.
- the signature of the fireAsync is <U extends T> CompletionStage<U> fireAsync(U event);
I think we need to add a 2nd method that takes an Executor as a parameter, for 2 reasons :
- it would stick to the CompletionStage patterns
- in a Java EE world, it would allow one to state that the processing of the event should take place in a ManagedExecutorService, obtained by injection, that the BeanManager might not be aware of.
> Firing events asynchronously
> -----------------------------
>
> Key: CDI-499
> URL: https://issues.jboss.org/browse/CDI-499
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is:
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (CDI-499) Firing events asynchronously
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-499:
-------------------------------------
Description:
We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
Our proposal is:
h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
Signature of the method on {{Event<T>}} would be
{code:java}
<U extends T> CompletionStage<U> fireAsync(U event);
{code}
Signature on {{BeanManager}} would be
{code:java}
<T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
{code}
h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
h2. 3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously
h2. 4. Event Ordering
Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
h2. 5. Event state (payload mutability)
We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
was:
We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
Our proposal is:
h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
Signature of the method on {{Event<T>}} would be
{code:java}
<U extends T> CompletionStage<U> fireAsync(U event);
{code}
Signature on {{BeanManager}} would be
{code:java}
<T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
{code}
h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
h2. 3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously
h2. 4. Event Ordering
Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
h2. 5. Event state (payload mutability)
We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
> Firing events asynchronously
> -----------------------------
>
> Key: CDI-499
> URL: https://issues.jboss.org/browse/CDI-499
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is:
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (CDI-499) Firing events asynchronously
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand edited comment on CDI-499 at 1/21/15 5:32 AM:
-------------------------------------------------------------------
This ticket comes after a lot of discussion around async events in CDI-31, in the event workshop document (http://bit.ly/cdi2wsevt) or IRC meeting. In these discussions there were a lot of more complicated scenario but we wanted to keep CDI event as simple as possible. For advanced asynchronous scenario, JDK8 will provide its new API {{CompletableFuture}} or we could add the support of asynchronous operation in CDI if necessary.
was (Author: antoinesabot-durand):
This ticket comes after a lot of discussion around async events in CDI-31 or in the event workshop document. In these discussions there were a lot of more complicated scenario but we wanted to keep CDI event as simple as possible. For advanced asynchronous scenario, JDK8 will provide its new API {{CompletableFuture}} or we could add the support of asynchronous operation in CDI if necessary.
> Firing events asynchronously
> -----------------------------
>
> Key: CDI-499
> URL: https://issues.jboss.org/browse/CDI-499
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is:
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months