Menu
▾
▴
Re: [log4perl-devel] Re: logdie / logcroak
|
From: Erik W. S. <er...@se...> - 2002-08-30 02:57:44
|
> Kevin Goess wrote: > >Very interesting. I seem to remember reading something in the log4j >docs rejecting the 7 syslog levels, something about them being too many, >confusing, unnecessary. And we don't want to break compatibility with >log4j. So I don't think we should implement the missing syslog levels. > From the "what they're doing" bit from http://jakarta.apache.org/log4j/docs/manual.html: "Loggers /may/ be assigned levels. The set of possible levels, that is DEBUG <http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Level.html#DEBUG>, INFO <http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Level.html#INFO>, WARN <http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Level.html#WARN>, ERROR <http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Level.html#ERROR> andFATAL <http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Level.html#FATAL> are defined in the |org.apache.log4j.Level <http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Level.html>| class. Although we do not encourage you to do so, you may define your own levels by sub-classing the |Level| class. A perhaps better approach will be explained later on." The Log4J guys also defined Level as a class, and have a Level.toLevel() method, one of which is the following: toLevel public static Level <http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Level.html> *toLevel*(int val) Convert an integer passed as argument to a level. If the conversion fails, then this method returns |DEBUG| <http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/Level.html#DEBUG>. which is really just: public static Level toLevel(int val, Level defaultLevel) { switch(val) { case ALL_INT: return ALL; case DEBUG_INT: return Level.DEBUG; case INFO_INT: return Level.INFO; case WARN_INT: return Level.WARN; case ERROR_INT: return Level.ERROR; case FATAL_INT: return Level.FATAL; case OFF_INT: return OFF; default: return defaultLevel; } } where the levels are 7, 7, 6, 4, 3, 0, and 0, respectively (they have ALL = 7 and OFF = 0, as in Log::Log4perl currently). I don't know the full history of Log4j myself, but looking at it, it seems pretty clear that they took the sysloc(3) facility, attempted to abstract away some of the more random criticalities (ALERT, CRITICAL, and NOTIFY), and probably botched the OFF vs FATAL bit --- or assumed that this didn't matter, as intrinsicly I'd imagine that most folks did something like: logger.fatal("Dogs and cats, living together!"); throw TheEndOfTheWorldException; That being said, say we implement CRITICAL, ALERT, and NOTIFY. How does that break compatibility with log4j? (See below in that the existing log4j code handles some error cases badly when you use ints directly). Are you worried that somebody could write a config file using Log::Log4perl that uses CRITICAL, ALERT, and NOTIFY and thus wouldn't work if they were then using a Log4j application? (it turns out that the actual result if they did would bethat CRITICAL, ALERT, and NOTIFY would turn into DEBUG vs FATAL or ERROR :) >We should also keep the details of the level constants private. Someday >I'd like to allow users to create their own levels (log4j does it with >subclassing), so it would help to keep as many of the details hidden >(therefore changeable) as possible, the user shouldn't count on anything >more detailed than > DEBUG < INFO < WARN < ERROR < FATAL. > >But to enable what you're trying to do I can see some useful class >methods to add to Level, what about > >get_next_higher_level($level_const){..} >get_next_lower_level($level_const){..} > >With the caveat that since log4j defines FATAL as *high* these functions >will actually return the opposite of the priority values, e.g. >get_next_higher_level(ERROR) would return FATAL, which you could then >use to set your logger. > So here's what would make me happy, which is similar. :) inc_level($levels) dec_level($levels) where $levels is an integer value. I don't usually care what the order of log levels are, but I know that another -v gets me more info. So, if we assume we're starting off at Level 0 (OFF / FATAL :), $log->inc_level(3) puts us up three levels. If those levels happen to be ERROR, WARN, and INFO, then we're at INFO. If some user decides they need CRITICAL and ALERT (say legacy syslog support) and put them in, then inc_level(3) just get's 'em to ERROR. Make sense? -e > > >How does that sound? > > >"Erik W. Selberg" wrote: > >>While we're on the subject of levels... :) >> >>In most of my progs, I have a verbosity setting that's strictly >>increasing. What I'm transitioning them from is: >> >>% myprog +v +v >> >>my $v; >>GetOptions("v+" => \$v, ...); >> >>logdebug(2, "This only prints if $v >= 2\n"); >> >>into: >> >>$log->info("This only prints if we're at info level, which is normally >>two +v's"); >> >>Needless to say, I've had to reinvent a step function that basically >>counts from 0 3 4 6 7, which is kinda icky. :) >> >>What's I'd propose is something like the following: >> >>our %PRIORITY = { >> OFF => -1, >> FATAL => 0, >> ALERT => 1, >> CRITICAL => 2, >> ERROR => 3, >> WARN => 4, >> NOTICE => 5, >> INFO => 6, >> DEBUG => 7 >>}; >> >>This is actually the complete list of the syslog(3) levels. Needless to >>say, I'm not sure if we would want to implement >>log->alert / critical / notice (although I would like notice... I tend >>to have three levels of verbosity that's non-error and I'm not a big fan >>of down-shifting to using warn() for one), but it would be nice to >>include so when people specify an integer like 2 for the priority, calls >>to $log->fatal spew something and calls to $log->error don't. >> >>Whatcha think? >> >>-e >> >> >>Kevin Goess wrote: >> >> >> >>>I agree, and I think that makes all three of us, that logdie should >>>always die regardless of what it logs. My rationale is this: A. >>>Programmer is using Log4perl to control whither the messages spew. When >>>he calls logdie(), he is saying "Please spew this message according to >>>the behavior I have defined for Log4perl, and then die, because my >>>program has encountered a fatal error and must not continue." >>> >>>If A. Programmer has turned logging OFF, Log4perl should spew no >>>messages, including FATAL messages. We can fix it like this in >>>Level.pm, does that sound good? (Erik, then we need to adjust your unit >>>tests). >>> >>>our %PRIORITY = ( >>> "FATAL" => 0, >>> "ERROR" => 3, >>> "WARN" => 4, >>> "INFO" => 6, >>> "DEBUG" => 7, >>>); >>> # Min and max >>>$PRIORITY{'OFF'} = $PRIORITY{'ALL'} = -1; >>>map { ($_ > $PRIORITY{'ALL'} ? $PRIORITY{'ALL'} = $_ : '' ) } values >>>%PRIORITY; >>>$PRIORITY{'ALL'} += 1; >>> >>> # Reverse mapping >>>our %LEVELS = map { $PRIORITY{$_} => $_ } keys %PRIORITY; >>> >>> >>> >>> >>>msc...@ao... wrote: >>> >>> >>> >>> >>>>In a message dated Wed, 28 Aug 2002 1:47:59 AM Eastern Standard Time, er...@se... writes: >>>> >>>> >>>> >>>> >>>> >>>>>Here ya go. >>>>> >>>>> >>>>> >>>>> >>>>Applied! It's checked into CVS now and will be part of the 0.23 release. Nice work, thanks Erik! >>>> >>>> >>>> >>>> >>>> >>>>>An interesting question is, assuming that OFF does turn even FATAL off, >>>>>is what the behavior of logdie / logcroak / logconfess should be. >>>>> >>>>>Should they still die, just not log anything? Or should logging OFF >>>>>suppress the death as well? >>>>> >>>>>My own $0.02 would be that the default behaviour would be that they >>>>>still die, as the behavior is really log->fatal && die. >>>>> >>>>> >>>>> >>>>> >>>>Good question. I don't think we've made up our minds yet on what log->fatal should actually return -- one solution might be to have it return true if it logs something and false if it doesn't. In any case, until this is resolved, >>>> >>>> log->fatal && die >>>> >>>>would die randomly, depending on what log->fatal returns. But in this case, if "OFF" does indeed turn of fatal(), die() wouldn't be executed. Tough one. >>>> >>>>I think logdie($msg) should actually be more like >>>> >>>> log->fatal($msg); die $msg; >>>> >>>>because in most cases this will be called in desperate situations when all you want to do is get out, no matter what the log settings are. >>>> >>>>So, if it turns out indeed that OFF overrules FATAL, we need to make sure your logdie/warn functions still do the right thing. >>>> >>>>-- >>>>-- Mike >>>>Mike Schilli >>>>log...@pe... >>>> >>>>------------------------------------------------------- >>>>This sf.net email is sponsored by:ThinkGeek >>>>Welcome to geek heaven. >>>>http://thinkgeek.com/sf >>>>_______________________________________________ >>>>log4perl-devel mailing list >>>>log...@li... >>>>https://lists.sourceforge.net/lists/listinfo/log4perl-devel >>>> >>>> >>>> >>>> >>> >>> >>> >>------------------------------------------------------- >>This sf.net email is sponsored by:ThinkGeek >>Welcome to geek heaven. >>http://thinkgeek.com/sf >>_______________________________________________ >>log4perl-devel mailing list >>log...@li... >>https://lists.sourceforge.net/lists/listinfo/log4perl-devel >> >> > > > |
