Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 73675 invoked from network); 14 Jan 2002 10:39:11 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 14 Jan 2002 10:39:11 -0000 Received: (qmail 8511 invoked by uid 97); 14 Jan 2002 10:39:04 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 8463 invoked by uid 97); 14 Jan 2002 10:39:03 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 8447 invoked from network); 14 Jan 2002 10:39:03 -0000 Reply-To: From: "Paulo Gaspar" To: "Jakarta Commons Developers List" Subject: RE: [logging] consensus about Log interface? Date: Mon, 14 Jan 2002 11:54:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200201141022.g0EAMM818362@mail008.syd.optusnet.com.au> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N LOL Paulo > -----Original Message----- > From: Peter Donald [mailto:peter@apache.org] > Sent: Monday, January 14, 2002 10:59 AM > To: Jakarta Commons Developers List > Subject: Re: [logging] consensus about Log interface? >=20 >=20 > Wow - almost identical to the Avalon Logger interface. >=20 > On Mon, 14 Jan 2002 10:09, robert burrell donkin wrote: > > i think it's important to get a consensus since we might have to = stick > > with this interface for some time. this is an attempt to=20 > summarize what i > > think came out of the various threads. it should make it easier=20 > for anyone > > else who thinks otherwise to make that clear. > > > > 1. no one else (but me) has any great enthusiasm for making log = levels > > internal to commons-logging. so we'll lose that idea. > > > > 2. commons-logging should not perform any configuration of the=20 > underlying > > logging system. therefore setLevel() should be removed. > > > > 3, getLevel cannot be used reliable for anything more than the basic > > levels (ie. debug, info, warn, error, fatal). the behaviour of > > commons-logging (from a component's point of view) should not depend = on > > any feature of the logging system which the user chooses. therefore > > getLevel should be removed and isWarnEnabled, isErrorEnabled and > > isFatalEnabled methods added instead. any implementation which = cannot > > reliable determine the log level should return true for each of = these > > methods. > > > > - robert >=20 > --=20 > Cheers, >=20 > Pete >=20 > "You know what a dumbshit the 'average man' on the street is? Well, by > definition, half of them are even dumber than that!" > J.R. "Bob" Dobbs >=20 > -- > To unsubscribe, e-mail: =20 > > For additional commands, e-mail:=20 > >=20 -- To unsubscribe, e-mail: For additional commands, e-mail: