Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka, mail # dev - Logging in new clients


Copy link to this message
-
Re: Logging in new clients
Xavier Stevens 2014-02-03, 19:14
I'm all for less dependencies but I would personally vote for slf4j-api.
Just don't use any underlying implementations like logback or slf4j-log4j
bridge. Then people can hookup whatever they want.

On Mon, Feb 3, 2014 at 11:08 AM, Neha Narkhede <[EMAIL PROTECTED]>wrote:

> >> Basically my preference would be java.util.logging unless there is some
> known problem with it, otherwise I guess slf4j, and if not that then log4j.
>
> +1. My preference is to use java.util.logging to avoid adding an external
> dependency,
> but I'm not too sure about what's the "standard" out there, so open to
> suggestions
> on picking a different library.
>
>
>
> On Mon, Feb 3, 2014 at 11:00 AM, Jay Kreps <[EMAIL PROTECTED]> wrote:
>
> > We probably need to add a small amount of logging in the new producer and
> > (soon) consumer clients. I wanted to have a quick discussion on logging
> > libraries before I start adding this in the producer.
> >
> > Previously we have been pretty verbose loggers and I think we should stop
> > that. For clients you mostly don't need to log: if there is an error you
> > should throw it back not log it, so you don't need ERROR logging.
> Likewise
> > I think it is rude to pollute peoples logs with the details of client
> > initialization (establishing connections, etc), so you don't need INFO
> > logging. However perhaps there is an argument to be made for WARN and
> > DEBUG. I think it is perhaps useful to log a WARN when a server breaks a
> > connection or metadata initialization fails. It can sometimes also be
> > useful to be able to enable debug logging to see step by step processing
> in
> > the client, which is the case for DEBUG logging.
> >
> > Here is my knowledge about the state of Java logging:
> > 1. Most people still use log4j. The server is using log4j.
> > 2. Second runner-up in slf4j. I personally consider slf4j pretty silly
> but
> > this is perhaps the more flexible choice since people can plug in
> different
> > stuff.
> > 3. java.util.logging ships with the jdk, but for some reason no one uses
> > it.
> > 4. There is no critical mass around any other logging library.
> >
> > The context for how to think about this is the following. We are not
> trying
> > to pick the "best" logging library. Fundamentally logging is pretty
> > straight-forward and for our simple use case it is inconceivable that any
> > particular library could be much better than any other in terms of
> feature
> > set. We want the most standard library. My goal is to minimize the
> > dependencies of the client and make our basic logging cases work for most
> > cases.
> >
> > Is there a reason not to just the java.util.logging? It comes with the
> jdk
> > and supports pluggable appenders so people who have some other library
> can
> > plug that in right?
> >
> > Basically my preference would be java.util.logging unless there is some
> > known problem with it, otherwise I guess slf4j, and if not that then
> log4j.
> >
> > Thougts?
> >
> > -Jay
> >
>