Bump this topic up for visibility as the code freeze is coming soon. This seems like a good change to include in 5.0 as this kind of library upgrade is more natural when the major version changes. It is still possible to postpone it to 6.0, but the main concern here is that the current version of dropwizard metrics library is obsolete and no longer supported and it is better to avoid emergencies that could arise (like the panic with log4j library upgrade some time ago).
The change itself is straightforward and deserves more eyes on it from my point of view. On Fri, 21 Jul 2023 at 14:51, Maxim Muzafarov <mmu...@apache.org> wrote: > > Hello everyone, > > It still needs a pair of eyes to push it forward. > > > I came across another good thing that might help us to overcome the > difficulties with the dropwizard metrics dependency upgrade. The > change relates to the driver itself and reuses the same approach that > was used to deal with the driver's netty dependencies. We need to > shade the dropwizard metrics classes and no longer rely on the > cassandra classpath at least for the 3.x version of the java driver, > and make the next 3.11.4 release of the java driver accordingly. > > The changes for the driver are here: > https://github.com/datastax/java-driver/pull/1685 > > This will give us (and users as well) the confidence to move forward > with this change to 5.x alongside the 3.11 version of the driver > usage. Looking forward to your thoughts. > > Changes for the Cassandra part are here: > https://github.com/apache/cassandra/pull/2238/files > > On Mon, 3 Jul 2023 at 15:15, Maxim Muzafarov <mmu...@apache.org> wrote: > > > > I'd like to mention the approach we took here: to untangle the driver > > update in tests with the dropwizard library version (cassandra-driver > > 3.11 requires the "old" JMXReporter classes in the classpath) we have > > copied the classes into the tests themselves, as it is allowed by the > > Apache License 2.0. This way we can update the metrics library itself > > and then update the driver used in the tests afterwards. > > > > If there are no objections, we need another committer to take a look > > at these changes: > > https://issues.apache.org/jira/browse/CASSANDRA-14667 > > https://github.com/apache/cassandra/pull/2238/files > > > > Thanks in advance for your help! > > > > On Wed, 28 Jun 2023 at 16:04, Bowen Song via dev > > <dev@cassandra.apache.org> wrote: > > > > > > IMHO, anyone upgrading software between major versions should expect to > > > see breaking changes. Introducing breaking or major changes is the whole > > > point of bumping major version numbers. > > > > > > Since the library upgrade need to happen sooner or later, I don't see > > > any reason why it should not happen in the 5.0 release. > > > > > > > > > On 27/06/2023 19:21, 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
