search

jakartaee / messaging

Jakarta Messaging
https://eclipse.org/ee4j/messaging
Other
40 stars 33 forks source link

Jakarta Messaging Next #242

Open dblevins opened 5 years ago

dblevins commented 5 years ago

This issue serves as effectively the JSR replacement, intended to give a high-level view of the Jakarta Messaging 3.0 road map and goals.

Road Map

The community is still bootstrapping initial discussion. All items below should be viewed as tentative.

New Features

Enhancements

TBD

Bugs

TBD

Resources

Submit a Use Case or Proposal

For information on how to submit a use case or proposal, file a new issue labeled either use case or proposal. Do not file one issue labeled with both. See this for more guidance:

m-reza-rahman commented 5 years ago

This looks good. I'll add more (lower priority) issues as soon as I can. Did you happen to look through the old issues from JMS 2.1? Nigel and I had filed quite a few as backlog items. If not, I can track those down and just link them?

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.

vongosling commented 4 years ago

Great, I am very happy to hear the next step for previous JMS specification, especially the change from https://github.com/eclipse-ee4j/jms-api to https://github.com/eclipse-ee4j/messaging-api. @dblevins I wonder do you consider to import the connector, event or streaming support, some works are made by OpenMessaging(https://github.com/openmessaging). if any possible, we could work together in messaging field :-)

arjantijms commented 3 years ago

I changed the title to 4.0, as we already delivered 3.0.

Continuing this though, now that EE 9 has been delivered, should we start to set dates for these items? Anyone eager to start doing a prototype implementation for some of these things?

dblevins commented 3 years ago

Switched it from 4.0 to "Next" as we could potentially deliver some of these things in a handful of smaller releases: 3.1, 3.2, 3.3 and iterate.

On prototyping, certainly, anyone is welcome to start! On my end we'll be 100% focused on getting TomEE Jakarta EE 8 and 9 certified before we tackle new spec work.

OndroMih commented 3 years ago

Hi @vongosling,

I'm reacting to your comment here and to your email in https://www.eclipse.org/lists/jms-dev/msg00151.html as well.

First about your concerns about container environment. I believe you don't need to be afraid that JMS would require running in a container for any functionality. The idea is only to make it easier to use MDBs if the application already runs in a container. A new Annotation-Based API aims to replace the cumbersome MDB API, CDI integration should make it possible to specify the scope of MDBs and also clarify how CDI beans are injected into MDBs. All in all, this doesn't add any substantial functionality, it aims only to simplify and clarify existing features.

However, it would also be interesting to add support for something new that's missing. I agree that support for connectors and streaming would be useful. For streaming, I would like to avoid having to rely on some reactive API if possible, or at least rely on Java 9 Flow interfaces and let people use a reactive library that combines publishers and subscribers. MicroProfile reactive messaging already has support for both connectors and streaming so we can look into whether and how we can bring some of it over to Jakarta Messaging. MicroProfile has some nice things, like channels, which can be mapped to connectors to external systems (e.g. to a JMS topic) or to internal lightweight topics to connect and chain publishers and suppliers. On the other hand, what I don't like about MicroProfile RS is the complexity of the reactive API, which is hard to get around even for people who have experience with reactive programming.