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:[EMAIL PROTECTED]] > 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:[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: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]>
