[JBoss JIRA] (CDI-544) 10.2.3. The Event interface - provided executor cannot execute observers notification
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-544?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-544:
------------------------------------------
It certainly could be clarified, but the idea here is to have a different exception if something happens inside event dispatcher and not observers (user code). For instance a user may provide a shut down executor that will not be able to run our async observer not because of their content. We have 2 options here:
# Expose the exception coming from the faulty executor, could be not very user friendly
# Wrap it in our own execption with our own error message. Perhaps {{IllegalArgumentException}} is not the best choice
> 10.2.3. The Event interface - provided executor cannot execute observers notification
> -------------------------------------------------------------------------------------
>
> Key: CDI-544
> URL: https://issues.jboss.org/browse/CDI-544
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Tomas Remes
>
> {quote}
> If the provided executor cannot execute observers notification, an IllegalArgumentException is thrown.
> {quote}
> What does it mean "cannot execute"? I am not really sure. Does it mean the observer throws an exception which should be wrapped in IAE?
> This would likely contradict {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}}.
> Maybe this sentence could be omitted.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-545) Clarify that observers can't be remote business method
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-545:
----------------------------------------
Summary: Clarify that observers can't be remote business method
Key: CDI-545
URL: https://issues.jboss.org/browse/CDI-545
Project: CDI Specification Issues
Issue Type: Clarification
Components: Java EE integration
Affects Versions: 1.2.Final
Reporter: Antoine Sabot-Durand
In section 10.4 of 1.2 spec we have:
{quote}
If the bean is a session bean, the observer method must be either a business method of the EJB or a static method of the bean class.
{quote}
in 10.4.2 we also have:
{quote}
If a non-static method of a session bean class has a parameter annotated {{@Observes}}, and the method is not a business method of the EJB, the container automatically detects the problem and treats it as a definition error.
{quote}
This 2 assertions don't prevent an observer to be a business method of a remote client of an EJB. We should be more precise here and forbid this scenario.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-544) 10.2.3. The Event interface - provided executor cannot execute observers notification
by Tomas Remes (JIRA)
Tomas Remes created CDI-544:
-------------------------------
Summary: 10.2.3. The Event interface - provided executor cannot execute observers notification
Key: CDI-544
URL: https://issues.jboss.org/browse/CDI-544
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Tomas Remes
{quote}
If the provided executor cannot execute observers notification, an IllegalArgumentException is thrown.
{quote}
What does it mean "cannot execute"? I am not really sure. Does it mean the observer throws an exception which should be wrapped in IAE?
This would likely contradict {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}}.
Maybe this sentence could be omitted.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-543) Handling exception during async event - contradiction?
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-543?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-543:
----------------------------------
I think it would be more consistent if an exception thrown by any synchronous observer aborts the processing of the event. On the other hand, this may not be the best thing from the user point of view. E.g. an async observer is suddenly not notified after a sync obser which throws an exception is added.
> Handling exception during async event - contradiction?
> ------------------------------------------------------
>
> Key: CDI-543
> URL: https://issues.jboss.org/browse/CDI-543
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Tomas Remes
>
> In {{10.5. Observer notification}} there is (wrt sync observer method):
> {quote}
> Otherwise, the exception aborts processing of the event. No other observer methods of that event will be called
> {quote}
> This looks like contradiction to {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}} where is:
> {quote}
> If an event is asynchronous, and an exception is thrown by any of its notified observers, the CompletionStage returned by fireAsync will complete exceptionally ..
> {quote}
> The question is following: Async Event is fired -> some sync observers are notified -> one of them throws exception -> async observers will be notified or not?
> I assume they should be notified and therefore {{10.5. Observer notification}} needs an update.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-543) Handling exception during async event - contradiction?
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-543?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-543:
---------------------------------
There is already available TCK test - org.jboss.cdi.tck.tests.event.observer.async.handlingExceptions.MultipleExceptionsInObserversNotificationTest
> Handling exception during async event - contradiction?
> ------------------------------------------------------
>
> Key: CDI-543
> URL: https://issues.jboss.org/browse/CDI-543
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Tomas Remes
>
> In {{10.5. Observer notification}} there is (wrt sync observer method):
> {quote}
> Otherwise, the exception aborts processing of the event. No other observer methods of that event will be called
> {quote}
> This looks like contradiction to {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}} where is:
> {quote}
> If an event is asynchronous, and an exception is thrown by any of its notified observers, the CompletionStage returned by fireAsync will complete exceptionally ..
> {quote}
> The question is following: Async Event is fired -> some sync observers are notified -> one of them throws exception -> async observers will be notified or not?
> I assume they should be notified and therefore {{10.5. Observer notification}} needs an update.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-543) Handling exception during async event - contradiction?
by Tomas Remes (JIRA)
Tomas Remes created CDI-543:
-------------------------------
Summary: Handling exception during async event - contradiction?
Key: CDI-543
URL: https://issues.jboss.org/browse/CDI-543
Project: CDI Specification Issues
Issue Type: Bug
Components: Events
Affects Versions: 2.0-EDR1
Reporter: Tomas Remes
In {{10.5. Observer notification}} there is (wrt sync observer method):
{quote}
Otherwise, the exception aborts processing of the event. No other observer methods of that event will be called
{quote}
This looks like contradiction to {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}} where is:
{quote}
If an event is asynchronous, and an exception is thrown by any of its notified observers, the CompletionStage returned by fireAsync will complete exceptionally ..
{quote}
The question is following: Async Event is fired -> some sync observers are notified -> one of them throws exception -> async observers will be notified or not?
I assume they should be notified and therefore {{10.5. Observer notification}} needs an update.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes updated CDI-541:
----------------------------
Description:
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?
was:
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}
What will be the order in this case? First, Second, Third? First, Third, Second?
{quote}
@Priority is not defined for the async part, it just says
{quote}
I guess this is not explicitly stated anywhere. Is it? Ok so sync observers go first anytime so let's focus only on the async observers. I am adding one more @ObservesAsync to the game.
> 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.3.15#6346)
9 years, 5 months
[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:
----------------------------------
I think the question is whether to support priority for async observers or not. If we do, all async observers would have to be notified serially, probably in a single thread (this is what we do in Weld right now). This would be handy if a mutable event payload is used. On the other hand, this would also prevent further optimizations (e.g. notify async observers in parallel).
> 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}
> What will be the order in this case? First, Second, Third? First, Third, Second?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified
by Mark Paluch (JIRA)
[ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.sy... ]
Mark Paluch commented on CDI-541:
---------------------------------
{{@Priority}} is not defined for the async part, it just says
{quote}
If synchronous observer have to be notified, fireAsync returns immediately after the last synchronous observer has returned.
{quote}
So {{@Priority}} is valid (even in the context of {{fireAsync}}) to {{@Observes}}.
> 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}
> What will be the order in this case? First, Second, Third? First, Third, Second?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (CDI-542) "10.2.2. Firing events asynchronously" update/enhancements
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-542?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-542:
---------------------------------
This is more my personal feeling/opinion...Maybe I am too bad interpreter.:)
> "10.2.2. Firing events asynchronously" update/enhancements
> ----------------------------------------------------------
>
> Key: CDI-542
> URL: https://issues.jboss.org/browse/CDI-542
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Affects Versions: 2.0-EDR1
> Reporter: Tomas Remes
> Priority: Minor
>
> This chapter (similar as the preceding) defines in general what does it mean to "fire an event" (sync vs async). Let say I am ordinary reader reading the spec from the beginning and I come to this chapter.
> First of all I guess I will struggle little bit with the notion of ??resolved synchronous observers?? (vs ??resolved asynchronous observers??)
> I think the following important information from "10.3. Observer resolution" could be mentioned earlier or some general description/example could be handy:
> {quote}
> * The event is fired synchronously and the observer is defined with @Observes.
> * The event is fired asynchronously and the observer is defined with @Observes or @ObservesAsync.
> {quote}
> Second there is following sentence which TBH I have had fairly hard times to understand:
> {quote}
> If synchronous observer have to be notified, fireAsync returns immediately after the last synchronous observer has returned. Otherwise it returns immediately.
> {quote}
> ...and is IMO wrong. There should be "observers have to be" or "observer has to be" and it could be bit more explanatory.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months