+users Hi Adel
I'll be putting something more formal together closer to the release, but for now a dump of my brain: For applications using AMQP 0-8..0-10 clients, I would expect no changes. For applications using AMQP 1.0 and making use of the Qpid JMS Client [1] the following would apply: 1) For application using JMS topic subscriptions, the queues backing topic subscriptions and now named differently. Messages would need to be moved manually from the old subscription queues to the new ones to avoid message loss across the upgrade. 2) Qpid JMS Client 0.24 is required for SCRAM-SHA based SASL authentication to function. For the REST API, there are a couple of potentially breaking changes: 1) The biggest change is the modelling of Bindings (the link between Exchange to Queues). If you use the REST API to programatically query or create bindings, the code will need to be changed. 2) The REST API used to return a JSON list in response to a single object GET request e.g. /api/version/queue/vhn/vh/myqueue. It now returns a single JSON object, as one might expect. It is possible to get back the old behaviour if desired with a flag. I'm sure my colleagues will jump in if I have missed anything major. [1] https://qpid.apache.org/components/jms/index.html On 27 September 2017 at 10:26, Keith W <[email protected]> wrote: > Hi Adel > > I'll be putting something more formal together closer to the release, > but for now a dump of my brain: > > For applications using AMQP 0-8..0-10 clients, I would expect no > changes. For applications using AMQP 1.0 and making use of the Qpid > JMS Client [1] the following would apply: > > 1) For application using JMS topic subscriptions, the queues backing > topic subscriptions and now named differently. Messages would need to > be moved manually from the old subscription queues to the new ones to > avoid message loss across the upgrade. > 2) Qpid JMS Client 0.24 is required for SCRAM-SHA based SASL > authentication to function. > > For the REST API, there are a couple of potentially breaking changes: > > 1) The biggest change is the modelling of Bindings (the link between > Exchange to Queues). If you use the REST API to programatically query > or create bindings, the code will need to be changed. > 2) The REST API used to return a JSON list in response to a single > object GET request e.g. /api/version/queue/vhn/vh/myqueue. It now > returns a single JSON object, as one might expect. It is possible to > get back the old behaviour if desired with a flag. > > I'm sure my colleagues will jump in if I have missed anything major. > > > [1] https://qpid.apache.org/components/jms/index.html > > > > On 27 September 2017 at 09:05, Adel Boutros <[email protected]> wrote: >> Hello Keith, >> >> >> Normally, with a major release, I could expect some broken APIs when >> developing code for an older version of the Qpid Broker such as REST API for >> communicating with the broker or any configuration related disruptive >> changes. >> >> >> Does the 7.0 version include any disruptive change? Or if I just bump the >> version of my broker to 7.0 (from 6.0), it will work out of the box? >> >> >> Regards, >> >> Adel >> >> ________________________________ >> From: Keith W <[email protected]> >> Sent: Wednesday, September 27, 2017 9:38:15 AM >> To: [email protected] >> Subject: Plans for Qpid Broker J v7.0 >> >> Hi all, >> >> Qpid Broker J (the Java Broker) is stabilising ready for the next >> release. The major user facing changes in this release will be: much >> improved AMQP 1.0 support, support for JMS 2.0 clients implementing >> the AMQP 1.0 JMS bind mapping, and much improved message conversion to >> benefit users with applications using AMQP 1.0 and the older AMQP >> protocols. We hope to be putting out an RC in a few weeks time. >> >> This anyone has any additional needs, please discuss here. >> >> cheers, Keith. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
