commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <ssand...@nextance.com>
Subject RE: how should log levels work? [Was Re: [Logging] default log level]
Date Wed, 09 Jan 2002 23:19:10 GMT
>From what you are saying then I would like to propose Paulo's suggestion
of removing setLevel().  The slippery slope is much too steep :(

Scott

> -----Original Message-----
> From: robert burrell donkin [mailto:robertdonkin@mac.com] 
> Sent: Wednesday, January 09, 2002 1:53 PM
> To: Jakarta Commons Developers List
> Subject: Re: how should log levels work? [Was Re: [Logging] 
> default log level]
> 
> 
> 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>
> 
> 

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