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@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jms-dev
|
