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:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]] > > 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-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
