commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: how should log levels work? [Was Re: [Logging] default log level]
Date Wed, 09 Jan 2002 19:38:59 GMT
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>


Mime
View raw message