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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hugh Salgado's post about Filters brought to mind a situation where 
changing the level from, say, INFO to DEBUG would result in *less* 
logging, if there's a (as yet unimplemented) LevelFilter on the appender 
that, say, only accepts INFO messages.

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