Re: [log4perl-devel] Re: logdie / logcroak

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> How about we split the difference and just have inc_level / dec_level
> AND more_logging / less_logging? 

Tee hee--perfect!  

"Erik W. Selberg" wrote:
> 
> So I understand that inc_level / more_logging may not increase the
> amount of messages for lots of reasons. appender threshholds being a
> fine one. appenders that send those levels to random places being
> another. Lack of logging messages at that level being a third. :) But I
> don't think that matters so much.
> 
> How about we split the difference and just have inc_level / dec_level
> AND more_logging / less_logging? Not like we can't make functions
> aliases for the other. This way, folks who like to think of incrementing
> and decrementing levels can, and folks who just want more or less
> logging can just call the obvious function.
> 
> -e
> 
> Kevin Goess wrote:
> 
> > > I'm confused... can you give me an example whereby changing the logging
> > > from WARN to INFO would result in FEWER messages?
> >
> > You're absolutely right, there's not, I was confused, thinking of
> > appender thresholds.  However, there is the easy case where changing a
> > logger level from WARN to INFO would not result in any change in
> > logging behavior:
> >     log4perl.appender.app1.Threshold = WARN
> > in which case neither INFO nor DEBUG messages ever appear in that
> > appender's logs. See attached for a non-contrived example.
> >
> > I'm perfectly happy to be outvoted, shall we have a chorus of AYE's or
> > NAY's for
> >
> > inc_level/dec_level   more_logging/less_logging  pumpup/silence other?
> >
> >
> > Erik W. Selberg wrote:
> >
> >> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >------------------------------------------------------------------------
> >
> >#!/usr/bin/perl
> >
> >use Log::Log4perl;
> >
> >my $config = <<EOT;
> >
> >log4perl.category.app = FATAL, pageTheVP
> >log4perl.category.app.module1 = INFO, applicationLogs
> >
> >log4perl.appender.pageTheVP          = Log::Dispatch::Screen
> >log4perl.appender.pageTheVP.layout   = Log::Log4perl::Layout::SimpleLayout
> >log4perl.appender.pageTheVP.Threshold = FATAL
> >
> >log4perl.appender.applicationLogs          = Log::Log4perl::TestBuffer
> >log4perl.appender.applicationLogs.layout   = Log::Log4perl::Layout::SimpleLayout
> >
> >EOT
> >
> >Log::Log4perl::init(\$config);
> >
> >my $logger = Log::Log4perl::get_logger('app.module1');
> >
> >
> >$logger->info('info message 1');
> >$logger->info('info message 2');
> >$logger->info('info message 3');
> >$logger->inc_level();
> >$logger->debug('debug message');
> >$logger->fatal('big problem!!!');
> >
> >
> >
> >
> >

-- 
Happy Trails . . .

Kevin M. Goess 
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217