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.