Fred- There isn’t going to be anything more “official” from the open source project. If you require more official certification, then you should look at vendor support options.
The cross broker-client version compatibility has some unit tests and interactive testing was completed. The key piece to realize is that there was not a wire protocol revision change between 5.x and 6.x. The only issue that has been identified (and fixed) was related to exception name mapping for errors that was related to the java.jms to jakarta.jms namespace change. In short— the open source team has been committed to making sure it works, if you find anything report it and we’ll fix it. Thanks, Matt Pavlovich ActiveMQ PMC > On Dec 10, 2024, at 9:35 AM, Fred Welland <fred.well...@gmail.com> wrote: > > Yeah I know -- tested that a few ways (and mentioned that in my post). > > But is it endorsed or recommended (by any authoritative source)? > > I've scrapped around and seen a comment or two that says stuff like -- " > yeah it (new client to older remote broker) may work -- but that really > isn't tested or really 'supported'; so use at own risk" > > > > On Tue, Dec 10, 2024 at 10:26 AM Matt Pavlovich <mattr...@gmail.com> wrote: > >> Hi Fred- >> >> The 6.x client jar can work with to 5.x brokers. >> >> Matt Pavlovich >> >>> On Dec 10, 2024, at 8:56 AM, Fred Welland <fred.well...@gmail.com> >> wrote: >>> >>> Subject summarizes my question: I can not seem to find an RAR artifact >>> that is 'ok' for a remote AMQ broker 5.17x/5.18x but is suitable for >>> Jakarta based application platforms like Wildfly 26x and greater. >>> >>> Does one exist? (Or is there a recipe to provide a workable >> solution?) >>> >>> This GAV: 'org.apache.activemq:activemq-client-jakarta:5.18.6' is OK for >>> Jakarta based clients just pushing messages (using AMQ jakarta client >> APIs >>> more directly). Doesn't help for listeners/mdbs. >>> >>> Constraints: >>> >>> Need to migrate dozens of MDB based on JavaEE & JMS 1.0/1.1 (currently >>> running on Wildfly and older JBOSSes) to newer JakartaEE on Wildfly > 26 >>> (34.x or greater). All use a remote AMQ classic broker. All MBDs >> use >>> JMS 1.0/1.1 level JavaEE API -- Will NOT try to use new Jakarta JMS >> style >>> features & APIs beyond compatibility with older JMS 1/1.1 specs. >>> >>> Moving to Artimis broker is not an option. >>> >>> Moving to AMQ Classic 6.x broker is not an option in the same time frame >> as >>> I need to migrate to newer Wildfly servers. >>> >>> YES: the AMQ 6.1.x RAR in a Wildfly > 26.x does seem to work OK >> against a >>> 5.17.x/5.18.x remote broker -- minimal bench testing only. >>> >>> I feel it is in better form to keep the client side (rar or jar) as >>> close as possible to it's broker and probably 'less desirable' to use >> newer >>> major client side (rar or jar) to connect to an older broker. Correct? >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org >> For additional commands, e-mail: users-h...@activemq.apache.org >> For further information, visit: https://activemq.apache.org/contact >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org For additional commands, e-mail: users-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
