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: Jim C. <jc...@di...> - 2003-08-11 10:59:08
|
Mike Schilli wrote:
> Hey all,
>
> "kid on grok" (think that's J.C.) suggested to rename l4p's internal
> debug constants from DEBUG to _INTERNAL_DEBUG to avoid confusion with
> the function DEBUG() or the constant $DEBUG. Checked in.
>
> --
> -- Mike
> Mike Schilli
Mike,
I went ahead and did this on my tree:
find . -exec perl -pi.bak -e's/use constant DEBUG =>/our
\$_internal_DEBUG =/' {} \;
find . -exec perl -pi -e's/if DEBUG/if \$_internal_DEBUG/' {} \;
other than complaints when trying to inplace-edit directories,
it worked (compiles and runs, havent checked in detail).
now I can override constants (for convenience) from test-scripts.
ala
$Log::Log4perl::_internal_DEBUG = 1;
$Log::Log4perl::Appender::_internal_DEBUG = 0;
$Log::Log4perl::Config::_internal_DEBUG = 1;
$Log::Log4perl::Filter::_internal_DEBUG = 0;
$Log::Log4perl::JavaMap::_internal_DEBUG = 0;
$Log::Log4perl::Logger::_internal_DEBUG = 0;
$Log::Log4perl::Config::DOMConfigurator::_internal_DEBUG = 0;
$Log::Log4perl::Config::Watch::_internal_DEBUG = 0;
$Log::Log4perl::Filter::Boolean::_internal_DEBUG = 0;
$Log::Log4perl::Filter::LevelMatch::_internal_DEBUG = 0;
$Log::Log4perl::Filter::LevelRange::_internal_DEBUG = 0;
$Log::Log4perl::Filter::StringMatch::_internal_DEBUG = 0;
$Log::Log4perl::JavaMap::TestBuffer::_internal_DEBUG = 0;
Im sure this will hurt performance by defeating compile-time optimization,
and in any case, you may not want to expose the variables this way,
so feel free to not accept these changes.
and my apologies, I should have just done this 1st, rather than bother you.
|
|
From: Jim C. <jc...@di...> - 2003-08-11 10:11:34
|
Mike Schilli wrote:
> Hey all,
>
> "kid on grok" (think that's J.C.) suggested to rename l4p's internal
> debug constants from DEBUG to _INTERNAL_DEBUG to avoid confusion with
> the function DEBUG() or the constant $DEBUG. Checked in.
>
Mike,
confusion continues :-0
use constant DEBUG => 0; # defines a constant function - looks like a
bareword.
$DEBUG is true when is_debug() is true, right ?
(I know, I could hop this curb, but Im looking for the wheelchair ramp)
could you re-check ? (im just pulled cvs, assuming HEAD by default)
0.37 (not yet released)
* (kg) adjusting tests for XML::Parser 2.32 having broken
XML::DOM 1.42 and lower
* (ms) Added signal handling to init_and_watch
[jimc@harpo Log-Log4perl]$ grep -r _INTERNAL_DEBUG *
[jimc@harpo Log-Log4perl]$
|
|
From: Mike S. <msc...@ao...> - 2003-08-11 05:26:16
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title></title> </head> <body> <font face="Arial,sans-serif"><font size="2">Hey all,<br> <br> "kid on grok" (think that's J.C.) suggested to rename l4p's internal debug constants from DEBUG to _INTERNAL_DEBUG to avoid confusion with the function DEBUG() or the constant $DEBUG. Checked in.<br> <br> <span>-- <br> -- Mike<br> Mike Schilli<br> <a class="moz-txt-link-abbreviated" href="mailto:m...@pe...">m...@pe...</a></span></font></font> </body> </html> |
|
From: Mike S. <msc...@ao...> - 2003-08-09 19:32:06
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title></title> </head> <body bgcolor="#ffffff"> <font face="Arial,sans-serif"><font size="2">These Log::Dispatch::Email all feature a flag "buffered" which defaults to "1", causing unwanted buffering at times. Log::Log4perl allows you to pass on any option the appender supports via the configuration file. What you might want to do is set<br> <br> log4perl.appender.Mailer.buffered = 0<br> <br> which will turn off the default buffering and send emails right away, given that you named your email appender "Mailer" in the log4perl configuration file.<br> <br> </font></font><font face="Arial,sans-serif" size="2"><font size="2"><span id="x-photon-sig-117638148">-- <br> -- Mike<br> Mike Schilli<br> <a class="moz-txt-link-abbreviated" href="mailto:m...@pe...">m...@pe...</a><br> <br> </span></font></font><font face="Arial,sans-serif"><font size="2"><span type="cite">Todd Lorenz wrote:</span> </font></font> <p><font face="Arial,sans-serif" size="2"></font></p> <blockquote type="cite" ><font face="Arial,sans-serif" size="2"></font> <div><font face="Arial" size="2">I see that Log::Dispatch::Email confers email message buffering, storing up all logged messages until the buffer is flushed. A flush occurs upon destruction of the appender object, and I don't see any explicit flushing done by the Log::Dispatch::Email subclasses.</font></div> <font face="Arial,sans-serif" size="2"></font> <div><font face="Arial,sans-serif" size="2"> </font></div> <font face="Arial,sans-serif" size="2"></font> <div><font face="Arial" size="2">This doesn't work so well for long-running programs or daemons. Is there a way to control the buffering behavior of Log::Dispatch::Email through the log4perl init() interface?</font></div> <font face="Arial,sans-serif" size="2"></font> <div><font face="Arial,sans-serif" size="2"> </font></div> </blockquote> <font face="Arial,sans-serif"><font size="2"><span id="x-photon-sig-117638148"></span></font></font> </body> </html> |
|
From: Todd L. <trl...@ho...> - 2003-08-08 23:01:29
|
I see that Log::Dispatch::Email confers email message buffering, storing = up all logged messages until the buffer is flushed. A flush occurs upon = destruction of the appender object, and I don't see any explicit = flushing done by the Log::Dispatch::Email subclasses. This doesn't work so well for long-running programs or daemons. Is there = a way to control the buffering behavior of Log::Dispatch::Email through = the log4perl init() interface? Thanks for any help. Todd Lorenz |
|
From: Mike S. <msc...@ao...> - 2003-08-06 22:22:10
|
Wiggins d'Anconia wrote: > I like the idea but I think this goes back to the notion of > init_and_watch calling die on failure. So two quick questions, You've got a lot of good points. There's a bunch open questions which we need to find answers for before we proceed (partially just summarizing your points): [1] Are we ok with the way Log::Log4perl handles re-initializing the configuration by throwing out everything and starting from scratch or should we rather go with the log4j model of a somewhat more complicated reload? [2] What's supposed to happen if a config reload fails? a) die b) keep the old one (and if: how can we notify the user? If it's a daemon?) [3] How does that fit in if we upgrade Log::Log4perl to handle logger repositories? Couple of comments on your questions: > 2) Is it possible to compartmentalize the config reading+updating, etc. > code to the extent of rather than passing init_and_watch a signal to > catch, that a particular class method could be called instead Sounds good, we should offer that. And, as you said, a callback to init_and_watch which calls back into the application when the re-init happens. > Currently I am using Log4perl extensively in a POE framework app (by the > way it works beautifully, well with the exception of FileRotate FileRotate has been updated a couple of times recently, as far as I'm aware (FileRotate isn't part of Log::Log4perl) it should be stable now. Grab the latest from CPAN. Lots of stuff ahead - and we're always welcoming helping hands :) -- -- Mike Mike Schilli m...@pe... |
|
From: Jim C. <jc...@di...> - 2003-08-06 20:33:32
|
Mike Schilli wrote:
>Jim Cromie wrote:
>
> > does patch allow user to use ALRM to duplicate existing behavior.
> > consistency would dictate that this is a good idea.
>
>Interesting idea, I've just tested it with setting the signal to 'ALRM'
>and triggering it via alarm(1). Works.
>
cool - that was my hope
> > also, since the handler is set there, theres no opportunity to restart
> > the alarm.
>
>That should be up to the application. By calling alarm(0), the alarm
>will be reset. Should be independant of Watch.pm.
>
>
Ok - but it precludes use of alarm to (fully) emulate $delay = 60
behavior of existing timeout, as it cant reset itself. Of course,
theres no 'real' reason to emulate - folks can do it the old way.
> > any point to saving prior signal handler, and maybe even calling it
> > after setting SIGNAL_CAUGHT ?
>
>Hmm, you mean what happens if there's already a signal handler defined?
>It'll be brutally overwritten, hopefully the new doc in Watch.pm
>illustrates that. I don't want to get into the business of calling other
>people's signal handlers :).
>
>
# you should add a
warn "IM DESTROYING YOUR EXISTING SIGNAL HANDLER ON $sig"
if $SIG{$sig}
# cuz people are often unaware of the signals used deep in a library or
a framework.
# and perhaps/maybe give them some (obscure, undocumented) way to shoot
themselves in the foot.
$Log::Log4perl::Watcher::stack_handlers = 1;
> > also FWIW - 5.8.0 has safe signals by default, earlier doesnt. there
> > may be some suprises in there.
>
>The design allows for all kinds of hickups -- all the handler does is
>set a global variable. It either does it or the signal gets lost. If it
>does, Log4perl gets re-initialized, if it gets lost, it doesn't. Can you
>think of anything more severe?
>
>
heh - true true. your approach borders on paranoid :-) L<perldoc perlipc>
>Anyways, thanks a bunch for your comments!
>
:-) even half-baked comments are better than silence. this list is
low-traffic enough that a little noise is ok.
>
>Oh, by the way, I found something in the watcher code: By delaying
>getting the $logger and $level parameters from the stack until they're
>actually needed, the 'SIG' watch enabled code now holds up to 90% of the
>full init() speed for suppressed logger calls! This also helped the
>traditional init_and_watch, which is now at about 60%.
>
>
>
cool ! esp for traditional - where 99% of re-inits have no changes.
btw - when re-init happens, does it just throw away the old init and
rebuild a brand-new structure ?
the reason I ask is that my AutoCategorize sub-class builds a lot of
anonymous subs to delegate up
to Log4perl, and it would be nice not to throw out the whole lot.
If both the b4 and after configs are available at some (transient)
point, and a hook is available so I
can inspect them, I can find the diffs and delete only those subs whose
config has been superceded.
|
|
From: Kevin G. <ke...@go...> - 2003-08-06 16:55:03
|
Mike Schilli wrote: > Rit...@ub... wrote: > > > I want to use LOG4PERL for logging up my messages and sending it to > > Micromuse socket probe. > > I need to use socket appender. Is it available? If it is where can I > > found its details? Dave Rolsky (Log::Dispatch author) once remarked that you could make a socket appender by creating an IO::Socket object and passing it to Log::Dispatch::Handle. -- Happy Trails . . . Kevin M. Goess (and Anne and Frank) 904 Carmel Ave. Albany, CA 94706 (510) 525-5217 |
|
From: Mike S. <msc...@ao...> - 2003-08-06 04:06:14
|
Jim Cromie wrote: > does patch allow user to use ALRM to duplicate existing behavior. > consistency would dictate that this is a good idea. Interesting idea, I've just tested it with setting the signal to 'ALRM' and triggering it via alarm(1). Works. > new() sets the signal handler itself, its probly prudent to document > this IN LARGE LETTERS. I've added some documentation to both Log4perl.pm (about performance) and Watch.pm (about the new signal handler), thanks for the reminder :). > also, since the handler is set there, theres no opportunity to restart > the alarm. That should be up to the application. By calling alarm(0), the alarm will be reset. Should be independant of Watch.pm. > any point to saving prior signal handler, and maybe even calling it > after setting SIGNAL_CAUGHT ? Hmm, you mean what happens if there's already a signal handler defined? It'll be brutally overwritten, hopefully the new doc in Watch.pm illustrates that. I don't want to get into the business of calling other people's signal handlers :). > also FWIW - 5.8.0 has safe signals by default, earlier doesnt. there > may be some suprises in there. The design allows for all kinds of hickups -- all the handler does is set a global variable. It either does it or the signal gets lost. If it does, Log4perl gets re-initialized, if it gets lost, it doesn't. Can you think of anything more severe? Anyways, thanks a bunch for your comments! Oh, by the way, I found something in the watcher code: By delaying getting the $logger and $level parameters from the stack until they're actually needed, the 'SIG' watch enabled code now holds up to 90% of the full init() speed for suppressed logger calls! This also helped the traditional init_and_watch, which is now at about 60%. -- -- Mike Mike Schilli msc...@ao... AOL Unified Preferences Engineering |
|
From: Wiggins d'A. <wi...@da...> - 2003-08-06 02:33:21
|
msc...@ao... wrote: > Hey, > > just had an idea: How about if we add functionality to init_and_watch in Log::Log4perl to not only watch config files but to also be able to listen to (Unix) signals instead? Yeah, yeah, I know signals are unreliable and can cause all kinds of crazy stuff -- but how about if we have the signal handler just set a global variable, which is checked by the watcher code instead of calling time() all the time? > Please take a look at the patch below, and let me know what you think ... the addtl. syntax is: > > init_and_watch($file, 'HUP'); # will listen to SIGHUP > > I've also attached a test file. > I like the idea but I think this goes back to the notion of init_and_watch calling die on failure. So two quick questions, 1) Is it possible to store the current config, load the new one, and rollback to the previous one if something goes wrong? 2) Is it possible to compartmentalize the config reading+updating, etc. code to the extent of rather than passing init_and_watch a signal to catch, that a particular class method could be called instead, then the user could install their own signal handler easy enough. (Or maybe both cause if you can do #2, then it should be trivial to have init_and_watch accept a signal and it would just set the call to the class method to that signal for the user). Currently I am using Log4perl extensively in a POE framework app (by the way it works beautifully, well with the exception of FileRotate but I think an upgrade will improve that situation) so I already have a framework for handling events and signals, but it would be nice if I could control the reloading of the config file on my own, rather than having init_and_watch do it for me either through a time based or a signal based mechanism. Because I have a 24/7 running app as well, I don't want to have the worry of sending a signal to the app or even after a certain amount of time, having it caught and having it 'die' on me when that isn't the type of signal I sent. This essentially gets somewhat back to being able to pass a callback to the init_and_watch so that when it fires, certain actions can be taken. I realize this is open source, and that I should put my keyboard where my mouth is but I am still a little intimidated by taking this on my own especially without being familar with the Log4perl internals (yet!), but these are just some ideas I have mulled over while writing our app. Given enough time I will probably get around to taking a stab at it myself, but if Mike or Kevin, et al. have a way to work it in while all of this is fresh I think it would be a nice addition. I also realize there is the log4j standards, etc. Just my $.02 for what their worth... http://danconia.org |
|
From: Jim C. <jc...@di...> - 2003-08-05 20:46:02
|
msc...@ao... wrote: >Hey, > >just had an idea: How about if we add functionality to init_and_watch in Log::Log4perl to not only watch config files but to also be able to listen to (Unix) signals instead? Yeah, yeah, I know signals are unreliable and can cause all kinds of crazy stuff -- but how about if we have the signal handler just set a global variable, which is checked by the watcher code instead of calling time() all the time? >Please take a look at the patch below, and let me know what you think ... the addtl. syntax is: > > init_and_watch($file, 'HUP'); # will listen to SIGHUP > >I've also attached a test file. > >-- Mike > > > Ive only glanced at patch, so this might be done already (or might be stupid - I havent thought it thru) does patch allow user to use ALRM to duplicate existing behavior. consistency would dictate that this is a good idea. in lib/Log/Log4perl/Config/Watch.pm new() sets the signal handler itself, its probly prudent to document this IN LARGE LETTERS. also, since the handler is set there, theres no opportunity to restart the alarm. any point to saving prior signal handler, and maybe even calling it after setting SIGNAL_CAUGHT ? also FWIW - 5.8.0 has safe signals by default, earlier doesnt. there may be some suprises in there. |
|
From: Kevin G. <ke...@go...> - 2003-08-05 18:07:02
|
That's a pretty neat idea, go for it, dude! msc...@ao... wrote: > Hey, > > just had an idea: How about if we add functionality to init_and_watch in Log::Log4perl to not only watch config files but to also be able to listen to (Unix) signals instead? Yeah, yeah, I know signals are unreliable and can cause all kinds of crazy stuff -- but how about if we have the signal handler just set a global variable, which is checked by the watcher code instead of calling time() all the time? > Please take a look at the patch below, and let me know what you think ... the addtl. syntax is: > > init_and_watch($file, 'HUP'); # will listen to SIGHUP > > I've also attached a test file. > > -- Mike > > ############################ > # Mike Schilli # > # log...@pe... # > # http://perlmeister.com # > # log4perl.sourceforge.net # > ############################ > > > ------------------------------------------------------------------------ > > Index: lib/Log/Log4perl/Config.pm > =================================================================== > RCS file: /cvsroot/log4perl/Log-Log4perl/lib/Log/Log4perl/Config.pm,v > retrieving revision 1.52 > diff -a -u -r1.52 Config.pm > --- lib/Log/Log4perl/Config.pm 20 Jul 2003 20:24:18 -0000 1.52 > +++ lib/Log/Log4perl/Config.pm 4 Aug 2003 04:47:28 -0000 > @@ -45,10 +45,16 @@ > sub init_and_watch { > ########################################### > my ($class, $config, $delay) = @_; > + # delay can be a signal name - in this case we're gonna > + # set up a signal handler. > > if(defined $WATCHER) { > $config = $WATCHER->file(); > - $delay = $WATCHER->check_interval(); > + if(defined $Log::Log4perl::Config::Watch::SIGNAL_CAUGHT) { > + $delay = $WATCHER->signal(); > + } else { > + $delay = $WATCHER->check_interval(); > + } > } > > print "init_and_watch ($config-$delay). Resetting.\n" if DEBUG; > @@ -57,8 +63,6 @@ > > defined ($delay) or $delay = $DEFAULT_WATCH_DELAY; > > - $delay =~ /\D/ && die "illegal non-numerical value for delay: $delay"; > - > if (ref $config) { > die "Log4perl can only watch a file, not a string of " . > "configuration information"; > @@ -66,10 +70,17 @@ > die "Log4perl can only watch a file, not a url like $config"; > } > > - $WATCHER = Log::Log4perl::Config::Watch->new( > - file => $config, > - check_interval => $delay, > - ); > + if($delay =~ /\D/) { > + $WATCHER = Log::Log4perl::Config::Watch->new( > + file => $config, > + signal => $delay, > + ); > + } else { > + $WATCHER = Log::Log4perl::Config::Watch->new( > + file => $config, > + check_interval => $delay, > + ); > + } > > _init($class, $config); > } > Index: lib/Log/Log4perl/Logger.pm > =================================================================== > RCS file: /cvsroot/log4perl/Log-Log4perl/lib/Log/Log4perl/Logger.pm,v > retrieving revision 1.55 > diff -a -u -r1.55 Logger.pm > --- lib/Log/Log4perl/Logger.pm 4 Aug 2003 02:37:35 -0000 1.55 > +++ lib/Log/Log4perl/Logger.pm 4 Aug 2003 04:47:30 -0000 > @@ -292,13 +292,14 @@ > > if (defined $Log::Log4perl::Config::WATCHER) { > > - $watch_code = <<'EOL'; > - my($logger, $subname) = @_; > - if(time() > $Log::Log4perl::Config::Watch::NEXT_CHECK_TIME and > - $Log::Log4perl::Config::WATCHER->change_detected()) { > + my $cond = generate_watch_conditional(); > + > + $watch_code = <<EOL; > + my(\$logger, \$subname) = \@_; > + if($cond) { > Log::Log4perl->init_and_watch(); > # Forward call to new configuration > - return $logger->$subname(); > + return \$logger->\$subname(); > } > EOL > } > @@ -317,20 +318,36 @@ > ################################################## > print "generate_watch_code:\n" if DEBUG; > > - return <<'EOL'; > + my $cond = generate_watch_conditional(); > + > + return <<EOL; > print "exe_watch_code:\n" if DEBUG; > > # more closures here > - if(time() > $Log::Log4perl::Config::Watch::NEXT_CHECK_TIME and > - $Log::Log4perl::Config::WATCHER->change_detected()) { > + if($cond) { > Log::Log4perl->init_and_watch(); > > - my $methodname = lc($level); > - $logger->$methodname(@_); # send the message > - # to the new configuration > + my \$methodname = lc(\$level); > + \$logger->\$methodname(\@_); # send the message > + # to the new configuration > return; #and return, we're done with this incarnation > } > EOL > +} > + > +################################################## > +sub generate_watch_conditional { > +################################################## > + > + if(defined $Log::Log4perl::Config::Watch::SIGNAL_CAUGHT) { > + # In this mode, we just check for the variable indicating > + # that the signal has been caught > + return q{$Log::Log4perl::Config::Watch::SIGNAL_CAUGHT}; > + } > + > + # In this mode, we check if the config file has been modified > + return q{time() > $Log::Log4perl::Config::Watch::NEXT_CHECK_TIME > + and $Log::Log4perl::Config::WATCHER->change_detected()}; > } > > ################################################## > Index: lib/Log/Log4perl/Config/Watch.pm > =================================================================== > RCS file: /cvsroot/log4perl/Log-Log4perl/lib/Log/Log4perl/Config/Watch.pm,v > retrieving revision 1.3 > diff -a -u -r1.3 Watch.pm > --- lib/Log/Log4perl/Config/Watch.pm 20 Jul 2003 20:24:01 -0000 1.3 > +++ lib/Log/Log4perl/Config/Watch.pm 4 Aug 2003 04:47:30 -0000 > @@ -8,6 +8,7 @@ > use constant DEBUG => 0; > > our $NEXT_CHECK_TIME; > +our $SIGNAL_CAUGHT; > > ########################################### > sub new { > @@ -16,6 +17,7 @@ > > my $self = { file => "", > check_interval => 30, > + signal => undef, > %options, > _last_checked_at => 0, > _last_timestamp => 0, > @@ -23,8 +25,15 @@ > > bless $self, $class; > > - # Just called to initialize > - $self->change_detected(); > + if($self->{signal}) { > + # We're in signal mode, set up the handler > + $SIG{$self->{signal}} = sub { $SIGNAL_CAUGHT = 1; }; > + # Reset the marker. The handler is going to modify it. > + $SIGNAL_CAUGHT = 0; > + } else { > + # Just called to initialize > + $self->change_detected(); > + } > > return $self; > } > @@ -35,6 +44,14 @@ > my($self) = @_; > > return $self->{file}; > +} > + > +########################################### > +sub signal { > +########################################### > + my($self) = @_; > + > + return $self->{signal}; > } > > ########################################### -- Happy Trails . . . Kevin M. Goess (and Anne and Frank) 904 Carmel Ave. Albany, CA 94706 (510) 525-5217 |
|
From: <msc...@ao...> - 2003-08-04 05:00:08
|
Hey, just had an idea: How about if we add functionality to init_and_watch in Log::Log4perl to not only watch config files but to also be able to listen to (Unix) signals instead? Yeah, yeah, I know signals are unreliable and can cause all kinds of crazy stuff -- but how about if we have the signal handler just set a global variable, which is checked by the watcher code instead of calling time() all the time? Please take a look at the patch below, and let me know what you think ... the addtl. syntax is: init_and_watch($file, 'HUP'); # will listen to SIGHUP I've also attached a test file. -- Mike ############################ # Mike Schilli # # log...@pe... # # http://perlmeister.com # # log4perl.sourceforge.net # ############################ |
|
From: Mike S. <msc...@ao...> - 2003-07-31 19:13:14
|
> Please advice, Is it possible to use Log4j with perl version 5.00402. > If yes then how can I install it on windows 2000. We're supporting all perl versions back to 5.00503 on all platforms, but no further. Any chance you could upgrade to something more recent? -- -- Mike Mike Schilli m...@pe... |
|
From: Mike S. <msc...@ao...> - 2003-07-31 18:25:20
|
Vince Veggus wrote: > Sorry guys, > I can't find any email like > uns...@li... to unsubscribe. > Neither I can find a unsubscribe button on > https://lists.sourceforge.net/lists/listinfo/log4perl-devel Actually, it's at the very bottom of the page: "To change your subscription (set options like digest and delivery modes, get a reminder of your password, or unsubscribe from log4perl-devel), enter your subscription email address:" Let me know if this works for you ... :) -- -- Mike Mike Schilli log...@pe... |
|
From: <moh...@wi...> - 2003-07-31 17:06:35
|
Please advice, Is it possible to use Log4j with perl version 5.00402. If yes then how can I install it on windows 2000. Thanks in advance Mohammad Shahzad Technical Developer Business Innovation Center Binely Business Park Coventry 024 7643 0180 Wire-e Ltd on behalf of Vodafone Corporate http://www.wire-e.co.uk |
|
From: Vince V. <vi...@ly...> - 2003-07-31 05:42:38
|
Sorry guys, I can't find any email like uns...@li... to unsubscribe. Neither I can find a unsubscribe button on https://lists.sourceforge.net/lists/listinfo/log4perl-devel The FAQ didn't answer this question too... Is it just to early in the morning *wonder* or am I just too dumb to unsubscribe? -- Best regards, Vince mailto:vi...@ly... |
|
From: Mike S. <msc...@ao...> - 2003-07-30 21:52:41
|
Rit...@ub... wrote: > I want to use LOG4PERL for logging up my messages and sending it to > Micromuse socket probe. > I need to use socket appender. Is it available? If it is where can I > found its details? Hi Ritu, we don't have a socket appender yet, but it should be easy to implement a simple one. Check out http://log4perl.sourceforge.net/releases/Log-Log4perl/docs/html/Log/Log4perl/FAQ.html#how_can_i_write_my_own_appender and let me know how it works out ... -- Mike Mike Schilli m...@pe... |
|
From: Kevin G. <ke...@go...> - 2003-07-29 20:41:56
|
done and checked in Msc...@ao... wrote: > In a message dated 7/29/03 11:26:05 AM Pacific Daylight Time, > ke...@go... writes: > >> So it's not our problem, it means the versions of XML::Parser and >> XML::DOM used by Kingpin are incompatible. What should we do with the >> error report? > > > > We should probably check for those offending versions and, if they're > detected, we could warn and skip the tests, just to allow for a > (somewhat) smooth install. > > -- Mike > Mike Schilli -- Happy Trails . . . Kevin M. Goess (and Anne and Frank) 904 Carmel Ave. Albany, CA 94706 (510) 525-5217 |
|
From: <Msc...@ao...> - 2003-07-29 19:05:32
|
In a message dated 7/29/03 11:26:05 AM Pacific Daylight Time, ke...@go... writes: > So it's not our problem, it means the versions of XML::Parser and > XML::DOM used by Kingpin are incompatible. What should we do with the > error report? > We should probably check for those offending versions and, if they're detected, we could warn and skip the tests, just to allow for a (somewhat) smooth install. -- Mike Mike Schilli |
|
From: Kevin G. <ke...@go...> - 2003-07-29 18:24:06
|
Msc...@ao... wrote: > Kevin, any clue? > > > Subject: FAIL Log-Log4perl-0.36 perl 5.8.0 solaris 7 > From: Kingpin <mthurn@carbon> > Date: Tue, 29 Jul 2003 11:49:39 -0400 (EDT) > To: msc...@cp... > > Hmmmm, maybe this is an XML::Parser error? If that's the case, sorry to bother you... > > t/038XML-DOM1........Can't locate XML/Parser/Style/Dom.pm in @INC > at /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-multi-64int/XML/Parser.pm line 54. It looks like the v2.32 release of XML::Parser on 27-Jul-2003 broke XML::DOM. The v1.43 of XML::DOM released on 28-Jul-2003 has this changelog: 1.43 (tjmather) 07/28/2003 - Fixed bug that manifests itself with XML::Parser 2.32 and greater, specify external style as 'XML::Parser::Dom' rather than just 'Dom'. (Matt Sergeant) So it's not our problem, it means the versions of XML::Parser and XML::DOM used by Kingpin are incompatible. What should we do with the error report? -- Happy Trails . . . Kevin M. Goess (and Anne and Frank) 904 Carmel Ave. Albany, CA 94706 (510) 525-5217 |
|
From: <msc...@ao...> - 2003-07-29 02:40:22
|
Hi all,
just released 0.36 to CPAN, here's what's new:
0.36 (07/22/2003)
* (ms) Matthew Keene <mk...@ne...> suggested to have
an accessor for all appenders currently defined -- added
appenders() method
* (ms) Test case 041SafeEval.t didn't share $0 explicitely and
created some warnings, fixed that with (jf)'s help.
* (ms) Added performance improvements suggested by
Kyle R. Burton <mo...@vo...>. is_debug/is_info/etc.
are now precompiled, similar to the debug/info/etc. methods.
* (ms) Added a fix to have is_debug()/is_info()/etc. pay
attention to on-the-fly config file changes via init_and_watch().
* (ms) Fixed bug that reloaded the config under init_and_watch()
every time the check period expired, regardless if the config
file itself had changed. Added test case.
-- Mike
############################
# Mike Schilli #
# log...@pe... #
# http://perlmeister.com #
# log4perl.sourceforge.net #
############################
|
|
From: <msc...@ao...> - 2003-07-25 07:03:12
|
In a message dated 7/24/2003 9:00:45 AM Eastern Standard Time, jo...@vi... writes:
> according to the documentation the command
> Log::Log4perl::Logger::create_custom_level("NOTIFY", "WARN");
> should add the custom level NOTIFY right ***AFTER*** the level WARN.
> But within log4Perl Version 0.35 the implementation is wrong:
> NOTIFY is added ***BEFORE*** the level WARN.
Hey Johannes,
hmmmm, the terms "after" and "before" might be a bit scewed in the Log4perl world, let's see, let me try to analyze the problem, according to the documentation,
create_custom_level("NOTIFY", "WARN")
would add a level "NOTIFY" between "INFO" and "WARN". I've a attached a code snippet illustrating the issue -- can you explain what's wrong with it?
-- Mike
############################
# Mike Schilli #
# log...@pe... #
# http://perlmeister.com #
# log4perl.sourceforge.net #
############################
use Log::Log4perl qw(get_logger);
use Log::Log4perl::Level;
Log::Log4perl::Logger::create_custom_level("NOTIFY", "WARN");
Log::Log4perl->init(\ <<EOT
log4perl.category = NOTIFY, Screen
log4perl.appender.Screen = Log::Log4perl::Appender::Screen
log4perl.appender.Screen.layout = Log::Log4perl::Layout::PatternLayout
log4perl.appender.Screen.layout.ConversionPattern = %d %F{1} %L> %m %n
EOT
);
my $logger = get_logger();
$logger->debug("debug");
$logger->info("info");
$logger->notify("notify");
$logger->warn("warn");
__END__
2003/07/25 00:00:32 t 24> notify
2003/07/25 00:00:32 t 25> warn
|
|
From: Johannes K. <jo...@vi...> - 2003-07-24 12:59:27
|
Hi there,
according to the documentation the command
Log::Log4perl::Logger::create_custom_level("NOTIFY", "WARN");
should add the custom level NOTIFY right ***AFTER*** the level WARN. But
within log4Perl Version 0.35 the implementation is wrong: NOTIFY is added
***BEFORE*** the level WARN.
Either the documentation has to be changed, or the following patch corrects
the behaviour....
Greetings
Johannes
Patch for Log::Log4perl::Logger.pm
------SNIP HERE----------------------
*** c:\Programme\Perl\site\lib\Log\Log4perl\Logger.pm Thu Jul 24 14:42:52
2003
--- c:\Programme\Perl\site\lib\Log\Log4perl\Logger_ori.pm Sun Jun 8
19:37:08 2003
***************
*** 507,513 ****
# figure out new int value by AFTER + (AFTER+ 1) / 2
! my $next_prio =
Log::Log4perl::Level::get_higher_level($PRIORITY{$after}, 1);
my $cust_prio = int(($PRIORITY{$after} + $next_prio) / 2);
# CORE::warn("Creating prio $cust_prio between $PRIORITY{$after} and
$next_prio");
--- 507,513 ----
# figure out new int value by AFTER + (AFTER+ 1) / 2
! my $next_prio = Log::Log4perl::Level::get_lower_level($PRIORITY{$after},
1);
my $cust_prio = int(($PRIORITY{$after} + $next_prio) / 2);
# CORE::warn("Creating prio $cust_prio between $PRIORITY{$after} and
$next_prio");
------SNIP HERE----------------------
|
|
From: Mike S. <log...@pe...> - 2003-07-20 19:50:59
|
Hey guys,
just discovered that we're reading the config file more often than necessary,
here's a fix to only re-read the conf file if has really changed:
Index: Logger.pm
===================================================================
RCS file: /cvsroot/log4perl/Log-Log4perl/lib/Log/Log4perl/Logger.pm,v
retrieving revision 1.53
diff -a -u -r1.53 Logger.pm
--- Logger.pm 16 Jul 2003 09:06:22 -0000 1.53
+++ Logger.pm 20 Jul 2003 19:37:14 -0000
@@ -294,7 +294,8 @@
$watch_code = <<'EOL';
my($logger, $subname) = @_;
- if(time() > $Log::Log4perl::Config::Watch::NEXT_CHECK_TIME) {
+ if(time() > $Log::Log4perl::Config::Watch::NEXT_CHECK_TIME and
+ $Log::Log4perl::Config::WATCHER->change_detected()) {
Log::Log4perl->init_and_watch();
# Forward call to new configuration
return $logger->$subname();
@@ -320,7 +321,8 @@
print "exe_watch_code:\n" if DEBUG;
# more closures here
- if(time() > $Log::Log4perl::Config::Watch::NEXT_CHECK_TIME) {
+ if(time() > $Log::Log4perl::Config::Watch::NEXT_CHECK_TIME and
+ $Log::Log4perl::Config::WATCHER->change_detected()) {
Log::Log4perl->init_and_watch();
my $methodname = lc($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.
