> -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 29, 2002 12:22 PM > To: Jakarta Commons Developers List > Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release > > On Tue, 29 Jan 2002, Berin Loritsch wrote: > > > Date: Tue, 29 Jan 2002 15:00:55 -0500 > > From: Berin Loritsch <[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 > > > > 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 don't want any credit for anything related to logging. I > want people who originated the ideas get credit for it. And > I learned quite a bunch of what I know about logging from Ceki. > > > > > > > > > >>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. > > > > Sorry, I never even noticed this one (which has nothing at > all to do with its value, or whether it was first or not, > yadda yadda). Just out of curiousity, was this abstraction > new as of the 1.1 check-in (10/31/2001), or did it get > migrated from somewhere else in the code base?
I have found reference as early as August. I don't have the reference though. > > BTW, you might want to review the use of the "short form" > Apache license in the Avalon sources. Comments from > PMC/Board folks in the past have been that only the long-form > is appropriate. > > > > > > > > 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. > > > > Craig > > > -- > 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]>
