+1 for SLF4J. It is the only option that doesn't force a consumer to use a
particular style of configuration. It is common enough that I think it
would not cause any adoption friction. There's a relevant and lengthier
On Mon, Feb 3, 2014 at 3:00 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:
> Hey Joel,
> I see server and client logging and dependencies are really different in my
> mind. The server is a standalone process. Once we decouple the clients I
> think we can actually be a lot more aggressive about using more libraries
> on the server, why not? We have avoided that so far because they inevitably
> leak into the clients since they arent separated.
> The problem on the client side is that if we choose anything used by our
> clients and there is any incompatibility then they can't use kafka.
> From my point of view the improved logging libraries (log4j2, logback, etc)
> are the worst option. They are new so likely will have api changes, and few
> people use them so they don't get the benefit of sharing the same logging
> 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.
> > Joel
> > On Mon, Feb 03, 2014 at 11:08:39AM -0800, Neha Narkhede 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
> > > 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]>
> > >
> > > > 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
> > > > 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
> > > > 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
> > 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