Menu
▾
▴
log4perl-devel — Ongoing log4perl development
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(38) |
Sep
(126) |
Oct
(23) |
Nov
(72) |
Dec
(36) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(76) |
Feb
(32) |
Mar
(19) |
Apr
(6) |
May
(54) |
Jun
(40) |
Jul
(45) |
Aug
(35) |
Sep
(51) |
Oct
(67) |
Nov
(10) |
Dec
(50) |
| 2004 |
Jan
(51) |
Feb
(22) |
Mar
(22) |
Apr
(28) |
May
(53) |
Jun
(99) |
Jul
(38) |
Aug
(49) |
Sep
(23) |
Oct
(29) |
Nov
(30) |
Dec
(48) |
| 2005 |
Jan
(15) |
Feb
(21) |
Mar
(25) |
Apr
(16) |
May
(131) |
Jun
|
Jul
(8) |
Aug
(5) |
Sep
(15) |
Oct
|
Nov
(15) |
Dec
(12) |
| 2006 |
Jan
(15) |
Feb
(20) |
Mar
(8) |
Apr
(10) |
May
(3) |
Jun
(16) |
Jul
(15) |
Aug
(11) |
Sep
(17) |
Oct
(27) |
Nov
(11) |
Dec
(12) |
| 2007 |
Jan
(19) |
Feb
(18) |
Mar
(33) |
Apr
(4) |
May
(15) |
Jun
(22) |
Jul
(19) |
Aug
(20) |
Sep
(14) |
Oct
(4) |
Nov
(34) |
Dec
(11) |
| 2008 |
Jan
(8) |
Feb
(18) |
Mar
(2) |
Apr
(4) |
May
(26) |
Jun
(9) |
Jul
(8) |
Aug
(8) |
Sep
(3) |
Oct
(17) |
Nov
(14) |
Dec
(4) |
| 2009 |
Jan
(6) |
Feb
(41) |
Mar
(21) |
Apr
(10) |
May
(21) |
Jun
|
Jul
(8) |
Aug
(4) |
Sep
(3) |
Oct
(8) |
Nov
(6) |
Dec
(5) |
| 2010 |
Jan
(14) |
Feb
(13) |
Mar
(7) |
Apr
(12) |
May
(4) |
Jun
(1) |
Jul
(11) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(10) |
Dec
|
| 2011 |
Jan
(7) |
Feb
(3) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(1) |
Jul
(6) |
Aug
(6) |
Sep
(10) |
Oct
(5) |
Nov
(4) |
Dec
(5) |
| 2012 |
Jan
(4) |
Feb
(5) |
Mar
(1) |
Apr
(7) |
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
(5) |
Oct
(5) |
Nov
(4) |
Dec
(5) |
| 2013 |
Jan
(6) |
Feb
|
Mar
(14) |
Apr
(9) |
May
(3) |
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(4) |
Dec
(6) |
| 2014 |
Jan
|
Feb
(1) |
Mar
(10) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: <msc...@ao...> - 2002-09-14 18:51:41
|
In a message dated Fri, 13 Sep 2002 10:55:12 AM Eastern Standard Time, ke...@go... writes: >The attached should take care of it, don't you think? I've just applied your patch, added documentation and test cases, and released 0.23beta3. -- Mike ############################ # Mike Schilli # # log...@pe... # # http://perlmeister.com # # log4perl.sourceforge.net # ############################ |
|
From: <Msc...@ao...> - 2002-09-13 17:18:38
|
In a message dated 9/13/02 8:56:19 AM Pacific Daylight Time, ke...@go... writes: > The attached should take care of it, don't you think? > Looks great! Wanna check it in with a note in the docs and maybe a test case? I can take care of it also, just let me know. BTW how's 0.23 looking? I've renamed it "beta2" on the site, with the latest check-ins (Kevin, did you CVS-checkin you latest "watch" fix?) we could release "beta3", have everybody run checks and then release 0.23 to CPAN. -- Mike Mike Schilli log...@pe... http://perlmeister.com http://log4perl.sourceforge.net -- Mike Mike Schilli log...@pe... http://perlmeister.com http://log4perl.sourceforge.net |
|
From: Kevin G. <ke...@go...> - 2002-09-13 15:55:25
|
log4j defaults to append, Log::Dispatch defaults to truncate. I agree, the log4j behavior is more desirable. The attached should take care of it, don't you think? The JavaMap::FileAppender was already defaulting to append, but there was some nonsense in the conditional, so I fixed it. Erik W. Selberg wrote: > I'd say yes, even if it was contrary to log4j. I hate loggers that > automatically nuke the previous log... 'cuz usually that's the one I > want. :) > > -e > > Msc...@ao... wrote: > >> Hey guys, >> >> I keep running into the same issue that Log::Dispatch::File by default >> overwrites an existing log file, because I forget to explicitly tell >> my configuration to append: >> >> Log4perl.logger = WARN, File >> Log4perl.appender.File= Log::Dispatch::File >> Log4perl.appender.File.layout=Log::Log4perl::Layout::SimpleLayout >> Log4perl.appender.File.filename=/blah/blah >> >> Wouldn't it be smarter to assume "append" as default? Does anybody >> have an idea on how we could make "append" the default choice with a >> minimum of code mess? >> >> -- Mike >> >> Mike Schilli >> log...@pe... >> http://perlmeister.com >> http://log4perl.sourceforge.net > > > > > > > > ------------------------------------------------------- > 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-09-13 09:00:52
|
I'd say yes, even if it was contrary to log4j. I hate loggers that automatically nuke the previous log... 'cuz usually that's the one I want. :) -e Msc...@ao... wrote: > Hey guys, > > I keep running into the same issue that Log::Dispatch::File by default > overwrites an existing log file, because I forget to explicitly tell > my configuration to append: > > Log4perl.logger = WARN, File > Log4perl.appender.File= Log::Dispatch::File > Log4perl.appender.File.layout=Log::Log4perl::Layout::SimpleLayout > Log4perl.appender.File.filename=/blah/blah > > Wouldn't it be smarter to assume "append" as default? Does anybody > have an idea on how we could make "append" the default choice with a > minimum of code mess? > > -- Mike > > Mike Schilli > log...@pe... > http://perlmeister.com > http://log4perl.sourceforge.net |
|
From: <Msc...@ao...> - 2002-09-13 04:18:11
|
Hey guys,
I keep running into the same issue that Log::Dispatch::File by default
overwrites an existing log file, because I forget to explicitly tell my
configuration to append:
Log4perl.logger = WARN, File
Log4perl.appender.File= Log::Dispatch::File
Log4perl.appender.File.layout=Log::Log4perl::Layout::SimpleLayout
Log4perl.appender.File.filename=/blah/blah
Wouldn't it be smarter to assume "append" as default? Does anybody have an
idea on how we could make "append" the default choice with a minimum of code
mess?
-- Mike
Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net
|
|
From: <msc...@ao...> - 2002-09-12 06:40:13
|
In a message dated Thu, 12 Sep 2002 12:51:03 AM Eastern Standard Time, er...@se... writes: >Now, hurry, please and apply this patch: >http://www.selberg.org/Log-Log4perl/morelogging.patch Glad you found this one, that's major doo-doo :). Patch applied, I've put 0.23beta2 on the website. -- Mike ############################ # Mike Schilli # # log...@pe... # # http://perlmeister.com # # log4perl.sourceforge.net # ############################ |
|
From: Erik W. S. <er...@se...> - 2002-09-12 05:49:31
|
Sweet! Now, hurry, please and apply this patch: http://www.selberg.org/Log-Log4perl/morelogging.patch moron that I am (a) didn't include any test cases, (b) didn't use the proper object calling method, and (c) reversed the order, so more was less and less was more. :) Thanks, -e Msc...@ao... wrote: > Hey folks, > > the Log4perl tutorial I wrote is on www.perl.com, check it out: > > http://www.perl.com > > and > > http://www.perl.com/pub/a/2002/09/11/log4perl.html > > -- Mike > > Mike Schilli > log...@pe... > http://perlmeister.com > http://log4perl.sourceforge.net |
|
From: <Msc...@ao...> - 2002-09-12 05:17:40
|
In a message dated 9/12/02 2:05:36 AM W. Europe Daylight Time, ke...@go... writes: > Shall we go with this?: > Perfect! -- Mike log...@pe... http://perlmeister.com |
|
From: <Msc...@ao...> - 2002-09-12 00:48:14
|
Hey folks, the Log4perl tutorial I wrote is on www.perl.com, check it out: http://www.perl.com and http://www.perl.com/pub/a/2002/09/11/log4perl.html -- Mike Mike Schilli log...@pe... http://perlmeister.com http://log4perl.sourceforge.net |
|
From: Kevin G. <ke...@go...> - 2002-09-12 00:05:23
|
Damn! Well at least I could tell when I needed the code review. I had
looked at that routine so much it looks like Chinese to me. And I
couldn't think of a decent way to test or describe the boundary
conditions. Shall we go with this?:
print "exe_watch_code:\n" if DEBUG;
#more closures here
if ( ($LAST_CHECKED_AT + $WATCH_DELAY) < time()){
$LAST_CHECKED_AT = time();
if ($LAST_CHANGED_AT < (stat($FILE_TO_WATCH))[9] ){
$LAST_CHANGED_AT = (stat(_))[9];
print " Config file has been modified\n" if DEBUG;
#these are now handled by the call to reset() in _init()
#%APPENDER_BY_NAME = ();
#$DISPATCHER = Log::Dispatch->new();
Log::Log4perl->init_and_watch($FILE_TO_WATCH, $WATCH_DELAY);
my $methodname = lc($level);
$logger->$methodname($message); # send the message
# to the new configuration
}
return;
}
Msc...@ao... wrote:
> In a message dated 9/11/02 10:00:20 AM Pacific Daylight Time,
> ke...@go... writes:
>
>
>> if ( (($LAST_CHECKED_AT + $WATCH_DELAY) < time()){
>
>
> Yup, and also you need to update LAST_CHANGED_AT (in addition to
> LAST_CHECKED_AT) inside the if-body ...
>
> -- 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-09-11 23:14:21
|
In a message dated 9/11/02 10:00:20 AM Pacific Daylight Time, ke...@go...
writes:
> if ( (($LAST_CHECKED_AT + $WATCH_DELAY) < time()){
>
Yup, and also you need to update LAST_CHANGED_AT (in addition to
LAST_CHECKED_AT) inside the if-body ...
-- Mike
Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net
|
|
From: Kevin G. <ke...@go...> - 2002-09-11 16:59:25
|
Doh! So it should really be this:
if ( (($LAST_CHECKED_AT + $WATCH_DELAY) < time()){
$LAST_CHECKED_AT = time();
if ($LAST_CHANGED_AT < (stat($FILE_TO_WATCH))[9] ){
print " Config file has been modified\n" if DEBUG;
#these are now handled by the call to reset() in _init()
#%APPENDER_BY_NAME = ();
#$DISPATCHER = Log::Dispatch->new();
Log::Log4perl->init_and_watch($FILE_TO_WATCH, $WATCH_DELAY);
my $methodname = lc($level);
$logger->$methodname($message); # send the message
# to the new configuration
}
return;
}
Msc...@ao... wrote:
> In a message dated 9/11/02 1:43:58 AM W. Europe Daylight Time,
> ke...@go... writes:
>
>
>> $LAST_CHECKED_AT is being reset, but only when the file is actually
>> checked.
>
>
>
> Let's assume that the file never changes. At first, you're gonna wait
> $WATCH_DELAY seconds. Once that is over, you're going to run the check, but
>
> $LAST_CHANGED_AT < (stat($FILE_TO_WATCH))[9]
>
> evaluates to false, the if-body isn't executed, $LAST_CHECKED_AT not
> being reset. And with the next (and all of the following) calls, you're
> gonna run stat() again, right?
>
> -- Mike
>
> Mike Schilli
> log...@pe...
> http://perlmeister.com
--
Happy Trails . . .
Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA 94706
(510) 525-5217
|
|
From: <Msc...@ao...> - 2002-09-11 00:57:39
|
In a message dated 9/11/02 1:43:58 AM W. Europe Daylight Time,
ke...@go... writes:
> $LAST_CHECKED_AT is being reset, but only when the file is actually
> checked.
Let's assume that the file never changes. At first, you're gonna wait
$WATCH_DELAY seconds. Once that is over, you're going to run the check, but
$LAST_CHANGED_AT < (stat($FILE_TO_WATCH))[9]
evaluates to false, the if-body isn't executed, $LAST_CHECKED_AT not being
reset. And with the next (and all of the following) calls, you're gonna run
stat() again, right?
-- Mike
Mike Schilli
log...@pe...
http://perlmeister.com
|
|
From: Kevin G. <ke...@go...> - 2002-09-10 23:53:18
|
Here's another one I could use your opinions on. I've been working for two days on a DBI appender, and I'm not sure I'm completely happy with it. It requires subclassing to change much of the behavior (but then so does JDBCAppender as well as Log::Dispatch::DBI). If you subclass then you can apply PatternFormats to the column values, but I'm not sure that's an efficient way to do it. Following Log::Dispatch::DBI, it creates an $sth at the beginnng and just continues to use it, which is good for efficiency but might cause problems in long-running programs (mod_perl). It holds one connection open for each appender, which might be too many (or might not?) It doesn't follow log4j's JDBCAppender very closely, but then the java docs say that's going to change soon anyway. Do you guys have any thoughts on it? Do you think it's good enough to release, or does somebody think they can do better? Attached are two files and a patch. DBI.pm goes in lib/Log/Log4perl/Appenders/DBI.pm. -- 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 23:43:55
|
$LAST_CHECKED_AT is being reset, but only when the file is actually checked. Before, $LAST_CHECKED_AT was being reset even if the file hadn't been checked, hence the bug--if the routine was called more often than $WATCH_DELAY then the file would never be checked! Msc...@ao... wrote: > In a message dated 9/9/02 7:52:16 PM W. Europe Daylight Time, > ke...@go... writes: > > >> I just found a heinous bug in the watch code, if the logger was called >> *more* often than the wait interval than the config would never be >> reloaded. > > > > Not 100% sure, but with $LAST_CHECKED_AT not being reset, aren't you > running the stat() every time this function is being called now? > > -- Mike > > Mike Schilli > m...@pe... > http://perlmeister.com -- Happy Trails . . . Kevin M. Goess (and Anne and Frank) 904 Carmel Ave. Albany, CA 94706 (510) 525-5217 |
|
From: <Msc...@ao...> - 2002-09-10 19:12:03
|
In a message dated 9/9/02 7:52:16 PM W. Europe Daylight Time, ke...@go... writes: > I just found a heinous bug in the watch code, if the logger was called > *more* often than the wait interval than the config would never be > reloaded. > Not 100% sure, but with $LAST_CHECKED_AT not being reset, aren't you running the stat() every time this function is being called now? -- Mike Mike Schilli m...@pe... http://perlmeister.com |
|
From: Erik W. S. <er...@se...> - 2002-09-10 17:03:01
|
I have some $Id: $'s floating about somewhere. For my own $0.02, I'd
prefer we just use ${Log:: ...} and keep 'em versus turning off that in
CVS... as when somebody checks out our code and puts it into their own
CVS repository, they'll clobber it and never know why.
-e
Kevin Goess wrote:
>
>> * Had to change $Log::... to ${Log::...} somewhere because stupid CVS
>> would expand that to what $Log$ is used for :).
>
>
> I just ran 'cvs admin -ko' on our repository, that turns of the cvs
> keyword substitution on all the files (we're not using $Revision$ or
> anything anywhere, right?) so we shouldn't have this problem any more.
>
>
> avoiding keyword substitution
> http://www.loria.fr/~molli/cvs/doc/cvs_12.html#SEC95
>
> cvs admin:
> http://www.loria.fr/~molli/cvs/doc/cvs_16.html#SEC113
>
>
> I tested it on a fresh checkout and it seems to work fine. Let me
> know if any problems.
>
>
>
>
|
|
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
|
|
From: Kevin G. <ke...@go...> - 2002-09-10 15:52:28
|
msc...@ao... wrote: > Hey guys, > > Could you guys please verify it's ok before it's going to CPAN? We need to apply that patch to fix the timing bug first, it's a heinous bug. I'm pretty sure it's ok, but if somebody could eyeball the timing logic (after the patch) in Logger::generate_watch_code() I'd feel better. -- 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 15:50:21
|
> * Had to change $Log::... to ${Log::...} somewhere because stupid CVS would expand that to what $Log$ is used for :).
I just ran 'cvs admin -ko' on our repository, that turns of the cvs
keyword substitution on all the files (we're not using $Revision$ or
anything anywhere, right?) so we shouldn't have this problem any more.
avoiding keyword substitution
http://www.loria.fr/~molli/cvs/doc/cvs_12.html#SEC95
cvs admin:
http://www.loria.fr/~molli/cvs/doc/cvs_16.html#SEC113
I tested it on a fresh checkout and it seems to work fine. Let me know
if any problems.
--
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 15:33:53
|
msc...@ao... wrote: > In a message dated Mon, 9 Sep 2002 5:27:21 PM Eastern Standard Time, ke...@go... writes: > > >>I just found and fixed a bug where if a category/appender was deleted > > > Cool -- was this the same one you posted a patch for earlier or is this a different issue? This is a different issue, the other one is still an outstanding bug, if somebody could put another pair of eyes to the timing issues in that subroutine (Logger::generate_watch_code()) I'd really appreciate it. > > -- Mike > > ############################ > # Mike Schilli # > # log...@pe... # > # http://perlmeister.com # > # 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-09-10 08:32:29
|
Hey guys,
Erik's changes are in (with a couple of minor modifications, see below) and I've released 0.23 on the website. Documentation and Changes are also updated. Could you guys please verify it's ok before it's going to CPAN?
Here's the stuff I changed from Erik's patch, Erik please let me know if you're ok with it, we can still change it:
* Added a couple of test cases to t/001Level.t
* I moved your excellent documentation on custom levels and inc/decrementing further down to the "Cool Tricks" section -- log4j harshly depreciates custom levels and therefore we shouldn't point the user to it until the "categories" section explains more standard ways to control the amount
of logging.
* Had to change $Log::... to ${Log::...} somewhere because stupid CVS would expand that to what $Log$ is used for :).
--
-- Mike
############################
# Mike Schilli #
# log...@pe... #
# http://perlmeister.com #
# log4perl.sourceforge.net #
############################
|
|
From: <msc...@ao...> - 2002-09-10 06:36:35
|
In a message dated Mon, 9 Sep 2002 5:27:21 PM Eastern Standard Time, ke...@go... writes: >I just found and fixed a bug where if a category/appender was deleted Cool -- was this the same one you posted a patch for earlier or is this a different issue? -- Mike ############################ # Mike Schilli # # log...@pe... # # http://perlmeister.com # # log4perl.sourceforge.net # ############################ |
|
From: Kevin G. <ke...@go...> - 2002-09-09 22:27:27
|
I just found and fixed a bug where if a category/appender was deleted from the config file and then reloaded it would continue with its old behavior. Test case confirming the bug and the fix is 027-Watch2.t. -- Happy Trails . . . Kevin M. Goess (and Anne and Frank) 904 Carmel Ave. Albany, CA 94706 (510) 525-5217 |
|
From: <Msc...@ao...> - 2002-09-09 21:46:00
|
In a message dated 9/9/02 12:22:39 PM Pacific Daylight Time, ke...@go...
writes:
> Sorry, Hugh, we haven't implemented anything comparable to
>
... but we *do* have appender thresholds. Couldn't you use those instead?
Something like this
log4perl.appender.Screen=Log::Dispatch::Screen
log4perl.appender.Screen.stderr=0
log4perl.appender.Screen.Threshold=FATAL
log4perl.appender.Screen.layout=Log::Log4perl::Layout::SimpleLayout
will limit messages logged by the appender to FATAL ones. Everything else
(caused by lower-prio messages bubbling up the hierarchy) will be suppressed
at the appender level.
-- Mike
Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net
|
139 messages has been excluded from this view by a project administrator.
