My vote would be with log4j, I don't have that much experience with log4j2
or a good feel for how much the industry is moving towards it.
On Mon, Feb 3, 2014 at 11:17 AM, Joel Koshy <[EMAIL PROTECTED]> wrote:
> We are already using other libraries in various parts of our code
> (e.g., metrics, zkclient, joptsimple, etc) some of which pull in these
> other logging dependencies anyway. i.e., what do we gain by using jul?
> There may be a good reason why people don't use jul so I think we
> should fully understand that before going with jul. So it may be
> simpler to just stick with log4j for the client rewrites and
> investigate logging later.
> log4j2 is becoming more widespread and many users seem to be favorable
> toward logback. slf4j would cover all of these very easily. From what
> I understand jul does not make it very easy to plug in with these
> various options but I could be wrong.
> I completely agree on the need to fix our client logging as that will
> go a long way in usability for end-users unless we want to keep
> getting asked the "Why do I see this ERROR in my logs..?" questions.
> On Mon, Feb 03, 2014 at 11:08:39AM -0800, Neha Narkhede wrote:
> > >> Basically my preference would be java.util.logging unless there is
> > known problem with it, otherwise I guess slf4j, and if not that then
> > +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
> > > (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
> > > that. For clients you mostly don't need to log: if there is an error
> > > should throw it back not log it, so you don't need ERROR logging.
> > > 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
> > > 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
> > > this is perhaps the more flexible choice since people can plug in
> > > stuff.
> > > 3. java.util.logging ships with the jdk, but for some reason no one
> > > 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
> > > to pick the "best" logging library. Fundamentally logging is pretty
> > > straight-forward and for our simple use case it is inconceivable that
> > > particular library could be much better than any other in terms of
> > > 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
> > > cases.
> > >
> > > Is there a reason not to just the java.util.logging? It comes with the
> > > and supports pluggable appenders so people who have some other library
> > > 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