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 19:23:26 GMT
I can see your viewpoint, but I think that it is sometimes necessary.
What if my component logs to 25 categories but I give you an easy way to
cascade it by calling the main setLevel().

Scott

> -----Original Message-----
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de] 
> Sent: Wednesday, January 09, 2002 11:39 AM
> To: Jakarta Commons Developers List
> Subject: RE: how should log levels work? [Was Re: [Logging] 
> default log level]
> 
> 
> 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: <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>
> 
> 
> --
> 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