To repeat what I am getting from you here to be sure I get it right: JMXConfiguratorMBean used in LogbackLoggingSupport#setLoggingLevel was introduced only for reloading the configuration.
In order to call that MBean, we need to instruct Logback to expose such MBean for us to call in the first place. That is achieved by introduction of <jmxConfigurator /> into logback.xml (as, presumably, with introducing it, that mean would not be exposed hence not possible to call). In trunk's code, there is another way to reload, and this code (in trunk) can be also used in a lower branch - achieving the same goal, which renders the exposure of MBean redundant. Since we have never committed ourselves into exposing all management methods JMXConfiguratorMBean has to users, the fact that there are other methods on that MBean a user can technically call is just a consequence of that exposure rather than something we would do intentionally. Hence, if we remove <jmxConfigurator /> for logback.xml and somebody complains about MBean methods disappearing, they should never actually use it in the first place and they should go via nodetool command and interact with it instead. (1) https://github.com/apache/cassandra/blob/cassandra-5.0/src/java/org/apache/cassandra/utils/logging/LogbackLoggingSupport.java#L111 On Mon, Jan 19, 2026 at 5:56 PM Michael Morris <[email protected]> wrote: > > Thanks Štefan for your feedback. Some comments for your consideration: > > I believe I have found the reason the element was added in the first > place - see this issue to support getting/setting of the logging levels > through nodetool: > https://issues.apache.org/jira/browse/CASSANDRA-7090 > Specifically, it seems to have been introduced to support using > JMXConfiguratorMBean in LogbackLoggingSupport setLoggingLevel() for > resetting log levels through nodetool. This code is refactored as part > of the PR to maintain the same functionality but with using > JMXConfiguratorMBean, so it would appear the reason for introducing it > is no longer relevant with the refactoring. > > It will still be possible to get/set logging levels through JMX using > the StorageService MBean (though the JMXConfigurator did have additional > operations for reloading from a file/URL). > > This method of getting/setting log levels does not seem to be documented > in the cassandra documentation which only seems to mention editing the > logback.xml directly or using nodetool > > We do indeed use the CVE suppression information and the analysis of the > community is very valuable to us, however, we are subject to our > customers scanning procedures. I believe there is value in removing even > unexploitable CVEs if possible, as unexploitable CVEs are a constant > source of noise that diverts attention away from actual issues. > > > On 16/01/2026 12:28, Štefan Miklošovič wrote: > > Has anybody ever configured logback via JMX? Is this genuinely used by > > somebody frequently enough that this has to be enabled by default? Was > > that introduced as "nice to have" or what was the reasoning behind it? > > > > Because we are striving to have as much smooth experience as possible > > hopping from one minor release to another, that tells me to not remove > > this, especially when, as you said, it does not represent something > > which is exploitable. > > > > Apache Cassandra has its own CVE / vulnerabilities check, under "ant > > dependency-check" target where non-exploitable CVEs are suppressed. It > > is disappointing to see that users are deploying their own custom > > solutions for security scanning of dependencies and they do not count > > on the Cassandra community to evaluate the impact of each CVE which > > they suppressed if not applicable. > > > > On Fri, Jan 16, 2026 at 10:38 AM Michael Morris <[email protected]> > > wrote: > >> I created a PR a while ago to hopefully drop back CASSANDRA-20429 to > >> cassandra-5.0, see https://github.com/apache/cassandra/pull/4432. > >> There was an initial discussion in this thread: > >> https://lists.apache.org/thread/757n89p9j3mfqdmlohm6gxtx1zjtjqbz. > >> Id like to raise this again to see if we can progress. > >> > >> To summarize the concern Štefan raised in the above thread: > >> Logback 1.2 included a feature whereby if you include <jmxConfigurator/> > >> in the logback.xml file, you could make changes to the logback > >> configuration through JMX. This feature was removed in logback 1.3/1.4 > >> due to security issues and lack of use and a warning message will now be > >> generated if that element is included in the logback.xml. > >> The default cassandra logback.xml file contains this element. The PR > >> removes the element from the default logback.xml as part of the changes > >> to upgrade to logback 1.5 as it is no longer useful and would result in > >> warning messages being generated. However, if someone was to use a > >> logback.xml from an older cassandra version, then they will get warning > >> messages in the logs on cassandra start up. If this scenario arises the > >> user can remove <jmxConfigurator/> from their logback.xml and the > >> warning messages will no longer be generated. > >> > >> It would be great to get agreement if people are happy to proceed with > >> this dropback > >> >
