RE: how should log levels work? [Was Re: [Logging] default log level]

[Scott Sanders <ss...@nextance.com>]

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.

Scott

> -----Original Message-----
> From: robert burrell donkin [mailto:robertdonkin@mac.com] 
> Sent: Wednesday, January 09, 2002 10:31 AM
> To: Jakarta Commons Developers List
> Subject: how should log levels work? [Was Re: [Logging] 
> default log level]
> 
> 
> On Tuesday, January 8, 2002, at 10:01 PM, Craig R. McClanahan wrote:
> 
> <snip>
> 
> > Shouldn't the logging level be inherited from the 
> underlying logging 
> > configuration?  If I set a particular level in my Log4J or JDK 1.4 
> > configuration file, *that* is what I want to use, right?
> 
> i was going to try to get round to raising some stuff related 
> this as a 
> design issue (but i didn't have time to draft a good email on 
> it before). 
> it's basically whether log levels should be delegated to the wrapped 
> logging system or whether they should be enforced by the logging 
> implementation. i'll try to state this more precisely:
> 
> the question is whether log levels
> 
> 1. should be a way of wrapping the configuration of the 
> underlying logging 
> system or whether
> 
> 2. they should act within the commons-logging implementations 
> as a filter 
> preventing calls going to the underlying system.
> 
> 
> for example, setting a log level to Log.INFO
> 
> 1. means that the implementation calls some configuration 
> code on it's 
> wrapped logging instance that allows logging
> 
> 2. means that the implementation checks the current 
> commons-logging log 
> level before calling and only calls the wrapped logging system if the 
> logging call is INFO or higher.
> 
> 
> i think that 2 is the right way to go but i also think that 
> there are good 
> arguments for 1 as well. the refactoring uses interpretation 
> 2. i think i' ll stop here and give my reasons in another email.
> 
> - robert
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <ma...@jakarta.apache.org>
> 
> 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: how should log levels work? [Was Re: [Logging] default log level]

[Paulo Gaspar <pa...@krankikom.de>]

I personally think you should avoid changing the log level after the
configuration step.

However, I also agree that if you call setLevel() is because you
really want to change the level and are supposed to know what you
are doing.

The 2 alternatives that make more sense to me:
 - A setLevel() that always changes the level;

 - No setLevel() at all.
   The (Avalon) wrappers I use work this way and I never miss that
   thing. I am not sure if it is such a common need that it should
   have a place in this common interface.

   Notice that I believe in being able to set the level in some
   common configuration mechanism, just not on the interface.


Have fun,
Paulo Gaspar


> -----Original Message-----
> From: Scott Sanders [mailto:ssanders@nextance.com]
> Sent: Wednesday, January 09, 2002 7:28 PM
>
>
> 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.
>
> Scott
>
> > -----Original Message-----
> > From: robert burrell donkin [mailto:robertdonkin@mac.com]
> > Sent: Wednesday, January 09, 2002 10:31 AM
> > To: Jakarta Commons Developers List
> > Subject: how should log levels work? [Was Re: [Logging]
> > default log level]
> >
> >
> > On Tuesday, January 8, 2002, at 10:01 PM, Craig R. McClanahan wrote:
> >
> > <snip>
> >
> > > Shouldn't the logging level be inherited from the
> > underlying logging
> > > configuration?  If I set a particular level in my Log4J or JDK 1.4
> > > configuration file, *that* is what I want to use, right?
> >
> > i was going to try to get round to raising some stuff related
> > this as a
> > design issue (but i didn't have time to draft a good email on
> > it before).
> > it's basically whether log levels should be delegated to the wrapped
> > logging system or whether they should be enforced by the logging
> > implementation. i'll try to state this more precisely:
> >
> > the question is whether log levels
> >
> > 1. should be a way of wrapping the configuration of the
> > underlying logging
> > system or whether
> >
> > 2. they should act within the commons-logging implementations
> > as a filter
> > preventing calls going to the underlying system.
> >
> >
> > for example, setting a log level to Log.INFO
> >
> > 1. means that the implementation calls some configuration
> > code on it's
> > wrapped logging instance that allows logging
> >
> > 2. means that the implementation checks the current
> > commons-logging log
> > level before calling and only calls the wrapped logging system if the
> > logging call is INFO or higher.
> >
> >
> > i think that 2 is the right way to go but i also think that
> > there are good
> > arguments for 1 as well. the refactoring uses interpretation
> > 2. i think i' ll stop here and give my reasons in another email.
> >
> > - robert
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
> >
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: how should log levels work? [Was Re: [Logging] default log level]

[robert burrell donkin <ro...@mac.com>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>