yep both have advantages and drawbacks. One open question for me is Class or String but not int cause first thing you'll do if not the name (or class) is to look for all other adatpers...not efficient. Class makes a forced dependency, String make it optional. ATM I think Class is enough while we don't abuse of it in extensions like does arquillian (which uses priority because it can't do anything else).
I really hope we don't need it. Trying to summarize my thoughts: while internal events I think api is nice and efficient but for the particular event we speak about we can just fire a CDI event and benefit from @Priority very soon ;). Would make everybody happy Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-03-21 21:09 GMT+01:00 David Blevins <david.blev...@gmail.com>: > There are some downsides to reference based approaches as well. > > A.class: public void observe(final @Observes SimpleEvent event) > Z.class: public void observe(final @Observes(after=A.class) SimpleEvent > event) > > If you later want to add B.class or C.class in the middle between A and Z, > you can't. > > As well you can't really express things like "low priority" and "high > priority" > > EventLogger.class: public void observe(final @Observes(priority=1) > Object event) > > > On Mar 21, 2014, at 12:08 PM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> -1 to index, it is what is in deltaspike, spec etc and it doesn't work >> by design (see the spec already defined constants). For such an >> internal thing we know where we want to bind our event so I still >> think referencing the event is better. >> >> Always better to say where you want to be than saying "i want to be >> here...almost" which is the index case. >> Romain Manni-Bucau >> Twitter: @rmannibucau >> Blog: http://rmannibucau.wordpress.com/ >> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> Github: https://github.com/rmannibucau >> >> >> >> 2014-03-21 20:02 GMT+01:00 David Blevins <david.blev...@gmail.com>: >>> For Observers maybe we can find another way to achieve OPENEJB-2082 without >>> binding one observer directly to another: >>> >>> public void observe(final @Observes(after = SimpleObserver.class) >>> SimpleEvent event) >>> >>> I can see that creating just as much of a mess as having too many events. >>> Having to sort each event is not exactly optimal for speed either. >>> >>> If we were to take a sorting based approach, maybe we can take a page from >>> the interceptor ordering of Java EE 7, based on unix start orders: >>> >>> @Priority(5) >>> public void observe(final @Observes SimpleEvent event) >>> >>> Default priority for all observers would be say, 5, like it is for a >>> thread. We would recommend 1-10 as the range and use a float rather than >>> an int so it can be easy to break a tie without complex hacking. >>> >>> Also as an optimization, we don't actually call the sort method unless one >>> of the Observers actually has a priority. >>> >>> Thoughts? >>> >>> >>> -David >>> >
