log4perl-devel — Ongoing log4perl development

Re: [log4perl-devel] New Levels

[Erik W. S. <er...@se...>]

Actually, ignore my previous patch and check this one out. I took the 
liberty of re-doing how the code is generated using the following syntax:

*{ <foo> } = sub { <bar> }

vs:

$code = "sub foo { <bar> }"; eval $code;

which enabled me to re-use it to auto-create new levels on the fly using:

Log::Log4perl::Logger::create_custom_level("LITEWARN", "WARN");

I also re-did 025CustLevels.t with this in mind, as I think it's nicer 
than the BEGIN block method.

While I was at it, I also updated logdie and friends so they die 
regardless of the OFF setting (and changed appropriate test classes), 
and implemented the newer constants that Mike has (although note I'm 
pretty sure this patch will clobber his).

Cheers,
-e

Re: [log4perl-devel] New Levels

[<msc...@ao...>]

> So, I got a different patch, that does the same stuff 
> only more.

Sorry, I can't apply your patch. It contains backed-up Emacs files, CVS directories, and it's not in a format my "patch" can process. Could you please  submit it again, using the standard

    cvs diff -Nau 

while you're located in the Log-Log4perl directory? Also, please make sure there's none of your local files left. If you want to make sure it's actually working, just check out a fresh version of Log-Log4perl, apply your patch and check the result. This way you're making it easier for me to get your stuff in.

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com

Re: [log4perl-devel] New Levels

[Erik S. <er...@se...>]

So, I got a different patch, that does the same stuff only more. :)

I also attempted (and this DOESN'T work.. YET! :) to generalize the 
Levels. Rather than doing the BEGIN{.. our PRIORITY = {} } statement, I 
wanted to create a simple routine (or even set of routines) that would 
just create and insert a new level appropriately.

It's close, but not there yet. I'm having issues figuring out how to 
export a new variable on demand to the current namespace. If you guys 
could take a look at 026CustLevel2.t and perhaps give a hand, I'd 
appreciate it.

Thanks,
-e

Mike Schilli wrote:

>Hey guys,
>
>please find attached a patch for log4j-compatible levels, they're like
>
>our %PRIORITY = (
>    "OFF"   => 60000,
>    "FATAL" => 50000,
>    "ERROR" => 40000,
>    "WARN"  => 30000,
>    "INFO"  => 20000,
>    "DEBUG" => 10000,
>    "ON"    => 0,
>)
>
>now and I had to change a couple of test cases and code doing actual comparisons (<= etc.) -- can
>you please verify before I check it in? Just to make sure I'm not wiping out anything you guys came
>up with over labor day ;)
>
>
>-- Mike
>--------------------------------------------------------
>Mike Schilli log...@pe... http://perlmeister.com
>--------------------------------------------------------
>  
>
>------------------------------------------------------------------------
>
>diff -Naur Log-Log4perl/lib/Log/Log4perl/Appender.pm Log-Log4perl.mike/lib/Log/Log4perl/Appender.pm
>--- Log-Log4perl/lib/Log/Log4perl/Appender.pm	Wed Aug 21 00:52:51 2002
>+++ Log-Log4perl.mike/lib/Log/Log4perl/Appender.pm	Tue Sep  3 22:33:53 2002
>@@ -83,7 +83,7 @@
> 
>     # Check if the appender has a last-minute veto in form
>     # of an "appender threshold"
>-    if($self->{level} < $
>+    if($self->{level} > $
>                         Log::Log4perl::Level::PRIORITY{$level}) {
>         return;
>     }
>diff -Naur Log-Log4perl/lib/Log/Log4perl/Level.pm Log-Log4perl.mike/lib/Log/Log4perl/Level.pm
>--- Log-Log4perl/lib/Log/Log4perl/Level.pm	Tue Sep  3 11:12:17 2002
>+++ Log-Log4perl.mike/lib/Log/Log4perl/Level.pm	Tue Sep  3 23:07:15 2002
>@@ -10,20 +10,18 @@
> no strict qw(refs);
> 
> our %PRIORITY = (
>-    "FATAL" => 0,
>-    "ERROR" => 3,
>-    "WARN"  => 4,
>-    "INFO"  => 6,
>-    "DEBUG" => 7,
>+    "OFF"   => 60000,
>+    "FATAL" => 50000,
>+    "ERROR" => 40000,
>+    "WARN"  => 30000,
>+    "INFO"  => 20000,
>+    "DEBUG" => 10000,
>+    "ON"    => 0,
> ) unless %PRIORITY;
> 
>     # Reverse mapping
> our %LEVELS = map { $PRIORITY{$_} => $_ } keys %PRIORITY;
> 
>-    # Min and max
>-$PRIORITY{'OFF'} = $PRIORITY{'FATAL'};
>-$PRIORITY{'ALL'} = $PRIORITY{'DEBUG'};
>-
> ###########################################
> sub import {
> ###########################################
>@@ -120,8 +118,8 @@
> 
>     foreach (1..$delta){
>         #so the list is DEBUG, INFO, WARN, ERROR, FATAL
>-        foreach my $p (reverse sort keys %LEVELS){
>-            if ($p < $old_priority) {
>+        foreach my $p (sort keys %LEVELS){
>+            if ($p > $old_priority) {
>                 $new_priority = $p;
>                 last;
>             }
>@@ -140,8 +138,8 @@
> 
>     foreach (1..$delta){
>         #so the list is FATAL, ERROR, WARN, INFO, DEBUG
>-        foreach my $p (sort keys %LEVELS){
>-            if ($p > $old_priority) {
>+        foreach my $p (reverse sort keys %LEVELS){
>+            if ($p < $old_priority) {
>                 $new_priority = $p;
>                 last;
>             }
>diff -Naur Log-Log4perl/lib/Log/Log4perl/Logger.pm Log-Log4perl.mike/lib/Log/Log4perl/Logger.pm
>--- Log-Log4perl/lib/Log/Log4perl/Logger.pm	Tue Sep  3 11:13:41 2002
>+++ Log-Log4perl.mike/lib/Log/Log4perl/Logger.pm	Tue Sep  3 22:55:59 2002
>@@ -140,12 +140,12 @@
>     my %priority = %Log::Log4perl::Level::PRIORITY; #convenience and cvs
> 
>     foreach my $levelname (keys %priority){
>-        if ($priority{$levelname} <= $level) {
>-            print "  ($priority{$levelname} <= $level)\n"
>+        if ($priority{$levelname} >= $level) {
>+            print "  ($priority{$levelname} >= $level)\n"
>                   if DEBUG;
>             $self->{$levelname} = $coderef;
>         }else{
>-            print "  ($priority{$levelname} > $level)\n" if DEBUG;
>+            print "  ($priority{$levelname} < $level)\n" if DEBUG;
>             $self->{$levelname} = $noop;
>         }
> 
>@@ -493,7 +493,7 @@
>         \$_[0]->{$level}(\@_, '$level');
>      }
>      
>-     sub is_$lclevel { return \$_[0]->level() >= \$$level; }
>+     sub is_$lclevel { return \$_[0]->level() <= \$$level; }
> EOL
> 
>     eval $code;
>diff -Naur Log-Log4perl/t/001Level.t Log-Log4perl.mike/t/001Level.t
>--- Log-Log4perl/t/001Level.t	Wed Jul  3 14:53:33 2002
>+++ Log-Log4perl.mike/t/001Level.t	Tue Sep  3 22:38:39 2002
>@@ -16,16 +16,16 @@
> ok(1); # If we made it this far, we're ok.
> 
> # Import them into the 'main' namespace;
>-ok($FATAL < $ERROR);
>-ok($ERROR < $INFO);
>-ok($INFO  < $DEBUG);
>+ok($FATAL > $ERROR);
>+ok($ERROR > $INFO);
>+ok($INFO  > $DEBUG);
> 
> # Import them into the 'Level' namespace;
>-ok($Level::FATAL < $Level::ERROR);
>-ok($Level::ERROR < $Level::INFO);
>-ok($Level::INFO  < $Level::DEBUG);
>+ok($Level::FATAL > $Level::ERROR);
>+ok($Level::ERROR > $Level::INFO);
>+ok($Level::INFO  > $Level::DEBUG);
> 
> # Import them into the 'My::Level' namespace;
>-ok($My::Level::FATAL < $My::Level::ERROR);
>-ok($My::Level::ERROR < $My::Level::INFO);
>-ok($My::Level::INFO  < $My::Level::DEBUG);
>+ok($My::Level::FATAL > $My::Level::ERROR);
>+ok($My::Level::ERROR > $My::Level::INFO);
>+ok($My::Level::INFO  > $My::Level::DEBUG);
>diff -Naur Log-Log4perl/t/016Export.t Log-Log4perl.mike/t/016Export.t
>--- Log-Log4perl/t/016Export.t	Sun Aug  4 13:01:40 2002
>+++ Log-Log4perl.mike/t/016Export.t	Tue Sep  3 22:39:30 2002
>@@ -18,10 +18,10 @@
> 
> ok(1);
> 
>-ok($DEBUG > $ERROR);
>-ok($INFO > $WARN);
>-ok($WARN > $ERROR);
>-ok($ERROR > $FATAL);
>+ok($DEBUG < $ERROR);
>+ok($INFO < $WARN);
>+ok($WARN < $ERROR);
>+ok($ERROR < $FATAL);
> 
> ##################################################
> # Init logger
>diff -Naur Log-Log4perl/t/024WarnDieCarp.t Log-Log4perl.mike/t/024WarnDieCarp.t
>--- Log-Log4perl/t/024WarnDieCarp.t	Wed Aug 28 22:33:28 2002
>+++ Log-Log4perl.mike/t/024WarnDieCarp.t	Tue Sep  3 23:00:26 2002
>@@ -90,17 +90,12 @@
> }
> 
> ######################################################################
>-# change logging to OFF... FATALs still produce output though.
>+# change logging to OFF... FATALs don't produce output.
> 
>-$log->level($OFF); # $OFF == $FATAL... although I suspect that's a bug in the log4j spec
>+$log->level($OFF);
> 
> foreach my $f ("logwarn", "logcarp", "logcluck",
>-    "error_warn", "error_die") {
>+    "error_warn", "error_die", "logdie", "logcroak", "logconfess") {
>   warndietest_nooutput(sub {$log->$f(@_)}, "Test $test: $f", "Test $test: $f", $app, "$f");
>-  $test++;
>-}
>-
>-foreach my $f ("logdie", "logcroak", "logconfess") {
>-  warndietest(sub {$log->$f(@_)}, "Test $test: $f", "Test $test: $f", $app, "$f");
>   $test++;
> }
>diff -Naur Log-Log4perl/t/025CustLevels.t Log-Log4perl.mike/t/025CustLevels.t
>--- Log-Log4perl/t/025CustLevels.t	Tue Sep  3 11:09:42 2002
>+++ Log-Log4perl.mike/t/025CustLevels.t	Tue Sep  3 23:03:47 2002
>@@ -12,12 +12,14 @@
> BEGIN {
> package Log::Log4perl::Level;
> our %PRIORITY = (
>-    "FATAL" => 0,
>-    "ERROR" => 3,
>-    "WARN"  => 4,
>-    "LITEWARN"  => 5,
>-    "INFO"  => 6,
>-    "DEBUG" => 7,
>+    "OFF"       => 60000,
>+    "FATAL"     => 50000,
>+    "ERROR"     => 40000,
>+    "WARN"      => 30000,
>+    "LITEWARN"  => 25000,
>+    "INFO"      => 20000,
>+    "DEBUG"     => 10000,
>+    "ON"        => 0,
> );
> }
> 
>  
>

[log4perl-devel] New Levels

[Mike S. <m...@pe...>]

Hey guys,

please find attached a patch for log4j-compatible levels, they're like

our %PRIORITY = (
    "OFF"   => 60000,
    "FATAL" => 50000,
    "ERROR" => 40000,
    "WARN"  => 30000,
    "INFO"  => 20000,
    "DEBUG" => 10000,
    "ON"    => 0,
)

now and I had to change a couple of test cases and code doing actual comparisons (<= etc.) -- can
you please verify before I check it in? Just to make sure I'm not wiping out anything you guys came
up with over labor day ;)


-- Mike
--------------------------------------------------------
Mike Schilli log...@pe... http://perlmeister.com
--------------------------------------------------------

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

[Erik W. S. <er...@se...>]

Kevin Goess wrote:

> I just took a shot at some of these:
>
> 1) inc_level, dec_level: I didn't really like "more_logging", though 
> you could talk me out of it, and we should document which direction 
> "increment" goes.  Boundary conditions are handled, if you call 
> inc_level(999) you just get the highest level in %Level::PRIORITY.

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 --- 
especially when we get into the realm of subclassing and having users 
define their own Levels and inserting them in the order. inc_level and 
dec_level kinda do that, as what we want is inc_level to correspond to 
more logging (as "more" implies "bigger numbers"), but it's gonna get 
messy in the code. more_logging() / less_logging() allow us to abstract 
HOW we do the order, and lets the user do what he or she wants: get more 
or less logigng. :)

Besides, with more_logging and less_logging, we don't need to document 
which way "increment" goes. :)

-e

>
>
> 2) custom error levels: I changed the Logger: sub fatal{..}, sub 
> error{..}, etc. to autogenerated code based on the contents of 
> %Level::PRIORITY.  So the user can generate custom levels if they a 
> BEGIN block before calling 'use Log4perl'
>
>   #create a custom level "LITEWARN"
>   BEGIN {
>   package Log::Log4perl::Level;
>   our %PRIORITY = (
>     "FATAL" => 0,
>     "ERROR" => 3,
>     "WARN"  => 4,
>     "LITEWARN"  => 5,
>     "INFO"  => 6,
>     "DEBUG" => 7,
>   );
>   }
>
> This seems kind of hacky to me (if simple and effective), I sort of 
> feel we should be subclassing Level and doing some stricter OO stuff, 
> though I don't see any particular problems with doing it this way.  If 
> you guys don't like it, I'll back the changes out of CVS.
>
> The caveats are that if the users make sub fatal{..} go away and don't 
> replace it, then they break the logdie() stuff.  And their new level 
> names have to be valid perl subroutine names.
>
> It's all in CVS, see the new unit test 025CustLevels.t .  Any comments?
>
>
> Erik W. Selberg wrote:
>
>>>
>>> > 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?
>>
>>
>>
>>
>> Let's solve the problem with naming:
>>
>> more_logging($levels)
>> less_logging($levels)
>>
>> So, a user never cares whether more_logging(3) sets the constant from 
>> MAXINT to 30,000 or from 0 to 3, just that we're getting getting 
>> three more levels of verbosity than we have right now.
>>
>> I'd also recommend we have something ALA syslog for all us soon-to-be 
>> ex-syslog(3) users:
>>
>> $log->syslog_level($SYSLOG_LEVEL)
>>
>> which does the appropriate mapping, and maps things like NOTIFY to 
>> WARN, as NOTIFY doesn't exist in log4perl land.
>>
>> And, I'd even say we should push these back to the log4j guys, as 
>> they seem pretty useful to me. :)
>>
>> -e
>>
>>
>>
>> -------------------------------------------------------
>> 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
>
>
>

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

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

I just took a shot at some of these:

1) inc_level, dec_level: I didn't really like "more_logging", though you 
could talk me out of it, and we should document which direction 
"increment" goes.  Boundary conditions are handled, if you call 
inc_level(999) you just get the highest level in %Level::PRIORITY.

2) custom error levels: I changed the Logger: sub fatal{..}, sub 
error{..}, etc. to autogenerated code based on the contents of 
%Level::PRIORITY.  So the user can generate custom levels if they a 
BEGIN block before calling 'use Log4perl'

   #create a custom level "LITEWARN"
   BEGIN {
   package Log::Log4perl::Level;
   our %PRIORITY = (
     "FATAL" => 0,
     "ERROR" => 3,
     "WARN"  => 4,
     "LITEWARN"  => 5,
     "INFO"  => 6,
     "DEBUG" => 7,
   );
   }

This seems kind of hacky to me (if simple and effective), I sort of feel 
we should be subclassing Level and doing some stricter OO stuff, though 
I don't see any particular problems with doing it this way.  If you guys 
don't like it, I'll back the changes out of CVS.

The caveats are that if the users make sub fatal{..} go away and don't 
replace it, then they break the logdie() stuff.  And their new level 
names have to be valid perl subroutine names.

It's all in CVS, see the new unit test 025CustLevels.t .  Any comments?


Erik W. Selberg wrote:
>>
>> > 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?
> 
> 
> 
> Let's solve the problem with naming:
> 
> more_logging($levels)
> less_logging($levels)
> 
> So, a user never cares whether more_logging(3) sets the constant from 
> MAXINT to 30,000 or from 0 to 3, just that we're getting getting three 
> more levels of verbosity than we have right now.
> 
> I'd also recommend we have something ALA syslog for all us soon-to-be 
> ex-syslog(3) users:
> 
> $log->syslog_level($SYSLOG_LEVEL)
> 
> which does the appropriate mapping, and maps things like NOTIFY to WARN, 
> as NOTIFY doesn't exist in log4perl land.
> 
> And, I'd even say we should push these back to the log4j guys, as they 
> seem pretty useful to me. :)
> 
> -e
> 
> 
> 
> -------------------------------------------------------
> 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

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

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

 > so if you guys are ok with it, I'm gonna take care of it.

Rock on, dude!


Msc...@ao... wrote:
> In a message dated 8/29/02 9:58:43 AM Pacific Daylight Time, 
> ke...@go... writes:
> 
> 
>> If A. Programmer has turned logging OFF, Log4perl should spew no
>> messages, including FATAL messages. 
> 
> 
> 
> Just rummaged through the log4j code and this is what I found:
> 
>  public final static int OFF_INT = Integer.MAX_VALUE;
>  public final static int FATAL_INT = 50000;
>  public final static int ERROR_INT = 40000;
>  public final static int WARN_INT  = 30000;
>  public final static int INFO_INT  = 20000;
>  public final static int DEBUG_INT = 10000;
>    //public final static int FINE_INT = DEBUG_INT;
>  public final static int ALL_INT = Integer.MIN_VALUE;
> 
> So according to this, OFF will indeed turn off FATAL, which makes sense. 
> I took my mappings from the syslog equivalents (also defined in log4j), 
> which is probably wrong. We should be able to restructure the integer 
> values behind the scenes without breaking anything, so if you guys are 
> ok with it, I'm gonna take care of it.
> 
> -- Mike
> 
> Mike Schilli
> log...@pe...
> http://perlmeister.com
> http://log4perl.sourceforge.net


-- 
Happy Trails . . .

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

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

[Erik W. S. <er...@se...>]

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


Let's solve the problem with naming:

more_logging($levels)
less_logging($levels)

So, a user never cares whether more_logging(3) sets the constant from 
MAXINT to 30,000 or from 0 to 3, just that we're getting getting three 
more levels of verbosity than we have right now.

I'd also recommend we have something ALA syslog for all us soon-to-be 
ex-syslog(3) users:

$log->syslog_level($SYSLOG_LEVEL)

which does the appropriate mapping, and maps things like NOTIFY to WARN, 
as NOTIFY doesn't exist in log4perl land.

And, I'd even say we should push these back to the log4j guys, as they 
seem pretty useful to me. :)

-e

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

[Erik W. S. <er...@se...>]

This is kinda moot now, but I wanted to weight in as the meta-point is a 
good one.

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

So I agree with all, but I don't think the point on (c) has the proper 
scope. We certainly want to have the benefit of all the brain sweat. 
However, if / when we find design issues and whatnot, the beauty of open 
source is that we can contribute our brain sweat back. Case in point, 
say they really had defined OFF as FATAL and ALL as DEBUG. I'd like to 
say that we'd want to fix that brokenness and give back to them and 
explain why (as it may well work in a Java world, but break horribly in 
others, and thus should be fixed to work in all worlds).

> 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?
>
Here's what my advisor would say:

That's equivalent to saying: "So if log4j has a bug that crashes the 
entire system, I think we should do the same thing, even if we think 
it's wrong, just because it's the *same*."

In general, I agree that if Log4j does things a certain way and there's 
a reason for that certain way, then we should follow that way. Format of 
the config file, for example. However, if and when we find something 
that just doesn't make sense, we should talk to the Log4j folks, figure 
out if it does, and then do the right thing --- which, if it differs 
from Log4j, is fine, we just give them the option of fixing it as well.

At least, that's my $0.02. :)

-e

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

[Erik W. S. <er...@se...>]

A-HA! Now I think I get what they did. Not fully broken. Just standard 
Java code of far too much abstraction while embedding constants every 
now and then. :)

The Priority Class has a built-in notion of syslog equivalent. This, 
Level.ERROR, which is a Level Class (and extends Priority), has an 
attribute of syslogEquivalent which in this case is 3. I didn't properly 
read the constructors, as I saw things like:

final static public Priority ERROR = new Level(ERROR_INT, "ERROR", 3);

and assumed that 3 was the constant they used, not ERROR_INT, which is 
40,000. Their toLevel(int) also expects one of the integer constants, 
like ERROR_INT == 40000.

So, I'd say we should:
(a) adjust our constants to match, and
(b) implement something like what I want so I can just inc up some 
levels and not care that WARN is 10,000 more than ERROR.

-e

Msc...@ao... wrote:

> In a message dated 8/29/02 9:58:43 AM Pacific Daylight Time, 
> ke...@go... writes:
>
>
>> If A. Programmer has turned logging OFF, Log4perl should spew no
>> messages, including FATAL messages. 
>
>
>
> Just rummaged through the log4j code and this is what I found:
>
>  public final static int OFF_INT = Integer.MAX_VALUE;
>  public final static int FATAL_INT = 50000;
>  public final static int ERROR_INT = 40000;
>  public final static int WARN_INT  = 30000;
>  public final static int INFO_INT  = 20000;
>  public final static int DEBUG_INT = 10000;
>    //public final static int FINE_INT = DEBUG_INT;
>  public final static int ALL_INT = Integer.MIN_VALUE;
>
> So according to this, OFF will indeed turn off FATAL, which makes 
> sense. I took my mappings from the syslog equivalents (also defined in 
> log4j), which is probably wrong. We should be able to restructure the 
> integer values behind the scenes without breaking anything, so if you 
> guys are ok with it, I'm gonna take care of it.
>
> -- Mike
>
> Mike Schilli
> log...@pe...
> http://perlmeister.com
> http://log4perl.sourceforge.net

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

[<Msc...@ao...>]

In a message dated 8/30/02 4:45:04 PM Pacific Daylight Time, ke...@go... 
writes:


> One of *my* goals in starting this project was to emulate log4j behavior 
> as closely as possible

Yep, 100% agreed.

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

Agreed, but I don't think it does, so I think we just need to redefine the 
constants behind the scenes, so that we can implement the inc_level/dec_level 
methods of the Level (!) class as proposed by Erik. These constants should be 
invisible to the Log::Log4perl user, of course. 

I also don't like introducing non-log4j-compatible levels, if we want that, 
we should provide user-defined Level classes just like log4j does. 
inc_level/dec_level would have to cope with those. I personally haven't felt 
a need for more levels (yet), but hey, if log4j provides it, why not. But 
again, we want to be compliant with log4j, for all the reasons Kevin 
mentioned earlier.

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net

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

[<Msc...@ao...>]

In a message dated 8/29/02 9:58:43 AM Pacific Daylight Time, ke...@go... 
writes:


> If A. Programmer has turned logging OFF, Log4perl should spew no
> 

Just rummaged through the log4j code and this is what I found:

  public final static int OFF_INT = Integer.MAX_VALUE;
  public final static int FATAL_INT = 50000;
  public final static int ERROR_INT = 40000;
  public final static int WARN_INT  = 30000;
  public final static int INFO_INT  = 20000;
  public final static int DEBUG_INT = 10000;
    //public final static int FINE_INT = DEBUG_INT;
  public final static int ALL_INT = Integer.MIN_VALUE;

So according to this, OFF will indeed turn off FATAL, which makes sense. I 
took my mappings from the syslog equivalents (also defined in log4j), which 
is probably wrong. We should be able to restructure the integer values behind 
the scenes without breaking anything, so if you guys are ok with it, I'm 
gonna take care of it.

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net

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

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

 > 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

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

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

 > 1) To an extent, the cat's out of the bag. Log4j makes the (constant)
 > integer representations of the above public, which means it's a BIG DEAL
 > (tm) to change ERROR => 3 to say ERROR => 1, and has a toLevel() method
 > which takes an int. We've done the same with Log4perl.

The whole point of exporting constants is that if the users always use 
your exported constants, you can export different ones tomorrow and 
they're never the wiser.  If they start using their own ints then it's 
their funeral.  That's why you say
	flock(FH, LOCK_EX);
instead of just
	flock(FH, 7)
or whatever the actual value might be today on your platform.

 > lets us play fast & loose with numbers, we could just create something
 > like "MOREINFO" with a value of 6.5 and $logger->log(6.5, "You want it,
 > you got it") would work.

Yeah, but it's no fun unless $logger->moreinfo(..) works!




Erik W. Selberg wrote:
> Kevin Goess wrote:
> 
>> 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.
>>  
>>
> So, thinking some more on this...
> 
> 1) To an extent, the cat's out of the bag. Log4j makes the (constant) 
> integer representations of the above public, which means it's a BIG DEAL 
> (tm) to change ERROR => 3 to say ERROR => 1, and has a toLevel() method 
> which takes an int. We've done the same with Log4perl. So I'm not 
> convinced we need to move towards hiding the fact that levels are just 
> ints, and just give people a total order on a quasi-enumerated type.
> 
> 2) It seems that it'd be super straightforward to add some code to 
> Level.pm to enable the insertion of a Level whereever --- and since Perl 
> lets us play fast & loose with numbers, we could just create something 
> like "MOREINFO" with a value of 6.5 and $logger->log(6.5, "You want it, 
> you got it") would work. Although I'm pretty sure that this would have 
> to be done within a Perl program --- not clear if an external config 
> would work though.
> 
> Thoughts?
> -e
> 
> 
> 
> -------------------------------------------------------
> 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

Re: [log4perl-devel] Bug while using Log::Dispatch::File

[<Msc...@ao...>]

In a message dated 8/30/02 11:05:32 AM Pacific Daylight Time, 
er...@se... writes:


> Could you have a \r in the log format? Without a \n after, it will cause 
> the current line to be overwritten (or to appear overwritten when 
> displayed in things like less and more).
> 

Actually, what I'm seeing is that it jumps back about 10 lines -- so it can't 
be \r. Once I got a simple test case, it should be easier to tackle.

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net

Re: [log4perl-devel] Bug while using Log::Dispatch::File

[Erik W. S. <er...@se...>]

Could you have a \r in the log format? Without a \n after, it will cause 
the current line to be overwritten (or to appear overwritten when 
displayed in things like less and more).

-e


Msc...@ao... wrote:

> Hi Kevin and Dave,
>
> there seems to be a weird bug with Log::Log4perl and 
> Log::Dispatch::File. The application I'm using it with produces a lot 
> of multi-line DEBUG messages and in certain circumstances this will 
> overwrite (!) previously written (!) sections of the log file.
> Looks like the file handle gets confused and suddenly jumps back.
> Using Log::Dispatch::Screen instead doesn't show the problem.
> Dave, is there any limitations to Log::Dispatch::File you can think of?
>
> My suspicion is that this is caused by our closures holding references 
> to the Log::Dispatch::File object(s) which is/are using a "local"ized 
> filehandle instead of a $fh scalar variable (open my $fh, ">blah") to 
> keep track of the opened file.
>
> I don't have an easy-to-reproduce test case yet, just to give you guys 
> a heads-up and maybe you already know where to look for?
>
> -- Mike
>
> Mike Schilli
> log...@pe...
> http://perlmeister.com
> http://log4perl.sourceforge.net

[log4perl-devel] Re: Bug while using Log::Dispatch::File

[Dave R. <au...@ur...>]

On Fri, 30 Aug 2002 Msc...@ao... wrote:

> Using Log::Dispatch::Screen instead doesn't show the problem.
> Dave, is there any limitations to Log::Dispatch::File you can think of?

Not that I know of.  This is the first I've heard of such a problem.

> My suspicion is that this is caused by our closures holding references to the
> Log::Dispatch::File object(s) which is/are using a "local"ized filehandle
> instead of a $fh scalar variable (open my $fh, ">blah") to keep track of the
> opened file.

Actually, the filehandle in Log::Dispatch::File is lexical.  The 'local'
bit in the code is just a Perl trick to get a filehandle into a scalar in
Perl 5.005 and earlier.

I can't imagine why closures would be a problem.

> I don't have an easy-to-reproduce test case yet, just to give you guys a
> heads-up and maybe you already know where to look for?

Without a test case I'm at a loss.  Log::Dispatch::File is barely 100
lines of code.  Not that I can't manage to fit a few bugs in there, but it
really is simple stuff so I don't see how this could be happening.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

[log4perl-devel] Bug while using Log::Dispatch::File

[<Msc...@ao...>]

Hi Kevin and Dave,

there seems to be a weird bug with Log::Log4perl and Log::Dispatch::File. The 
application I'm using it with produces a lot of multi-line DEBUG messages and 
in certain circumstances this will overwrite (!) previously written (!) 
sections of the log file.
Looks like the file handle gets confused and suddenly jumps back. 
Using Log::Dispatch::Screen instead doesn't show the problem. 
Dave, is there any limitations to Log::Dispatch::File you can think of?

My suspicion is that this is caused by our closures holding references to the 
Log::Dispatch::File object(s) which is/are using a "local"ized filehandle 
instead of a $fh scalar variable (open my $fh, ">blah") to keep track of the 
opened file.

I don't have an easy-to-reproduce test case yet, just to give you guys a 
heads-up and maybe you already know where to look for? 

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net

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

[Erik W. S. <er...@se...>]

Kevin Goess wrote:

>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. 
>
>  
>
So, thinking some more on this...

1) To an extent, the cat's out of the bag. Log4j makes the (constant) 
integer representations of the above public, which means it's a BIG DEAL 
(tm) to change ERROR => 3 to say ERROR => 1, and has a toLevel() method 
which takes an int. We've done the same with Log4perl. So I'm not 
convinced we need to move towards hiding the fact that levels are just 
ints, and just give people a total order on a quasi-enumerated type.

2) It seems that it'd be super straightforward to add some code to 
Level.pm to enable the insertion of a Level whereever --- and since Perl 
lets us play fast & loose with numbers, we could just create something 
like "MOREINFO" with a value of 6.5 and $logger->log(6.5, "You want it, 
you got it") would work. Although I'm pretty sure that this would have 
to be done within a Perl program --- not clear if an external config 
would work though.

Thoughts?
-e

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

[Erik W. S. <er...@se...>]

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

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

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

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. 

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.

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

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

[Erik W. S. <er...@se...>]

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

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

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

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

-- 
Happy Trails . . .

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

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

[<msc...@ao...>]

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

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

[Erik S. <er...@se...>]

Here ya go.

>>I also noticed that there's no turning off FATAL logging.
>>    
>>
>
>That's probably not intended, I think "OFF" should be higher prio than FATAL and therefore suppress it. Kevin, what do you think?
>

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.

Thoughts?

-e

>  
>
>  
>