commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [logging] consensus about Log interface?
Date Mon, 14 Jan 2002 01:46:21 GMT

On Sun, 13 Jan 2002, robert burrell donkin wrote:

> Date: Sun, 13 Jan 2002 23:09:55 +0000
> From: robert burrell donkin <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: [logging] consensus about Log interface?
> 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.

It's clear that different logging systems have different notions about
what "levels" are available, so removing getLevel() makes sense to me as

I don't personally plan to call is{Warn,Error,Fatal}Enabled in my code,
but I can see adding them for semantic completeness.

> - robert


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message