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