[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:
---------------------------------
Interesting idea, tell us more.
Anything which is 'outside' the observers is a welcome bonus. If we create a model where the observers need to know about other observers, then 90% of the benefits of the observer/observable pattern is lost imo.
> 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: Mike 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
14 years, 8 months
[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Jason Porter (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Jason Porter commented on CDI-4:
--------------------------------
Maybe I'm coming at this from an odd angle, but why not allow them to register, via the same service provider API, a Comparator<InjectionPoint> or Comparator<ObserverMethod>? We could leave everything the way it is or create a default one that just returns 0. This allows the users complete control over where each observer falls in the set of observers, they don't need to add more XML, it's a very simply, widely used pattern for ordering. Not sure why we're trying to reinvent an ordering solution when one has already been provided by the language.
> 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: Mike 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
14 years, 8 months
[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/8/11 6:31 AM:
---------------------------------------------------------
huh, just realized that I could do the 2nd code block even more elegantly:
{code}
public void checkSecurity(@Observes MyEvent me, @Secured Event<MyEvent> securedEventSource) {
checkSecurity();
securedEventSource.fire(me);
}
{code}
The trick here is that any observer method can have additional injection points as parameters which will get resolved by the container automatically ...
was (Author: struberg):
huh, just realized that I could to the 2nd code block even more elegantly:
{code}
public void checkSecurity(@Observes MyEvent me, @Secured Event<MyEvent> securedEventSource) {
checkSecurity();
securedEventSource.fire(me);
}
{code}
The trick here is that any observer method can have additional injection points as parameters which will get resolved by the container automatically ...
> 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: Mike 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
14 years, 8 months
[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:
---------------------------------
huh, just realized that I could to the 2nd code block even more elegantly:
{code}
public void checkSecurity(@Observes MyEvent me, @Secured Event<MyEvent> securedEventSource) {
checkSecurity();
securedEventSource.fire(me);
}
{code}
The trick here is that any observer method can have additional injection points as parameters which will get resolved by the container automatically ...
> 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: Mike 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
14 years, 8 months
[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:
---------------------------------
John, think you mean the discussion over in CDI-7, right?
Btw, good discussion right now. Think we are moving forward.
I understand that magic numbers is not an optimal idea neither. So lets step back a bit and look at the problem from the distance.
* the @Before doesn't scale out in practice. You cannot always change your event if someone adds a jar into the classpath which needs that event
* the @After is not necessary. The problems you explained can also easily get solved with the current spec. See my example below
The original code just throws the original Event:
{code}
BeanManager.fire(new MyEvent());
{code}
The 'before' observes this event, does some security checks and rethrows it with a qualifier @Secured
{code}
public void checkSecurity(@Observes MyEvent me) {
checkSecurity();
bm.fire(me, SecuredAnnotationLiteral);
}
{code}
The 'after' then just observes the @Secured version of the event
{code}
public void doThaRealThing(@Observes @Secured MyEvent me) {
doTheActualWork();
}
{code}
I'm coming always closer to the firm conviction that we should pull out the observer ordering into an external config, as we did with interceptor ordering.
> 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: Mike 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
14 years, 8 months
[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
John Ament commented on CDI-4:
------------------------------
One of the things Pete and I spoke about was observer resolution with multiple qualifiers. I believe the 1.0 spec has an issue with terminology (another inconsistency in it). I would recommend against a solution to this that relied on the idea of multiple qualifiers resolving to similar observers.
> 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
14 years, 8 months
[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Christian Sadilek (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Christian Sadilek commented on CDI-4:
-------------------------------------
I'd prefer the more expressive approach using @Before and @After over the simpler approach using salience/priority values.
However, I'd like to suggest having the ordering specified on the observer methods rather than on the event parameters. That is to have a separation of concerns between event qualifiers and observer ordering. I think this would further increase readability:
{code}
public class MyBean
public void myFirstObserver(@Observes @A @B MyEvent event) {
...
}
@After({A.class, B.class})
public void mySecondObserver(@Observes @A @B @C MyEvent event) {
...
}
}
{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
14 years, 8 months
[JBoss JIRA] Commented: (CDI-70) Clarify that if an extension provides an Annotated* then it is considered "metadata complete"
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-70?page=com.atlassian.jira.plugin.sys... ]
Arne Limburg commented on CDI-70:
---------------------------------
The spec already says in 11.4. that the container must not use the reflection api, but it is not emphasized and should be explicitly sayed in 11.5.5. If you change the sentence "The container must use the operations of Annotated and its subinterfaces to discover program element types and annotations, instead of directly calling the Java Reflection API" (in 11.4.) to "The container must use the operations of Annotated and its subinterfaces to discover program element types and annotations. The container must not directly call the Java Reflection API." it would emphasize this behavior. An additional sentence about missing fields, methods or parameters would clarify it even more.
In 11.5.5. you may change "The container must use the final value
of this property, after all observers have been called, to discover the types and read the annotations of the program elements." to "The container must use the final value of this property, after all observers have been called, as the only source to discover the types and program elements and read their annotations."
> Clarify that if an extension provides an Annotated* then it is considered "metadata complete"
> ---------------------------------------------------------------------------------------------
>
> Key: CDI-70
> URL: https://issues.jboss.org/browse/CDI-70
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> I think the correct behavior is to ignore any members that are missing from the AnnotatedType. You should not be directly accessing the reflection API at all. If the parameters for a method or a constructor don't match the underlying class, it should be considered a definition error.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[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 2:14 PM:
-------------------------------------------------------------
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}
was (Author: cbrock):
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
14 years, 8 months
[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 2:16 PM:
-------------------------------------------------------------
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. 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}
was (Author: cbrock):
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
14 years, 8 months