|Re: [jms-dev] Thoughts on JMS 3.0
Hi, I saw a presentation too and I liked the proposal, I just wonder how the management of threads for multiple queues will be done.
Try making a controller similar to the one proposed in the presentation using JavaEE Concurrency. https://github.com/brunodutr/jms-hello-world/blob/master/src/main/java/br/com/bdutra/controller/PessoaController.java
I would like to participate in the discussion to contribute.
Obter o Outlook para Android
From: jms-dev-bounces@xxxxxxxxxxx <jms-dev-bounces@xxxxxxxxxxx> on behalf of Alexey <onodera@xxxxxxx>
Sent: Sunday, September 15, 2019 11:45:30 AM
To: jms developer discussions <jms-dev@xxxxxxxxxxx>
Subject: 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