Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 29981 invoked from network); 13 Jan 2002 23:09:12 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 13 Jan 2002 23:09:12 -0000 Received: (qmail 2579 invoked by uid 97); 13 Jan 2002 23:09:11 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 2555 invoked by uid 97); 13 Jan 2002 23:09:11 -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 2544 invoked from network); 13 Jan 2002 23:09:10 -0000 Date: Sun, 13 Jan 2002 23:09:55 +0000 Subject: [logging] consensus about Log interface? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v475) From: robert burrell donkin To: "Jakarta Commons Developers List" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.475) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 summarize what i think came out of the various threads. it should make it easier 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 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 -- To unsubscribe, e-mail: For additional commands, e-mail: