|
I think you writing down the initial
API proposals might avoid future issues. I can help perhaps
moderate the discussions and give minor feedback.
It would be helpful if the Eclipse
folks provided some guidance. The general guideline I follow is
everything is fine until you need to commit code that will be
licensed. However, I am very far from a lawyer.
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/23/2019 9:05 PM, David Blevins
wrote:
I think that's a judgement call you need to make. It generally
isn't code that's the biggest concern, but patentable ideas.
If it helps, I plan to create
written proposals this weekend for everything I presented on
the 10th for JakartaOne Live.
--
To be honest my paperwork
status with the Eclipse Foundation is murky. As a
result, I do not want to put the IP status of this work
at risk. Let's treat me as someone that cannot commit
code right now to be safe. I will get this fixed on my
end as soon as I can.
That being the case, do you
think there are any issues with me getting the
discussion started? When it gets to the point of needing
to commit code, I will ask for help from someone that
has a clear IP line. Is that alright (this question is
really directed at the good people at the Eclipse
Foundation)?
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/23/2019 8:34 PM, David
Blevins wrote:
You're a committer according to the project proposal at
least. Either way, I'd say definitely don't step aside.
IMO, if the line between committer and
contributor was blurry to invisible, that'd be pretty
fantastic. Anyone willing to do work should be
enabled to the best of our ability.
Can I begin
putting the road map together without
actually being a committer right away? When
the commiters step up, I will step aside.
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/23/2019 7: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
--
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.
_______________________________________________
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.
_______________________________________________
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.
|
