On Wed, 15 Aug 2001, Sam Ruby wrote:
>
> My fear is that I compose a system with a dozen components, each of which
> has its own wrapper over logging functionality, so the total footprint
> consumed by these wrappers is larger than the logging system which is
> undoubtably going to be including anyway.
>
That's why I didn't want to go down the road of DigesterLogger ... :-)
> Trying to standardize on a wrapper without settling for an absolute least
> common denominator approach essentially is equivalent to selecting a
> logging package with a reasonably good interface, and stripping from
> package the set of backends which are not of interest.
>
Having slept on it overnight, I'd like to propose that we stick with the
logging abstraction that's currently in the sandbox. (I'm going to check
in a couple of tweaks that remove it's legacy references to
"httpclient" property names).
For Log4J fans, it's interesting to note that it *defaults* to Log4J if
those classes are available on your classpath.
> - Sam Ruby
>
>
Craig
