[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Christopher Brock (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Christopher Brock commented on CDI-4:
-------------------------------------
I do, of course. And I've stewed about this problem for quite a long time. Ever since we needed the ability to control event ordering in Forge and now in some cases, in Errai.
The problem is that when you're trying to _keep it simple_ you can't discount the possibility that you're merely exporting the complexity of a problem, as well. And I think that while this does add complexity to CDI, it does so in a way that balances the complexity with programmatic intuitiveness, maintains a modicum of readability, leverages qualifiers, and provides frameworks like say, Forge or Errai, with the ability to offer expressive -- and more importantly, documentable -- ways of controlling event-firing across decoupled components.
The truth is, and I know Dan Allen can attest to this, that my initial suggestion was to use magic numbers for salience, as well. And while it's an undeniably simple thing to implement, it will more than likely just produce convoluted code.
I mean, to further my example from earlier, and not to put to fine a point on it, but I would cringe to write something like this in my documentation:
{code}
In order to ensure that your changes are picked up by the persistence plugin, you must ensure that the CodeChange event observer has a salience of less than 0.7f.
{code}
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Christopher Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Mark Struberg commented on CDI-4:
---------------------------------
you know the KISS pattern? This would be a pretty heavy change for 1.1 imo. From my gut feeling I'd say we should think a few days/weeks about this.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Christopher Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Issue Comment Edited: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Christopher Brock (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Christopher Brock edited comment on CDI-4 at 5/7/11 1:49 PM:
-------------------------------------------------------------
_This solution might introduce cycles in more complex scenarios_
True. But they're also extremely easy to detect by the container at bootstrap time. That is to say, that you can easily detect a conflict in the ordering and blow up with a fairly informative message. CDI-aware IDEs will also have no problem detecting this, too.
This solution has the same basic effect as a magic number solution to define salience. But the problem with magic numbers is that it suffers from an even worse readability problem than this. Especially if you have salience values for common events being declared in dynamically loaded modules -- say, like Seam Forge.
So in a Forge plugin, the plugin author would need to know the basal value, and then if coordinating with other plugins (a likely possibility in Forge) know _their_ basal values as well.
When you look at this solution in that scenario, it's much easier to resolve the issue.
All you need to do is provide qualifiers that can then be referenced with {{@Before}} and {{@After}} from the plugins.
So, {{(a)After(BeanLoading.class) @Before(BeanDeploy.class)}} is a heck of a lot easier to document for and read than say something like {{(a)Salience(1.30f)}}.
was (Author: cbrock):
_This solution might introduce cycles in more complex scenarios_
True. But they're also extremely easy to detect by the container at bootstrap time.
This solution has the same basic effect as a magic number solution to define salience. But the problem with magic numbers is that it suffers from an even worse readability problem than this. Especially if you have salience values for common events being declared in dynamically loaded modules -- say, like Seam Forge.
So in a Forge plugin, the plugin author would need to know the basal value, and then if coordinating with other plugins (a likely possibility in Forge) know _their_ basal values as well.
When you look at this solution in that scenario, it's much easier to resolve the issue.
All you need to do is provide qualifiers that can then be referenced with {{@Before}} and {{@After}} from the plugins.
So, {{(a)After(BeanLoading.class) @Before(BeanDeploy.class)}} is a heck of a lot easier to document for and read than say something like {{(a)Salience(1.30f)}}.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Christopher Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Issue Comment Edited: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Christopher Brock (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Christopher Brock edited comment on CDI-4 at 5/7/11 1:46 PM:
-------------------------------------------------------------
_This solution might introduce cycles in more complex scenarios_
True. But they're also extremely easy to detect by the container at bootstrap time.
This solution has the same basic effect as a magic number solution to define salience. But the problem with magic numbers is that it suffers from an even worse readability problem than this. Especially if you have salience values for common events being declared in dynamically loaded modules -- say, like Seam Forge.
So in a Forge plugin, the plugin author would need to know the basal value, and then if coordinating with other plugins (a likely possibility in Forge) know _their_ basal values as well.
When you look at this solution in that scenario, it's much easier to resolve the issue.
All you need to do is provide qualifiers that can then be referenced with {{@Before}} and {{@After}} from the plugins.
So, {{(a)After(BeanLoading.class) @Before(BeanDeploy.class)}} is a heck of a lot easier to document for and read than say something like {{(a)Salience(1.30f)}}.
was (Author: cbrock):
_This solution might introduce cycles in more complex scenarios_
True. But they're also extremely easy to detect by the container at bootstrap time.
This solution has the same basic effect as a magic number solution to define salience. But the problem with magic numbers is that it suffers from an even worse readability problem than this. Especially if you have salience values for common events being declared in dynamically loaded modules -- say, like Seam Forge.
So in a Forge plugin, the plugin author would need to know the basal value, and then if coordinating with other plugins (a likely possibility in Forge) know _their_ basal values as well.
When you look at this solution in that scenario, it's much easier to resolve the issue.
All you need to do is provide qualifiers that can then be referenced with @Before and @After from the plugins.
So, {{(a)After(BeanLoading.class) @Before(BeanDeploy.class)}} is a heck of a lot easier to document for and read than say something like {{(a)Salience(1.30f)}}.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Christopher Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Issue Comment Edited: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Christopher Brock (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Christopher Brock edited comment on CDI-4 at 5/7/11 1:44 PM:
-------------------------------------------------------------
_This solution might introduce cycles in more complex scenarios_
True. But they're also extremely easy to detect by the container at bootstrap time.
This solution has the same basic effect as a magic number solution to define salience. But the problem with magic numbers is that it suffers from an even worse readability problem than this. Especially if you have salience values for common events being declared in dynamically loaded modules -- say, like Seam Forge.
So in a Forge Plugin, the plugin author would need to know the basal value, and then if coordinating with other plugins (a likely possibility in Forge) know _their_ basal values as well.
When you look at this solution in that scenario, it's much easier to resolve the issue.
All you need to do is provide qualifiers that can then be referenced with @Before and @After from the plugins.
So, {{(a)After(BeanLoading.class) @Before(BeanDeploy.class)}} is a heck of a lot easier to document for and read than say something like {{(a)Salience(1.30f)}}.
was (Author: cbrock):
_This solution might introduce cycles in more complex scenarios_
True. But they're also extremely easy to detect by the container at bootstrap time.
This solution has the same basic effect as a magic number solution to define salience. But the problem with magic numbers is that it suffers from an even worse readability problem than this. Especially if you have salience values for common events being declared in dynamically loaded modules -- say, like Seam Forge.
So in a Forge Plugin, the plugin author would need to know the basal value, and then if coordinating with other plugins (a likely possibility in Forge) know _their_ basal values as well.
When you look at this solution in that scenario, it's much easier to resolve the issue.
All you need to do is provide qualifiers that can then be referenced with @Before and @After from the plugins.
So, @After(BeanLoading.class) @Before(BeanDeploy.class) is a heck of a lot easier to document for and read than say something like @Salience(1.30f).
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Christopher Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Issue Comment Edited: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Christopher Brock (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Christopher Brock edited comment on CDI-4 at 5/7/11 1:45 PM:
-------------------------------------------------------------
_This solution might introduce cycles in more complex scenarios_
True. But they're also extremely easy to detect by the container at bootstrap time.
This solution has the same basic effect as a magic number solution to define salience. But the problem with magic numbers is that it suffers from an even worse readability problem than this. Especially if you have salience values for common events being declared in dynamically loaded modules -- say, like Seam Forge.
So in a Forge plugin, the plugin author would need to know the basal value, and then if coordinating with other plugins (a likely possibility in Forge) know _their_ basal values as well.
When you look at this solution in that scenario, it's much easier to resolve the issue.
All you need to do is provide qualifiers that can then be referenced with @Before and @After from the plugins.
So, {{(a)After(BeanLoading.class) @Before(BeanDeploy.class)}} is a heck of a lot easier to document for and read than say something like {{(a)Salience(1.30f)}}.
was (Author: cbrock):
_This solution might introduce cycles in more complex scenarios_
True. But they're also extremely easy to detect by the container at bootstrap time.
This solution has the same basic effect as a magic number solution to define salience. But the problem with magic numbers is that it suffers from an even worse readability problem than this. Especially if you have salience values for common events being declared in dynamically loaded modules -- say, like Seam Forge.
So in a Forge Plugin, the plugin author would need to know the basal value, and then if coordinating with other plugins (a likely possibility in Forge) know _their_ basal values as well.
When you look at this solution in that scenario, it's much easier to resolve the issue.
All you need to do is provide qualifiers that can then be referenced with @Before and @After from the plugins.
So, {{(a)After(BeanLoading.class) @Before(BeanDeploy.class)}} is a heck of a lot easier to document for and read than say something like {{(a)Salience(1.30f)}}.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Christopher Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Christopher Brock (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Christopher Brock commented on CDI-4:
-------------------------------------
_This solution might introduce cycles in more complex scenarios_
True. But they're also extremely easy to detect by the container at bootstrap time.
This solution has the same basic effect as a magic number solution to define salience. But the problem with magic numbers is that it suffers from an even worse readability problem than this. Especially if you have salience values for common events being declared in dynamically loaded modules -- say, like Seam Forge.
So in a Forge Plugin, the plugin author would need to know the basal value, and then if coordinating with other plugins (a likely possibility in Forge) know _their_ basal values as well.
When you look at this solution in that scenario, it's much easier to resolve the issue.
All you need to do is provide qualifiers that can then be referenced with @Before and @After from the plugins.
So, @After(BeanLoading.class) @Before(BeanDeploy.class) is a heck of a lot easier to document for and read than say something like @Salience(1.30f).
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Christopher Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Mark Struberg commented on CDI-4:
---------------------------------
As with every solution there are pros and cons. Your solution is very neat to read, but there are also a few cons which should not be unmentioned:
a) This solution might introduce cycles in more complex scenarios
b) In a more modular and thus more complex situation, you don't always know your other observers.
c) Having to know other observers is a bit against the basic idea of the observer design pattern.
d) Again: if I know my other observers, then just fu***n simply call them directly ;)
e) If I _don't_ know the other observers (e.g. they are in another jar which is not compile time scoped but only added at runtime), then there's now way to do it.
I know: a Float with a default value of 1.0f is really stone age technology. But it works. But sure, this also has cons so lets discuss this further.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Christopher Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Issue Comment Edited: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Mark Struberg edited comment on CDI-4 at 5/7/11 1:31 PM:
---------------------------------------------------------
As with every solution there are pros and cons. Your solution is very neat to read, but there are also a few cons which should not be unmentioned:
a) This solution might introduce cycles in more complex scenarios
b) In a more modular and thus more complex situation, you don't always know your other observers.
c) Having to know other observers is a bit (*edit*: should better say totally?) against the basic idea of the observer design pattern.
d) Again: if I know my other observers, then just fu***n simply call them directly ;)
e) If I _don't_ know the other observers (e.g. they are in another jar which is not compile time scoped but only added at runtime), then there's now way to do it.
I know: a Float with a default value of 1.0f is really stone age technology. But it works. But sure, this also has cons so lets discuss this further.
was (Author: struberg):
As with every solution there are pros and cons. Your solution is very neat to read, but there are also a few cons which should not be unmentioned:
a) This solution might introduce cycles in more complex scenarios
b) In a more modular and thus more complex situation, you don't always know your other observers.
c) Having to know other observers is a bit against the basic idea of the observer design pattern.
d) Again: if I know my other observers, then just fu***n simply call them directly ;)
e) If I _don't_ know the other observers (e.g. they are in another jar which is not compile time scoped but only added at runtime), then there's now way to do it.
I know: a Float with a default value of 1.0f is really stone age technology. But it works. But sure, this also has cons so lets discuss this further.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Christopher Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Issue Comment Edited: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Christopher Brock (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Christopher Brock edited comment on CDI-4 at 5/7/11 1:11 PM:
-------------------------------------------------------------
After having a conversation with Dan Allen about solving this problem, this is what we came up with.
We propose the addition of two new annotations, {{@Before}} and {{@After}} which both accept {{Class<? extends Annotation>[]}} to reference qualifiers (one or more).
For example:
*Case A:*
{code}
public class MyBean
public void myFirstObserver(@Observes @Before(Initialization.class) MyEvent event) {
...
}
public void mySecondObserver(@Observes @Initialization MyEvent event) {
...
}
}
{code}
*Case B:*
{code}
public class MyBean
public void myFirstObserver(@Observes @After(Initialization.class) MyEvent event) {
...
}
public void mySecondObserver(@Observes @Initialization MyEvent event) {
...
}
}
{code}
In Case A, the container would guarantee that when a {{MyEvent}} is fired, that {{myFirstObserver()}} is called before {{mySecondObserver()}}. In Case B, the container would guarantee that {{myFirstObserver()}} is called only _after_ {{mySecondObserver()}} has been called.
In a situation where multiple observers are observing the event with the referenced qualifier, {{@Before}} will indicate the annotated observer shall execute before any of those thus qualified execute. The converse will be true for {{@After}}.
Where multiple qualifiers are specified in {{@Before}} or {{@After}} the matching behavior will be identical to the dispatch matching behavior of the CDI specification. For instance:
*Case C*
{code}
public void firstObserver(@Observes @A @B @C MyEvent event) {
}
public void secondObserver(@Observes @A @B @D MyEvent event) {
}
public void thirdObserver(@Observes @A @E @F @After({A.class, D.class}) MyEvent event) {
}
{code}
In Case C, {{thirdObserver()}} will only be called after {{secondObserver()}} is called. However, {{firstObserver()}} may be called before or after; the contract with the container does not guarantee any firing order for {{firstObserver()}} relative to the other two observers.
---
Also, the specification may benefit from the addition of an {{@OrderingQualifier}} which permits the creation of qualifiers used only for the purpose of ordering, but are otherwise ignored by the container for dispatching of events. This would be optional, of course. Any regular qualifier can be used for ordering.
Example:
{code}
@OrderingQualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.PARAMETER, ElementType.FIELD, ElementType.METHOD})
public @interface MyQualifier {
}
{code}
The presence of ordering qualifiers may muddy the water a little bit in terms of readability. However, I could foresee situations where the use of ordering qualifiers -- when used properly -- could make resolving some complex ordering situations less difficult. At the very least, it would allow for dispatch ordering that could not be circumvented accidentally. And by that I mean, ordering qualifiers cannot be used to qualify event consumers; they are used by the container merely for resolving the dispatch ordering -- which is done when the container bootstraps -- and otherwise have no runtime side-effects.
was (Author: cbrock):
After having a conversation with Dan Allen about solving this problem, this is what we came up with.
We propose the addition of two new annotations, @Before and @After which both accept {{Class<? extends Annotation>[]}} to reference qualifiers (one or more).
For example:
*Case A:*
{code}
public class MyBean
public void myFirstObserver(@Observes @Before(Initialization.class) MyEvent event) {
...
}
public void mySecondObserver(@Observes @Initialization MyEvent event) {
...
}
}
{code}
*Case B:*
{code}
public class MyBean
public void myFirstObserver(@Observes @After(Initialization.class) MyEvent event) {
...
}
public void mySecondObserver(@Observes @Initialization MyEvent event) {
...
}
}
{code}
In Case A, the container would guarantee that when a {{MyEvent}} is fired, that {{myFirstObserver()}} is called before {{mySecondObserver()}}. In Case B, the container would guarantee that {{myFirstObserver()}} is called only _after_ {{mySecondObserver()}} has been called.
In a situation where multiple observers are observing the event with the referenced qualifier, {{@Before}} will indicate the annotated observer shall execute before any of those thus qualified execute. The converse will be true for {{@After}}.
Where multiple qualifiers are specified in {{@Before}} or {{@After}} the matching behavior will be identical to the dispatch matching behavior of the CDI specification. For instance:
*Case C*
{code}
public void firstObserver(@Observes @A @B @C MyEvent event) {
}
public void secondObserver(@Observes @A @B @D MyEvent event) {
}
public void thirdObserver(@Observes @A @E @F @After({A.class, D.class}) MyEvent event) {
}
{code}
In Case C, {{thirdObserver()}} will only be called after {{secondObserver()}} is called. However, {{firstObserver()}} may be called before or after; the contract with the container does not guarantee any firing order for {{firstObserver()}} relative to the other two observers.
---
Also, the specification may benefit from the addition of an {{@OrderingQualifier}} which permits the creation of qualifiers used only for the purpose of ordering, but are otherwise ignored by the container for dispatching of events. This would be optional, of course. Any regular qualifier can be used for ordering.
Example:
{code}
@OrderingQualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.PARAMETER, ElementType.FIELD, ElementType.METHOD})
public @interface MyQualifier {
}
{code}
The presence of ordering qualifiers may muddy the water a little bit in terms of readability. However, I could foresee situations where the use of ordering qualifiers -- when used properly -- could make resolving some complex ordering situations less difficult. At the very least, it would allow for dispatch ordering that could not be circumvented accidentally. And by that I mean, ordering qualifiers cannot be used to qualify event consumers; they are used by the container merely for resolving the dispatch ordering -- which is done when the container bootstraps -- and otherwise have no runtime side-effects.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Christopher Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years