ijuma commented on code in PR #17373:
URL: https://github.com/apache/kafka/pull/17373#discussion_r1898950768
##########
build.gradle:
##########
@@ -1099,15 +1103,17 @@ project(':core') {
implementation libs.dropwizardMetrics
exclude module: 'slf4j-log4j12'
exclude module: 'log4j'
- // Both Kafka and Zookeeper use slf4j. ZooKeeper moved from log4j to
logback in v3.8.0, but Kafka relies on reload4j.
+ // Both Kafka and Zookeeper use slf4j. ZooKeeper moved from log4j to
logback in v3.8.0.
// We are removing Zookeeper's dependency on logback so we have a
singular logging backend.
exclude module: 'logback-classic'
exclude module: 'logback-core'
}
// ZooKeeperMain depends on commons-cli but declares the dependency as
`provided`
implementation libs.commonsCli
-
- compileOnly libs.reload4j
+ implementation libs.log4j2Core
+ implementation libs.log4j2Api
+ implementation libs.log4j1Bridge2Api
+ implementation libs.jacksonDatabindYaml
Review Comment:
@ppkarwasz It is true that we previously tried hard to avoid making the
logging choice for the Maven artifact while making it for the distributed
binaries. However, this is brittle and only worked partially. When I tried to
fix it in #12148, it caused problems and it was partially reverted (#16260,
#16559).
Also, it's actually bad to silently not support the dynamic logging
functionality for the broker (this is _incredibly_ useful in production).
So, I think the simplest thing is to make the logging choice explicit for
the server modules (the rare user who doesn't want that can still override it
with exclusions via their build file) and leave it up to the applications for
the client modules. In the future, if there is a way to address these issues,
we can change it again. There are two promising and complementary paths:
1. Your logging admin library.
2. slf4j2 makes it possible to choose the logging library dynamically
instead of via classpath tricks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
