commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <ssand...@nextance.com>
Subject RE: [Logging] [VOTE] Commons Logging 1.0 Release
Date Tue, 29 Jan 2002 20:03:44 GMT
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> Sent: Tuesday, January 29, 2002 12:01 PM
> To: Jakarta Commons Developers List
> Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release
> 
> 
> 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?

I think Craig is saying that we (commons) should attribute both Avalon
and Log4j, not Avalon attributing us.  Craig?

> 
> 
> 
> 
> >>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>
> 
> 

--
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