Thanks actually! That may just be good enough.
Was trending that way (6.x client to 5.18broker) anyway. Just trying to see if there is anything I missed. Good to know the wire protocol didn't change between 5x and 6x.. BTW -- I assume you mean OpenWire -- which is all I use OpenWire/TLS. On Tue, Dec 10, 2024 at 10:53 AM Matt Pavlovich <mattr...@gmail.com> wrote: > 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 > > >
