[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ] Mike Brock edited comment on CDI-4 at 5/8/11 3:45 PM: ------------------------------------------------------ A few points of contention here: _"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"_ Can you give a solid example of this? I mean, one the reasons why I am proposing this, is that the sorting _can_ deal with the addition of new beans which have ordered observers. The solution that you're proposing -- which is to use a sort of "marathon pattern" -- seems to suffer greatly from a coupling problem, because you're relying there being a discretely defined event type for each step. That, in itself, almost entirely precludes the adding of new beans to the container that change the ordering -- at all. I'm struggling to see how my proposal introduces coupling. Having both {{@Before}} and {{@After}} is, for the very reason of dealing with potentially unseen model, very necessary. Say I have an event {{BusEvent}}. And it has qualifiers like {{@Initialize}} and {{@PostInitialize}}. If I add a jar in the future which contains a bean which has say, something like this: {code} public void beforeInit(@Observes @Before(Initialize.class) BusEvent event) { ... } {code} ... I would get _exactly_ the kind of behavior I would expect. So I fail to see the problem you're referring to. There'd be no guarantee of ordering for all the @Before(Initialize.class) events, but I somehow doubt that would be any trouble in such a use case. --- _"The service could be something like javax.enterprise.inject.spi.ObserverComparator, applied after the ProcessObserverMethod event."_ I think this is actually a really good idea. But it's really orthogonal to the problem I'm trying to solve. For the very example I point out above. It seems to me that event ordering is not something which violates decoupling of events, and is a concept which is purely a component-container contract issue. Simply having say, a framework like Forge implement comparators, doesn't help readability of the model at all. In fact, it sort of suffers from the same problem that putting the configuration in an XML file suffers from: you can't get any sense of the ordering just by looking at any given observer. was (Author: cbrock): A few points of contention here: _"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"_ Can you give a solid example of this? I mean, one the reasons why I am proposing this, is that the sorting _can_ deal with the addition of new beans which have ordered observers. The solution that you're proposing -- which is to use a sort of "marathon pattern" -- seems to suffer greatly from a coupling problem, because you're relying there being a discretely defined event type for each step. That, in itself, almost entirely precludes the adding of new beans to the container that change the ordering -- at all. I'm struggling to see how my proposal introduces coupling. Having both {{@Before}} and {{@After}} is, for the very reason of dealing with potentially unseen model, very necessary. Say I have an event {{BusEvent}}. And it has qualifiers like {{@Initialize}} and {{@PostInitialize}}. If I add a jar in the future which contains a bean which has say, something like this: {code} public void beforeInit(@Observes @Before(Initialize.class) BusEvent event) { ... } {code} ... I would get _exactly_ the kind of behavior I would expect. So I fail to see the problem you're referring to. --- _"The service could be something like javax.enterprise.inject.spi.ObserverComparator, applied after the ProcessObserverMethod event."_ I think this is actually a really good idea. But it's really orthogonal to the problem I'm trying to solve. For the very example I point out above. It seems to me that event ordering is not something which violates decoupling of events, and is a concept which is purely a component-container contract issue. Simply having say, a framework like Forge implement comparators, doesn't help readability of the model at all. In fact, it sort of suffers from the same problem that putting the configuration in an XML file suffers from: you can't get any sense of the ordering just by looking at any given observer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira