> -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > 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 <[EMAIL PROTECTED]> > >>Reply-To: Jakarta Commons Developers List > >><[EMAIL PROTECTED]> > >>To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > >>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-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
