Java EE issues from java.net JIRA projects were transferred to
their corresponding GitHub issue trackers. The issues from
JavaEE GitHub organization projects are being migrated over to
Jakarta EE project repositories. JMS API issues in Jakarta EE
are at this
link. These are migrated after the initial code push. For
many projects, this is still work in progress but they should
find their way into Jakarta EE.
If you have issue IDs, the IDs should match the ID from the
original java.net JIRA. The issues you had previously filed at
java.net can be found by search with search-term "reza" (here's
a link).
Do you know if the Java.net JIRA issues are archived
somewhere? That's really the best way for me to re-engage and
state what I had in mind originally.
What I see missing at a high level are:
* Decoupling from EJB altogether.
* Standardizing parallelism, retries, dead letter queues
and so on.
* Higher level declarative semantics for things like bulk
processing, ordering, request-reply model using correlation
ID/reply-to header and so on.
In addition we should look at the following:
* The reactive/flow control stuff the person from Lightbend
had in mind vis-a-vis JMS.
* An analysis of what can be adopted from the likes of
Kafka to make JMS more compelling to people now using those
solutions instead of JMS. My layman's understanding is that it
has mostly to do with quality of service than API as well as
things like clustering and routing that JMS does not really
specify. In fact it may be smart to make whatever API we come
up with work with Kafka as part of DeltaSpike or MicroProfile.
* One issue with microservices seemingly is
interoperability. Maybe it's time again to look to an AMQP,
REST/WebSocket, gRPC or like binding for JMS.
Other than this, what you have I think is fine, although I
sort of question the value of the CDI Event binding part. I
suspect there would be far too much mapping to do in both
directions. As always, it's probably a matter of prioritizing
and tackling what time and resources allow.
Sent via
the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
Date: 5/18/18 8:43 PM (GMT+01:00)
Subject: Re: [jms] Eclipse Project for JMS
[resending as it didn't make it to jms-spec@xxxxxxxxxxxxxxxx]
Hi Everyone!
The new Eclipse list for future JMS work is jms-dev@xxxxxxxxxxx,
which you can subscribe to via sending an email to jms-dev-subscribe@xxxxxxxxxxx.
We should make sure everyone does that, but as there are
currently only 10 subscribers on that list, I think we should cc
both lists for a short period of time.
High-level there's an effort in Jakarta EE overall to have
projects put some thoughts together on the roadmap. Understand
this does not need to be perfect or exhaustive or permanent.
Just something to get us started and ensure technical direction
is originating here.
For those who want a good resource on where we left off with JMS
2.1, here's the page we had been using to aggregate status:
- https://javaee.github.io/jms-spec/pages/JMS21
Essentially, the work that was underway was to create a
completely annotation-driven API for consuming JMS messages
styled after JAX-RS. This would allow:
- Consumption of messages from multiple topics/queues in one
class (like JAX-RS has @Path to allow multiple endpoints)
- Consumption of messages using specific Message types (no need
to cast to TextMessage, just declare that)
- Ability to pass message headers into the methods (like JAX-RS
has @PathParam, @HeaderParam, etc)
- Ability to convert from string to Java for those method params
(like JAX-RS can eliminate "parsing" of string-to-java for
method params)
This underwent at least 5 revisions. Here's the latest:
- https://javaee.github.io/jms-spec/pages/JMSListener5
What wasn't underway, but I think we should add:
- Ability to convert the message itself to Java via JAXB or
JSON-B (like JAX-RS can convert bodies to java based on
content-type)
We discussed a handful of CDI related topics:
- Allowing the consumption of messages via CDI Events
- Potential custom scopes specific to JMS
We can do what we want, but that is more or less what was in
motion before JMS 2.1 was officially shut down.
One thing I think we should correct is if we add this major new
JAX-RS-styled message consumption API, it's probably bigger than
a "point 1" release. I.e. we should go big and call it JMS 3.0
instead of hiding it in a JMS 2.1.
This could be one of the major headlining things to come out of
Jakarta EE, why go small.
Anyway, this is just an attempt to bootstrap a community
conversation, so do speak up! All ideas are on the table.
-David
> On May 17, 2018, at 11:14 AM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
wrote:
>
> Hi,
>
> If you are interested in contributing to the new expert
group at the Eclipse Foundation, which will be defining JMS 3.0
for Jakarta EE, please send me an email. David Blevin’s is
leading the effort . At this time we are not formally forming
the expert group, which is currently named “Eclipse Project for
JMS”, but will have a voting process in place later. For now, we
are looking to discuss the future of the specification and put
together ideas for a rough roadmap to share with the Jakarta EE
Project Management Comittee. If you or someone you know, wants
to contribute to this effort please reply to me directly at rmonson@xxxxxxxxxxxxx.
>
> Thank you,
>
> Richard Monson-Haefel
> Sr. Software Engineer
> Tomitribe
> --
> Richard Monson-Haefel
> http://twitter.com/rmonson
> http://www.tomitribe.com
> http://www.tomitribe.io
>
_______________________________________________
jms-dev mailing list
jms-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jms-dev
