Something I've been thinking about for a while now is the mapping APIs used by Seam JMS. Currently, you write an interface to define routes used by JMS events. This requires a bit of extra code that I'm not a big fan of. What I was thinking was put an extra annotation on either the injection point of the event or the observer method. The idea is that the annotation would include all of the destination configuration necessary. For example: @Inject @JMS("jms/QueueOne","jms/QueueTwo","jms/QueueThree") Event<MyType> myTypeEvent; @JMS("jms/MyTopic") public void handleMessages(@Observes Long longsInTopic) { .... } The issues I see, since essentially I have to create an extra observer/firing pair to support each of these, is how to determine the observed type in the event. In general, any thoughts? Is it possible to determine the event's type in this case? If so, does the approach make sense? - John

On 2 Jun 2011, at 02:29, John D. Ament wrote: > Something I've been thinking about for a while now is the mapping APIs used by Seam JMS. Currently, you write an interface to define routes used by JMS events. This requires a bit of extra code that I'm not a big fan of. What I was thinking was put an extra annotation on either the injection point of the event or the observer method. The idea is that the annotation would include all of the destination configuration necessary. For example: > > @Inject @JMS("jms/QueueOne","jms/QueueTwo","jms/QueueThree") Event<MyType> myTypeEvent; > > @JMS("jms/MyTopic") > public void handleMessages(@Observes Long longsInTopic) { > > .... > > } > > The issues I see, since essentially I have to create an extra observer/firing pair to support each of these, is how to determine the observed type in the event. In general, any thoughts? Is it possible to determine the event's type in this case? If so, does the approach make sense? Can you show what this replaces? I.e. before and after?

On 2 Jun 2011, at 16:15, John D. Ament wrote: > Certainly, would have made more sense. > > Currently, in JMS you define interfaces like this to map routes - equivalent to a CDI Event Bridge - to JMS Destinations (Queues and Topics): > > public interfaces MyMappingInterface{ > @Inbound > public void handleStrings(@Observes String s, @JmsDestination("jms/MyTopic") Topic topic); > @Outbound > public void handleLongs(@Observes Long l, @JmsDestination("jms/MyQueue") Queue queue); > } > > This says that a listener will be created for the topic jms/MyTopic and any TextMessage or ObjectMessage with payload type String.class will be forwarded to an observer method defined like this: > > public void observeStrings(@Observes @Inbound String s) { > > } > > Likewise, the second line in the interface says that Events of type Long that are fired with the @Outbound qualifier will be sent to a Queue jms/MyQueue, > > @Inject @Outbound Event<Long> longEvent; > > Results in Seam JMS dynamically generating an observer method on deployment that handles and forwards the long fired. > > What I'm proposing is that we do away with (not literally, I would keep it in) the interface. Instead, we look at the events injected and the observers defined. The same observer method would be defined like this: > > @JMS("jms/MyTopic") > public void observeStrings(@Observes @Inbound String s) { > } > > And the injected event: > > @Inject @JMS("jms/MyQueue") @Outbound Event<Long> longEvent; > > Does that make sense? Yes. However my concern with this scheme is that we are now defining that the observer method receives JMS events (and the event sends them) rather than defining a mapping between CDI events/observers and JMS. I think this is a step backward as increases coupling.

On 5 Jun 2011, at 21:01, John D. Ament wrote: > I do agree that this binds the observer to a JMS specific event, however I don't believe that it is any different than how it is treated today. Remember that JMS events must be uniquely qualified at both the firing and the observing points to avoid event feedback/infinite messaging I have to admit to (still) not really understanding this. Can you explain why (again, I know ;-). > (this is true of pretty much any of the bus implementations out there, most are proxying the object in a non child wrapper, JMS is trying to avoid this). This doesn't block the application developer from creating standard observers for the object, but does add the need to identify the event point as JMS rather than the event type > > I guess this argument boils down to which makes more sense. Should the event type define the event bus, or should the event injection point define the bus? If we go with the former, then all strings would be forwarded to JMS, Errai, etc, whereas in the latter than specific strings qualified per event bus get to JMS, and other strings qualified for errai go to Errai. If we go with the latter, we can also do this: > if(forwardEventToJms) { > eventToFire.select(JmsLiteral.INSTANCE).fire(someObject); > } else if(forwardToErrai) { > eventToFire.seelct(ErraiLiteral.INSTANCE).fire(someObject); > } > > Like I mentioned, I would remove the current capability, but this would augment it. > > > On Fri, Jun 3, 2011 at 9:43 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > > On 2 Jun 2011, at 16:15, John D. Ament wrote: > > > Certainly, would have made more sense. > > > > Currently, in JMS you define interfaces like this to map routes - equivalent to a CDI Event Bridge - to JMS Destinations (Queues and Topics): > > > > public interfaces MyMappingInterface{ > > @Inbound > > public void handleStrings(@Observes String s, @JmsDestination("jms/MyTopic") Topic topic); > > @Outbound > > public void handleLongs(@Observes Long l, @JmsDestination("jms/MyQueue") Queue queue); > > } > > > > This says that a listener will be created for the topic jms/MyTopic and any TextMessage or ObjectMessage with payload type String.class will be forwarded to an observer method defined like this: > > > > public void observeStrings(@Observes @Inbound String s) { > > > > } > > > > Likewise, the second line in the interface says that Events of type Long that are fired with the @Outbound qualifier will be sent to a Queue jms/MyQueue, > > > > @Inject @Outbound Event<Long> longEvent; > > > > Results in Seam JMS dynamically generating an observer method on deployment that handles and forwards the long fired. > > > > What I'm proposing is that we do away with (not literally, I would keep it in) the interface. Instead, we look at the events injected and the observers defined. The same observer method would be defined like this: > > > > @JMS("jms/MyTopic") > > public void observeStrings(@Observes @Inbound String s) { > > } > > > > And the injected event: > > > > @Inject @JMS("jms/MyQueue") @Outbound Event<Long> longEvent; > > > > Does that make sense? > > Yes. > > However my concern with this scheme is that we are now defining that the observer method receives JMS events (and the event sends them) rather than defining a mapping between CDI events/observers and JMS. > > I think this is a step backward as increases coupling. >