Hi,
I'm glad to see some substantial progress in Jakarta Messaging. I've been following the mailing group a long time ago, and I'd like to discuss some of the standard evolutions of messaging. Forget to mention that I was the original founder of Apache RocketMQ and currently working to advance the evolution of the next-generation 5.0 architecture. Personally, I think it might be more valuable to draft a schema registry than the plans that are listed now[1]. Frankly speaking, I'm skeptical about the plans listed here. Early on when I created RocketMQ, I had a concern that I didn't want it to be bound to a container environment like spring or cdi. I like JMS2's succinct abstraction. I created a Linux OpenMessaging project for this similar objectives. Right now, I think with the reorganization of Jakarta EE, we could look at some new options, some ideas like comments here[1].
I'd like to hear from you, and I'm glad to work with you to move the standards forward, let the Apache RocketMQ 5.0 be close to Jakarta Messaging 3.x :-)
Hi,
I'm glad to see some substantial progress in Jakarta Messaging. I've been following the mailing group a long time ago, and I'd like to discuss some of the standard evolutions of messaging. Forget to mention that I was the original founder of Apache RocketMQ and currently working to advance the evolution of the next-generation 5.0 architecture. Personally, I think it might be more valuable to draft a schema registry than the plans that are listed now[1]. Frankly speaking, I'm skeptical about the plans listed here. Early on when I created RocketMQ, I had a concern that I didn't want it to be bound to a container environment like spring or cdi. I like JMS2's succinct abstraction. I created a Linux OpenMessaging project for this similar objectives. Right now, I think with the reorganization of Jakarta EE, we could look at some new options, some ideas like comments here[1].
I'd like to hear from you, and I'm glad to work with you to move the standards forward, let the Apache RocketMQ 5.0 be close to Jakarta Messaging 3.x :-)
> On May 4, 2021, at 4:29 PM, Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:
>
> Because we didn't have any discussion about new features recently, we could introduce something from the roadmap outlined by David in 2019 in a github issue. I would only go after things that are rather straightforward, long overdue, and already well documented. So from the items in that issue, I suggest to consider only:
> • Annotation-Based API for Consuming Messages #243
> • CDI Message Consumers #244
> • MessagingClient #249
> Additionally, we can support repeatable annotations in some cases, e.g. for JMSDestinationDefinition.
[...]
> Should we plan to add the new features as I suggested above? Or it's much more that we can handle and it's better to submit a plan just to add fixes and possibly support repeatable annotations?
My primary influence over thoughts for the plan review is the "for Jakarta EE 10" target. If we're not targeting a specific release and have unlimited time, I'd go for something more like the first suggestion. If we're targeting something that has to be done by EE 10, then I'd go for fixes and repeatable annotations. Note, we can revise our plans via any number of Progress Reviews, so it is possible to start small and add things as they look to become attainable.
There are some practicalities that I think need to be dealt with before we're really positioned to make major changes:
- Not enough people familiar with adding/modifying tests to the TCK.
- Effort to separate JMS tests from jakartaee-tck to a project here
- More compatible implementations filing CCRs
I think it'll be a community effort to separate the JMS section of the TCK from the overall EE TCK and in that process we'll naturally come out the other side with many more people who are positioned to write tests for the ideas we put in the spec.
In terms of implementations, I know I'll need some time to get ActiveMQ classic through the Messaging 3.0 tests. Once that is done, I personally am in a better place to work on new features/tests. I don't know what position other implementations are in such as RabbitMQ or RocketMQ, but we should at least reach out to them about interest in passing the current tests. They could be using the same time to get caught up and we could collectively come out the other side with a lot of implementations at the table.
Anyway, those are some high level thoughts.
I could be persuaded to go for the more aggressive plan, I just don't think it'll be ready for Jakarta EE 10, so it'd probably be better to start small and add to the plan as things become actionable.
My $0.02 for the moment.
-David
_______________________________________________
jms-dev mailing list
jms-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jms-dev
--
--
