Menu
▾
▴
Re: [log4perl-devel] Re: logdie / logcroak
|
From: Kevin G. <ke...@go...> - 2002-08-30 23:45:45
|
> 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). Poop! We're emulating brokenness! (At least now I know where Mike S. got his constants!). > 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? One of *my* goals in starting this project was to emulate log4j behavior as closely as possible so that a) a person who knew one could easily transfer his knowledge base to the other, b) documentation that applies to one would apply to the other, c) log4perl would have the benefit of the log4j design decisions and all the log4j brain sweat, d) a config file could be used by either log4j or log4perl--they get complex, they should be reusable. Once we start diverging, it becomes a matter of "Wow, this is great, I can use all the knowledge I gained about log4j and apply it in this Perl project, I just have to remember that A is actually B and C is sometimes D and ....". Once you start diverging at all then the user doesn't have confidence that the two systems work the same and he has to keep it in his head as two different systems. So if log4j has OFF = FATAL, I think we should do the same thing, even if we think it's wrong, just because it's the *same*. That's my opinion, anyway. Nice thing about having three developers talking about this is we don't have to worry about breaking ties. What do you guys think? > So here's what would make me happy, which is similar. :) > > inc_level($levels) > dec_level($levels) Ja, way better! > 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? Yeah, but the other way. All the log4j docs say FATAL is *high* and DEBUG is *low*, (DEBUG < INFO < WARN < ERROR < FATAL) so from INFO $log->inc_level(2) would give you ERROR. When adding -v to increase the *verbosity* you'd want to decrease the log level towards DEBUG. Does that sound right? Erik W. Selberg wrote: >> 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 >>> >> >> >> >> > > > -- Happy Trails . . . Kevin M. Goess (and Anne and Frank) 904 Carmel Ave. Albany, CA 94706 (510) 525-5217 |
