[
https://issues.apache.org/jira/browse/KAFKA-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653949#comment-14653949
]
Grant Henke commented on KAFKA-2285:
------------------------------------
Thanks for all the related Jiras and input [~ijuma]. I agree that scala-logging
is likely not a good option for Kafka and the resulting solution may be a
larger code change, but potentially and opportunity to "clean up" existing
logging.
I think its important to evaluate the options and make sure the implementation
makes sense going forward and is not just a bandaid.
> Logging trait obfuscates call site information
> ----------------------------------------------
>
> Key: KAFKA-2285
> URL: https://issues.apache.org/jira/browse/KAFKA-2285
> Project: Kafka
> Issue Type: Improvement
> Components: core
> Affects Versions: 0.8.2.0
> Reporter: E. Sammer
> Assignee: Grant Henke
>
> Using a logging trait, as many components in the codebase do, destroys call
> site information in logging message making debugging certain kinds of
> failures annoying in production systems. Most messages end up look like:
> {code}
> 2015-06-18 07:41:11,550 (kafka-request-handler-0) [WARN -
> kafka.utils.Logging$class.warn(Logging.scala:83)] Partition [events,1] on
> broker 1: No checkpointed highwatermark is found for partition [events,1]
> {code}
> I think the mental overhead of issuing the standard incantation of {{private
> static final Logger logger = LoggerFactory.get(Foo.class)}} (or the even
> shorter Scala equivalent) for each class is outweighed by the operational
> overhead of mapping strings back to their original call sites. This is an
> easy win improve the traceability of complex failures in production
> deployments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
