Re: [jms-dev] Thoughts on JMS 3.0

[Snackbox <snackbox@xxxxxxxxx>]

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