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
