There are 2 places that expose non-standard java classes, so JMX only works if and only if the JMX client also has Cassandra's jars, else they will fail; the 2 examples are
org.apache.cassandra.service.StorageServiceMBean#enableAuditLog throws org.apache.cassandra.exceptions.ConfigurationException, removing that exception does not break binary compatibility, but does break source as javac will say catching it isn't allowed as it doesn't throw. If you call the method without Cassandra jars the method will work properly until a ConfigurationException is thrown, in which case a ClassNotFoundException will be thrown, hiding the error message. org.apache.cassandra.db.ColumnFamilyStoreMBean#forceCompactionForTokenRange takes a collection of org.apache.cassandra.dht.Range<org.apache.cassandra.dht.Token>, since this is an operation the only people who could call it are those with the jars in the path. Given that both are not properties and require setting values, jmx get object does not break, so the impact is limited to the callers of each method. We have a few options to address: 1) live with it. Allow these cases to keep doing what they are doing, but block new cases from popping up 2) live with it, but expose new versions which do not break JMX 3) remove ConfigurationException from StorageServiceMBean#enableAuditLog and accept the source compatibility issue 4) remove or fix ColumnFamilyStoreMBean#forceCompactionForTokenRange 5) #3 and #4 What do others think? In CASSANDRA-17527 I am adding a test to detect these cases and block them, I am also fixing the JMX issues on trunk that were not released, so this thread is only limited to the cases that were actually released Thanks!
