OK, I would be fine with that. Let's wait a week to give some space for people to jump in if they have some objections.
On Mon, Jan 19, 2026 at 8:22 PM Michael Morris <[email protected]> wrote: > > Yes, that is correct > > On 19/01/2026 17:58, Štefan Miklošovič wrote: > > 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 > >>>> >
