[CASSANDRA-17527] Clients using JMX are unable to handle non-standard java types but we leak this into our interfaces

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 4.1-alpha1, 4.1
• Component/s: Observability/JMX
• Bug Category: Correctness - API / Semantic Definition
• Severity: Normal
• Complexity: Low Hanging Fruit
• Discovered By: Workload Replay
• Platform: All
• Since Version: 3.0.0

Source Control Link

https://github.com/apache/cassandra/commit/cf0a231a1d44aa572a299ca18352c7b6a6f2171c

Test and Documentation Plan

new unit test to detect this and trigger failure

• Assignee: David Capwell
• Reporter: David Capwell

Authors

David Capwell

Reviewers

Alex Petrov, Andres de la Peña

• Created: 05/Apr/22 21:33
• Updated: 01/Nov/22 20:09
• Resolved: 08/Apr/22 20:23

Description

JMX clients only work if-and-only-if they have the same types defined by the interface, so non-standard java (or javax) types should never be used; we currently rely on humans to block this in review, which has lead to a few interfaces exposing Cassandra types

Issue Links

• causes: CASSANDRA-18002 Update NetBeans project file for dependency changes since 7th July 2021
• is related to: CASSANDRA-17638 Clients using JMX are unable to handle non-standard java types but we leak this into our Exceptions
• is related to: CASSANDRA-17580 Clients using JMX are unable to handle non-standard java types but we leak this into our Exceptions
• links to: CI: trunk
• links to: PR: trunk