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: Ming <mi...@gm...> - 2010-02-04 20:00:49
|
Linux ubuntu 2.6.31-17-generic #54-Ubuntu SMP This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi t/023Date.t .......... 1/36 # Failed test at t/023Date.t line 67. # got: '0 00 000 0000' # expected: '22 22 022 0022' # Failed test at t/023Date.t line 103. # got: '26 Aug 2002 23:32:00,123' # expected: '26 Aug 2002 23:32:22,123' # Failed test at t/023Date.t line 106. # got: '2002-08-26 23:32:00,123' # expected: '2002-08-26 23:32:22,123' # Failed test at t/023Date.t line 109. # got: '23:32:00,123' # expected: '23:32:22,123' # Failed test at t/023Date.t line 112. # got: '[Mon Aug 26 23:32:00 2002]' # expected: '[Mon Aug 26 23:32:22 2002]' # Looks like you failed 5 tests of 36. t/023Date.t .......... Dubious, test returned 5 (wstat 1280, 0x500) Failed 5/36 subtests TIA |
From: Mike S. <m...@pe...> - 2010-02-02 20:43:14
|
On Mon, 1 Feb 2010, Maciej Grela wrote: > Is it possible to use the log4perl appenders, layouts etc. to mask > secret values (passwords) from the log files generated by log4perl ? The best way to avoid passwords in the logs is to avoid logging them in the first place. If you're writing the application, simply strip out the password fields from the web forms before you dump them to the logging mechanism. Stripping out logged passwords, by using a simple search/replace on the logged passwords is not a safe practice, because a) the application would actually have to know and store the cleartext passwords and b) you'd get funny (and revealing!) results if the password matches regular text. -- Mike Mike Schilli m...@pe... > > For example, I routinely use log4perl to dump the data in web forms > before POSTing them. These forms often contain sensitive user > information and I wouldn't want any of my users to post a log with his > password on some public bugzilla. To this day I have manually filtered > out these secrets using a wrapper function used in sensitive places. I > feel however, that I need a better approach. > > As a quick proof-of-concept I simply hacked my own version of the > Multiline appender adding the following code: > > --- /usr/lib/perl5/vendor_perl/5.8.8/Log/Log4perl/Layout/PatternLayout/Multiline.pm 2009-12-30 > 14:27:32.000000000 +0100 > +++ lib/Log/Log4perl/Layout/PatternLayout/Masked.pm 2010-02-01 > 07:24:01.000000000 +0100 > @@ -1,8 +1,11 @@ > #!/usr/bin/perl > > -package Log::Log4perl::Layout::PatternLayout::Multiline; > +package Log::Log4perl::Layout::PatternLayout::Masked; > use base qw(Log::Log4perl::Layout::PatternLayout); > > +use Log::Log4perl::MDC; > + > + > ########################################### > sub render { > ########################################### > @@ -13,8 +16,15 @@ > $caller_level = 0 unless defined $caller_level; > > my $result; > + my $secret_list = Log::Log4perl::MDC->get("secrets"); > > for my $msg ( @messages ) { > + # Mask the secret values if needed > + if ( $secret_list ) { > + foreach (keys %{$secret_list}) { > + $msg =~ s/$_/$secret_list->{$_}/g; > + } > + } > $result .= $self->SUPER::render( > $msg, $category, $priority, $caller_level + 1 > ); > > The "proper" solution however would be to make this feature > independent of the layout and appender used. I have tried to use > filters but unfortunately the filter function cannot change the > contents of the message. I think the best approach would be to allow > the filter function to change the contents of the message by passing a > reference to the message hash instead of a copy. > This of course will break compatibility with existing filters and they > would have to be rewritten. Fortunately, there is not a lot of them in > the Log4perl distribution, I don't know about any external ones. > > What do you think about all of this ? I'm willing to write the code & > tests needed to implement this feature properly if there is interest > in it. > > Best regards, > Maciej Grela > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > log4perl-devel mailing list > log...@li... > https://lists.sourceforge.net/lists/listinfo/log4perl-devel > |
From: Maciej G. <mac...@gm...> - 2010-02-01 07:22:10
|
Hi, When using log4perl recently in one of my Web-automation scripts I asked myself the following question: Is it possible to use the log4perl appenders, layouts etc. to mask secret values (passwords) from the log files generated by log4perl ? For example, I routinely use log4perl to dump the data in web forms before POSTing them. These forms often contain sensitive user information and I wouldn't want any of my users to post a log with his password on some public bugzilla. To this day I have manually filtered out these secrets using a wrapper function used in sensitive places. I feel however, that I need a better approach. As a quick proof-of-concept I simply hacked my own version of the Multiline appender adding the following code: --- /usr/lib/perl5/vendor_perl/5.8.8/Log/Log4perl/Layout/PatternLayout/Multiline.pm 2009-12-30 14:27:32.000000000 +0100 +++ lib/Log/Log4perl/Layout/PatternLayout/Masked.pm 2010-02-01 07:24:01.000000000 +0100 @@ -1,8 +1,11 @@ #!/usr/bin/perl -package Log::Log4perl::Layout::PatternLayout::Multiline; +package Log::Log4perl::Layout::PatternLayout::Masked; use base qw(Log::Log4perl::Layout::PatternLayout); +use Log::Log4perl::MDC; + + ########################################### sub render { ########################################### @@ -13,8 +16,15 @@ $caller_level = 0 unless defined $caller_level; my $result; + my $secret_list = Log::Log4perl::MDC->get("secrets"); for my $msg ( @messages ) { + # Mask the secret values if needed + if ( $secret_list ) { + foreach (keys %{$secret_list}) { + $msg =~ s/$_/$secret_list->{$_}/g; + } + } $result .= $self->SUPER::render( $msg, $category, $priority, $caller_level + 1 ); The "proper" solution however would be to make this feature independent of the layout and appender used. I have tried to use filters but unfortunately the filter function cannot change the contents of the message. I think the best approach would be to allow the filter function to change the contents of the message by passing a reference to the message hash instead of a copy. This of course will break compatibility with existing filters and they would have to be rewritten. Fortunately, there is not a lot of them in the Log4perl distribution, I don't know about any external ones. What do you think about all of this ? I'm willing to write the code & tests needed to implement this feature properly if there is interest in it. Best regards, Maciej Grela |
From: Rob R. <Rob...@cl...> - 2010-01-29 17:57:04
|
After plunking (actually, single-stepping in the debugger) around the marvel of appender wrappers, appenders, closures, levels, thresholds, and priorities that is Log4perl, I noticed the following. As the Log4perl doc says, under "Access Defined Appenders": "The previously mentioned method appender_by_name() returns a reference to the real appender object. If you want access to the wrapper class (e.g. if you want to modify the appender's threshold), use the hash $Log::Log4perl::Logger::APPENDER_BY_NAME{...} instead, which holds references to all appender wrapper objects." Okay. But when your application does: my $wrapper = $Log::Log4perl::Logger::APPENDER_BY_NAME{'somename'}; $wrapper->threshold ('INFO'); what you get is the wrapper object's "level" field set to the... um, priority of the 'INFO' level you passed in. And that works, as subsequently the appender does not log anything of higher... um, or maybe lower, level... um, priority than INFO. Yeah, that's it. But it does leave the actual appender object's "Threshold" field unchanged. So if that field were already 'DEBUG', what you get is a wrapper saying one thing about level, while it contains an appender saying another thing about Threshold. The effect turns out correct, but only because the appender's "Threshold" is actually the wrapper's "level", and the two values need not agree, since one of them seems to be ignored past initialization. Ugh. In the end, it seems like the threshold() routine ought to set (or perhaps just delete) the appender's Threshold field when it sets the wrapper's level field. ========== Rob Retter |
From: Mike S. <m...@pe...> - 2010-01-28 07:56:26
|
On Wed, 27 Jan 2010, Keith Clay wrote: > Is there a way to pass info to a called command? can it ingest the config > file for the calling program, add it's own appender/s and write to files the > calling program has open? Not sure I'm following ... what are you trying to do? -- Mike Mike Schilli m...@pe... |
From: Keith C. <kei...@gm...> - 2010-01-27 17:37:35
|
Is there a way to pass info to a called command? can it ingest the config file for the calling program, add it's own appender/s and write to files the calling program has open? keith |
From: Mike S. <m...@pe...> - 2010-01-27 16:41:16
|
On Wed, 20 Jan 2010, Trevor Little wrote: > I'm adding logging to a high-traffic mod_perl website and am worried > about the performance penalties of writing stuff to disc on every > request. It depends on your traffic numbers. I've found that a file appender works quite well up to 1000 reqs/sec because the OS typically caches disc access quite efficiently. Your mileage might vary, so prudent load testing is of the essence. -- Mike Mike Schilli m...@pe... |
From: Mike S. <m...@pe...> - 2010-01-27 09:02:49
|
On Wed, 27 Jan 2010, "Silkenbäumer, Karsten" wrote: > I found out I can use CODE refs in my config file. > log4perl.appender.testnameAppender.filename=sub { return 'example.log' > } This function doesn't get any arguments right now (warn @_) Would be > great to access the name of the logger (and maybe appender) there. Interesting idea ... I presume we could add the left side of the line as an argument to the function call, but that's probably about it. Logger info might not be available at this point. The other option is to write a subclass of Log::Log4perl::Appender::File and have it deal with the dynamically created file names. Or, you could set up your Log4perl configuration programmatically, using logger and appender methods. However, every dynamic modification comes at a price: A new person might have trouble understanding what's going on by looking at the configuration file. Leaving redundancies in place sometimes makes the configuration easier to understand. > Next thing is: using filenames, either with Dispatch::File or all the > others has one fatal behaviour: If the directory does not exists, it > throws an error message and quits. I'd be careful with that. This opens up a whole new set of problems: Are you going to create directory hierarchies of arbitrary depth? What are the permissions on each level? Rather than making the appender smarter in this regard, I'd rather modify those cronjobs to keep the directories in place. Your mileage might vary, and you might want to create a subclass of Log::Log4perl::Appender::File (rather than Log::Dispatch which misses a number of features) to accomplish what you want. Hope that helps! -- Mike Mike Schilli m...@pe... |
From: Silkenbäumer, K. <si...@im...> - 2010-01-27 07:51:07
|
Hi, I'm using Log4perl more and more extensively. It's great. However, I'm missing some features - maybe they are implemented right now and I don't see them. I found out I can use CODE refs in my config file. log4perl.appender.testnameAppender.filename=sub { return 'example.log' } This function doesn't get any arguments right now (warn @_) Would be great to access the name of the logger (and maybe appender) there. I have many loggers and they all do the same except for logging in different files. So I need a log4perl.logger.* line and for each 4 (or more) log4perl.appender.* lines which are equal but differ only in their .filename. Next thing is: using filenames, either with Dispatch::File or all the others has one fatal behaviour: If the directory does not exists, it throws an error message and quits. As some dirs maybe deleted by cronjobs, they should be created when a logger needs it. I could write my own Dispatch-Class, but since all File::* are derived from Dispatch::File, it's not a good idea, I guess. Should be implemented in Dispatch::File. Regards Karsten |
From: Mike S. <m...@pe...> - 2010-01-26 17:54:43
|
On Fri, 22 Jan 2010, Rob Retter wrote: > I sent this message a little while ago Sorry for the delay, thanks for your patience. > In DateFormat.pm, the routine fmt() should not bother to recreate the This is a neat idea, we just need to change that the mere presence of the Time::HiRes module introduces milliseconds and hence kills the optimization. More to come soon ... -- Mike Mike Schilli m...@pe... > time string over and over and over....You tend to see the same > timestamp on numerous consecutive log entries (unless you're using > milliseconds, which seems like overkill in many situations). Anyway, > the code should be something like: > > { > my $lastSecs = 0; > my $lastMsecs = 0; > my $lastFmt = ''; > > ########################################### > sub format { > ########################################### > my($self, $secs, $msecs) = @_; > > $msecs = 0 unless defined $msecs; > > return $lastFmt if ($lastSecs == $secs and > $lastMsecs == $msecs); > > my @time; > > if($GMTIME) { > @time = gmtime($secs); > } else { > @time = localtime($secs); > } > > # add milliseconds > push @time, $msecs; > > my @values = (); > > for(@{$self->{stack}}) { > my($val, $code) = @$_; > if($code) { > push @values, $code->($time[$val]); > } else { > push @values, $time[$val]; > } > } > > $lastSecs = $secs; > $lastMsecs = $msecs; > $lastFmt = sprintf($self->{fmt}, @values); > return $lastFmt; > } > > } > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > log4perl-devel mailing list > log...@li... > https://lists.sourceforge.net/lists/listinfo/log4perl-devel > |
From: Jean-Denis M. <jd...@kl...> - 2010-01-26 08:48:24
|
On 1/22/10 18:45 , "Rob Retter" <Rob...@cl...> wrote: > > > -----Original Message----- > From: log...@li... > [mailto:log...@li...] > Sent: Friday, January 22, 2010 9:29 AM > To: Rob Retter > Post by non-member to a members-only list > ^^^^^^^^^^ > > > > Um, no...not really. I joined the damned list ten minutes ago. But > thanks for the message. I'm beginning to suspect there simply is no way > to post anything here, so I think I'll just give up now. > I got your two messages just fine. So the list is working... But it's rather low traffic. Jean-Denis |
From: Rob R. <Rob...@cl...> - 2010-01-22 17:46:02
|
-----Original Message----- From: log...@li... [mailto:log...@li...] Sent: Friday, January 22, 2010 9:29 AM To: Rob Retter Subject: Your message to log4perl-devel awaits moderator approval Your mail to 'log4perl-devel' with the subject performance enhancement for timestamps Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list ^^^^^^^^^^ Um, no...not really. I joined the damned list ten minutes ago. But thanks for the message. I'm beginning to suspect there simply is no way to post anything here, so I think I'll just give up now. |
From: Rob R. <Rob...@cl...> - 2010-01-22 17:28:54
|
I sent this message a little while ago, but I was not then a member of the mailing list. I got no response and do not see it in the archives, so I can't tell if it's awaiting some sort of moderator approval, or it just got tossed into the trash. I've joined the list and am trying again. I apologize for any duplication(s) caused. ---------------------------------------------------------------------- In DateFormat.pm, the routine fmt() should not bother to recreate the time string over and over and over....You tend to see the same timestamp on numerous consecutive log entries (unless you're using milliseconds, which seems like overkill in many situations). Anyway, the code should be something like: { my $lastSecs = 0; my $lastMsecs = 0; my $lastFmt = ''; ########################################### sub format { ########################################### my($self, $secs, $msecs) = @_; $msecs = 0 unless defined $msecs; return $lastFmt if ($lastSecs == $secs and $lastMsecs == $msecs); my @time; if($GMTIME) { @time = gmtime($secs); } else { @time = localtime($secs); } # add milliseconds push @time, $msecs; my @values = (); for(@{$self->{stack}}) { my($val, $code) = @$_; if($code) { push @values, $code->($time[$val]); } else { push @values, $time[$val]; } } $lastSecs = $secs; $lastMsecs = $msecs; $lastFmt = sprintf($self->{fmt}, @values); return $lastFmt; } } |
From: Trevor L. <tl...@we...> - 2010-01-20 18:07:33
|
Hi, I'm adding logging to a high-traffic mod_perl website and am worried about the performance penalties of writing stuff to disc on every request. In production, we'd probably only be logging a few lines per request. I'm wondering what the common usage of log4perl is like in these situations. I've seen suggestions for piping messages to a message bus with something like Log::Log4perl::Appender::Spread, but I'd love to hear what the experiences of people on this list have been when deploying log4perl on high traffic sites. What's worked, what hasn't? Is anyone logging directly to a database? Thanks in advance for your insight, Trevor |
From: Mike S. <m...@pe...> - 2010-01-14 07:32:24
|
On Tue, 12 Jan 2010, Malcolm Nooning wrote: > Please add the above note to the faq. Done, thanks for the note! http://github.com/mschilli/log4perl/commit/aa140e15be803988ccee7ea3f1da83d5d5165a11 -- Mike Mike Schilli m...@pe... > > There is already a section in the FAQ.html entitled > "Log4perl complains that no initialization happened during > shutdown!" > The tell tale message is > 'Seems like no initialization happened. Forgot to call init()?" > The faq goes on to explain the "circular reference" problem. > > This can also happen when a new user neglects to "add_appender", as in > the form below. > $logger->add_appender($appender); > |
From: Malcolm N. <m.n...@co...> - 2010-01-13 01:13:23
|
Hello, There is already a section in the FAQ.html entitled "Log4perl complains that no initialization happened during shutdown!" The tell tale message is 'Seems like no initialization happened. Forgot to call init()?" The faq goes on to explain the "circular reference" problem. This can also happen when a new user neglects to "add_appender", as in the form below. $logger->add_appender($appender); Please add the above note to the faq. No points for guessing how I found this out. Excellent module, by the way. |
From: Martin J. E. <mar...@ea...> - 2010-01-06 12:01:40
|
Mike Schilli wrote: > Thanks for the detailed description, here's what's happening: > > This change in behavior was caused by a patch introduced with > Log-Log4perl-1.19 in > > > http://github.com/mschilli/log4perl/commit/35d86ae53859424ea3ac357eaf0f15d9e69f4bed > > > in September 2008. A detailed description of the issue at the time is > available in > > http://rt.cpan.org/Ticket/Display.html?id=38356 > > on the request tracker. It fixed problems with the caller_depth, but it > also introduced a change to get_logger() which bumped up the caller() > level to obtain the category (aka package name) of the calling package. > > This is probably a good opportunity to rethink how Log4perl wrapper > classes should be implemented. > > To implement a L4p wrapper class correctly, it needs to provide the > following four methods: > > 1 Wrap::get_logger() > 2 Wrap::get_logger( $package ) > 3 Wrap->get_logger() > 4 Wrap->get_logger( $package ) > > Calls #1 and #3 are supposed to obtain a logger with the category of the > calling package, not the category of the wrapper package. This is > especially difficult in case #3, as Log4perl doesn't know if "Wrap" is > a Log4perl wrapper or if it's the #2 signature where "$package" is an > application package called "Wrap". > > Another complication is that we don't know how "Wrap" is implemented. > Is it relaying the get_logger() call to Log4perl by implementing its own > get_logger function? Or is it simply inheriting from Log4perl? > > I've put together a fix to resolve this, please check out the > documentation: > > > http://github.com/mschilli/log4perl/commit/8ad3fbae60a4667aba848eb545c66339aeff161a > > > As this might break backward compatibility with earlier versions of > Log4perl, I'm interested in hearing what you think about it, feedback > definitely welcome. If I don't hear anything back, it'll go out with the > next release. > > You can play around with the new implementation, here's the tarball: > > http://github.com/mschilli/log4perl/tarball/wrapper_fix > > Also, I've opened a bug on RT to track this issue: > > https://rt.cpan.org/Ticket/Display.html?id=52913 > > Give it a spin! > > -- Mike > > Mike Schilli m...@pe... Thank you Mike. I've tried this now and it appears to fix the change in behaviour I reported and does not appear to break anything else I can see. I am now using the tarball you provided and will report if I see anything. I will also update the rt later today. Thanks again Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com > On Wed, 9 Dec 2009, Martin Evans wrote: > >> Mike Schilli wrote: >>> On Wed, 9 Dec 2009, Martin Evans wrote: >>> >>>> Since the upgrade we are getting no logging in one of the files we >>>> expected to get it. After a bit of searching around I discovered the >>>> module we were using was doing this: >>>> >>>> local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1; >>>> $h{logger} = Log::Log4perl->get_logger(); >>>> and the fix was to change the order of those lines. >>> >>> Thanks for reporting this, although I have a hard time imaginining how >>> increasing the caller_depth and then getting a logger would be different >>> from what you'd get if you did it in the reverse order. Not to mention >>> that it's puzzling why this would change the logging behavior, as >>> caller_depth is used mainly for cosmetic reasons in certain features >>> of the pattern layout. >>> >>> Can you provide a snippet of code that reproduces the problem in full? >>> That would really help track down the root of the problem. >>> >>> Thanks! >>> >>> -- Mike >>> >>> Mike Schilli >>> m...@pe... >>> >>> >> >> It was ending up with "main" and the category in the following code >> instead of DBIx::Log4perl. >> >> >> sub get_logger { # Get an instance (shortcut) >> ################################################## >> # get_logger() can be called in the following ways: >> # >> # (1) Log::Log4perl::get_logger() => () >> # (2) Log::Log4perl->get_logger() => ("Log::Log4perl") >> # (3) Log::Log4perl::get_logger($cat) => ($cat) >> # >> # (5) Log::Log4perl->get_logger($cat) => ("Log::Log4perl", $cat) >> # (6) L4pSubclass->get_logger($cat) => ("L4pSubclass", $cat) >> >> # Note that (4) L4pSubclass->get_logger() => ("L4pSubclass") >> # is indistinguishable from (3) and therefore can't be allowed. >> # Wrapper classes always have to specify the category explicitely. >> >> my $category; >> >> if(@_ == 0) { >> # 1 >> $category = scalar caller($Log::Log4perl::caller_depth); >> } elsif(@_ == 1) { >> # 2, 3 >> if($_[0] eq __PACKAGE__) { >> # 2 >> $category = scalar caller($Log::Log4perl::caller_depth); >> } else { >> $category = $_[0]; >> } >> } else { >> # 5, 6 >> $category = $_[1]; >> } >> >> # Delegate this to the logger module >> return Log::Log4perl::Logger->get_logger($category); >> } >> >> >> Here is an example: >> >> 1.pl >> ==== >> >> use Log::Log4perl qw(get_logger :levels); >> use DBIx::Log4perl; >> >> Log::Log4perl->init_and_watch('x.conf', 60); >> >> my $a = DBIx::Log4perl->new(); >> >> Log4perl.pm (put this in a dir called DBIx) >> =========== >> >> package DBIx::Log4perl; >> >> sub new >> { >> >> local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1; >> $h = Log::Log4perl->get_logger(); >> >> $h->debug("log msg"); >> >> } >> 1; >> >> x.conf >> ====== >> >> log4perl.logger=ERROR >> log4perl.logger.Server = INFO >> log4perl.logger.DBIx.Log4perl=DEBUG, X1 >> log4perl.appender.X1=Log::Log4perl::Appender::File >> log4perl.appender.X1.filename=dbix.log >> log4perl.appender.X1.mode=append >> log4perl.appender.X1.utf8 = 1 >> log4perl.appender.X1.umask = sub { 0002 } >> log4perl.appender.X1.layout=Log::Log4perl::Layout::PatternLayout >> log4perl.appender.X1.layout.ConversionPattern=%d %p> %F{1}:%L %M - %m%n >> >> then run >> perl -I/dir_where_DBIx_dir_is 1.pl >> >> nothing comes out in log. Change the depth after get_logger and it works. >> >> Martin >> -- >> Martin J. Evans >> Easysoft Limited >> http://www.easysoft.com >> >> ------------------------------------------------------------------------------ >> >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> log4perl-devel mailing list >> log...@li... >> https://lists.sourceforge.net/lists/listinfo/log4perl-devel >> > > > |
From: Martin J. E. <mar...@ea...> - 2009-12-20 09:59:07
|
Mike Schilli wrote: > Thanks for the detailed description, here's what's happening: > > This change in behavior was caused by a patch introduced with > Log-Log4perl-1.19 in > > > http://github.com/mschilli/log4perl/commit/35d86ae53859424ea3ac357eaf0f15d9e69f4bed > > > in September 2008. A detailed description of the issue at the time is > available in > > http://rt.cpan.org/Ticket/Display.html?id=38356 > > on the request tracker. It fixed problems with the caller_depth, but it > also introduced a change to get_logger() which bumped up the caller() > level to obtain the category (aka package name) of the calling package. > > This is probably a good opportunity to rethink how Log4perl wrapper > classes should be implemented. > > To implement a L4p wrapper class correctly, it needs to provide the > following four methods: > > 1 Wrap::get_logger() > 2 Wrap::get_logger( $package ) > 3 Wrap->get_logger() > 4 Wrap->get_logger( $package ) > > Calls #1 and #3 are supposed to obtain a logger with the category of the > calling package, not the category of the wrapper package. This is > especially difficult in case #3, as Log4perl doesn't know if "Wrap" is > a Log4perl wrapper or if it's the #2 signature where "$package" is an > application package called "Wrap". > > Another complication is that we don't know how "Wrap" is implemented. > Is it relaying the get_logger() call to Log4perl by implementing its own > get_logger function? Or is it simply inheriting from Log4perl? > > I've put together a fix to resolve this, please check out the > documentation: > > > http://github.com/mschilli/log4perl/commit/8ad3fbae60a4667aba848eb545c66339aeff161a > > > As this might break backward compatibility with earlier versions of > Log4perl, I'm interested in hearing what you think about it, feedback > definitely welcome. If I don't hear anything back, it'll go out with the > next release. > > You can play around with the new implementation, here's the tarball: > > http://github.com/mschilli/log4perl/tarball/wrapper_fix > > Also, I've opened a bug on RT to track this issue: > > https://rt.cpan.org/Ticket/Display.html?id=52913 > > Give it a spin! > > -- Mike > > Mike Schilli m...@pe... > Thanks Mike, I'm on holiday now and I doubt I'll get a chance to try this properly until the first week on January - if I do I'll let you know. Hope this fits in with your timescales - I will try it out as soon as I can. Martin > On Wed, 9 Dec 2009, Martin Evans wrote: > >> Mike Schilli wrote: >>> On Wed, 9 Dec 2009, Martin Evans wrote: >>> >>>> Since the upgrade we are getting no logging in one of the files we >>>> expected to get it. After a bit of searching around I discovered the >>>> module we were using was doing this: >>>> >>>> local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1; >>>> $h{logger} = Log::Log4perl->get_logger(); >>>> and the fix was to change the order of those lines. >>> >>> Thanks for reporting this, although I have a hard time imaginining how >>> increasing the caller_depth and then getting a logger would be >>> different >>> from what you'd get if you did it in the reverse order. Not to mention >>> that it's puzzling why this would change the logging behavior, as >>> caller_depth is used mainly for cosmetic reasons in certain features >>> of the pattern layout. >>> >>> Can you provide a snippet of code that reproduces the problem in full? >>> That would really help track down the root of the problem. >>> >>> Thanks! >>> >>> -- Mike >>> >>> Mike Schilli >>> m...@pe... >>> >>> >> >> It was ending up with "main" and the category in the following code >> instead of DBIx::Log4perl. >> >> >> sub get_logger { # Get an instance (shortcut) >> ################################################## >> # get_logger() can be called in the following ways: >> # >> # (1) Log::Log4perl::get_logger() => () >> # (2) Log::Log4perl->get_logger() => ("Log::Log4perl") >> # (3) Log::Log4perl::get_logger($cat) => ($cat) >> # >> # (5) Log::Log4perl->get_logger($cat) => ("Log::Log4perl", $cat) >> # (6) L4pSubclass->get_logger($cat) => ("L4pSubclass", $cat) >> >> # Note that (4) L4pSubclass->get_logger() => ("L4pSubclass") >> # is indistinguishable from (3) and therefore can't be allowed. >> # Wrapper classes always have to specify the category explicitely. >> >> my $category; >> >> if(@_ == 0) { >> # 1 >> $category = scalar caller($Log::Log4perl::caller_depth); >> } elsif(@_ == 1) { >> # 2, 3 >> if($_[0] eq __PACKAGE__) { >> # 2 >> $category = scalar caller($Log::Log4perl::caller_depth); >> } else { >> $category = $_[0]; >> } >> } else { >> # 5, 6 >> $category = $_[1]; >> } >> >> # Delegate this to the logger module >> return Log::Log4perl::Logger->get_logger($category); >> } >> >> >> Here is an example: >> >> 1.pl >> ==== >> >> use Log::Log4perl qw(get_logger :levels); >> use DBIx::Log4perl; >> >> Log::Log4perl->init_and_watch('x.conf', 60); >> >> my $a = DBIx::Log4perl->new(); >> >> Log4perl.pm (put this in a dir called DBIx) >> =========== >> >> package DBIx::Log4perl; >> >> sub new >> { >> >> local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth >> + 1; >> $h = Log::Log4perl->get_logger(); >> >> $h->debug("log msg"); >> >> } >> 1; >> >> x.conf >> ====== >> >> log4perl.logger=ERROR >> log4perl.logger.Server = INFO >> log4perl.logger.DBIx.Log4perl=DEBUG, X1 >> log4perl.appender.X1=Log::Log4perl::Appender::File >> log4perl.appender.X1.filename=dbix.log >> log4perl.appender.X1.mode=append >> log4perl.appender.X1.utf8 = 1 >> log4perl.appender.X1.umask = sub { 0002 } >> log4perl.appender.X1.layout=Log::Log4perl::Layout::PatternLayout >> log4perl.appender.X1.layout.ConversionPattern=%d %p> %F{1}:%L %M - %m%n >> >> then run >> perl -I/dir_where_DBIx_dir_is 1.pl >> >> nothing comes out in log. Change the depth after get_logger and it >> works. >> >> Martin >> -- >> Martin J. Evans >> Easysoft Limited >> http://www.easysoft.com >> >> ------------------------------------------------------------------------------ >> >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> log4perl-devel mailing list >> log...@li... >> https://lists.sourceforge.net/lists/listinfo/log4perl-devel >> > > |
From: Mike S. <m...@pe...> - 2009-12-19 21:21:07
|
Thanks for the detailed description, here's what's happening: This change in behavior was caused by a patch introduced with Log-Log4perl-1.19 in http://github.com/mschilli/log4perl/commit/35d86ae53859424ea3ac357eaf0f15d9e69f4bed in September 2008. A detailed description of the issue at the time is available in http://rt.cpan.org/Ticket/Display.html?id=38356 on the request tracker. It fixed problems with the caller_depth, but it also introduced a change to get_logger() which bumped up the caller() level to obtain the category (aka package name) of the calling package. This is probably a good opportunity to rethink how Log4perl wrapper classes should be implemented. To implement a L4p wrapper class correctly, it needs to provide the following four methods: 1 Wrap::get_logger() 2 Wrap::get_logger( $package ) 3 Wrap->get_logger() 4 Wrap->get_logger( $package ) Calls #1 and #3 are supposed to obtain a logger with the category of the calling package, not the category of the wrapper package. This is especially difficult in case #3, as Log4perl doesn't know if "Wrap" is a Log4perl wrapper or if it's the #2 signature where "$package" is an application package called "Wrap". Another complication is that we don't know how "Wrap" is implemented. Is it relaying the get_logger() call to Log4perl by implementing its own get_logger function? Or is it simply inheriting from Log4perl? I've put together a fix to resolve this, please check out the documentation: http://github.com/mschilli/log4perl/commit/8ad3fbae60a4667aba848eb545c66339aeff161a As this might break backward compatibility with earlier versions of Log4perl, I'm interested in hearing what you think about it, feedback definitely welcome. If I don't hear anything back, it'll go out with the next release. You can play around with the new implementation, here's the tarball: http://github.com/mschilli/log4perl/tarball/wrapper_fix Also, I've opened a bug on RT to track this issue: https://rt.cpan.org/Ticket/Display.html?id=52913 Give it a spin! -- Mike Mike Schilli m...@pe... On Wed, 9 Dec 2009, Martin Evans wrote: > Mike Schilli wrote: >> On Wed, 9 Dec 2009, Martin Evans wrote: >> >>> Since the upgrade we are getting no logging in one of the files we >>> expected to get it. After a bit of searching around I discovered the >>> module we were using was doing this: >>> >>> local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1; >>> $h{logger} = Log::Log4perl->get_logger(); >>> and the fix was to change the order of those lines. >> >> Thanks for reporting this, although I have a hard time imaginining how >> increasing the caller_depth and then getting a logger would be different >> from what you'd get if you did it in the reverse order. Not to mention >> that it's puzzling why this would change the logging behavior, as >> caller_depth is used mainly for cosmetic reasons in certain features >> of the pattern layout. >> >> Can you provide a snippet of code that reproduces the problem in full? >> That would really help track down the root of the problem. >> >> Thanks! >> >> -- Mike >> >> Mike Schilli >> m...@pe... >> >> > > It was ending up with "main" and the category in the following code > instead of DBIx::Log4perl. > > > sub get_logger { # Get an instance (shortcut) > ################################################## > # get_logger() can be called in the following ways: > # > # (1) Log::Log4perl::get_logger() => () > # (2) Log::Log4perl->get_logger() => ("Log::Log4perl") > # (3) Log::Log4perl::get_logger($cat) => ($cat) > # > # (5) Log::Log4perl->get_logger($cat) => ("Log::Log4perl", $cat) > # (6) L4pSubclass->get_logger($cat) => ("L4pSubclass", $cat) > > # Note that (4) L4pSubclass->get_logger() => ("L4pSubclass") > # is indistinguishable from (3) and therefore can't be allowed. > # Wrapper classes always have to specify the category explicitely. > > my $category; > > if(@_ == 0) { > # 1 > $category = scalar caller($Log::Log4perl::caller_depth); > } elsif(@_ == 1) { > # 2, 3 > if($_[0] eq __PACKAGE__) { > # 2 > $category = scalar caller($Log::Log4perl::caller_depth); > } else { > $category = $_[0]; > } > } else { > # 5, 6 > $category = $_[1]; > } > > # Delegate this to the logger module > return Log::Log4perl::Logger->get_logger($category); > } > > > Here is an example: > > 1.pl > ==== > > use Log::Log4perl qw(get_logger :levels); > use DBIx::Log4perl; > > Log::Log4perl->init_and_watch('x.conf', 60); > > my $a = DBIx::Log4perl->new(); > > Log4perl.pm (put this in a dir called DBIx) > =========== > > package DBIx::Log4perl; > > sub new > { > > local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1; > $h = Log::Log4perl->get_logger(); > > $h->debug("log msg"); > > } > 1; > > x.conf > ====== > > log4perl.logger=ERROR > log4perl.logger.Server = INFO > log4perl.logger.DBIx.Log4perl=DEBUG, X1 > log4perl.appender.X1=Log::Log4perl::Appender::File > log4perl.appender.X1.filename=dbix.log > log4perl.appender.X1.mode=append > log4perl.appender.X1.utf8 = 1 > log4perl.appender.X1.umask = sub { 0002 } > log4perl.appender.X1.layout=Log::Log4perl::Layout::PatternLayout > log4perl.appender.X1.layout.ConversionPattern=%d %p> %F{1}:%L %M - %m%n > > then run > perl -I/dir_where_DBIx_dir_is 1.pl > > nothing comes out in log. Change the depth after get_logger and it works. > > Martin > -- > Martin J. Evans > Easysoft Limited > http://www.easysoft.com > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > log4perl-devel mailing list > log...@li... > https://lists.sourceforge.net/lists/listinfo/log4perl-devel > |
From: Martin E. <mar...@ea...> - 2009-12-09 16:59:16
|
Mike Schilli wrote: > On Wed, 9 Dec 2009, Martin Evans wrote: > >> Since the upgrade we are getting no logging in one of the files we >> expected to get it. After a bit of searching around I discovered the >> module we were using was doing this: >> >> local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1; >> $h{logger} = Log::Log4perl->get_logger(); >> and the fix was to change the order of those lines. > > Thanks for reporting this, although I have a hard time imaginining how > increasing the caller_depth and then getting a logger would be different > from what you'd get if you did it in the reverse order. Not to mention > that it's puzzling why this would change the logging behavior, as > caller_depth is used mainly for cosmetic reasons in certain features > of the pattern layout. > > Can you provide a snippet of code that reproduces the problem in full? > That would really help track down the root of the problem. > > Thanks! > > -- Mike > > Mike Schilli > m...@pe... > > It was ending up with "main" and the category in the following code instead of DBIx::Log4perl. sub get_logger { # Get an instance (shortcut) ################################################## # get_logger() can be called in the following ways: # # (1) Log::Log4perl::get_logger() => () # (2) Log::Log4perl->get_logger() => ("Log::Log4perl") # (3) Log::Log4perl::get_logger($cat) => ($cat) # # (5) Log::Log4perl->get_logger($cat) => ("Log::Log4perl", $cat) # (6) L4pSubclass->get_logger($cat) => ("L4pSubclass", $cat) # Note that (4) L4pSubclass->get_logger() => ("L4pSubclass") # is indistinguishable from (3) and therefore can't be allowed. # Wrapper classes always have to specify the category explicitely. my $category; if(@_ == 0) { # 1 $category = scalar caller($Log::Log4perl::caller_depth); } elsif(@_ == 1) { # 2, 3 if($_[0] eq __PACKAGE__) { # 2 $category = scalar caller($Log::Log4perl::caller_depth); } else { $category = $_[0]; } } else { # 5, 6 $category = $_[1]; } # Delegate this to the logger module return Log::Log4perl::Logger->get_logger($category); } Here is an example: 1.pl ==== use Log::Log4perl qw(get_logger :levels); use DBIx::Log4perl; Log::Log4perl->init_and_watch('x.conf', 60); my $a = DBIx::Log4perl->new(); Log4perl.pm (put this in a dir called DBIx) =========== package DBIx::Log4perl; sub new { local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1; $h = Log::Log4perl->get_logger(); $h->debug("log msg"); } 1; x.conf ====== log4perl.logger=ERROR log4perl.logger.Server = INFO log4perl.logger.DBIx.Log4perl=DEBUG, X1 log4perl.appender.X1=Log::Log4perl::Appender::File log4perl.appender.X1.filename=dbix.log log4perl.appender.X1.mode=append log4perl.appender.X1.utf8 = 1 log4perl.appender.X1.umask = sub { 0002 } log4perl.appender.X1.layout=Log::Log4perl::Layout::PatternLayout log4perl.appender.X1.layout.ConversionPattern=%d %p> %F{1}:%L %M - %m%n then run perl -I/dir_where_DBIx_dir_is 1.pl nothing comes out in log. Change the depth after get_logger and it works. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com |
From: Mike S. <m...@pe...> - 2009-12-09 16:34:25
|
On Wed, 9 Dec 2009, Martin Evans wrote: > Since the upgrade we are getting no logging in one of the files we > expected to get it. After a bit of searching around I discovered the > module we were using was doing this: > > local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1; > $h{logger} = Log::Log4perl->get_logger(); > and the fix was to change the order of those lines. Thanks for reporting this, although I have a hard time imaginining how increasing the caller_depth and then getting a logger would be different from what you'd get if you did it in the reverse order. Not to mention that it's puzzling why this would change the logging behavior, as caller_depth is used mainly for cosmetic reasons in certain features of the pattern layout. Can you provide a snippet of code that reproduces the problem in full? That would really help track down the root of the problem. Thanks! -- Mike Mike Schilli m...@pe... |
From: Martin E. <mar...@ea...> - 2009-12-09 10:28:55
|
Hi, I'm only sending this on the off chance someone here might be interested - I've sorted the problem out at my end. We've been using Log::Log4perl 1.25 and previous versions for ages but moved to a new development machine. The old one was perl 5.8.8 and Log::Log4perl 1.25 and the new one is perl 5.10.0 and Log::Log4perl 1.26 (I'm not sure the Perl version matters but I have not tested that). Since the upgrade we are getting no logging in one of the files we expected to get it. After a bit of searching around I discovered the module we were using was doing this: local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1; $h{logger} = Log::Log4perl->get_logger(); and the fix was to change the order of those lines. I've no idea why it works on one machine and not the other but I thought someone might be interested. The module in question was DBIx::Log4perl. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com |
From: Linke M. (K. 11) <mar...@cr...> - 2009-11-26 06:51:17
|
True :) to make things even more mysterious, it's only for one of my scripts, all the others don't show the issue. Same perl binary (same location), same perl-library settings ... Hmmmmmmmmmmmmmmmmmm .... -----Original Message----- From: Mike Schilli [mailto:m...@pe...] Sent: Mittwoch, 25. November 2009 18:52 To: Linke Markus (KSTB 11) Cc: Mike Schilli; log...@li... Subject: RE: [log4perl-devel] package 'Log::Dispatch::Email::MailSender' notregistered for warnings On Wed, 25 Nov 2009, Linke Markus (KSTB 11) wrote: > In regards to the version check: I did compare all modules and they > are identical. That's why I wanted to see if there might be anything > else beside the modules which comes into your mind. The perl version > is also the same. Something tells me that identical installation should behave identically :). You might also want to check if perl is actually pulling the correct version of the module, sometimes people install identical modules in multiple locations. -- Mike Mike Schilli m...@pe... > > -----Original Message----- > From: Mike Schilli [mailto:m...@pe...] > Sent: Mittwoch, 25. November 2009 04:39 > To: Linke Markus (KSTB 11) > Cc: Mike Schilli; log...@li... > Subject: RE: [log4perl-devel] package 'Log::Dispatch::Email::MailSender' > notregistered for warnings > > On Tue, 24 Nov 2009, Linke Markus (KSTB 11) wrote: > >> Strange enough I now have the same problem again on our production >> server. I have just checked the modules and they are the same as on >> the dev box where upgrading Log::Dispatch had solved the issue before. > > As I might have mentioned before, Log::Dispatch is a separate module > maintained by a different crew. > > But since you said the upgrade fixed your development box, I suspect > that the upgrade on the production box didn't go over well and maybe > you're still pulling the old version? Try > > $ /usr/local/bin/perl -d -e 1 > DB<1> use Log::Dispatch > DB<2> print $Log::Dispatch::VERSION > > and check the version number printed. > > -- Mike > > Mike Schilli > m...@pe... > >> >> Any ideas? >> >> Thanks, >> Markus >> >> >> -----Original Message----- >> From: Linke Markus (KSTB 11) >> Sent: Freitag, 10. Juli 2009 07:56 >> To: Mike Schilli >> Cc: log...@li... >> Subject: Re: [log4perl-devel] package > 'Log::Dispatch::Email::MailSender' >> notregistered for warnings >> >> Problem solved; thanks a lot! >> >> -----Original Message----- >> From: Mike Schilli [mailto:m...@pe...] >> Sent: Mittwoch, 8. Juli 2009 18:53 >> To: Linke Markus (KSTB 11) >> Cc: Mike Schilli; log...@li... >> Subject: RE: [log4perl-devel] package > 'Log::Dispatch::Email::MailSender' >> not registered for warnings >> >> On Wed, 8 Jul 2009, Linke Markus (KSTB 11) wrote: >> >>> I only have 2.21, you think that might be the reason? >> >> Possibly. I'm not affiliated with Log::Dispatch, but its 2.22 change > log >> has the line >> >> "- Fixed a misuse of warnings::enabled(). Reported by Darian Patrick. > RT >> #39784." >> >> which indicates a fix in this area. Give it a try! >> >> -- Mike >> >> Mike Schilli >> m...@pe... >> >> > ------------------------------------------------------------------------ >> ------ >> Enter the BlackBerry Developer Challenge >> This is your chance to win up to $100,000 in prizes! For a limited > time, >> >> vendors submitting new applications to BlackBerry App World(TM) will >> have >> the opportunity to enter the BlackBerry Developer Challenge. See full >> prize >> details at: http://p.sf.net/sfu/Challenge >> _______________________________________________ >> log4perl-devel mailing list >> log...@li... >> https://lists.sourceforge.net/lists/listinfo/log4perl-devel >> > |
From: Mike S. <m...@pe...> - 2009-11-25 17:51:53
|
On Wed, 25 Nov 2009, Linke Markus (KSTB 11) wrote: > In regards to the version check: I did compare all modules and they > are identical. That's why I wanted to see if there might be anything > else beside the modules which comes into your mind. The perl version > is also the same. Something tells me that identical installation should behave identically :). You might also want to check if perl is actually pulling the correct version of the module, sometimes people install identical modules in multiple locations. -- Mike Mike Schilli m...@pe... > > -----Original Message----- > From: Mike Schilli [mailto:m...@pe...] > Sent: Mittwoch, 25. November 2009 04:39 > To: Linke Markus (KSTB 11) > Cc: Mike Schilli; log...@li... > Subject: RE: [log4perl-devel] package 'Log::Dispatch::Email::MailSender' > notregistered for warnings > > On Tue, 24 Nov 2009, Linke Markus (KSTB 11) wrote: > >> Strange enough I now have the same problem again on our production >> server. I have just checked the modules and they are the same as on >> the dev box where upgrading Log::Dispatch had solved the issue before. > > As I might have mentioned before, Log::Dispatch is a separate module > maintained by a different crew. > > But since you said the upgrade fixed your development box, I suspect > that the upgrade on the production box didn't go over well and maybe > you're still pulling the old version? Try > > $ /usr/local/bin/perl -d -e 1 > DB<1> use Log::Dispatch > DB<2> print $Log::Dispatch::VERSION > > and check the version number printed. > > -- Mike > > Mike Schilli > m...@pe... > >> >> Any ideas? >> >> Thanks, >> Markus >> >> >> -----Original Message----- >> From: Linke Markus (KSTB 11) >> Sent: Freitag, 10. Juli 2009 07:56 >> To: Mike Schilli >> Cc: log...@li... >> Subject: Re: [log4perl-devel] package > 'Log::Dispatch::Email::MailSender' >> notregistered for warnings >> >> Problem solved; thanks a lot! >> >> -----Original Message----- >> From: Mike Schilli [mailto:m...@pe...] >> Sent: Mittwoch, 8. Juli 2009 18:53 >> To: Linke Markus (KSTB 11) >> Cc: Mike Schilli; log...@li... >> Subject: RE: [log4perl-devel] package > 'Log::Dispatch::Email::MailSender' >> not registered for warnings >> >> On Wed, 8 Jul 2009, Linke Markus (KSTB 11) wrote: >> >>> I only have 2.21, you think that might be the reason? >> >> Possibly. I'm not affiliated with Log::Dispatch, but its 2.22 change > log >> has the line >> >> "- Fixed a misuse of warnings::enabled(). Reported by Darian Patrick. > RT >> #39784." >> >> which indicates a fix in this area. Give it a try! >> >> -- Mike >> >> Mike Schilli >> m...@pe... >> >> > ------------------------------------------------------------------------ >> ------ >> Enter the BlackBerry Developer Challenge >> This is your chance to win up to $100,000 in prizes! For a limited > time, >> >> vendors submitting new applications to BlackBerry App World(TM) will >> have >> the opportunity to enter the BlackBerry Developer Challenge. See full >> prize >> details at: http://p.sf.net/sfu/Challenge >> _______________________________________________ >> log4perl-devel mailing list >> log...@li... >> https://lists.sourceforge.net/lists/listinfo/log4perl-devel >> > |
From: Linke M. (K. 11) <mar...@cr...> - 2009-11-25 09:00:23
|
Thanks Mike, you are obviously right about using the Log::Dispatch mailing list instead, it was just that I did get the right answer last time here, so I just tried :) In regards to the version check: I did compare all modules and they are identical. That's why I wanted to see if there might be anything else beside the modules which comes into your mind. The perl version is also the same. -----Original Message----- From: Mike Schilli [mailto:m...@pe...] Sent: Mittwoch, 25. November 2009 04:39 To: Linke Markus (KSTB 11) Cc: Mike Schilli; log...@li... Subject: RE: [log4perl-devel] package 'Log::Dispatch::Email::MailSender' notregistered for warnings On Tue, 24 Nov 2009, Linke Markus (KSTB 11) wrote: > Strange enough I now have the same problem again on our production > server. I have just checked the modules and they are the same as on > the dev box where upgrading Log::Dispatch had solved the issue before. As I might have mentioned before, Log::Dispatch is a separate module maintained by a different crew. But since you said the upgrade fixed your development box, I suspect that the upgrade on the production box didn't go over well and maybe you're still pulling the old version? Try $ /usr/local/bin/perl -d -e 1 DB<1> use Log::Dispatch DB<2> print $Log::Dispatch::VERSION and check the version number printed. -- Mike Mike Schilli m...@pe... > > Any ideas? > > Thanks, > Markus > > > -----Original Message----- > From: Linke Markus (KSTB 11) > Sent: Freitag, 10. Juli 2009 07:56 > To: Mike Schilli > Cc: log...@li... > Subject: Re: [log4perl-devel] package 'Log::Dispatch::Email::MailSender' > notregistered for warnings > > Problem solved; thanks a lot! > > -----Original Message----- > From: Mike Schilli [mailto:m...@pe...] > Sent: Mittwoch, 8. Juli 2009 18:53 > To: Linke Markus (KSTB 11) > Cc: Mike Schilli; log...@li... > Subject: RE: [log4perl-devel] package 'Log::Dispatch::Email::MailSender' > not registered for warnings > > On Wed, 8 Jul 2009, Linke Markus (KSTB 11) wrote: > >> I only have 2.21, you think that might be the reason? > > Possibly. I'm not affiliated with Log::Dispatch, but its 2.22 change log > has the line > > "- Fixed a misuse of warnings::enabled(). Reported by Darian Patrick. RT > #39784." > > which indicates a fix in this area. Give it a try! > > -- Mike > > Mike Schilli > m...@pe... > > ------------------------------------------------------------------------ > ------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > > vendors submitting new applications to BlackBerry App World(TM) will > have > the opportunity to enter the BlackBerry Developer Challenge. See full > prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > log4perl-devel mailing list > log...@li... > https://lists.sourceforge.net/lists/listinfo/log4perl-devel > |