Reasons 1 and 2 (getting into CVE coverage pipeline proactively rather than reactively, JDK consistency) seem compelling enough to justify the upgrade on their own to me.
> This is a problem for applications/tools that rely on the cassandra > classpath (lib/jars) as after the upgrade they may be looking for the > JmxReporter class which has changed its location. Yep; this is going to be painful: https://github.com/dropwizard/metrics/issues/1581 https://github.com/dropwizard/metrics/issues/1306 https://github.com/micrometer-metrics/micrometer/issues/587 https://github.com/doanduyhai/Achilles/issues/353 https://github.com/dropwizard/dropwizard/issues/2285 > in this case, > we can upgrade the cassandra driver up to 4.x [5][6] to fix the > problem, as the new driver uses a newer version of the library, but > that's another story I won't go into for now It seems like driver upgrades would be the cleanest way through this (and that's saying something...). With the driver donation in CEP-8 that'd help our ability to synchronize these updates, but there's still going to be plenty of noise and pain from this change. Doesn't mean it's not worth doing though. On Tue, Jun 27, 2023, at 2:21 PM, Maxim Muzafarov wrote: > Hello everyone, > > > We use the Dropwizard Metrics 3.1.5 library, which provides a basic > set of classes to easily expose Cassandra internals to a user through > various interfaces (the most common being JMX). We want to upgrade > this library version in the next major release 5.0 up to the latest > stable 4.2.19 for the following reasons: > - the 3.x (and 4.0.x) Dropwizard Metrics library is no longer > supported, which means that if we face a critical CVE, we'll still > need to upgrade, so it's better to do it sooner and more calmly; > - as of 4.2.5 the library supports jdk11, jdk17, so we will be in-sync > [1] as well as having some of the compatibility fixes mentioned in the > related JIRA [2]; > - there have been a few user-related requests [3][4] whose > applications collide with the old version of the library, we want to > help them; > > > The problem > > The problem with simply upgrading is that the JmxReporter class of the > library has moved from the com.codahale.metrics package in the 3.x > release to the com.codahale.metrics.jmx package in the 4.x release. > This is a problem for applications/tools that rely on the cassandra > classpath (lib/jars) as after the upgrade they may be looking for the > JmxReporter class which has changed its location. > > A good example of the problem that we (or a user) may face after the > upgrade is our tests and the cassandra-driver-core 3.1.1, which uses > the old 3.x version of the library in tests. Of course, in this case, > we can upgrade the cassandra driver up to 4.x [5][6] to fix the > problem, as the new driver uses a newer version of the library, but > that's another story I won't go into for now. I'm talking more about > visualising the problem a user might face after upgrading to 5.0 if > he/she rely on the cassandra classpath, but on the other hand, they > might not face this problem at all because, as I understand, they will > provide this library in their applications by themselves. > > > So, since Cassandra has a huge ecosystem and a variety of tools that I > can't even imagine, the main question here is: > > Can we move forward with this change without breaking backwards > compatibility with any kind of tools that we have considering the > example above as the main case? Do you have any thoughts on this? > > The changes are here: > https://github.com/apache/cassandra/pull/2238/files > > > > [1] > https://github.com/dropwizard/metrics/pull/2180/files#diff-5dbf1a803ecc13ff945a08ed3eb09149a83615e83f15320550af8e3a91976446R14 > [2] https://issues.apache.org/jira/browse/CASSANDRA-14667 > [3] https://github.com/dropwizard/metrics/issues/1581#issuecomment-628430870 > [4] https://issues.apache.org/jira/browse/STORM-3204 > [5] https://issues.apache.org/jira/browse/CASSANDRA-15750 > [6] https://issues.apache.org/jira/browse/CASSANDRA-17231 >
