Hi Endre, It should work with 6.0.0 (as we have both javax and jakarta namespace and JMS API is backward compatible). But it's mostly a transition purpose. So, maybe I wasn't clear: it should work, but I would recommend to upgrade to clients too at some point :)
Regards JB On Mon, Mar 18, 2024 at 12:59 PM Endre Stølsvik <[email protected]> wrote: > > I was kinda hoping that there was some solution here, because otherwise it > will be a rather big bang to get over to 6. > > I was hoping that I could upgrade the broker to 6, and then roll out > upgrades to the heap of services (the client side) over the next few months. > > I can envision that this won't be an uncommon situation: A big part of the > idea with a MQ broker is that you have one of them, and then multiple > clients connecting to it. Requiring all of the clients to go from 5 to 6 at > the same time is close to an insurmountable task, and very much not what > one want for such a microservice architecture, where at least we try to do > everything in a fashion where each of the sub-projects (the microservices) > can handle their upgrade when it best suits them. > > Since this is a wire protocol that is close to totally disjunct from the > APIs used on each side, such a "guarantee" (for a period) should not be > impossible to make? > > Maybe make a final 5.x release/client that incorporates the necessary > changes for 6.x, and then keep it in mind when changing the wire protocol > on the v.6 server side? For a while? > > Thanks a bunch, > Endre. > > > > On Mon, Mar 18, 2024 at 6:26 AM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi, > > > > If you are still using ActiveMQ 5.x clients, I recommend staying with > > an ActiveMQ 5.x broker. > > > > Regards > > JB > > > > On Sun, Mar 17, 2024 at 11:58 AM Endre Stølsvik <[email protected]> > > wrote: > > > > > > Hi! > > > Thanks for the release! > > > > > > I have a question wrt. upgrading a 50+ microservice solution: How is the > > > compatibility between old JMS clients (5.x) towards the 6+ server > > versions? > > > > > > I guess the wire protocol doesn't care one bit wrt. javax./jakarta? But > > do > > > the ActiveMQ team have any suggestion wrt. such an upgrade situation? Are > > > there any "guarantees" wrt. the future compatibility between client > > > versions and server versions? > > > > > > I ask since any such compatibility guarantee would put my mind a bit more > > > at ease wrt. doing the upgrade in a rolling fashion. We do obviously > > have a > > > test env, but knowing whether there is any intention, or not, wrt. > > > compatibility, would be of value. > > > > > > The problem is of course that the jakarta-situation is a bit .. large. > > Both > > > the JMS libs, the Servlet libs, and Spring, pretty much have to be done > > "in > > > one go". So knowing what works with what is of value in setting up a > > > transition path. > > > > > > Thanks, > > > Endre > > > > > > > > > > > > On Sun, Mar 17, 2024 at 11:38 AM Jean-Baptiste Onofré <[email protected]> > > > wrote: > > > > > > > The ActiveMQ team is pleased to announce Apache ActiveMQ 6.1.0 release. > > > > > > > > It's a new milestone, bringing: > > > > - New JMS 2/3 operations support > > > > - Mapping javax / jakarta exception in openwire protocol > > > > - Add destination field on the job scheduler > > > > - Add org.apache.activemq.broker.BouncyCastleNotAdded property to > > > > control the bouncycastle addition in BrokerService classloader > > > > - A lot of dependency upgrades (Spring 6.1.4, log4j 2.23.0, Jetty > > 11.0.20, > > > > …) > > > > - ... and much more ! > > > > > > > > You can find details on the Release Notes: > > > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12353745 > > > > > > > > You can download ActiveMQ 6.1.0 here: > > > > https://activemq.apache.org/components/classic/download/ > > > > > > > > Enjoy! > > > > > > > > Regards > > > > -- > > > > The Apache ActiveMQ team > > > > > >
