|Re: [jms-dev] Thoughts on JMS 3.0|
I agree that the ideas are great and would make a lot of existing boilerplate redundant. There’s just one piece of the puzzle that’s missing: how do you link the new listener to a JMS connection?
If you take a look at https://github.com/tomitribe/jms-proposals/blob/master/all-together/src/test/java/org/example/BuildAndNotify.java, it’s just a @MessageConsumer, so there must be a place in the code that creates the correct connection factory and attaches the consumer to the correct connection. This is something that shouldn’t be an implementation detail of a Jakarta EE application server, as I hope to see Jakarta Messaging 100% usable in lightweight applications.
Another piece of the same code that I linked to above that bothers me is the creation of the new strongly-typed client. First of all, it should probably be injected into the class instead of the connection factory. And secondly, a lot of JMS code replies to the queue specified in the ReplyTo header, so a non-void listener method could be annotated to indicate the way its return value should be converted to the message to be sent to that queue.
Back to the top