log4perl-devel — Ongoing log4perl development

[log4perl-devel] 1.26 installation fails date test with perl v5.10.0

[Ming <mi...@gm...>]

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

Re: [log4perl-devel] Masking secrets in log4perl output

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

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
>

[log4perl-devel] Masking secrets in log4perl output

[Maciej G. <mac...@gm...>]

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

[log4perl-devel] invoking threshold() leaves appender data inconsistent

[Rob R. <Rob...@cl...>]

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

Re: [log4perl-devel] question re: running system commands from a wrapper

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

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

[log4perl-devel] question re: running system commands from a wrapper

[Keith C. <kei...@gm...>]

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

Re: [log4perl-devel] Log4perl best practices for high traffic sites

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

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

Re: [log4perl-devel] [FR] CODE refs in config file.

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

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

[log4perl-devel] [FR] CODE refs in config file.

[Silkenbäumer, K. <si...@im...>]

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

Re: [log4perl-devel] performance enhancement for timestamps

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

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
>

Re: [log4perl-devel] FW: Your message to log4perl-devel awaits moderator approval

[Jean-Denis M. <jd...@kl...>]

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

[log4perl-devel] FW: Your message to log4perl-devel awaits moderator approval

[Rob R. <Rob...@cl...>]

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

[log4perl-devel] performance enhancement for timestamps

[Rob R. <Rob...@cl...>]

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

}

[log4perl-devel] Log4perl best practices for high traffic sites

[Trevor L. <tl...@we...>]

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

Re: [log4perl-devel] Please add comments to FAQ

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

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

[log4perl-devel] Please add comments to FAQ

[Malcolm N. <m.n...@co...>]

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.

Re: [log4perl-devel] Change in behavior when upgrading to 1.26 and perl 5.10.0

[Martin J. E. <mar...@ea...>]

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

Re: [log4perl-devel] Change in behavior when upgrading to 1.26 and perl 5.10.0

[Martin J. E. <mar...@ea...>]

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

Re: [log4perl-devel] Change in behavior when upgrading to 1.26 and perl 5.10.0

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

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
>

Re: [log4perl-devel] Change in behavior when upgrading to 1.26 and perl 5.10.0

[Martin E. <mar...@ea...>]

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

Re: [log4perl-devel] Change in behavior when upgrading to 1.26 and perl 5.10.0

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

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

[log4perl-devel] Change in behavior when upgrading to 1.26 and perl 5.10.0

[Martin E. <mar...@ea...>]

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

Re: [log4perl-devel] package 'Log::Dispatch::Email::MailSender' notregistered for warnings

[Linke M. (K. 11) <mar...@cr...>]

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

Re: [log4perl-devel] package 'Log::Dispatch::Email::MailSender' notregistered for warnings

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

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

Re: [log4perl-devel] package 'Log::Dispatch::Email::MailSender' notregistered for warnings

[Linke M. (K. 11) <mar...@cr...>]

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
>