From: Erik W. S. <er...@se...> - 2002-09-06 03:01:57
|
Kevin Goess wrote: > Jeez, don't you guys sleep? um..... no. :p > After thinking about this for a day, I have to say I'm convinced > inc_level and dec_level best describe what's going on. > more/less_logging or pumpup/silence both presuppose that changing a > logger's level towards DEBUG results in *more* messages. That's not > necessarily the case, with appender thresholds it might just result in > *different* message behavior, maybe even less messages? What the > functions are doing is changing the level, what logging behavior that > change results in is up to the config file. I'm confused... can you give me an example whereby changing the logging from WARN to INFO would result in FEWER messages? To the below, there is an intrinsic ordering, and my take away is that a higher level in the ordering will spew out (a) all the log messages of the previous levels, and (b) all the log messages of the current level. Granted, you COULD do something like: if ($logger->is_warn()) { $logger->warn("This only shows up when we're at WARN level"); } but nobody's gonna do that, really. -e > > What inc_level and dec_level do is change the level of the logger. > Since the log4j docs say quite prominently: > > "Basic Selection Rule: A log request of level p in a logger with > (either assigned or inherited, whichever is appropriate) level q, is > enabled if p >= q. > This rule is at the heart of log4j. It assumes that levels are > ordered. For the standard levels, we have DEBUG < INFO < WARN < ERROR > < FATAL. " > > I understand your motivation in saying "the less I like exposing the > user to the concept that there's some integer value that corresponds > to a Level" but that's not the same as saying we shouldn't expose the > user to the concept that levels are ordered and are comparisonable, > which is a basic fact of life in log4j. > > If we really wanted to do it cleanly, we'd have a Priority.pm object > with is_greater and is_less_than methods, like log4j does and we'd > throw those around instead of the integers, but that would be stupid > performance-wise and I think we don't want to go there yet, right? > > BTW, there's also a getSyslogEquivalent() in Priority.java, so that's > fair game to implement. > > And re you guys' confusion between these proposed functions going in > Level.pm vs. Logger.pm, note that my implementation has > Logger::inc_level() calling Level::get_higher_level() to get the right > value. > > > Erik W. Selberg wrote: > >> Why would these be part of the Level class? I'd imagine they'd be >> part of the Logger class and affect the Logger's current Level. >> >> -e >> >> >> msc...@ao... wrote: >> >>> In a message dated Tue, 3 Sep 2002 9:50:57 PM Eastern Standard Time, >>> er...@se... writes: >>> >>> >>> >>>> So the more I think about it, the less I like exposing the user to >>>> the concept that there's some integer value that corresponds to a Level >>>> >>> >>> >>> >>> Good point. Only problem is that more_logging/less_logging methods >>> are kinda strange in a "Level" class. How about pumpup() and >>> silence() :) ? >>> >>> -- Mike >>> >>> Mike Schilli >>> log...@pe... >>> http://perlmeister.com >>> >>> >>> ------------------------------------------------------- >>> This sf.net email is sponsored by: OSDN - Tired of that same old >>> cell phone? Get a new here for FREE! >>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >>> _______________________________________________ >>> log4perl-devel mailing list >>> log...@li... >>> https://lists.sourceforge.net/lists/listinfo/log4perl-devel >>> >>> >>> >> >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: OSDN - Tired of that same old >> cell phone? Get a new here for FREE! >> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >> _______________________________________________ >> log4perl-devel mailing list >> log...@li... >> https://lists.sourceforge.net/lists/listinfo/log4perl-devel > > > |