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
Comment From: 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: https://github.com/apache/activemq/pull/969
Comment From: cshannon
As a follow up I realized that any changes in https://github.com/apache/activemq/pull/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.
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: graben
Jakarta JMS compatible version ActiveMQ 5.18.0 released [ANN] Apache ActiveMQ 5.18.0 has been released!
Comment From: bendiscz
Today I tried to reintroduce ActiveMQ in Spring Boot 3.0, mainly by reverting most of 63492507b437d1d5a14bbbb4056b27d4166120ce, changing ActiveMQ version to 5.18.0 and replacing activemq-client with activemq-client-jakarta.
Unfortunately, the activemq-broker module still uses javax.jms.* classes internally, so the ActiveMQ smoke test fails with java.lang.NoClassDefFoundError: javax/jms/JMSException.
This could be solved by removing activemq-broker from dependencies and keeping only activemq-client-jakarta, but the option to run embedded in-memory ActiveMQ Broker would be lost. I will try it tomorrow.
Comment From: cshannon
Today I tried to reintroduce ActiveMQ in Spring Boot 3.0, mainly by reverting most of 6349250, changing ActiveMQ version to 5.18.0 and replacing
activemq-clientwithactivemq-client-jakarta.Unfortunately, the
activemq-brokermodule still usesjavax.jms.*classes internally, so the ActiveMQ smoke test fails withjava.lang.NoClassDefFoundError: javax/jms/JMSException.This could be solved by removing
activemq-brokerfrom dependencies and keeping onlyactivemq-client-jakarta, but the option to run embedded in-memory ActiveMQ Broker would be lost. I will try it tomorrow.
Yes that is correct, 5.18.0 only includes a client for Jakarta so you can't run an embedded broker. There is discussion to switch to Jakarta in a future version for the broker and rest of the code base as well, maybe 5.19.0 or 5.20.0 which would allow running an embedded broker again.
Comment From: bendiscz
The activemq-client-jakarta JAR is missing META-INF/services/* entries for any transport factories supported by the client (tcp:// and so on). I guess this needs to be fixed directly in ActiveMQ...
...
Caused by: java.io.IOException: Transport scheme NOT recognized: [tcp]
...
Caused by: java.io.IOException: Could not find factory class for resource: META-INF/services/org/apache/activemq/transport/tcp
...
Comment From: cshannon
Thanks for pointing that out, it looks like we will need to get 5.18.1 out soon to fix that as that appears to have been missed.
Comment From: mattrpav
ActiveMQ PR created #995
I'll perform some additional tests tomorrow
@bendiscz is there a specific test that failed that I could use as a basis to retest?
Comment From: bendiscz
Thank you, @mattrpav! You can checkout this branch and run ./gradlew :spring-boot-tests:spring-boot-smoke-tests:spring-boot-smoke-test-activemq:test. It should fail with the IO exceptions mentioned above.
Comment From: hzxie
Similar issue for the transport scheme [vm]
Caused by: org.springframework.context.ApplicationContextException: Failed to start bean 'org.springframework.jms.listener.SimpleMessageListenerContainer#0'
Caused by: org.springframework.jms.UncategorizedJmsException: Uncategorized exception occurred during JMS processing
Caused by: jakarta.jms.JMSException: Could not create Transport. Reason: java.io.IOException: Transport scheme NOT recognized: [vm]
Caused by: java.io.IOException: Transport scheme NOT recognized: [vm]
Caused by: java.io.IOException: Could not find factory class for resource: META-INF/services/org/apache/activemq/transport/vm
I follow the instructions here to keep the class name of the connection factory unchanged
<bean id="amqConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
<constructor-arg index="0" value="${jms.broker.url}" />
</bean>
Comment From: bendiscz
Similar issue for the transport scheme [vm]
Yes, but this is expected if you remove the activemq-broker module from classpath, because the vm transport is provided by it. The client libraries activemq-client(-jakarta) does not implement the vm transport.
Comment From: hzxie
@bendiscz I need it due to the unit tests. So I need to wait for the fix for activemq-broker in 5.18.1, right?
Comment From: bendiscz
I don't think 5.18.1 will reintroduce the vm transport, unfortunately... As @cshannon mentioned:
There is discussion to switch to Jakarta in a future version for the broker and rest of the code base as well, maybe 5.19.0 or 5.20.0 which would allow running an embedded broker again.
The activemq-broker will probably switch to Spring Boot 3.0 compatible JMS API in some later version (5.19+).
Comment From: hzxie
How about Spring MVC? I'm not using Spring Boot😭
Comment From: cshannon
As I said, an embedded broker is not going to work so no VM transport. The core broker dependency still uses javax.jms so until that gets updated the Jakarta client will only work in a different JVM. As stated already, in a future version will make the switch but this was a first attempt to at least get a client working. We will update the transition documentation page to make this more clear.
Comment From: dogilvie
@cshannon is there a timeline for 5.18.1 with the fix for missing META-INF/services/* entries ?
My reading of the above suggests that boot 3 could support all activemq clients using 5.18.1, but would be unable to host a broker.
Currently our own migration to boot 3 is paused because we have heavy dependency on ActiveMQ classic. So we would be very appreciative of this support being returned to boot.
Comment From: cshannon
5.18.1 should be going out soon, the fix has been merged. We just need to cut a release and vote.
For broker support (embedded broker, etc) it is looking like that will be re-introduced in 5.19.0 but the exact details are being ironed out still. There's a thread on this at https://lists.apache.org/thread/svq34o0n016wnn22fm1yk1k7kqnwvprk
Comment From: JamesPeters98
@cshannon @bendiscz so now that 5.18.1 is available is it possible to reimplement support for just the activemq client in Spring Boot?
Comment From: cshannon
@cshannon @bendiscz so now that 5.18.1 is available is it possible to reimplement support for just the activemq client in Spring Boot?
Yep you should be able to use that version just as a client now because it is based on Jakarta. As stated before, embedded broker support is being worked on for 5.19.x.
Comment From: bendiscz
@JamesPeters98, the pull request above should do it. Unfortunately, I had to remove spring-boot-smoke-test-activemq, because I don't know how to fix the test without the embedded in-memory broker. However, the test passes successfully when run against a locally running ActiveMQ instance.
Comment From: snicoll
Closing in favor of PR #35048. We're trying to get that in in time for Spring Boot 3.1.0-RC1 this week.
Comment From: mattrpav
@snicoll ActiveMQ 6.0.0 is released and artifacts are now available via Maven Central. This provides support for Jakarta on the broker side.