|Re: [jms-dev] Thoughts on JMS 3.0
Reza Rahman Principal Program Manager Java on AzurePlease note views expressed here are my own as an individual community member and do not reflect the views of my employer.
On 9/15/2019 11:27 AM, Snackbox wrote:
Alexey!On 2019-09-15, at 16:45, Alexey <onodera@xxxxxxx> wrote: Hello 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.Maybe the queue name should go into the config? It’s more something about the environment than the application itself. In the MessageApi, I used the name of the interface as a default, e.g. `org.example.NotificationsClient`.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.I strongly agree!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.I like your idea! So only if an application needs more than one reply, e.g. when sending a build-start and a build-success event, the code would have to care about the response queue. RüFrom: ghzooooon@xxxxxxxxx Sent: Sunday, September 15, 2019 01:10 To: jms developer discussions Subject: Re: [jms-dev] Thoughts on JMS 3.0 Hi everyone, I really love the ideas on David's presentation, also great work Rüdiger. Hi all, I just watched the presentation David gave on Jakarta Messaging 3.0 in the JakartaOne livestream, and I loved it. This is really what JMS needs and it probably just takes the right time for a revolution like this to become a reality. Back in 2010 I was coding a lot of JMS senders and receivers, so I turned my pain with writing all that boiler plate code into what I termed MessageApi (https://github.com/t1/message-api), which was based roughly on the same ideas as JMS 3.0. I even joined the JMS EG to help promote it into a standard, but it was obviously way too early. It’s wonderful to see something similar to happen now; it seems that some ideas are just destined to become reality! I haven’t worked with JMS for the last 5 years or so, so there was no progress from my side any more. Maybe you’ll find my old input worth taking a look at. Kind regards, Rüdiger _______________________________________________ jms-dev mailing list jms-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jms-dev _______________________________________________ jms-dev mailing list jms-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jms-dev_______________________________________________ jms-dev mailing list jms-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jms-dev
-- Reza Rahman Principal Program Manager Java on Azure Please note that views here are my own as an individual community member and do not represent the views of my employer.
Back to the top