RE: [httpclient] log4j reduxIs it possible to allow httpclient to be passed
a Category that can override an internal Category-like class like Rodney
mentioned which just does System.out/err? This would require log4j at
compile time, but only optionally at runtime. Full control for the log4jh
fanatic, without REQUIRING log4j.jar.
I would see this as a great way to incorporate full-blown logging for those
who want it, while not requiring it at all if you do not need it.
I am a huge fan of log4j type logging, but I personally do not want to use
it inside black-box type components within my system such as httpclient,
digester, collections, beanutils, etc.
Scott Sanders
----- Original Message -----
From: Waldhoff, Rodney
To: '[EMAIL PROTECTED]'
Sent: Wednesday, August 01, 2001 9:50 AM
Subject: RE: [httpclient] log4j redux
> -rw-r--r-- 1 544 cgu 29103 Aug 1 14:41 dist/lib/log4jME.jar
Hey, that's pretty cool. Especially in that it's using the log4j code base
unchanged.
I was thinking something a bit more radical in it's impact on log4j's
functionality, but probably much smaller in footprint.
Although I haven't tried it, it seems like we could create a new
org.apache.log4j.Category class that turns things like addAppender and
callAppenders into no-ops, sends all of the debug, error, fatal, info and
warn messaged to stdout or stderr, and always returns the same singleton
value for getInstance. If we wanted to be clever we might add the ability
to turn logging on or off per category or message type.
Would support for the Category methods alone cover most everyone's use of
log4j? If so we should be able to support that in a single class or so,
probably well under 5k in binary, and still maintain API compatibility with
log4j.
Ideally I think we should lobby the log4j folks to create the minimal log4j
binary, which may entail a bit of refactoring to get it all to work cleanly
(I'm a little uncomfortable with dropping in a radically different
implementation of the same class name, defining a Category-esque interface
would seem to be better), but I think something like the build Ceki put
together is probably good enough to start with.
Has anyone brought this up on the log4j lists?
