CASSANDRA-21525 trunk - Verify extension type before initializing reflectively-loaded classes

[smiklosovic]

Cassandra resolves pluggable extensions by class name from configuration, schema, and tooling inputs. These names were loaded with an initializing Class.forName(name) and type-checked only afterward, so the named class ran its static initializer before its type was confirmed. After this change such classes will be loaded without initialization, verified against the expected interface or base class, and initialized only through normal use after validation.

A shared FBUtilities.classForNameWithoutInitialization helper and typed instanceOrConstruct/construct overloads apply this to the configurable extension points loaded by class name: the guardrail value generator and validator, disk-error handler, Accord agent, TCM extension values, the authentication backends and mutual-TLS validators, seed provider, snitch and its location providers, abstract types, secondary and custom indexes, compaction strategy, compressor, replication strategy (including its metadata serializers), SASI analyzers, key and cache providers, query handler, storage and stream hooks, tracing, the JMX authorization proxy, MBeans, clocks, nodetool Sjk, triggers, the memtable factory contract, the guardrails config provider, the auto-repair token-range splitter, crypto provider, SSL context factory, the sstableloader and stress class options, and diagnostic event classes. ParameterizedClass.newInstance also takes an expected type and loads without initialization.

Regression tests confirm that an invalid-type load is rejected without initializing the target class, and that valid implementations still resolve.

Hard-coded JDK and internal class probes are left unchanged.

patch by Jeremiah Jordan; reviewed by for CASSANDRA-21525

Thanks for sending a pull request! Here are some tips if you're new here:

• Ensure you have added or run the appropriate tests for your PR.
• Be sure to keep the PR description updated to reflect all changes.
• Write your PR title to summarize what this PR proposes.
• If possible, provide a concise example to reproduce the issue for a faster review.
• Read our contributor guidelines
• If you're making a documentation change, see our guide to documentation contribution

Commit messages should follow the following format:

<One sentence description, usually Jira title or CHANGES.txt summary>

<Optional lengthier description (context on patch)>

patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-#####

Co-authored-by: Name1 <email1>
Co-authored-by: Name2 <email2>

The Cassandra Jira

[smiklosovic]

There are changes missing in CompressorRegistry class (introduced recently with CEP-49), please align CompressorRegistry.resolveProvider.

[smiklosovic]

two casts?

(Class<? extends AbstractType<?>>)(Class<?>)?