+1 from me > If classloaders are appropriately named in the current versions of Cassandra, > we should be able to test upgrade paths to that version without updating the > older branches or building new jvm-dtest JARs for them. Pretty sure Caleb was wrestling w/something recently that might have benefited from being able to differentiate which ClassLoader was sad; in general this seems like it'd be a big help to debugging startup / env issues, assuming it doesn't break anything. :)
On Fri, Mar 15, 2024, at 4:41 PM, Abe Ratnofsky wrote: > Hey folks, > > I'm working on gathering coverage data across all of our test suites. The > jvm-dtest-upgrade suite is currently unfriendly to Jacoco: it uses classes > from multiple versions of Cassandra but with the same class names, so > Jacoco's analysis fails due to "Can't add different class with same name"[1]. > We need a way to exclude alternate-version classes from Jacoco's analysis, so > we can get coverage for the current version of Cassandra. > > Jacoco supports exclusion of classes based on class name or classloader name, > but the class names are frequently usually identical across Cassandra > versions. The jvm-dtest framework doesn't name classloaders, so we can't use > that either. > > I'd like to propose that we name the jvm-dtest InstanceClassLoader instances > so that some can be excluded from Jacoco's analysis. Instances that create > new InstanceClassLoaders should be able to provide an immutable name in the > constructor. InstanceClassLoader names should indicate whether they're for > the current version of Cassandra (where coverage should be collected) or an > alternate version. If classloaders are appropriately named in the current > versions of Cassandra, we should be able to test upgrade paths to that > version without updating the older branches or building new jvm-dtest JARs > for them. > > Any objections or alternate approaches? > > -- > Abe > > [1]: More specifically: Jacoco uses class IDs to map the analysis data that's > produced during text execution to .class files. I'm configuring the Jacoco > agent's classdumpdir to ensure that the classes loaded during execution are > the same classes that are analyzed during report generation, as is > recommended. When we build the alternate version JARs for jvm-dtest-upgrade, > we end up with multiple classes with the same name but different IDs.
