commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [Logging] [VOTE] Commons Logging 1.0 Release
Date Tue, 29 Jan 2002 20:00:55 GMT
Craig R. McClanahan wrote:

> On Tue, 29 Jan 2002, Scott Sanders wrote:
>>Date: Tue, 29 Jan 2002 11:27:23 -0800
>>From: Scott Sanders <>
>>Reply-To: Jakarta Commons Developers List <>
>>To: Jakarta Commons Developers List <>
>>Subject: RE: [Logging] [VOTE] Commons Logging 1.0 Release
>>Berin, I think that I understand how you feel, and although the
>>abstraction was implemented outside of Avalon, I do believe that Avalon
>>should be attributed in some way, because it ended up being so close.
> If you read back through the COMMONS-DEV discussions, I'd say that the
> commons logging API started out closer to Log4j than it did to LogKit, and
> during the development sycle morphed towards what was obviously a good
> idea :-).
> I'm absolutely +1 on attribution, though, as long as its to both of them.

And you contributed to Avalon's logging abstraction how?

>>What can we do to make this better?  The biggest difference that I see
>>is that commons-logging is trying to be super small.  I want to talk
>>this out before I give my +1 on the release.  I am willing to try and
>>make this better.
> In particular, commons-logging *only* wants to be a facade (rather than
> providing anything other than a basic System.out logging implementation
> itself), where LogKit's white paper explicitly describes the Avalon team's
> need to go beyond that.

That is what the Avalon Logging abstraction is all about.  I am not talking
about Avalon's LogKit.  I am talking about the interfaces and facades in
org.apache.avalon.framework.logging package.

> I'm glad there is more than one choice in logging frameworks in the world,
> with differing feature sets and philosophies.  I just want to avoid having
> a Commons component that wants to do logging (such as Digester or
> BeanUtils) dictating to an application that it *must* use exactly one of
> them, whether it wants to or not.  That should be the choice of the
> developer who is using the commons components, or the sysadmin deploying
> the application into a production environment already based on one of
> them.

And nothing in the Avalon logging abstraction *requires* the developer to
use LogKit.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message