Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [messaging-dev] Meeting minutes from 16th June 2021

To reiterate what I said during the meeting, I feel confident Microsoft will officially invest into an effort to modernize Messaging via a Lite Profile (while also moving forward more minor, non provider related enhancements in the older full profile) as well as AMQP interoperability.

I hope we achieve broad consensus to move forward one or both these items.

From a purely personal standpoint, I would like to see MDB replaced by a modern CDI based equivalent. The MDB/EJB programming model is a very damaged brand, inflexible and now quite out of date. It doesn’t help moving the Jakarta brand forward.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On Jun 21, 2021, at 7:09 PM, Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:

Hi all,

Here are minutes from our meeting the previous week. They are published at I copy the minutes also here:

16th June 2021


  • Ivar Grimstad (Eclipse Foundation)
  • Ed Bratt (Oracle)
  • David Blevins (Tomitribe)
  • Jonathan Gallimore (Tomitribe)
  • Emmanuel Hugonnet (Red Hat).
  • Daniel Kec (Oracle)
  • Tanja Obradovic (Eclipse Foundation)
  • Luke Saker (IBM)
  • Reza Rahman
  • Clebert Suconic (Red Hat)
  • Ondro Mihalyi (Payara)


  • (Ondro) EE Messaging 3.1 plan as was approved recently didn’t have high goals, maybe we can add new features, but we aim here to discuss longer plans for EE Messaging
  • (Clebert) JMS is more than 20 years long and has a lot of legacy, which isn’t needed anymore and there’s a lot of usecases where it’s complicated or not possible to use it in the current state
  • (Reza) Presented a document that triages existing issues into categories and priorities
  • (Ondro) An idea: old API should be separated or maybe even create a new messaging spec side by side with the old spec
  • (David) it makes sense to separate the old API and and make it optional, maybe even create a “lite” profile with only the new API
  • (David and Clebert) The new API should be simple and allow that semantics are up to the implementation
  • (Ondro) We should revisit MicroProfile Messaging because they tried to achieve a similar goal
  • (David) it seems we have a consensus
  • (Reza) If there’s a consensus, MS (Azure Service Bus team) is interested to join and collaborate
  • (Ivar) To confirm a consensus, there should be a vote
  • (David) if we leave semantics to the implementations then it’s possible to find a good trade-off between speed and reliability by choosing an appropriate implementation
  • (David) We should create a new issue to cover the “lite” profile or reuse existing related issues - optional/relaxed delivery semantics and guarantees, etc.
  • Some existing related issues
  • (David) Let’s have an issue for each specific guarantee to relax them or make them optional
  • (David) Presented a proposed structure for the messaging-propsals repository, with a structure in the README file for each proposal, for example README for JSON-B proposal
messaging-dev mailing list
To unsubscribe from this list, visit

Back to the top