log4perl-devel — Ongoing log4perl development

[log4perl-devel] Introspecting the $logger object for log file path and name?

[Hugh E. <he...@ca...>]

Using Log::Log4perl, I need to test for the existence of a log path and
create it if necessary, I had hopes that this might give me what I was
looking for:  

	my $path = 
		Log::Log4perl->appender_by_name(
			'log4perl.appender.A1.filename'); 

But I am getting (on the next line):  

	Use of uninitialized value $path in substitution.  

Is there some way to query the class or perhaps the $logger object for
what path and filename it expects from the configuration so I can
created it before it is needed and its absence blows things up?  

I would try this with the $logger object itself, but attempting to
instantiate one when the log file's path is missing blows things up.  

How do I automate this process so that an arbitrary path and file are
created when my application is deployed into a fresh bare-metal
environment?

-- 
Hugh Esco 
skype: hresco3_ ; 678-921-8186 
http://www.CampaignFoundations.com/
Providing Application Hosting, Telephony, 
Custom Development and Consulting Services 
to Green Candidates, Green Parties and
the non profits working for a just and sustainable future.

if( $insurance->rationing() ) { $people->die(); }
if( isa_ok($self,'Troy::Davis') =~ m/^ok/) { $people->are_whole(); }

[log4perl-devel] Log::Log4perl 1.40 released

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

The Log::Log4perl 1.40 maintenance release has just been release to
CPAN. Here's what's new:

1.40 (2012/11/30)
    * (ms) Denis Ibaev added support for DBI appender attributes.
    * (ms) Chris Weyl put in a workaround for a DBD::CSV bug that
           tripped our test suite.
    * (ms) Tim Bunce provided a patch using Carp::confess() instead of die()
           on the "Root Logger not initialized" message which pops up
           during global construction to make it easier to find the
           offending code.
    * (ms) Cygwin masks MSWin32-ishness by setting $^O to "cygwin" and not
           to "Win32". Modified check to catch both.
    * (ms) Fixed unescaped brace in regex that perl 5.17.4 was complaining
           about.

Enjoy!

-- 
-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] Categories - doc/implementation problem ??

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

On Fri, 23 Nov 2012, David Pointon wrote:

> I'm sure I can't be the only one to have tried the my $logger
> = Log::Log4perl->new($class); way of dynamically creating a category

Hi David,

sorry, that part in the docs dates back to 2002 and it's a typo, it
should be Log::Log4perl->get_logger($class) instead. Fixed it:

     https://github.com/mschilli/log4perl/commit/2ba79b11eda280845559fb6df93b0a0375a42043


> I only tried this because, having created a root logger with
> category Foo::Bar, all get_logger($class) calls (where $class is
> in Foo::Bar or a subclass thereof) return an Log::Log4perl::Logger
> object whereas I expected, but could not get, a Foo::Bar or
> Foo::Bar::Logger object.

Hmm, I didn't quite get what you meant there, can you elaborate on what 
you're trying to accomplish?

-- 
-- Mike

Mike Schilli
m...@pe...

>
> Rgds ,
>
> --
> D.C. Pointon FIAP MBCS | Now I saw, tho' too late, the folly of
> 07810 645299           | beginning a work before we count the cost
> 01730 233886           | and before we judge rightly of our strength
>                       | to go thro' with  it. Robinson Crusoe
>
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

>Using category within the configuration
> isn't an option because, on a per-package basis, the composition
> of the categories is not determined 'til run-time and may change
> even then.

Re: [log4perl-devel] API for fetching the category from a logger?

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

On Sun, 4 Nov 2012, dan...@sa... wrote:

> I can't see an API for fetching the category of a logger. Is there a
> reason for that?

Sorry for the long wait on this, somehow your email got stuck in spam
quarantaine.

You're right, there's currently no accessor for a logger's category,
I've added one just now:

     https://github.com/mschilli/log4perl/commit/67360dc96380a878a267c4f434dd8b6c7d2a4031

To work around the limitation, you can use $logger->{category} till it
rolls out with the next release.

Thanks for bringing this issue to my attention.

-- 
-- Mike

Mike Schilli
m...@pe...


>
> In particular, I'd like to make a "daughter" logger from an existing one.  i.e. given
>
>  my $logger = get_logger("com.sadinoff.hello");
>
>
> . . .
>
> I'd like to say
>
>    my $subLogger = $logger->get_daughter_logger("foobar")
>
> ...and have the category be "com.sadinoff.hello.foobar".
>
> I thought maybe I'd do
>
>    get_logger($logger->getCategory() . ".foobar")
>
> ..but I don't see anything like either method above.  I *could* just
> fetch $logger->{category}, but I doubt that would be supported.
>
>
> ———
> Danny Sadinoff
> dan...@sa...
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel

[log4perl-devel] Categories - doc/implementation problem ??

[David P. <dav...@te...>]

Hi ,

I'm sure I can't be the only one to have tried the my $logger = Log::Log4perl->new($class); way of dynamically creating a category as suggested here (http://search.cpan.org/~mschilli/Log-Log4perl-1.39/lib/Log/Log4perl.pm#Categories) but end up with a 'THIS CLASS ISN'T FOR DIRECT USE. PLEASE CHECK...' error.

I only tried this because, having created a root logger with category Foo::Bar, all get_logger($class) calls (where $class is in Foo::Bar or a subclass thereof) return an Log::Log4perl::Logger object whereas I expected, but could not get, a Foo::Bar or Foo::Bar::Logger object. Using category within the configuration isn't an option because, on a per-package basis, the composition of the categories is not determined 'til run-time and may change even then.

Rgds ,

--
D.C. Pointon FIAP MBCS | Now I saw, tho' too late, the folly of
07810 645299           | beginning a work before we count the cost
01730 233886           | and before we judge rightly of our strength
                       | to go thro' with  it. Robinson Crusoe

[log4perl-devel] API for fetching the category from a logger?

[<dan...@sa...>]

I can't see an API for fetching the category of a logger.  Is there a reason for that?

In particular, I'd like to make a "daughter" logger from an existing one.  i.e. given

  my $logger = get_logger("com.sadinoff.hello");


. . .

I'd like to say

    my $subLogger = $logger->get_daughter_logger("foobar")

...and have the category be "com.sadinoff.hello.foobar".

I thought maybe I'd do

    get_logger($logger->getCategory() . ".foobar")

..but I don't see anything like either method above.  I *could* just
fetch $logger->{category}, but I doubt that would be supported.


———
Danny Sadinoff
dan...@sa...

[log4perl-devel] Log::Log4perl 1.39 released

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

Log4perl enthusiasts,

I've just released 1.39 with the following maintenance fixes:

1.39 (2012/10/27)
    *    (ms) Markus Benning reported that logcroak/confess/die stringify
              their arguments, which gets in the way when throwing data
              structures as exceptions. Added flag $STRINGIFY_DIE_MESSAGE.
    *    (ms) [rt.cpan.org #80086] David Morel pointed out misleading
              documentation in the Limiter composite appender. Fixed docs
              and added C<appender_method_on_flush> parameter to support
              appender flush calls by the limiter.
    *    (ms) [rt.cpan.org #79960] Fabrice Gabolde asked for %X{x} to be
              interpolated as NULL for the database appender if its value is
              undef. The DBI appender now inits PatternLayout with the
              undef_column_name parameter set to undef (defaults to "[undef]").
    *    (ms) Updated license/copyright/author sections in all files using
              licensizer and .licensizer.yml.
    *    (ms) Skipped log file recreation test on Win32 as it won't remove
              busy files anyway.

It should soon be available on your local CPAN mirror.

Enjoy!

-- 
-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] logcroak always stringifies when croak()ing

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

On Thu, 18 Oct 2012, BENNING, Markus wrote:

> I also would suggest to introduce a flag to avoid breaking existing
> code.  Since the option will be documented in the pod the behavior
> should be clear.

Done, will be released with 1.39:

     https://github.com/mschilli/log4perl/commit/33a34e0ea50fc785376abc9456bd7711193ba29e

Let me know if it works for you ...

-- 
-- Mike

Mike Schilli
m...@pe...

>
> Markus
>
> -----Ursprüngliche Nachricht-----
> Von: Mike Schilli [mailto:m...@pe...]
> Gesendet: Donnerstag, 18. Oktober 2012 09:29
> An: BENNING, Markus
> Cc: log...@li...
> Betreff: Re: [log4perl-devel] logcroak always stringifies when croak()ing
>
> On Mon, 15 Oct 2012, BENNING, Markus (ext) wrote:
>
>> Shouldn't logcroak log a stringified version and call croak on the
>> value you passed to it instead of calling croak on the log message?
>
> I guess that makes sense if you're using it for throwing exceptions, but I've never used it that way and that's the reason why logcroak() (and its
> companions) is using Log::Log4perl::Logger::warning_render() to format the message before it passes it to croak() et al.
>
> Of course, that's not easy to change now, because some people rely on the feature, but as a horrible hack, you could use something like
>
>     { no warnings qw( redefine );
>         *Log::Log4perl::Logger::warning_render = sub {
>             return $_[1];
>         }
>     }
>
> We should probably provide a flag you can set. What do you think?
>
>> The docs say: "Finally, there's the Carp functions that do just what
>> the Carp functions do, but with logging:"
>
> Fixed!
>
> https://github.com/mschilli/log4perl/commit/56c95a2d131678c4908785695fac0e56175c7b44
>
> --
> -- Mike
>
> Mike Schilli
> m...@pe...
>
>> I noticed that logcroak (die,confess...) always die()s with a
>> stringified version of what you pass to it.
>>
>> Here's an example:
>>
>> ---
>> #!/usr/bin/env perl
>>
>> package Status;
>>
>> use Moose;
>>
>> use Log::Log4perl qw(:easy);
>> Log::Log4perl->easy_init($ERROR);
>>
>> use Carp;
>>
>> use overload
>>    q{""}    => sub { $_[0]->as_string },
>>    fallback => 1;
>>
>> has 'logger' => (
>>        is => 'ro', isa => 'Log::Log4perl::Logger', lazy => 1,
>>        default => sub {
>>                return( Log::Log4perl->get_logger('Status') );
>>        },
>> );
>>
>> has code => ( is => 'ro', isa => 'Int', required => 1 ); has message
>> => ( is => 'ro', isa => 'Str', required => 1 );
>>
>> sub as_string {
>>    my ($self) = @_;
>>    return ( sprintf( 'Status: %s (%s)', $self->message, $self->code )
>> ); }
>>
>> sub throw {
>>        my $self = shift;
>>        croak($self);
>> }
>>
>> sub throw_log4perl {
>>        my $self = shift;
>>        $self->logger->logcroak($self); }
>>
>> package main;
>>
>> use Data::Dumper;
>>
>> my $s = Status->new( code => 500, message => 'Foobar');
>>
>> eval { $s->throw };
>> print Dumper($@);
>>
>> eval { $s->throw_log4perl };
>> print Dumper($@);
>> --- END
>>
>> --- Output:
>> $VAR1 = bless( {
>>                 'message' => 'Foobar',
>>                 'code' => 500
>>               }, 'Status' );
>> 2012/10/15 12:19:41 ESB Error: Foobar (500) at log4perl-test.pl line
>> 50
>> $VAR1 = 'ESB Error: Foobar (500) at log4perl-test.pl line 50 ';
>> ---
>>
>

Re: [log4perl-devel] logcroak always stringifies when croak()ing

[BENNING, M. <mar...@at...>]

I fixed the problem for me by replacing logcroak with $logger->error("$e"); croak($e);

I also would suggest to introduce a flag to avoid breaking existing code.
Since the option will be documented in the pod the behavior should be clear.

Markus

-----Ursprüngliche Nachricht-----
Von: Mike Schilli [mailto:m...@pe...] 
Gesendet: Donnerstag, 18. Oktober 2012 09:29
An: BENNING, Markus
Cc: log...@li...
Betreff: Re: [log4perl-devel] logcroak always stringifies when croak()ing

On Mon, 15 Oct 2012, BENNING, Markus (ext) wrote:

> Shouldn't logcroak log a stringified version and call croak on the 
> value you passed to it instead of calling croak on the log message?

I guess that makes sense if you're using it for throwing exceptions, but I've never used it that way and that's the reason why logcroak() (and its
companions) is using Log::Log4perl::Logger::warning_render() to format the message before it passes it to croak() et al.

Of course, that's not easy to change now, because some people rely on the feature, but as a horrible hack, you could use something like

     { no warnings qw( redefine );
         *Log::Log4perl::Logger::warning_render = sub {
             return $_[1];
         }
     }

We should probably provide a flag you can set. What do you think?

> The docs say: "Finally, there's the Carp functions that do just what 
> the Carp functions do, but with logging:"

Fixed!

https://github.com/mschilli/log4perl/commit/56c95a2d131678c4908785695fac0e56175c7b44

--
-- Mike

Mike Schilli
m...@pe...

> I noticed that logcroak (die,confess...) always die()s with a 
> stringified version of what you pass to it.
>
> Here's an example:
>
> ---
> #!/usr/bin/env perl
>
> package Status;
>
> use Moose;
>
> use Log::Log4perl qw(:easy);
> Log::Log4perl->easy_init($ERROR);
>
> use Carp;
>
> use overload
>    q{""}    => sub { $_[0]->as_string },
>    fallback => 1;
>
> has 'logger' => (
>        is => 'ro', isa => 'Log::Log4perl::Logger', lazy => 1,
>        default => sub {
>                return( Log::Log4perl->get_logger('Status') );
>        },
> );
>
> has code => ( is => 'ro', isa => 'Int', required => 1 ); has message 
> => ( is => 'ro', isa => 'Str', required => 1 );
>
> sub as_string {
>    my ($self) = @_;
>    return ( sprintf( 'Status: %s (%s)', $self->message, $self->code ) 
> ); }
>
> sub throw {
>        my $self = shift;
>        croak($self);
> }
>
> sub throw_log4perl {
>        my $self = shift;
>        $self->logger->logcroak($self); }
>
> package main;
>
> use Data::Dumper;
>
> my $s = Status->new( code => 500, message => 'Foobar');
>
> eval { $s->throw };
> print Dumper($@);
>
> eval { $s->throw_log4perl };
> print Dumper($@);
> --- END
>
> --- Output:
> $VAR1 = bless( {
>                 'message' => 'Foobar',
>                 'code' => 500
>               }, 'Status' );
> 2012/10/15 12:19:41 ESB Error: Foobar (500) at log4perl-test.pl line 
> 50
> $VAR1 = 'ESB Error: Foobar (500) at log4perl-test.pl line 50 ';
> ---
>

Re: [log4perl-devel] logcroak always stringifies when croak()ing

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

On Mon, 15 Oct 2012, BENNING, Markus (ext) wrote:

> Shouldn't logcroak log a stringified version and call croak on the
> value you passed to it instead of calling croak on the log message?

I guess that makes sense if you're using it for throwing exceptions, but
I've never used it that way and that's the reason why logcroak() (and its
companions) is using Log::Log4perl::Logger::warning_render() to format
the message before it passes it to croak() et al.

Of course, that's not easy to change now, because some people rely on
the feature, but as a horrible hack, you could use something like

     { no warnings qw( redefine );
         *Log::Log4perl::Logger::warning_render = sub {
             return $_[1];
         }
     }

We should probably provide a flag you can set. What do you think?

> The docs say: "Finally, there's the Carp functions that do just what
> the Carp functions do, but with logging:"

Fixed!

https://github.com/mschilli/log4perl/commit/56c95a2d131678c4908785695fac0e56175c7b44

-- 
-- Mike

Mike Schilli
m...@pe...

> I noticed that logcroak (die,confess...) always die()s with
> a stringified version of what you pass to it.
>
> Here's an example:
>
> ---
> #!/usr/bin/env perl
>
> package Status;
>
> use Moose;
>
> use Log::Log4perl qw(:easy);
> Log::Log4perl->easy_init($ERROR);
>
> use Carp;
>
> use overload
>    q{""}    => sub { $_[0]->as_string },
>    fallback => 1;
>
> has 'logger' => (
>        is => 'ro', isa => 'Log::Log4perl::Logger', lazy => 1,
>        default => sub {
>                return( Log::Log4perl->get_logger('Status') );
>        },
> );
>
> has code => ( is => 'ro', isa => 'Int', required => 1 );
> has message => ( is => 'ro', isa => 'Str', required => 1 );
>
> sub as_string {
>    my ($self) = @_;
>    return ( sprintf( 'Status: %s (%s)', $self->message, $self->code ) );
> }
>
> sub throw {
>        my $self = shift;
>        croak($self);
> }
>
> sub throw_log4perl {
>        my $self = shift;
>        $self->logger->logcroak($self);
> }
>
> package main;
>
> use Data::Dumper;
>
> my $s = Status->new( code => 500, message => 'Foobar');
>
> eval { $s->throw };
> print Dumper($@);
>
> eval { $s->throw_log4perl };
> print Dumper($@);
> --- END
>
> --- Output:
> $VAR1 = bless( {
>                 'message' => 'Foobar',
>                 'code' => 500
>               }, 'Status' );
> 2012/10/15 12:19:41 ESB Error: Foobar (500) at log4perl-test.pl line 50
> $VAR1 = 'ESB Error: Foobar (500) at log4perl-test.pl line 50
> ';
> ---
>

[log4perl-devel] logcroak always stringifies when croak()ing

[BENNING, M. (ext) <mar...@at...>]

Hello Log4perl Developers,

I noticed that logcroak (die,confess...) always die()s with a stringified
version of what you pass to it.

Here's an example:

---
#!/usr/bin/env perl

package Status;

use Moose;

use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init($ERROR);

use Carp;

use overload
    q{""}    => sub { $_[0]->as_string },
    fallback => 1;

has 'logger' => (
        is => 'ro', isa => 'Log::Log4perl::Logger', lazy => 1,
        default => sub {
                return( Log::Log4perl->get_logger('Status') );
        },
);

has code => ( is => 'ro', isa => 'Int', required => 1 );
has message => ( is => 'ro', isa => 'Str', required => 1 );

sub as_string {
    my ($self) = @_;
    return ( sprintf( 'Status: %s (%s)', $self->message, $self->code ) );
}

sub throw {
        my $self = shift;
        croak($self);
}

sub throw_log4perl {
        my $self = shift;
        $self->logger->logcroak($self);
}

package main;

use Data::Dumper;

my $s = Status->new( code => 500, message => 'Foobar');

eval { $s->throw };
print Dumper($@);

eval { $s->throw_log4perl };
print Dumper($@);
--- END

--- Output:
$VAR1 = bless( {
                 'message' => 'Foobar',
                 'code' => 500
               }, 'Status' );
2012/10/15 12:19:41 ESB Error: Foobar (500) at log4perl-test.pl line 50
$VAR1 = 'ESB Error: Foobar (500) at log4perl-test.pl line 50
';
---

Shouldn't logcroak log a stringified version and call croak on the value you passed to it
instead of calling croak on the log message?

The docs say: "Finally, there's the Carp functions that do just what the Carp functions do, but with logging:"

Regards,
Markus Benning

Re: [log4perl-devel] Bug: Wrapped logdie reports wrong file/line

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

On Tue, 18 Sep 2012, Bob Kleemann wrote:

> When might I expect 1.38 to be released to CPAN?

I've just pushed 1.38 to CPAN, should be on your mirror soon.

> Also, I note that you didn't change Log::Log4perl::get_logger to use
> caller_depth_offset.  I'm not sure if that was intentional or not.

Yeah, saw that, but the code is sufficiently different and the data
structure used for the wrappers is local to the package, so I think it's
good enough for now. If you have a patch to integrate it more tightly,
by all means, send it, I'll be happy to apply it :).

-- 
-- Mike

Mike Schilli
m...@pe...

> On Tue, Sep 18, 2012 at 12:28 AM, Mike Schilli <m...@pe...>
> wrote:
>> On Mon, 17 Sep 2012, Bob Kleemann wrote:
>>
>>> It prints the write file/line on the logged message (-e:1), but not on
>>> the die message (perllib/WSL/... line 174).
>>
>>
>> Hi Bob,
>>
>> thanks for reporting this issue, I've provided a fix here:
>>
>>
>> https://github.com/mschilli/log4perl/commit/e258163ef2c219e082419e6158ad6fa96eeebc5d
>>
>> You can download the updated tarball from:
>>
>>     https://github.com/mschilli/log4perl/tarball/1.38logdie
>>
>> Would be great if you could give it a whirl, let me know if it's working
>> for you.
>>
>> --
>> -- Mike
>>
>> Mike Schilli
>> m...@pe...
>>
>>> around in my wrapping code by incrementing
>>> $Log::Log4perl::caller_depth, but this feels like a hack, as I've
>>> already registered the package as a wrapper with
>>> Log::Log4perl->wrapper_register( __PACKAGE__ );.  I believe the
>>> correct fix is to change the Log::Log4perl::Logger::callerline method
>>> to use the %WRAPPERS_REGISTERED hash, similar to
>>> Log::Log4perl::get_logger:
>>>
>>> my $level = $Log::Log4perl::caller_depth;
>>> my ($pack, $file, $line);
>>> do { ($pack, $file, $line) = caller(++$level)
>>> } while ( exists $Log::Log4perl::WRAPPERS_REGISTERED{ $pack } );
>>>
>>> Although if you're replicating code, you should be wrapping the
>>> duplication in a function somewhere and just calling that.
>>>
>>> I would appreciate it if you could let me know if/when the issue will
>>> be addressed.
>>>
>>>  -- Bob
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> log4perl-devel mailing list
>>> log...@li...
>>> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>>>
>>
>

[log4perl-devel] Log::Log4perl 1.38 released

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

Log4perl enthusiasts,

a new maintenance release (1.38) has been pushed to CPAN, including the
following changes:

1.38 (2012/09/23)
    *    (ms) Bob Kleemann reported that logdie() in wrapper classes
              printed incorrect caller lines. Fixed by adding
              caller_depth_offset() utility to Log4perl.pm.
    *    (ms) Meir Guttman reported a use case for logging messages
              with dynamic levels on log...@li....
              Added to manual page.
    *    (ms) Implemented suggestion by Neil Hooey to check for and report
              undefined message elements before they're assembled in Appender.pm
              and a warning is issued without a proper code location:
              https://github.com/mschilli/log4perl/issues/15
    *    (ms) [rt.cpan.org #78734] Added spell check on filter parameter names

Enjoy!

-- 
-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] Bug: Wrapped logdie reports wrong file/line

[Bob K. <rkl...@gm...>]

Yes, it appears to work for me.  I've changed my caller_depth hack to
only operate on versions less than 1.38.  When might I expect 1.38 to
be released to CPAN?

Also, I note that you didn't change Log::Log4perl::get_logger to use
caller_depth_offset.  I'm not sure if that was intentional or not.

On Tue, Sep 18, 2012 at 12:28 AM, Mike Schilli <m...@pe...> wrote:
> On Mon, 17 Sep 2012, Bob Kleemann wrote:
>
>> It prints the write file/line on the logged message (-e:1), but not on
>> the die message (perllib/WSL/... line 174).
>
>
> Hi Bob,
>
> thanks for reporting this issue, I've provided a fix here:
>
>
> https://github.com/mschilli/log4perl/commit/e258163ef2c219e082419e6158ad6fa96eeebc5d
>
> You can download the updated tarball from:
>
>     https://github.com/mschilli/log4perl/tarball/1.38logdie
>
> Would be great if you could give it a whirl, let me know if it's working
> for you.
>
> --
> -- Mike
>
> Mike Schilli
> m...@pe...
>
>> around in my wrapping code by incrementing
>> $Log::Log4perl::caller_depth, but this feels like a hack, as I've
>> already registered the package as a wrapper with
>> Log::Log4perl->wrapper_register( __PACKAGE__ );.  I believe the
>> correct fix is to change the Log::Log4perl::Logger::callerline method
>> to use the %WRAPPERS_REGISTERED hash, similar to
>> Log::Log4perl::get_logger:
>>
>> my $level = $Log::Log4perl::caller_depth;
>> my ($pack, $file, $line);
>> do { ($pack, $file, $line) = caller(++$level)
>> } while ( exists $Log::Log4perl::WRAPPERS_REGISTERED{ $pack } );
>>
>> Although if you're replicating code, you should be wrapping the
>> duplication in a function somewhere and just calling that.
>>
>> I would appreciate it if you could let me know if/when the issue will
>> be addressed.
>>
>>  -- Bob
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> log4perl-devel mailing list
>> log...@li...
>> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>>
>

Re: [log4perl-devel] Bug: Wrapped logdie reports wrong file/line

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

On Mon, 17 Sep 2012, Bob Kleemann wrote:

> It prints the write file/line on the logged message (-e:1), but not on
> the die message (perllib/WSL/... line 174).

Hi Bob,

thanks for reporting this issue, I've provided a fix here:

     https://github.com/mschilli/log4perl/commit/e258163ef2c219e082419e6158ad6fa96eeebc5d

You can download the updated tarball from:

     https://github.com/mschilli/log4perl/tarball/1.38logdie

Would be great if you could give it a whirl, let me know if it's working
for you.

-- 
-- Mike

Mike Schilli
m...@pe...

> around in my wrapping code by incrementing
> $Log::Log4perl::caller_depth, but this feels like a hack, as I've
> already registered the package as a wrapper with
> Log::Log4perl->wrapper_register( __PACKAGE__ );.  I believe the
> correct fix is to change the Log::Log4perl::Logger::callerline method
> to use the %WRAPPERS_REGISTERED hash, similar to
> Log::Log4perl::get_logger:
>
> my $level = $Log::Log4perl::caller_depth;
> my ($pack, $file, $line);
> do { ($pack, $file, $line) = caller(++$level)
> } while ( exists $Log::Log4perl::WRAPPERS_REGISTERED{ $pack } );
>
> Although if you're replicating code, you should be wrapping the
> duplication in a function somewhere and just calling that.
>
> I would appreciate it if you could let me know if/when the issue will
> be addressed.
>
>  -- Bob
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

[log4perl-devel] Bug: Wrapped logdie reports wrong file/line

[Bob K. <rkl...@gm...>]

Log4perl developers,

Thanks for the work on this module.  It's saved me countless rewrites,
and has adapted beautifully with my needs.  Unfortunately, I've
noticed an issue with logdie (and the related methods).  I've wrapped
Log::Log4perl to add some functionality.  I've noticed that when I do
a logdie (or similar), I get the wrong file/line on the die text:

$ perl -I perllib -MWSL::Util::Log=logger_cat,wsl.stdout -e
'WLOGGER->logdie("This should die")'
FATAL> -e:1 main:: - This should die
This should die at perllib/WSL/Util/Log/Log4perl.pm line 174
## Should be ##
This should die at -e line 1

It prints the write file/line on the logged message (-e:1), but not on
the die message (perllib/WSL/... line 174).  I've created a work
around in my wrapping code by incrementing
$Log::Log4perl::caller_depth, but this feels like a hack, as I've
already registered the package as a wrapper with
Log::Log4perl->wrapper_register( __PACKAGE__ );.  I believe the
correct fix is to change the Log::Log4perl::Logger::callerline method
to use the %WRAPPERS_REGISTERED hash, similar to
Log::Log4perl::get_logger:

my $level = $Log::Log4perl::caller_depth;
my ($pack, $file, $line);
do { ($pack, $file, $line) = caller(++$level)
} while ( exists $Log::Log4perl::WRAPPERS_REGISTERED{ $pack } );

Although if you're replicating code, you should be wrapping the
duplication in a function somewhere and just calling that.

I would appreciate it if you could let me know if/when the issue will
be addressed.

  -- Bob

Re: [log4perl-devel] Good use of the $logger->log() method

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

On Wed, 4 Jul 2012, Meir Guttman wrote:

> Well, I found at least one use for the $logger->log() method: dynamic level logging.

Hi Meir,

that's an interesting use case, thanks for reporting it. I've changed
the documentation accordingly:

     https://github.com/mschilli/log4perl/commit/b60c85acb482095a5d1939c2a25e64653f3c3624

-- 
-- Mike

Mike Schilli
m...@pe...

> I have though an issue with one passage in the documentation. In the CPAN page Log::Log4perl (Ver. 1.37) (http://search.cpan.org/~mschilli/Log-Log4perl-1.37/lib/Log/Log4perl.pm) one can read the following:
>
>    Instead of calling the methods
>
>        $logger->trace("...");  # Log a trace message
>        ... (other variants deleted)
>
>    you could also call the log() method with the appropriate level using the constants defined in Log::Log4perl::Level:
>
>        use Log::Log4perl::Level;
>
>        $logger->log($TRACE, "...");
>        ... (other variants deleted)
>
>    But *** nobody does that, really ***. (my enhancement - MG) Neither
>    does anyone need more logging levels than these predefined ones. If
>    you think you do, I would suggest you look into steering your logging
>    behavior via the category mechanism.
>
> Well, I found at least one use for the $logger->log() method: dynamic level logging.
>
> Take for example a "system()" call. It can return a number of exit codes by issuing something like «exit(0x2C);» command. I find it very convenient to segregate on the basis of the return code what logging level to assign to the log message upon returning:
>
>    my %exit_level = (
>      0 => $INFO,
>      1 => $WARN,
>      2 => $WARN,
>      4 => $ERROR,
>      0xFF => $FATAL,
>      );
>
>    My %message = (
>      0 => "Message 1",
>      1 => "..."
>      ...
>      );
>
>    my $result = system ('perl', 'my_script.pl, @args) >>= 8;
>
>    $logger->log($exit_level{$result}, $message{$result});
>
> So, I would recommend a change in the doc showing such an example.
>
> Meir
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel

[log4perl-devel] Good use of the $logger->log() method

[Meir G. <me...@gu...>]

Dear logging folks,

First thank you for a very useful and comprehensive logging package.

I have though an issue with one passage in the documentation. In the CPAN page Log::Log4perl (Ver. 1.37) (http://search.cpan.org/~mschilli/Log-Log4perl-1.37/lib/Log/Log4perl.pm) one can read the following:

    Instead of calling the methods

        $logger->trace("...");  # Log a trace message
        ... (other variants deleted)

    you could also call the log() method with the appropriate level using the constants defined in Log::Log4perl::Level:

        use Log::Log4perl::Level;

        $logger->log($TRACE, "...");
        ... (other variants deleted)

    But *** nobody does that, really ***. (my enhancement - MG) Neither
    does anyone need more logging levels than these predefined ones. If
    you think you do, I would suggest you look into steering your logging
    behavior via the category mechanism.

Well, I found at least one use for the $logger->log() method: dynamic level logging.

Take for example a "system()" call. It can return a number of exit codes by issuing something like «exit(0x2C);» command. I find it very convenient to segregate on the basis of the return code what logging level to assign to the log message upon returning:

    my %exit_level = (
      0 => $INFO,
      1 => $WARN,
      2 => $WARN,
      4 => $ERROR,
      0xFF => $FATAL,
      );

    My %message = (
      0 => "Message 1",
      1 => "..."
      ...
      );

    my $result = system ('perl', 'my_script.pl, @args) >>= 8;

    $logger->log($exit_level{$result}, $message{$result});

So, I would recommend a change in the doc showing such an example.

Meir

[log4perl-devel] Log::Log4perl 1.37 released

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

Hi Log4perl enthusiasts,

the Log::Log4perl 1.37 maintenance release just went to CPAN. The
following changes were applied:

1.37 (2012/05/30)

    * (ms) [rt.cpan.org #75655] Meir Guttman found the module to make
 	  Log::Log4perl::Appender::ScreenColoredLevels work on Win32,
           updated docs.
    * (ms) [rt.cpan.org #76827] UTF-8 encoded configuration files are
           now supported (see Log::Log4perl::Config).
    * (ms) [rt.cpan.org #77501] Unescaped left brace in regex is
           deprecated with perl 5.17. Times we live in.

Enjoy!

-- 
-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] change log level in embedded system

[Gangemi, J. <Jae...@bm...>]

  that was the idea, but now i see that's not going to work. originally i
just wanted to change the log level on the root logger, which actually did
persist (i was dumb and spaced the fact that i was bypassing the embedded
perl engine when i was testing), but that only affected the one
interpreter instance and there are many sitting in a shared pool, so that
doesn't really help my needs.

  it seems at this point, my best approach would be to figure out a way to
have the configuration be external and then use the 'init_and_watch()'
approach, sending a HUP to cause the configuration to be re-read.

--
-jae




On 4/18/12 11:29 AM, "Mike Schilli" <m...@pe...> wrote:

>On Wed, 18 Apr 2012, Gangemi, Jae wrote:
>
>>  actually, no - the call into the system could be considered the
>> equivalent of running a cgi script inside of mod_perl, there is no
>>signal
>> handler involved, but i now realize my original approach just isn't
>>going
>> to work.
>
>I see, and the reset to the old configuration is related to something
>within the system calling Log4perl's init()?
>
>-- 
>-- Mike
>
>Mike Schilli
>m...@pe...
>
>>  the reason i'm not using 'init_and_watch()' is b/c we embed the
>> configuration file inside the code base (which is contained in a custom,
>> encrypted archive) and 'init_and_watch' only works w/ an external file,
>> but in order to make this work, i think i'm going to have to use some
>>kind
>> of external configuration file or change how 'init_and_watch' works
>> locally.
>>
>>  thanks!
>>
>> --
>> -jae
>>
>>
>>
>>
>> On 4/17/12 9:46 PM, "Mike Schilli" <m...@pe...> wrote:
>>
>>> On Tue, 17 Apr 2012, Gangemi, Jae wrote:
>>>
>>>>  am i missing something w/ this idea or will i need to re-initialize
>>>>  log4perl w/ a new configuration in order to make this work?
>>>
>>> You're not saying how your call into the system works, I presume that
>>> you're using a signal handler or some such to run a function that
>>> manipulates the logger on a received signal. Then, somehow Log4perl
>>>gets
>>> reinitialized by calling init() and it's back to normal. With mod_perl,
>>> this happens e.g. when Apache starts a new child process, I suspect
>>> something similar is happening in your embedded system.
>>>
>>> I wonder why you're not simply using init_and_watch() and modify the
>>> external config file to regularly check and reload it?
>>>
>>> --
>>> -- Mike
>>>
>>> Mike Schilli
>>> m...@pe...
>>>
>>>> hello -
>>>>
>>>>  i'm currently running log4perl inside an embedded instance, for all
>>>> intents and purposes, you could say it's an environment similar to
>>>> mod_perl.
>>>>
>>>>  while the system is running, i would like to send a command that
>>>> changes
>>>> the log level of either the root logger or against one of the logger
>>>> categories (and potentially dynamically adding an appender so i can
>>>>log
>>>> to
>>>> a separate file.
>>>>
>>>>  the problem i am having the log level does not persist between calls
>>>> into the system. i can make a call in and change the log level (and
>>>>log
>>>> a
>>>> message at the new level to make sure it worked) but on a subsequent
>>>> call,
>>>> the log level has been reset to what log4perl was originally
>>>>initialized
>>>> with, i.e.:
>>>>
>>>>   $logger = Log::Log4perl->get_logger("");
>>>>
>>>>   $logger->fatal("fatal message");
>>>>   $logger->trace("trace message, should not see");
>>>>
>>>>   $logger->level($TRACE);
>>>>   $logger->level("trace message, should see");
>>>>
>>
>>

Re: [log4perl-devel] panic in sv_setpvn

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

On Wed, 18 Apr 2012, Martin J. Evans wrote:

> panic: sv_setpvn called with negative strlen at /home/perlbrew//perls/perl-5.14.2/lib/site_perl/5.14.2/Log/Log4perl/Layout/PatternLayout.pm line 358.

This looks like a bug in perl, not Log4perl. Since Log4perl is pure
Perl, there should never be a panic situation, except if there's a bug
in perl itself.

You might want to write up a reproducable script, and file a bug with
perl via perlbug (which adds your complete perl -V build information for
reference).

-- 
-- Mike

Mike Schilli
m...@pe...

>
> That line in my distribution is:
>
> ##################################################
> sub shrink_category {
> ##################################################
>     my($category, $len) = @_;
>
>     my @components = split /\.|::/, $category;     # <-------------- here
>
>     if(@components > $len) {
>         splice @components, 0, @components - $len;
>         $category = join '.', @components;
>     }
>
>     return $category;
> }
>
> perl -MLog::Log4perl -le 'print $Log::Log4perl::VERSION;'
> 1.36
>
> This is Perl 5.14.2 on Linux 32 bit machine built as default via perlbrew.
>
> Any ideas.
>
> Martin
>

Re: [log4perl-devel] change log level in embedded system

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

On Wed, 18 Apr 2012, Gangemi, Jae wrote:

>  actually, no - the call into the system could be considered the
> equivalent of running a cgi script inside of mod_perl, there is no signal
> handler involved, but i now realize my original approach just isn't going
> to work.

I see, and the reset to the old configuration is related to something
within the system calling Log4perl's init()?

-- 
-- Mike

Mike Schilli
m...@pe...

>  the reason i'm not using 'init_and_watch()' is b/c we embed the
> configuration file inside the code base (which is contained in a custom,
> encrypted archive) and 'init_and_watch' only works w/ an external file,
> but in order to make this work, i think i'm going to have to use some kind
> of external configuration file or change how 'init_and_watch' works
> locally.
>
>  thanks!
>
> --
> -jae
>
>
>
>
> On 4/17/12 9:46 PM, "Mike Schilli" <m...@pe...> wrote:
>
>> On Tue, 17 Apr 2012, Gangemi, Jae wrote:
>>
>>>  am i missing something w/ this idea or will i need to re-initialize
>>>  log4perl w/ a new configuration in order to make this work?
>>
>> You're not saying how your call into the system works, I presume that
>> you're using a signal handler or some such to run a function that
>> manipulates the logger on a received signal. Then, somehow Log4perl gets
>> reinitialized by calling init() and it's back to normal. With mod_perl,
>> this happens e.g. when Apache starts a new child process, I suspect
>> something similar is happening in your embedded system.
>>
>> I wonder why you're not simply using init_and_watch() and modify the
>> external config file to regularly check and reload it?
>>
>> --
>> -- Mike
>>
>> Mike Schilli
>> m...@pe...
>>
>>> hello -
>>>
>>>  i'm currently running log4perl inside an embedded instance, for all
>>> intents and purposes, you could say it's an environment similar to
>>> mod_perl.
>>>
>>>  while the system is running, i would like to send a command that
>>> changes
>>> the log level of either the root logger or against one of the logger
>>> categories (and potentially dynamically adding an appender so i can log
>>> to
>>> a separate file.
>>>
>>>  the problem i am having the log level does not persist between calls
>>> into the system. i can make a call in and change the log level (and log
>>> a
>>> message at the new level to make sure it worked) but on a subsequent
>>> call,
>>> the log level has been reset to what log4perl was originally initialized
>>> with, i.e.:
>>>
>>>   $logger = Log::Log4perl->get_logger("");
>>>
>>>   $logger->fatal("fatal message");
>>>   $logger->trace("trace message, should not see");
>>>
>>>   $logger->level($TRACE);
>>>   $logger->level("trace message, should see");
>>>
>
>

Re: [log4perl-devel] change log level in embedded system

[Gangemi, J. <Jae...@bm...>]

  actually, no - the call into the system could be considered the
equivalent of running a cgi script inside of mod_perl, there is no signal
handler involved, but i now realize my original approach just isn't going
to work.

  the reason i'm not using 'init_and_watch()' is b/c we embed the
configuration file inside the code base (which is contained in a custom,
encrypted archive) and 'init_and_watch' only works w/ an external file,
but in order to make this work, i think i'm going to have to use some kind
of external configuration file or change how 'init_and_watch' works
locally.

  thanks!

--
-jae




On 4/17/12 9:46 PM, "Mike Schilli" <m...@pe...> wrote:

>On Tue, 17 Apr 2012, Gangemi, Jae wrote:
>
>>  am i missing something w/ this idea or will i need to re-initialize
>>  log4perl w/ a new configuration in order to make this work?
>
>You're not saying how your call into the system works, I presume that
>you're using a signal handler or some such to run a function that
>manipulates the logger on a received signal. Then, somehow Log4perl gets
>reinitialized by calling init() and it's back to normal. With mod_perl,
>this happens e.g. when Apache starts a new child process, I suspect
>something similar is happening in your embedded system.
>
>I wonder why you're not simply using init_and_watch() and modify the
>external config file to regularly check and reload it?
>
>-- 
>-- Mike
>
>Mike Schilli
>m...@pe...
>
>> hello -
>>
>>  i'm currently running log4perl inside an embedded instance, for all
>> intents and purposes, you could say it's an environment similar to
>> mod_perl.
>>
>>  while the system is running, i would like to send a command that
>>changes
>> the log level of either the root logger or against one of the logger
>> categories (and potentially dynamically adding an appender so i can log
>>to
>> a separate file.
>>
>>  the problem i am having the log level does not persist between calls
>> into the system. i can make a call in and change the log level (and log
>>a
>> message at the new level to make sure it worked) but on a subsequent
>>call,
>> the log level has been reset to what log4perl was originally initialized
>> with, i.e.:
>>
>>   $logger = Log::Log4perl->get_logger("");
>>
>>   $logger->fatal("fatal message");
>>   $logger->trace("trace message, should not see");
>>
>>   $logger->level($TRACE);
>>   $logger->level("trace message, should see");
>>

[log4perl-devel] panic in sv_setpvn

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

panic: sv_setpvn called with negative strlen at /home/perlbrew//perls/perl-5.14.2/lib/site_perl/5.14.2/Log/Log4perl/Layout/PatternLayout.pm line 358.

That line in my distribution is:

##################################################
sub shrink_category {
##################################################
     my($category, $len) = @_;

     my @components = split /\.|::/, $category;     # <-------------- here

     if(@components > $len) {
         splice @components, 0, @components - $len;
         $category = join '.', @components;
     }

     return $category;
}

perl -MLog::Log4perl -le 'print $Log::Log4perl::VERSION;'
1.36

This is Perl 5.14.2 on Linux 32 bit machine built as default via perlbrew.

Any ideas.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

Re: [log4perl-devel] change log level in embedded system

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

On Tue, 17 Apr 2012, Gangemi, Jae wrote:

>  am i missing something w/ this idea or will i need to re-initialize
>  log4perl w/ a new configuration in order to make this work?

You're not saying how your call into the system works, I presume that
you're using a signal handler or some such to run a function that
manipulates the logger on a received signal. Then, somehow Log4perl gets
reinitialized by calling init() and it's back to normal. With mod_perl,
this happens e.g. when Apache starts a new child process, I suspect
something similar is happening in your embedded system.

I wonder why you're not simply using init_and_watch() and modify the
external config file to regularly check and reload it?

-- 
-- Mike

Mike Schilli
m...@pe...

> hello -
>
>  i'm currently running log4perl inside an embedded instance, for all
> intents and purposes, you could say it's an environment similar to
> mod_perl.
>
>  while the system is running, i would like to send a command that changes
> the log level of either the root logger or against one of the logger
> categories (and potentially dynamically adding an appender so i can log to
> a separate file.
>
>  the problem i am having the log level does not persist between calls
> into the system. i can make a call in and change the log level (and log a
> message at the new level to make sure it worked) but on a subsequent call,
> the log level has been reset to what log4perl was originally initialized
> with, i.e.:
>
>   $logger = Log::Log4perl->get_logger("");
>
>   $logger->fatal("fatal message");
>   $logger->trace("trace message, should not see");
>
>   $logger->level($TRACE);
>   $logger->level("trace message, should see");
>