Sam Ruby wrote:
>What was first suggested was that we roll our own thin logging abstraction
>layer. Ultimately, it became clear that since you can write your own
>appenders, log4j could be viewed as a standard thin logging abstraction
>layer. One with conserable value add.
I actually agree, but how thin is thin? The size of the requisite JAR
seemed to be a point of contention when we tried (or I tried) to add direct
log4j support (and dependency) to httpclient. Ceki seemed to be getting
log4jME to be pretty small, but the logging proposal currently in the
sandbox is only a couple of KB when stripped down to the three minimal
classes (Log, LogSource, NoOpLog). If log4j could/would produce a JAR like
that, I'd be all over it (in fact, I did a bit of fishing along those lines
on this list).
In the meantime I think a commons component is warranted:
I think it is reasonable to say *some* people will expect logging from
*some* components, and that those people should be relatively free to choose
whatever underlying logging implemenation they want. A couple of extra KB
(and one extra JAR) for those non-trivial components (the only ones worth
logging) seems like a reasonable price to pay to keep those people happy
(and to help them integrate the commons component with their application).
I also think it is reasonable for some people to say they want the smallest
JAR/memory footprint that is reasonable. Asking them to include a 15K+ JAR
(I think log4jME was down to ~20K or so) probably isn't very reasonable.
The logging abstraction seems like a decent comprimise.
If we want to get any better than that, I think we should consider
conditional compilation and distribute two JARs, but that's a lot more
trouble than it's probably worth.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
