Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jms-dev] Thoughts on JMS 3.0

I agree with Ed on both sentiments; you don't need to be a committer and we can start anytime.  On my side of the fence I'll be on the same evenings-and-weekends commitment level as likely everyone else for the rest of the year as a ton of things went on hold to get Jakarta EE 8 out the door.

Wayne, what's the process for either either getting a new empty "messaging-proposals" repo created or this one moved over as "messaging-proposals"?


I suspect new repo is easier logistically -- I can commit everything again with the right license, etc.

-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

On Sep 23, 2019, at 4:39 PM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:

And don't forget ... lots of useful work can be accomplished without being a committer. Pull Requests can accomplish many things at GitHub.

On 9/23/2019 4:31 PM, Ed Bratt wrote:

Initial contributors were included in the original project proposals, which you can find here (search for the JMS proposal). Since then, changes to committer list have been handled through the committer election process.  Wayne wrote a blog page here, which describes this process. Current JMS committer list is here.

It would be fabulous if someone could start putting a road-map for JMS together. I don't know why we'd need to wait on putting together the thoughts on this.

-- Ed

On 9/23/2019 2:48 PM, Reza Rahman wrote:
Does anyone know what the time frame for starting this work is? Who become the first committers?

Reza Rahman
Principal Program Manager
Java on Azure

Please 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.




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



_______________________________________________
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


Back to the top