> Ok if log4j isn't a runtime dependency. I think
> it would be useful to be able to fully disable
> logging (and rely on the interceptors), for example by adding a
> "if (logger != null)" or something like it around the logging
> calls.
I haven't seen the CVS commit email come back around, but I just checked in
a revision that I think (or at least hope) everyone should be happy with.
I still need to write up more explicit notes on how to use it, but
essentially it works like this:
* I've added a simple org.apache.commons.httpclient.log.Log interface with
methods similar to the log4j Category.
* You can set a Java system property named httpclient.log to be the fully
specified name of any class that implements that Log interface, and all the
logging calls will be delegated to an instance of that class.
* There are currently three implementations of Log available, SimpleLog
which logs to stdout, Log4JCategoryLog which logs to a log4j Category, and
NoOpLog which doesn't do anything at all.
* If you don't set the httpclient.log property at all, or set it to a bad
value, etc., AND the log4j Category class is available in the classpath, it
defaults to using the Log4JCategoryLog (which means it just uses log4j
pretty much as usual.)
* If you don't set the httpclient.log property at all AND the log4j Category
class is NOT available in the classpath, it defaults to the NoOpLog, which
essentially turns off all logging.
* If you'd like to integrate this with logkit or merlin or something, it
should be relatively straightforward to introduce an implementation of Log
that delegates to whatever you want.
* Log4J is still a compile-time dependency, but not a run-time one.
* The additional logging classes add up to ~10K of byte code uncompressed,
which looks like ~7K in the .jar. Most of that is actually in the SimpleLog
class. The minimal set of runtime classes would probably be Log, LogSource,
and NoOpLog which looks like slightly less than 2K in the jar. But if we're
really concerned with optimizing the disk space, memory, and performance of
httpclient, I'd think we get a bigger bang for our buck elsewhere.
