For an overview of the original proposal, please review https://issues.jboss.org/browse/SEAMJMS-3 https://issues.jboss.org/browse/SEAMJMS-4 Why are we doing this? The issue raised recently on the list is that during AfterBeanDiscovery, there is no guarantee that beans are available. This conflicts with the Egress side of the feature where the full observer method must be created during ABD. As a result, we cannot guarantee that looking up beans will work (in fact, we can typically guarantee it won't work). Therefor, we can not support generic qualifiers on the destinations that are involved in the mapping, the extension needs to be able to resolve the destination manually. As a result, I am proposing a shorter, more defined API that will define the same type of interface level observer definitions, but have certain annotation requirements. There will continue to be no class level requirements for interfaces. Any class level annotations will be ignored. public void methodName(@Observes @SomeQualifier MyObject obj, @JmsDestination(jndiName="jms/SomeQueue") Queue q); This defines that an event fired of type MyObject qualified SomeQualifier will be sent to the queue at jms/SomeQueue. Then, messages received of jms/SomeQueue that can be cast to MyObject get fired under the same qualifier. You can have any number of arguments that are extensions of Destination (Queue & Topic). In addition, argument order is not taken into account. You can define your destinations in any order. JmsDestination is a Seam JMS provided annotation. The second supported style uses @Resource. Note that there is a current issue with JBoss Meta that requires a limitation of the interface. https://issues.jboss.org/browse/JBMETA-328 . @Resource(mappedName="jms/SomeTopic") @SomeQualifier public MyObject methodName(); Arguments to the method are optional, and are ignored. The functional behavior of this mapping is the exact same as the prior. In addition, JmsDestination can replace Resource in this case. In both of these examples, you can add in @RouteType(Routing.INGRESS) or @RouteType(Routing.EGRESS). If either of these are present, then only the listed routing type will be created (ingress for in bound messages on queues/topics, egress for outbound events to queues/topics). I hope that this is clear enough for all, but it's what I believe we can accomplish near term and still provide a concrete API to develop against that will work consistently across platforms. John