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