[ 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira