fix: use class-based logger name in BaseConfigurationService. by Dennis-Mircea · Pull Request #3352 · operator-framework/java-operator-sdk
Summary
BaseConfigurationService is the only class in operator-framework-core / operator-framework main sources that creates its SLF4J logger from a hard-coded string rather than from getClass() / Class.class:
private static final String LOGGER_NAME = "Default ConfigurationService implementation"; private static final Logger logger = LoggerFactory.getLogger(LOGGER_NAME);
That produces log lines like:
2026-05-11 14:52:16,844 Default ConfigurationService implementation [INFO ] Created configuration for reconciler org.apache.flink.kubernetes.operator.controller.FlinkDeploymentController with name flinkdeploymentcontroller
…which looks like a status message rather than a logger name when consumed by downstream operators (observed via Apache Flink Kubernetes Operator) and breaks the common %logger / %c pattern most logback / log4j configurations rely on for filtering and routing.
The literal string has been in place since 2021 (introduced in 10998f18 "feat: log when a configuration is not found or created automatically") and has been the only such case for the entire time, so this looks like a stray inconsistency rather than an intentional choice.
This PR aligns BaseConfigurationService with the rest of the codebase by deriving the logger name from the class:
private static final Logger logger = LoggerFactory.getLogger(BaseConfigurationService.class);
The public getLoggerName() method is preserved and now returns logger.getName(), so the API still works and stays consistent with whatever the logger is actually configured with.
Behavior change to be aware of
This does change the logger name as it appears in log output and in the value returned by BaseConfigurationService#getLoggerName():
- Before:
Default ConfigurationService implementation - After:
io.javaoperatorsdk.operator.api.config.BaseConfigurationService
If any consumer has logback / log4j filters, appenders, or log-routing rules keyed on the old literal string, those configurations will need to be updated to the FQCN (or a prefix match against io.javaoperatorsdk.operator.api.config). Worth a brief mention in the release notes.
Test plan
./mvnw -pl operator-framework-core -am compile- succeeds, no new warnings../mvnw -pl operator-framework-core -am test -Dtest=ConfigurationServiceOverriderTest- passes (2/2).- Spotless / license check pass for the touched module.