Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jms-dev] Eclipse Project for JMS 
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
>

Back to the top