Updating 5.16.x to have one of the suggested fixes, seems to be a straight-forward and simple solution to this issue. While unfortunate, I don’t think we should revert given there have already been a couple of 5.16.x releases since then.
While unfortunate that Art got caught up in the change, IMO this is a pretty narrow use case. -Matt > On Jun 21, 2022, at 9:07 AM, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > > The obvious "why not" answer would be however easy it is, its perhaps > not so obvious to people, and it certainly doesnt seem like it should > be necessary. Those with things which only use JMS 1.1 and previously > worked with <=5.16.2 (its not just 5.15.x upgraders affected) would > not typically expect to be broken by a simple update to using 5.16.3+, > or to necessarily understand they can work around the feature problem > by using the JMS 2 spec when their stuff isnt using that and they are > still clearly using a client implementing 1.1. > > If having both versions provided is possible, fixes simple upgrades > for all the existing JMS 1.1 users on <= 5.16.2, and still allows > those already working with JMS 2 to use it as now, then that would > seem a reasonable middle ground. The spec jar isnt exactly a monstrous > overhead after all, especially not compared to the client feature > already supplying [most of] the broker etc. > > Or, you suggested earlier what would happen currently is it would only > use/supply 2.0 unless something provided 1.1 first. Can it do the > reverse, i.e can it provide 1.1 as it did before but still allow for > using 2 if already supplied, falling back to using its provided 1.1 if > they dont? > > > On Tue, 21 Jun 2022 at 14:01, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: >> >> OK, now I understand the confusion: >> >> Karaf activemq-client feature uses activemq-osgi bundle, not >> activemq-client bundle. The activemq-client bundle is not used at all >> in the Karaf features: we use the activemq-osgi uber bundle. >> >> So, if a user uses activemq-client bundle (without the feature), it >> will have to install geronimo-spec-jms 1.1 bundle:but nothing changed >> there, it's as it was before. >> >> Now, strictly speaking of the activemq-client karaf feature, it's fine >> as it uses activemq-osgi bundle, with the javax.jms,version="[1.1,3)" >> range. >> >> Regarding Art's issue, the problem is that activemq-client karaf >> feature provides JMS 2.0 by default, but Art's bundle still import >> [1.1,2) (not [1.1,3)). >> >> I see three options here: >> 1. Art can fix his bundles header to use the extended range [1.1,3). >> 2. The user who wants to still use JMS 1.1, they can stay with ActiveMQ >> 5.15.x >> 3. The user who wants to still use JMS 1.1, we can add geronimo-spec >> jms 1.1 in activemq-client karaf feature, meaning that we will have >> both JMS 1.1 and 2.0 packages at runtime. >> >> Honestly, why not extending the range, easy to do and it works fine >> (it's what Karaf and Camel are using) ? >> >> Regards >> JB >> >> >> >> >> >> >> On Tue, Jun 21, 2022 at 1:53 PM Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >>> >>> I tested at runtime on activemq-osgi bundle used by activemq-client. >>> >>> The feature verify would not work with this range. >>> >>> Let me take a look but I doubt it's the case. >>> >>> On Tue, Jun 21, 2022 at 11:53 AM Robbie Gemmell >>> <robbie.gemm...@gmail.com> wrote: >>>> >>>> The javax.jms; version="[1.1,2)" value I quoted was directly from the >>>> Import-Package manifest entry of the 5.16.3 and 5.16.5 activemq-client >>>> jars on maven central. On checking 5.17.1 it lists the same. >>>> >>>> On Tue, 21 Jun 2022 at 09:56, Jean-Baptiste Onofré <j...@nanthrax.net> >>>> wrote: >>>>> >>>>> activemq-client 5.16.3 does use the right range: >>>>> >>>>> javax.jms;version="[1.1,3)", >>>>> >>>>> Else it won't work. >>>>> >>>>> And by the way, before the change, I sent a couple of messages on the >>>>> mailing list as a discussion thread. >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> On Tue, Jun 21, 2022 at 10:37 AM Robbie Gemmell >>>>> <robbie.gemm...@gmail.com> wrote: >>>>>> >>>>>> I believe the 5.16.x client doesnt have the below, instead saying: >>>>>> javax.jms; version="[1.1,2)" >>>>>> despite the Feature only supplying the 2.0 version which appears >>>>>> incompatible with this. Maybe thats whats tripping Art's usage up >>>>>> since he was clearly using <= 5.16.2 before? >>>>>> >>>>>> On Tue, 21 Jun 2022 at 09:24, Jean-Baptiste Onofré <j...@nanthrax.net> >>>>>> wrote: >>>>>>> >>>>>>> By the way, you can see in activemq-client: >>>>>>> >>>>>>> javax.jms;version="[1.1,3)", >>>>>>> >>>>>>> So: >>>>>>> 1. if your application uses the same range, it works >>>>>>> 2. if your application use [1.1,2), than, simple add javax.jms >>>>>>> (geronimo) 1.1 bundle >>>>>>> >>>>>>> Regards >>>>>>> JB >>>>>>> >>>>>>> On Mon, Jun 20, 2022 at 7:45 PM Arthur Naseef <a...@amlinv.com> wrote: >>>>>>>> >>>>>>>> I created the following ticket to address applications failing to load >>>>>>>> into >>>>>>>> Karaf with AMQ 5.16.3 - 5.17.1 due to an incompatible change in the >>>>>>>> activemq-client feature. >>>>>>>> >>>>>>>> https://issues.apache.org/jira/browse/AMQ-8971 >>>>>>>> >>>>>>>> >>>>>>>> Looks to me like the right fix here is to revert the change to the JMS >>>>>>>> 1.1 >>>>>>>> spec in the feature because all of the AMQ internals are still 100% on >>>>>>>> the >>>>>>>> JMS 1.1 spec. The maven-bundle-plugin for client applications is >>>>>>>> doing the >>>>>>>> right thing by generating "Package-Import" lines with version range >>>>>>>> "1.1,2.0)", but the feature doesn't match it. >>>>>>>> >>>>>>>> It seems we have sacrificed the core case to solve an edge case. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> Art
