views:

76

answers:

2

We'd like clients to be able to control logging levels in our client JAR. What is the best way to do this?

Currently we just have a handful of log statements that write to System.out. I realize that using Log4J would solve this problem although one of our biggest clients doesn't use Log4J and uses their own custom logging implementation. Is there a clean approach to let them control logging in our client jar?

Options we've thought of: clients could explicitly set properties on client jar classes to set logging level (don't like this), our client jar could read an optional .properties file that clients can put on their classpath (better but still a bit of a pain).

+2  A: 

Take a look at Apache commons-logging. It provides a thin isolation layer that can let your code use a consistent API and then plug in a lower-layer logger (including Log4J or another).

Jim Garrison
I would recommend slf4j over commons-logging.
notnoop
I'm not familiar with it. I guess I'll look it up.
Jim Garrison
I'd also recommend slf4j over commons logging. commons logging can lead to classloader problems: http://articles.qos.ch/classloader.html
Sylar
+4  A: 

Don't use a concrete logging framework, use SLF4J, so you can exchange logging if you need to. I'd start at first converting your own System.out's to the included java.util.logging. It's pretty straight forward and convenient for most needs.

If your client uses another logging framework, there either exists a bridge to slf4j or you can write your own.

EDIT: We've used it to streamline the logging of external libraries which used LOG4J into java.util.loogging which we use.

dhiller