8:44 a.m.
[
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)
3622
days inactive
3622
days old
0 comments
1 participants
participants (1)
-
Antoine Sabot-Durand (JIRA)