I approved 5.0 PR, we are going to track all of that here (1) Now, your job is to find the second reviewer (as you are not a committer, we need to have 2 committers at least to pass anything).
Feel free to find such a person. The list of committers you can choose from is here (2). Happy hunting! Regards Stefan (1) https://issues.apache.org/jira/browse/CASSANDRA-21137 (2) https://projects.apache.org/committee.html?cassandra On Tue, Jan 20, 2026 at 11:48 AM Štefan Miklošovič <[email protected]> wrote: > > 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 > > >>>> > >
