commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [Logging] [VOTE] Commons Logging 1.0 Release
Date Tue, 29 Jan 2002 20:21:51 GMT


On Tue, 29 Jan 2002, Berin Loritsch wrote:

> Date: Tue, 29 Jan 2002 15:00:55 -0500
> From: Berin Loritsch <bloritsch@apache.org>
> 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
>
> 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 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?

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-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message