commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
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 <ssanders@nextance.com>
>>Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
>>To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
>>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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message