An empty map of logger names and their logging levels was…

Error message

An empty map of logger names and their logging levels was returned, because you are using an unsupported slf4j logging implementation for which this functionality was not implemented.

What it means

NoOpFallbackLoggingSupport.getLoggingLevels logs this warning and returns Collections.emptyMap() because, without logback, there is no way to enumerate logger levels. Callers of nodetool getlogginglevels or the JMX getLoggingLevels operation receive an empty map in unsupported deployments.

Solutions

Restore logback as the slf4j backend so getLoggingLevels returns the real logger/level map.
Parse the startup 'unsupported deployment' warning to identify and remove the competing slf4j binding.
As a workaround, read conf/logback.xml directly for the configured levels.
Update automation to detect the empty map and treat it as 'levels unavailable' rather than 'all defaults'.

Example fix

// before: Map<String,String> levels = ssProxy.getLoggingLevels(); (always empty) // after: if (levels.isEmpty()) { logger.warn("NoOp logging support active; inspect conf/logback.xml manually"); }

Defensive patterns

Strategy: fallback

Validate before calling

Map<String,String> levels = ssProxy.getLoggingLevels(); if (levels.isEmpty()) { // NoOp logging support active - read config file instead levels = parseLogbackXmlLevels("conf/logback.xml"); }

Prevention

Treat an empty getlogginglevels result as 'unsupported logging backend', not 'no loggers'.
Ensure logback is the slf4j provider so introspection works.
Parse logback.xml directly in monitoring scripts as a fallback.
Check startup logs for the unsupported-deployment warning when levels look empty.

When it happens

Trigger: Invoking nodetool getlogginglevels (or StorageService/JMX getLoggingLevels) while slf4j is bound to a non-logback provider, so the NoOp fallback implementation runs.

Common situations: Monitoring scripts parsing getlogginglevels output that get an empty map and misreport log configuration; diagnosing logging on a node built without logback.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/832bd861e4d5ddc1. Report an issue: GitHub.

Appendix: source

Thrown at src/java/org/apache/cassandra/utils/logging/NoOpFallbackLoggingSupport.java:45

/**
 * A fallback implementation with empty implementations which ensures other slf4j bindings (logging implementations)
 * than the default supported framework can be used. This loses functionality, but is perfectly fine for most
 * integration test requirements of applications using an embedded cassandra server.
 */
public class NoOpFallbackLoggingSupport implements LoggingSupport
{
    private static final Logger logger = LoggerFactory.getLogger(NoOpFallbackLoggingSupport.class);

    @Override
    public void setLoggingLevel(String classQualifier, String rawLevel) throws Exception
    {
        logger.warn("The log level was not changed, because you are using an unsupported slf4j logging implementation for which this functionality was not implemented.");
    }

    @Override
    public Map<String, String> getLoggingLevels()
    {
        logger.warn("An empty map of logger names and their logging levels was returned, because you are using an unsupported slf4j logging implementation for which this functionality was not implemented.");
        return Collections.emptyMap();
    }
}

View on GitHub (pinned to 88fd0f6a0e)