[
https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst...
]
Christopher Brock edited comment on CDI-4 at 5/7/11 12:48 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.
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.
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.
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.
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.
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
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