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

[Kevin G. <ke...@go...>]

 > 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
>>
>>
>>
>>
> 
> 
> 


-- 
Happy Trails . . .

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