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
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links:
You receive all messages sent to this group.
View/Reply Online (#4):
https://javaee.groups.io/g/jms-spec/message/4
View All Messages In Topic (1):
https://javaee.groups.io/g/jms-spec/topic/19351565
Mute This Topic: https://groups.io/mt/19351565/326345
New Topic: https://javaee.groups.io/g/jms-spec/post
Change Your Subscription:
https://javaee.groups.io/g/jms-spec/editsub/326345
Group Home: https://javaee.groups.io/g/jms-spec
Contact Group Owner: jms-spec+owner@xxxxxxxxxxxxxxxx
Terms of Service: https://groups.io/static/tos
Unsubscribe:
https://javaee.groups.io/g/jms-spec/leave/666105/1067038317/xyzzy
-=-=-=-=-=-=-=-=-=-=-=-
_______________________________________________
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
