Alright, I'm sold. If no objections, slf4j it is.
-Jay
On Mon, Feb 3, 2014 at 1:11 PM, Joel Koshy wrote:
> > 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
> 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 ine
+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
discussion here:
http://stackoverflow.com/questions/11359187/dont-get-it-why-not-
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
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 wrote:
> We are already using other libraries in various parts of our code
> (e.g., metrics, zkclient, joptsimpl
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 wrote:
> >> Basically my preference would be java.
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 t
>> 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, s
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 mo
