Menu
▾
▴
log4perl-devel
|
From: <msc...@ao...> - 2002-08-28 04:14:18
|
In a message dated Tue, 27 Aug 2002 2:47:57 AM Eastern Standard Time, er...@se... writes:
>Here ya go.
Hmm, this doesn't work. Could you do me a favor and run a
diff -Naur Log-Log4perl Log-Log4perl.erik
and resend the patch? This way I can apply it easily with "patch". Also, including the test case into the patch file would save me some work. Sorry for the inconvenience :)
>
>Also made a new patch file, as the tests caught a bug (woot!).
Nice, that's what test suites are for :)
>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?
-- Mike
Mike Schilli
log...@pe...
|
|
From: <msc...@ao...> - 2002-08-29 05:51:30
|
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...
|
|
From: Kevin G. <ke...@go...> - 2002-08-29 16:58:40
|
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
|
|
From: Erik W. S. <er...@se...> - 2002-08-29 17:30:29
|
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
>>
>>
>
>
>
|
|
From: Kevin G. <ke...@go...> - 2002-08-29 18:05:39
|
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
|
|
From: Erik W. S. <er...@se...> - 2002-08-30 02:57:44
|
> 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 >> >> > > > |
|
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 |
|
From: Erik W. S. <er...@se...> - 2002-08-31 06:56:17
|
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 |
|
From: Erik W. S. <er...@se...> - 2002-08-31 07:04:24
|
> > > 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 |
|
From: Kevin G. <ke...@go...> - 2002-09-03 18:22:44
|
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
|
|
From: Erik W. S. <er...@se...> - 2002-09-04 02:49:26
|
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
>
>
>
|
|
From: Erik W. S. <er...@se...> - 2002-08-30 03:25:53
|
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 |
|
From: Kevin G. <ke...@go...> - 2002-08-30 23:26:54
|
> 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 |
|
From: <Msc...@ao...> - 2002-08-31 00:25:03
|
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
|
|
From: Erik W. S. <er...@se...> - 2002-08-31 06:42:12
|
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 |
|
From: Kevin G. <ke...@go...> - 2002-09-03 16:31:21
|
> 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 |
|
From: <Msc...@ao...> - 2002-08-31 00:39:27
|
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 |
|
From: <msc...@ao...> - 2002-09-05 06:58:14
|
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 |
|
From: Erik W. S. <er...@se...> - 2002-09-05 07:02:11
|
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 > > > |
|
From: Kevin G. <ke...@go...> - 2002-09-05 16:21:06
|
Jeez, don't you guys sleep? 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. 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 |
|
From: Erik W. S. <er...@se...> - 2002-09-06 03:01:57
|
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
>
>
>
|
|
From: Kevin G. <ke...@go...> - 2002-09-06 17:17:25
Attachments:
test.pl
|
> 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
|
|
From: Erik W. S. <er...@se...> - 2002-09-07 10:24:07
|
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!!!');
>
>
>
>
>
|
|
From: Kevin G. <ke...@go...> - 2002-09-08 03:58:27
|
> 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
|
|
From: Kevin G. <ke...@go...> - 2002-09-10 16:01:21
|
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X