On Wednesday, August 15, 2001, at 05:47 PM, Craig R. McClanahan wrote:
> 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 ... :-)
being able to log from digester to log4j is pretty important to me.
DigesterLogger was just a means to that end.
>
>> 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).
can we push the process along then?
as i understand it (i'm sure that somebody will correct me when i'm wrong)
,
the project needs to be voted into the commons proper and then a release
version produced before other components can depend on it. if there isn't
a consensus for the project then at least that'd be clear.
maybe - or probably - it isn't the ultimate solution but at least we'd
have something that would allow log4j to be used with the smaller
components.
- robert
