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
