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 19:46:12 GMT


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.

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

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.

> I am -0 until I can see completely where Berin is coming from.
>
> Scott Sanders
>

Craig


> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Tuesday, January 29, 2002 11:28 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [Logging] [VOTE] Commons Logging 1.0 Release
> >
> >
> > Craig R. McClanahan wrote:
> >
> > > We've refined the commons-logging APIs, and documented the
> > mechanics.
> > > In addition, I've heard from numerous people on various
> > projects that
> > > would like to use these APIs, but are hesitant to do so
> > without a 1.0
> > > release.
> > >
> > > Therefore, I'd like to now propose that we do a 1.0 release of the
> > > commons-logging package, based on the current contents of the CVS
> > > repository for this package.  I will volunteer to act as release
> > > manager, following the standard process for Commons packages:
> > >
> > >   http://jakarta.apache.org/commons/releases.html
> > >
> > > ----- CUT HERE -----
> > > [ ] +1  I support the release of Commons Logging 1.0 and
> > will help [ ]
> > > +0  I support the release, but cannot help [ ] -0  I am not
> > in favor
> > > of the release [ ] -1  I am opposed to this release, and here's why
> > > (attach reasons)
> > > ----- CUT HERE -----
> >
> >
> > -1
> >
> >
> > How many logger abstractions do we need?  Avalon has a
> > perfectly good one. (I am not a committer on commons though...).
> >
> > It looks like a direct rip off of the Avalon logger
> > abstraction, and despite the work that Peter Donald and I put
> > into it, we get no mention.
> >
> >
> >
> >
> > --
> >
> > "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>
>
>



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