Reintroduce support for Active MQ

[dogilvie]

ActiveMQ developer Jean-Baptiste Onofré says:

FYI, we will include jakarta/JMS2 client in ActiveMQ 5.18.x (currently
in preparation).

When this is released, please restore an activemq starter for Spring boot 3.0.

In our case, "move to artemis" is not an option as we use Amazon MQ which is currently ActiveMQ classic/RabbitMQ only.

Matt Pavlovich on the activemq users list has produced a jakarta based build from the 5.18.x branch

activemq-client-jakarta

AMQ-9170

[cshannon]

There's some more info here about the status of JMS 2.0: https://activemq.apache.org/jms2

But the more relevant change here to support Spring boot 3 and Spring Framework 6 is the recent PR to pull in the Jakarta module: apache/activemq#969

[cshannon]

As a follow up I realized that any changes in apache/activemq#969 likely won't be good enough for this. The biggest thing is Spring Boot supports running the server and any changes being done right now are just client compatibility. The broker itself still would require the old JMS jar for now so in order to add back in support to Spring boot I think the broker would have to migrate to Jakarta as well.

Also, not all the functionality is being implemented yet (as shown by the status page it's done gradually). So if Spring 6 and Spring boot 3 assume new methods actually work as defined in the Jakarta 3.x messaging API (which would be a reasonable assumption) then there would be issues if some of those methods were called and not properly implemented.

[mattrpav]

How does Spring Boot handle JMS providers that are not 100% Java? Esp broker-side? Seems like there would be an ability to have client-side starter and test-container (or similar) approach for integration testing.

[wilkinsona]

Boot can auto-configure a client that connects to a remote broker implemented in any language. We have that support in 3.0.x with Artemis. If the broker is not on the classpath, we'll only set up the client side of things, configuring it to connect to a remote broker. We could do the same with ActiveMQ if it's only the client that's going to have a Jakarta variant.

[cshannon]

@wilkinsona - Thanks for the info, I think the only way this would work is to just support t it from a client standpoint for now since the broker will take longer before it would use Jakarta.

Since it is a work in progress to actually implement everything in the new API, is it an issue for Spring 6 or Spring Boot 3 if this first version released of the Jakarta client does not implement all the functionality of the new methods at first (ie throws UnsupportedOperationException)?

It's probably not a problem for Spring boot if just using as a client but I'm mostly wondering if the core Spring framework has updated any of their messaging/JMS code in the spring-jms module classes (Connection factories, listener containers, etc) to use any of the newer JMS 2.0/Jakarta 3.x methods that would break if hitting an Unsupported method.

[wilkinsona]

Spring Framework has required JMS 2.0 since 2016. Prior to that it required JMS 1.1 but would use JMS 2.0 APIs when available. However, we aren't aware of any problems with ActiveMQ in Spring Boot 2.x so it would appear that, as long as application code does not make use of JMS 2.0 APIs, Spring Framework will not call them either. That suggests it may be possible to get things working despite various unsupported methods. Whether that's something that we'd want to spend time on and support is a separate question that we'd need to consider as a team.

[cshannon]

Thanks, that makes sense. Well the first version of the Jakarta client will likely go out with version ActiveMQ 5.18.0 and then I guess you can decide if you want to support the client at that point. There's always an option for us to create our own 3rd party Spring boot starter to support the client like Qpid JMS or Camel has I suppose.

[dogilvie]

Given that there is a working spring boot starter for 2.7.x, transitioning that code to boot 3.x hopefully will not be too much of a chore, given appropriate support for jakarta in activemq 5.18.x

Amazon have seen fit to support activemq classic users with a managed solution, so it would seem to be fairly popular.

[graben]

Jakarta JMS compatible version ActiveMQ 5.18.0 released [ANN] Apache ActiveMQ 5.18.0 has been released!