commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertdon...@mac.com>
Subject Re: how should log levels work? [Was Re: [Logging] default log level]
Date Wed, 09 Jan 2002 21:52:51 GMT
On Wednesday, January 9, 2002, at 06:28 PM, Scott Sanders wrote:

> I think that all calls should push through to the underlying system, and
> that if possible the set/getLevel methods should operate on the
> underlying implementation.

it's probably easier for me to start by saying why i made the change to 
dealing with log levels internally...

what broke logging was that somebody changed the values of the Log level 
constants. this broke the existing implementations pretty badly. i wanted 
a way to create robust implementations and which would allow test code to 
be written.

i switched to dealing with log level internally within commons-logging as 
a way to achieve these aims. i wasn't too sure what the original intention 
concerning log level had been until craig committed his Jdk14Logger. now 
we have one too many meanings for setLevel :)


they are other ways that logging could be fixed while still delegating log 
levels to the logging system but i do have a couple of reasons why i think 
that dealing with the log level internally is better.

how different logging systems are configured is much more variable than 
the logging interface they present. IMHO commons-logging should not 
perform any configuration of the underlying logging system. the user must 
be expected to perform that configuration but equally commons-logging 
should not change the configuration set up by the user.

i also think that dealing with log levels internally will be easier to 
explain to users. i have two particular cases in mind:

1. i'd expect that setLevel(Log.OFF) should turn off logging for that 
instance. delegating to the logging system means that the actual behaviour 
in this case is variable. for example, the old log4j implementation of 
setLevel(Log.OFF) actually did the opposite since log4j doesn't support an 
OFF priority.

2. let's say we have two instances of a component with logging. let's say 
a user creates code that calls setLevel(Log.OFF) on one instance and 
setLevel(Log.DEBUG) on the other. i'd say that most users would expect the 
effect of this would be to switch logging on for one instance and off for 
the other. what you get with delegation to the logging system is that the 
  effective priority will be determined by the order in which the calls are 
made. if they are internal to commons-logging then different instances can 
have different log levels.

- robert


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