Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
> >
>

 
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB