Migrate logging API from SLF4J to Log4j 2.x#459
Merged
Conversation
Standardize all modules on the Log4j 2.x API so Flume's own logging no longer goes through the SLF4J facade. Applied the OpenRewrite Slf4jToLog4j recipe, then normalized the result: drop loggers that were never used, make every logger field private static final named "logger", and use the no-arg LogManager.getLogger() since each one named its own class. Assisted-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
rgoers
approved these changes
Jun 17, 2026
Dependencies frequently ship a logging backend or an API bridge as a compile dependency, which then leaks to our consumers. Add a maven-enforcer rule that bans every known logging implementation/bridge and whitelists only the real logging APIs. To satisfy the rule, drop the now-unneeded log4j-1.2-api (no Flume code path reaches the Hadoop classes that use the org.apache.log4j API) and exclude the logging backends that Hadoop (reload4j) and ZooKeeper (logback) pull in. Exclusions live in dependencyManagement so they apply wherever the dependency is used, and only where the artifact is actually pulled; the enforcer rule catches anything reintroduced later. Assisted-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The ban-logging rule whitelisted the whole log4j2 group, which let the SLF4J 1.x binding (log4j-slf4j-impl) through. Switch the test bindings to log4j-slf4j2-impl and import slf4j-bom so conflict resolution cannot downgrade transitive SLF4J to 1.x. Drop the log4j-jul and log4j-jcl bridges the tightened rule then flagged, and manage commons-logging to a current release so transitive deps stop pulling the ancient 1.2. Assisted-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Member
Author
|
I also banned all transitive logging dependencies that are not logging APIs, so Flume libraries don't leak artifacts like |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Standardize all modules on the Log4j 2.x API so Flume's own logging no longer uses SLF4J. Applied the OpenRewrite Slf4jToLog4j recipe, then normalized the result: drop loggers that were never used, make every logger field private static final named "logger", and use the no-arg LogManager.getLogger() since each one named its own class.
Assisted-By: Claude Opus 4.8 (1M context) noreply@anthropic.com