log4perl-devel — Ongoing log4perl development

[log4perl-devel] Can the DBIAppender Work in Multithread?

[Nan C. <cui...@gm...>]

Hi Gurus,

I'm trying to get help from you as I'm facing a problem while trying to use
the DBIAppender in multithreading code. When my code tried to create new
threads, the logger in the sub-thread body threw out exception like this:

thread failed to start: DBD::Oracle::db prepare failed: handle 2 is owned by
thread 83e0008 not current thread 8973c18 (handles can't be shared between
threads and your driver may need a CLONE method added) at
/usr/cisco/packages/perl/perl-5.8.8/lib/site_perl/5.8.8/Log/Log4perl/Appender/DBI.pm
line 88.

I'm new to Perl. I heard of that DBI is thread-safe and this might be the
root cause of this problem. But while accpting this, I still need a solution
to make the logger work also in sub-threads. I tried to share the logger,
but it came out with another error saying "(in cleanup) Can't call method
"FIRSTKEY" on an undefined value at ..... /Log/Log4perl/Logger.pm line 90
during global destruction.". And one fellow told me try to create new DBI
connection while in new thread, but I have no idea of how to do it.


Since you guys are the source, I'm turning to you. Can you guys show me a
way to my destination? Would appreciate that.


Thanks & Regards,

NC

Re: [log4perl-devel] installation to non-system location

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

On Tue, 5 Apr 2011, Rob Retter wrote:

> How does one install all of Log4perl into a given non-system
> directory?

Hi Rob,

Perl offers a generic solution for this problem (so it's nothing
Log4perl-specific), and you can find details on the local::lib manual
page:

     http://search.cpan.org/~apeiron/local-lib-1.008004/lib/local/lib.pm

Alternatively, you can set the LIB variable when running Makefile.PL:

     perl Makefile.PL LIB=/home/mike/perl_modules

Hope that helps!

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] installation to non-system location

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

Hello,

I'm accustomed to the 'configure' utility which provides surprisingly
clear help on how to set the "base" directory into which a product is to
be installed.  There's usually one value to supply as a parameter to
'configure' which results in your installation going into
/somedir/of/mine rather than /usr/lib/somedir_I_should_not_mess_with.

How does one install all of Log4perl into a given non-system directory?
Thank you for your help.



-- Rob Retter

Re: [log4perl-devel] sample rolling log file with explicit log file mode setting?

[Jeff A. <je...@se...>]

Jeff McCarrell <jeffmcc <at> yahoo-inc.com> writes:

> 
> Hi folks.
> 
> I'm using log4perl in the obvious way.
> We have reqs to set the mode of the log file to 0666.
> 
> using
> 
> log4perl.appender.PUSHD=Log::Dispatch::FileRotate
> log4perl.appender.PUSHD.filename=/tmp/pushd.log
> log4perl.appender.PUSHD.mode=append
> log4perl.appender.PUSHD.permissions = 
> S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH
> # rotate among 5 log files of 10Mbytes each
> log4perl.appender.PUSHD.size=100kb
> log4perl.appender.PUSHD.max=5
> 
> results in 5 files of mode 0;
> 
> permissions=0666 gets passed as a string through the layers, not as an 
> octal number, and results in:
> 
> --w--wx-wT  1 nobody nobody 1063 Nov  2 12:41 pushd.log*
> 
> Anyone have a recipe here that works?
> 
I came across this looking for the same question, I'll throw down the answer I 
found just for other folks that come looking.

the value "0666" is interpreted as a string when it's specified in the file 
directly.  Perl's chmod command requires an actual octal value.  To force 
log4perl to figure this out, explicitly state that the value should be 
interpreted as Perl code:

permissions = sub{0666}

That worked just fine for me.

--Jeff

Re: [log4perl-devel] $Log::Log4perl::caller_depth, layout %c and %T, and category

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

On Sun, 30 Jan 2011, David Christensen wrote:

> I'm not certain if %T is doing the right thing (?).  You said there might be 
> a bug.  Do you mean that the:

Should be fixed in Log4perl 1.32 on CPAN, give it a try.

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] Log::Log4perl 1.32 released

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

Log4perl enthusiasts,

the Log::Log4perl 1.32 maintenance release has just been pushed to CPAN.
The following changes are included:

1.32 (2011/02/26)
    *    (ms) Fixed %T caller_depth with wrapper_register(), reported
              by David Christensen.
    *    (ms) [RT 63053] Fixed for qw() {} deprecated (Todd Rinaldo)
    *    (ms) [RT 62674] Fixed call to deprecated form of UNIVERSAL::can
              (Karen Etheridge).
    *    (ms) [RT 62896] Log::Log4perl::Appender::ScreenColoredLevels now
              inherits from Log::Log4perl::Appender::Screen and therefore
              supports the utf8 flag.
    *    (ms) [RT 64318] Andrew Sayers provided a better error message
              for "threshold needs to be uppercase".
    *    (ms) CharleyDixon fixed LOGWARN when :no_extra_logdie_message is
              in use to no longer exit().

Enjoy!

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] Unable to install on win32.Please help me.

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

On Fri, 21 Jan 2011, sunil kumar gawaday wrote:

> I'm not able to install log4perl on my machine. The installed perl
> version is 5.8.8 activestate.  Downloading ActiveState Package
> Repository packlist...failed 500 Can't

Hi Sunil,

sorry for the long delay on this ... just checked the sourceforge
directory and it contains the Log4perl 1.31 ppm. Looks like this was
a temporary error, let me know if it persists.

-- Mike

Mike Schilli
m...@pe...

>
> I executed the following command. But it throws the following error and i
> can't the install module.
>
>> ppm repo add http://log4perl.sourceforge.net/ppm
> connect t o ppm4.activestate.com:80 (Bad hostname
> 'ppm4.activestate.com') Downloading log4perl.sourceforge.net
> packlist...failed 500 Can't connect to log4 perl.sourceforge.net:80
> (Bad hostname 'log4perl.sourceforge.net') Downloading
> log4perl.sourceforge.net packlist...failed 500 Can't connect to log4
> perl.sourceforge.net:80 (Bad hostname 'log4perl.sourceforge.net')
> Downloading log4perl.sourceforge.net packlist...failed 500 Can't
> connect to log4 perl.sourceforge.net:80 (Bad hostname
> 'log4perl.sourceforge.net') Repo 2 added.
>
>
> Please help us.
>
> Thanks
> Sunil kumar
>

Re: [log4perl-devel] $Log::Log4perl::caller_depth, layout %c and %T, and category

[David C. <dpc...@ho...>]

Mike Schilli wrote:
 > We get tons of spam on this list, so it's moderated.

That's what I thought.  I'll post to the list and BCC you.


> What you want to do instead is use the long form with get_logger():
>     package Helper;
>     use Log::Log4perl qw(get_logger);
>     Log::Log4perl->wrapper_register(__PACKAGE__);
>     sub help { get_logger()->debug(__FILE__, "-", __LINE__, ' ', @_) }

That solves both %c and 'category' -- thanks!  The 'category' filtering 
will be very useful.  :-)


I'm not certain if %T is doing the right thing (?).  You said there 
might be a bug.  Do you mean that the:

     ... Helper::help(...) called at ...

stances should be

     ... Log::Log4perl::__ANON__(...) called at ...

?  It's not a burning issue for me; I can use the output as is.


David



2011-01-30 19:53:41 dpchrist@p43400e ~/sandbox
$ nl log4perl-helper4.pl
      1	#!/usr/bin/perl
      2	package Helper;
      3	use Log::Log4perl qw(get_logger);
      4	Log::Log4perl->wrapper_register(__PACKAGE__);
      5	sub help { get_logger()->debug(@_, ' ', __FILE__, '-', __LINE__); }

      6	package Foo;
      7	sub foo { Helper::help(@_, ' ', __FILE__, '-', __LINE__); }

      8	package main;
      9	use Log::Log4perl qw(:easy);
     10	Log::Log4perl->easy_init({layout=>'%m %T %n'});
     11	DEBUG(       __FILE__, '-', __LINE__);
     12	print "\n";
     13	Helper::help(__FILE__, '-', __LINE__);
     14	print "\n";
     15	Foo::foo(    __FILE__, '-', __LINE__);

2011-01-30 19:55:32 dpchrist@p43400e ~/sandbox
$ perl log4perl-helper4.pl
log4perl-helper4.pl-13 Log::Log4perl::__ANON__('log4perl-helper4.pl', 
'-', 13) called at log4perl-helper4.pl line 13

log4perl-helper4.pl-15 log4perl-helper4.pl-5 
Helper::help('log4perl-helper4.pl', '-', 15) called at 
log4perl-helper4.pl line 15

log4perl-helper4.pl-17 log4perl-helper4.pl-8 log4perl-helper4.pl-5 
Helper::help('log4perl-helper4.pl', '-', 17, ' ', 'log4perl-helper4.pl', 
'-', 8) called at log4perl-helper4.pl line 8, 
Foo::foo('log4perl-helper4.pl', '-', 17) called at log4perl-helper4.pl 
line 17

2011-01-30 19:55:35 dpchrist@p43400e ~/sandbox
$ cat /etc/debian_version
5.0.8

2011-01-30 19:55:44 dpchrist@p43400e ~/sandbox
$ perl -v

This is perl, v5.10.0 built for i486-linux-gnu-thread-multi

Copyright 1987-2007, Larry Wall

Perl may be copied only under the terms of either the Artistic License 
or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.


2011-01-30 19:55:46 dpchrist@p43400e ~/sandbox
$ perl -MLog::Log4perl -e 'print $Log::Log4perl::VERSION, "\n"'
1.31

Re: [log4perl-devel] $Log::Log4perl::caller_depth, layout %c and %T, and category

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

On Sun, 30 Jan 2011, David Christensen wrote:

> Putting the 'use' statement before the 'BEGIN' statement makes Perl
> happy, but %c still shows the Helper package, not 'main':

Ugh, that doesn't work in :easy mode, sorry about that. 
What you want to do instead is use the long form with get_logger():

     package Helper;
     use Log::Log4perl qw(get_logger);
     Log::Log4perl->wrapper_register(__PACKAGE__);
     sub help { get_logger()->debug(__FILE__, "-", __LINE__, ' ', @_) }

     package Foo;
     sub foo { Helper::help("blah"); }

     package main;
     use Log::Log4perl qw(:easy);
     Log::Log4perl->easy_init({layout=>'%c %m %n'});
     DEBUG(__FILE__, "-", __LINE__);
     Helper::help(__FILE__, "-", __LINE__);
     Foo::foo();

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] $Log::Log4perl::caller_depth, layout %c and %T, and category

[David C. <dpc...@ho...>]

Mike Schilli wrote:
> There's a section in the Log4perl manual thattalks about this (not easy to find, though):
> http://search.cpan.org/~mschilli/Log-Log4perl-1.31/lib/Log/Log4perl.pm#Using_Log::Log4perl_with_wrapper_functions_and_classes 

Thank you for the reply.  :-)


Yes, I read that.


> Note that if you're using qw(:easy), you need to use
> 
>     package Helper;
>     BEGIN {
>         Log::Log4perl->wrapper_register(__PACKAGE__);
>     };
>     use Log::Log4perl qw(:easy);

That code doesn't work on my system:

     2011-01-30 14:08:11 dpchrist@p43400e ~/sandbox
     $ cat log4perl-helper.pl
     #!/usr/bin/perl
     package Helper;
     BEGIN {
         Log::Log4perl->wrapper_register(__PACKAGE__);
     };
     use Log::Log4perl qw(:easy);

     2011-01-30 14:08:16 dpchrist@p43400e ~/sandbox
     $ perl log4perl-helper.pl
     Can't locate object method "wrapper_register" via package 
"Log::Log4perl" (perhaps you forgot to load "Log::Log4perl"?) at 
log4perl-helper.pl line 4.
     BEGIN failed--compilation aborted at log4perl-helper.pl line 5.


Putting the 'use' statement before the 'BEGIN' statement makes Perl 
happy, but %c still shows the Helper package, not 'main':

     2011-01-30 14:22:44 dpchrist@p43400e ~/sandbox
     $ nl log4perl-helper2.pl
          1	#!/usr/bin/perl
          2	package Helper;
          3	use Log::Log4perl qw(:easy);
          4	BEGIN {
          5	    Log::Log4perl->wrapper_register(__PACKAGE__);
          6	};
          7	sub help { DEBUG(__FILE__, __LINE__, ' ', @_) }
          8	package main;
          9	use Log::Log4perl qw(:easy);
         10	Log::Log4perl->easy_init({layout=>'%c %m %n'});
         11	DEBUG(__FILE__, __LINE__);
         12	Helper::help(__FILE__, __LINE__);

     2011-01-30 14:23:00 dpchrist@p43400e ~/sandbox
     $ perl log4perl-helper2.pl
     main log4perl-helper2.pl11
     Helper log4perl-helper2.pl7 log4perl-helper2.pl12


Any suggestions?


David


2011-01-30 14:23:03 dpchrist@p43400e ~/sandbox
$ cat /etc/debian_version
5.0.8

2011-01-30 14:24:04 dpchrist@p43400e ~/sandbox
$ perl -v

This is perl, v5.10.0 built for i486-linux-gnu-thread-multi

Copyright 1987-2007, Larry Wall

Perl may be copied only under the terms of either the Artistic License 
or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.


2011-01-30 14:24:06 dpchrist@p43400e ~/sandbox
$ perl -MLog::Log4perl -e 'print $Log::Log4perl::VERSION, "\n"'
1.31

Re: [log4perl-devel] $Log::Log4perl::caller_depth, layout %c and %T, and category

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

On Sun, 23 Jan 2011, David Christensen wrote:

> I've found that: $Log::Log4perl::caller_depth
> ... does not seem to affect the following layout placeholders:
>     %c Category of the logging event
>     %T A stack trace of functions called

Hi David,

sorry for the delay. There's a subtle difference between the package
class hierarchy in your application and Log4perl's categories: While
they're almost always the same, they are in fact independent concepts.

That's is why %c does not change automatically when you set caller_depth,
because caller_depth refers to the package hierarchy, while %c refers to
the Log4perl category. There's a section in the Log4perl manual that
talks about this (not easy to find, though):

     http://search.cpan.org/~mschilli/Log-Log4perl-1.31/lib/Log/Log4perl.pm#Using_Log::Log4perl_with_wrapper_functions_and_classes

If you scroll down to "Also, note that if you're writing a subclass of
Log4perl", it talks about using

     Log::Log4perl->wrapper_register(__PACKAGE__);

to register a wrapper class, so that get_logger() skips it and uses
the application's class as a category instead. Note that if you're using
qw(:easy), you need to use

     package Helper;
     BEGIN {
         Log::Log4perl->wrapper_register(__PACKAGE__);
     };
     use Log::Log4perl qw(:easy);

to make sure Log4perl's easy mode stealth loggers are set up
correctly.

With regards to %T, I think that's a bug, I'll investigate.

Hope that helps.

-- Mike

Mike Schilli
m...@pe...


> How do I write a helper function that does affect %c, %T, and category
> -- e.g. so that calls to my helper logger functions are handled by
> Log::Log4perl the same way that calls to Log::Log4perl logger functions
> are handled?
>
>
> TIA,
>
> David
>
>
>
> 2011-01-23 14:30:18 dpchrist@p43400e ~/sandbox
> $ cat log4perl-easy
> #!/usr/bin/perl
>
> $! = 1;
>
> #############
> package Foo;
> #############
> use strict;
> use warnings;
> use Log::Log4perl qw(:easy);
> sub foo {
>     DEBUG(       @_, 'foo', __LINE__);
>     Helper::help(@_, 'foo', __LINE__);
> }
>
> ###############
> package Helper;
> ###############
> use strict;
> use warnings;
> use Log::Log4perl qw(:easy);
> sub help
> {
>     local $Log::Log4perl::caller_depth =
>     $Log::Log4perl::caller_depth + 1;
>     DEBUG(@_, 'help', __LINE__);
> }
>
> #############
> package main;
> #############
> use strict;
> use warnings;
> use Log::Log4perl qw(:easy);
>
> Log::Log4perl->easy_init( {
>     layout	=> '%%c %c %n'
> 		 . '%%C %C %n'
> 		 . '%%d %d %n'
> 		 . '%%F %F %n'
> 		 . '%%H %H %n'
> 		 . '%%l %l %n'
> 		 . '%%L %L %n'
> 		 . '%%m %m %n'
> 		 . '%%M %M %n'
> 		 . '%%p %p %n'
> 		 . '%%P %P %n'
> 		 . '%%r %r %n'
> ### %R is broken in Log::Log4perl version 1.16
> ### Invalid conversion in sprintf: "%R" at
> /usr/share/perl5/Log/Log4perl/Layout/PatternLayout.pm line 286.
> #		 . '%%R %R %n'
> 		 . '%%T %T %n'
> 		 . '%%x %x %n',
> });
>
> print "### call DEBUG()\n";
> DEBUG(       'main', __LINE__);
> print "### call Foo::foo()\n";
> Foo::foo(    'main', __LINE__);
> print "### call Helper::help()\n";
> Helper::help('main', __LINE__);
>
>
>
> 2011-01-23 14:30:20 dpchrist@p43400e ~/sandbox
> $ perl log4perl-easy
> ### call DEBUG()
> %c main
> %C main
> %d 2011/01/23 14:30:24
> %F log4perl-easy
> %H p43400e
> %l main:: log4perl-easy (57)
> %L 57
> %m main57
> %M main::
> %p DEBUG
> %P 5030
> %r 41
> %T Log::Log4perl::__ANON__('main', 57) called at log4perl-easy line 57
> %x [undef]
> ### call Foo::foo()
> %c Foo
> %C Foo
> %d 2011/01/23 14:30:24
> %F log4perl-easy
> %H p43400e
> %l Foo::foo log4perl-easy (12)
> %L 12
> %m main59foo12
> %M Foo::foo
> %p DEBUG
> %P 5030
> %r 45
> %T Foo::foo('main', 59) called at log4perl-easy line 59
> %x [undef]
> %c Helper
> %C Foo
> %d 2011/01/23 14:30:24
> %F log4perl-easy
> %H p43400e
> %l Foo::foo log4perl-easy (13)
> %L 13
> %m main59foo13help26
> %M Foo::foo
> %p DEBUG
> %P 5030
> %r 45
> %T Helper::help('main', 59, 'foo', 13) called at log4perl-easy line 13,
> Foo::foo('main', 59) called at log4perl-easy line 59
> %x [undef]
> ### call Helper::help()
> %c Helper
> %C main
> %d 2011/01/23 14:30:24
> %F log4perl-easy
> %H p43400e
> %l main:: log4perl-easy (61)
> %L 61
> %m main61help26
> %M main::
> %p DEBUG
> %P 5030
> %r 46
> %T Helper::help('main', 61) called at log4perl-easy line 61
> %x [undef]
>
>
>
> 2011-01-23 14:22:11 dpchrist@p43400e ~/sandbox
> $ cat log4perl-easy-category
> #!/usr/bin/perl
>
> $! = 1;
>
> #############
> package Foo;
> #############
> use strict;
> use warnings;
> use Log::Log4perl qw(:easy);
> sub foo {
>     DEBUG(       @_, 'foo', __LINE__);
>     Helper::help(@_, 'foo', __LINE__);
> }
>
> ###############
> package Helper;
> ###############
> use strict;
> use warnings;
> use Log::Log4perl qw(:easy);
> sub help
> {
>     local $Log::Log4perl::caller_depth =
>     $Log::Log4perl::caller_depth + 1;
>     DEBUG(@_, 'help', __LINE__);
> }
>
> #############
> package main;
> #############
> use strict;
> use warnings;
> use Log::Log4perl qw(:easy);
>
> print "### no category\n";
> Log::Log4perl->easy_init(
>     {layout=>'%m category=%c %n'}
> );
> DEBUG(       'main', __LINE__);
> Foo::foo(    'main', __LINE__);
> Helper::help('main', __LINE__);
>
> print "### category 'main'\n";
> Log::Log4perl->easy_init(
>     {layout=>'%m category=%c %n', category=>'main'}
> );
> DEBUG(       'main', __LINE__);
> Foo::foo(    'main', __LINE__);
> Helper::help('main', __LINE__);
>
> print "### category 'Foo'\n";
> Log::Log4perl->easy_init(
>     {layout=>'%m category=%c %n', category=>'Foo'}
> );
> DEBUG(       'main', __LINE__);
> Foo::foo(    'main', __LINE__);
> Helper::help('main', __LINE__);
>
>
>
> 2011-01-23 14:22:51 dpchrist@p43400e ~/sandbox
> $ perl log4perl-easy-category
> ### no category
> main40 category=main
> main41foo12 category=Foo
> main41foo13help26 category=Helper
> main42help26 category=Helper
> ### category 'main'
> main48 category=main
> ### category 'Foo'
> main57foo12 category=Foo
>
>
>
> 2011-01-23 14:22:56 dpchrist@p43400e ~/sandbox
> $ cat /etc/debian_version
> 5.0.8
>
>
>
> 2011-01-23 14:23:23 dpchrist@p43400e ~/sandbox
> $ perl -v
>
> This is perl, v5.10.0 built for i486-linux-gnu-thread-multi
>
> Copyright 1987-2007, Larry Wall
>
> Perl may be copied only under the terms of either the Artistic License
> or the
> GNU General Public License, which may be found in the Perl 5 source kit.
>
> Complete documentation for Perl, including FAQ lists, should be found on
> this system using "man perl" or "perldoc perl".  If you have access to the
> Internet, point your browser at http://www.perl.org/, the Perl Home Page.
>
>
>
> 2011-01-23 14:23:26 dpchrist@p43400e ~/sandbox
> $ perl -MLog::Log4perl -e 'print $Log::Log4perl::VERSION, "\n"'
> 1.16
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

Re: [log4perl-devel] logger state is global

[Tom M. <tme...@gm...>]

Mike Schilli wrote:
> Tom Metro wrote:
>> It came about because the $logger object doesn't actually convey the
>> full state, so when serialized and passed to a remote method, the
>> remote logging reverts to default logging settings.
> 
> Yeah, the way it's currently implemented, a logger is only meaningful
> within an initialized Log4perl-system, there's some system-global magic
> involved, and you cannot serialize a logger and plant it into
> another Log4perl-enabled system at runtime easily (yet).
> 
> Can you explain more about what the use case is for serializing loggers
> and passing them to remote systems?

Sure. This is part of a parallel processing cluster. Class::Remote is
used to execute code on remote nodes of the cluster. I'd like to be able
to have a single configured logger object used for the controlling node
(local) and then be able to serialize it and pass it to a remote node so
it can log with the identical settings.


> What properties of the logger might be of interest to the remote
> system?

The better questions is what logger state information can't practically
be serialized?


> Is the remote system running Log4perl with exactly the same appenders
> or different ones?

In this case I know the answer is exactly the same - everything is
outputting to STDOUT. But generally speaking, I'm not sure I know what
you mean.

Are you asking whether the remote system has the same appender drivers
installed? Or are you asking whether the remote system will be logging
to identical paths?

I don't think as a module implementer you need to be concerned with
that. If the paths are not identical, then having "fixup" code on the
remote side will be an obvious requirement. And similarly, an
experienced developer will know better than to write to a network
mounted log file from multiple machines simultaneously.


>> I assume that this practice of maintaining global state in Log4perl
>> came about because it is convenient to be able to call get_logger() as
>> a class method, rather than having the application pass an object
>> around.  But it seems that it would be way better if Log4perl was
>> internally designed to store all state in instance variables, and
>> leave it to the application developer to decide whether they want to
>> pass around objects, or dedicate a global variable to it.
> 
> Agreed.

OK, so what can we do to start refactoring the code to have the more
desired architecture?


>> Ultimately I want a method I can call from my libraries where I can
>> pass in a $logger parameter. The method then looks to see if $logger
>> is set to anything, and if it is, clones it, sets the category, and
>> returns the object.
> 
> Hmm, that's similar to how the class method is defined. If the logger
> for the category exists, you get a copy, if it isn't, you get a new
> instance. We could implement an object method that does what you've
> suggested, can you post some code to display how your class hierarchy
> looks like and how you call the metods of the derived class from your
> application?

Sure.

By illustration, here's a sticky situation I'm dealing with right now.

In the controller, I have code approximately like:

  my $logger = Publisher::Logger->init;
  ...
  my $parallel_agents = Parallel::Cluster->new({
      agent_lib => 'Some::Agent::Class',
      logger    => $logger,
  });
  $parallel_agents->run();

This initializes a logger object, instantiates the parallel processing
system, passing in the logger object, which in turn will get passed to
the constructor of Some::Agent::Class, and kicks off the run.

Parallel::Cluster implements a map-reduce algorithm, where portions
(some instances of Some::Agent::Class) are executed locally on the
controlling node, while other portions (mapping) happen remotely via
Class::Remote.

If the agent code attempts to use $logger locally, it works as expected.
If they use it remotely, nothing gets output.

Looking at a dump of the $logger object shows little difference between
the working local version and the not working remote version:

local
Address: Publisher::Logger=HASH(0x41f9dc0)@15665
$logger = bless( {
                   'is_OFF' => sub { "DUMMY" },
                   'is_DEBUG' => sub { "DUMMY" },
                   'ERROR' => sub { "DUMMY" },
                   'is_INFO' => sub { "DUMMY" },
                   'layout' => undef,
                   'category' => 'main',
                   'is_TRACE' => sub { "DUMMY" },
                   'DEBUG' => $logger->{'ERROR'},
                   'is_ALL' => sub { "DUMMY" },
                   'additivity' => 1,
                   'TRACE' => sub { "DUMMY" },
                   'ALL' => $logger->{'TRACE'},
                   'is_FATAL' => sub { "DUMMY" },
                   'is_WARN' => sub { "DUMMY" },
                   'FATAL' => $logger->{'ERROR'},
                   'appender_names' => [
                                         'app001'
                                       ],
                   'WARN' => $logger->{'ERROR'},
                   'INFO' => $logger->{'ERROR'},
                   'level' => 10000,
                   'num_appenders' => 1,
                   'OFF' => $logger->{'ERROR'},
                   'is_ERROR' => sub { "DUMMY" }
                 }, 'Publisher::Logger' );


remote
Address: Publisher::Logger=HASH(0x411caa0)@15673
$logger = bless( {
                   'is_OFF' => sub { "DUMMY" },
                   'is_DEBUG' => sub { "DUMMY" },
                   'ERROR' => sub { "DUMMY" },
                   'layout' => undef,
                   'is_INFO' => sub { "DUMMY" },
                   'category' => 'main',
                   'DEBUG' => $logger->{'ERROR'},
                   'is_TRACE' => sub { "DUMMY" },
                   'TRACE' => sub { "DUMMY" },
                   'additivity' => 1,
                   'is_ALL' => sub { "DUMMY" },
                   'ALL' => $logger->{'TRACE'},
                   'is_FATAL' => sub { "DUMMY" },
                   'is_WARN' => sub { "DUMMY" },
                   'INFO' => $logger->{'ERROR'},
                   'WARN' => $logger->{'ERROR'},
                   'appender_names' => [
                                         'app001'
                                       ],
                   'FATAL' => $logger->{'ERROR'},
                   'level' => '10000',
                   'num_appenders' => 1,
                   'is_ERROR' => sub { "DUMMY" },
                   'OFF' => $logger->{'ERROR'}
                 }, 'Publisher::Logger' );


To compensate for this deficiency, I added code to the agent to
redundantly call Publisher::Logger->init, and this redundancy is
primarily why I spun off logger initialization to subclass of
Log::Log4perl::Logger.

However this then introduced a bug. The place in the agent class where
the logger gets initialized (in its constructor) is called both when the
agent is instantiated for local portions as well as remote portions. As
a result, it re-initalized the state of the local logger object, and as
I reported back in November when I ran across a similar bug I created,
it has the unexpected effect of killing all logged output in the local
process.

So I had to modify init() in my subclass to do:

    # bail out and return the global logger object if already initialized
    if ($Log::Log4perl::Logger::INITIALIZED) {
        return $class->get_logger($caller_class);
    }

And that fixed it.


But weighing the pros and cons...

Current scheme:

Pro: have the convenience of calling $class->get_logger() anywhere to
get a logger;

Con: all other behavior is less intuitive; loggers in the same memory
space can interact and library code, if not well behaved, can kill your
logger object; you can't serialize a logger object.

A revised scheme:

Pro: none of the cons above;

Con: you have to handle passing around your own $logger object, or
setting a global.

I'll take the latter any day.

 -Tom

[log4perl-devel] $Log::Log4perl::caller_depth, layout %c and %T, and category

[David C. <dpc...@ho...>]

log4perl-devel:

I'm a new Log::Log4perl user and am trying to create some Log4perl 
helper logger functions.


I've found that:

     $Log::Log4perl::caller_depth


seems to affect the following layout placeholders:

     %C Fully qualified package (or class) name of the caller

     %l Fully qualified name of the calling method followed by the
        callers source the file name and line number between
        parentheses.

     %L Line number within the file where the log statement was issued

     %M Method or function where the logging request was issued

but it does not seem to affect the following layout placeholders:

     %c Category of the logging event

     %T A stack trace of functions called

nor the following argument to easy_init():

     category


How do I write a helper function that does affect %c, %T, and category 
-- e.g. so that calls to my helper logger functions are handled by 
Log::Log4perl the same way that calls to Log::Log4perl logger functions 
are handled?


TIA,

David



2011-01-23 14:30:18 dpchrist@p43400e ~/sandbox
$ cat log4perl-easy
#!/usr/bin/perl

$! = 1;

#############
package Foo;
#############
use strict;
use warnings;
use Log::Log4perl qw(:easy);
sub foo {
     DEBUG(       @_, 'foo', __LINE__);
     Helper::help(@_, 'foo', __LINE__);
}

###############
package Helper;
###############
use strict;
use warnings;
use Log::Log4perl qw(:easy);
sub help
{
     local $Log::Log4perl::caller_depth =
     $Log::Log4perl::caller_depth + 1;
     DEBUG(@_, 'help', __LINE__);
}

#############
package main;
#############
use strict;
use warnings;
use Log::Log4perl qw(:easy);

Log::Log4perl->easy_init( {
     layout	=> '%%c %c %n'
		 . '%%C %C %n'
		 . '%%d %d %n'
		 . '%%F %F %n'
		 . '%%H %H %n'
		 . '%%l %l %n'
		 . '%%L %L %n'
		 . '%%m %m %n'
		 . '%%M %M %n'
		 . '%%p %p %n'
		 . '%%P %P %n'
		 . '%%r %r %n'
### %R is broken in Log::Log4perl version 1.16
### Invalid conversion in sprintf: "%R" at 
/usr/share/perl5/Log/Log4perl/Layout/PatternLayout.pm line 286.
#		 . '%%R %R %n'
		 . '%%T %T %n'
		 . '%%x %x %n',
});

print "### call DEBUG()\n";
DEBUG(       'main', __LINE__);
print "### call Foo::foo()\n";
Foo::foo(    'main', __LINE__);
print "### call Helper::help()\n";
Helper::help('main', __LINE__);



2011-01-23 14:30:20 dpchrist@p43400e ~/sandbox
$ perl log4perl-easy
### call DEBUG()
%c main
%C main
%d 2011/01/23 14:30:24
%F log4perl-easy
%H p43400e
%l main:: log4perl-easy (57)
%L 57
%m main57
%M main::
%p DEBUG
%P 5030
%r 41
%T Log::Log4perl::__ANON__('main', 57) called at log4perl-easy line 57
%x [undef]
### call Foo::foo()
%c Foo
%C Foo
%d 2011/01/23 14:30:24
%F log4perl-easy
%H p43400e
%l Foo::foo log4perl-easy (12)
%L 12
%m main59foo12
%M Foo::foo
%p DEBUG
%P 5030
%r 45
%T Foo::foo('main', 59) called at log4perl-easy line 59
%x [undef]
%c Helper
%C Foo
%d 2011/01/23 14:30:24
%F log4perl-easy
%H p43400e
%l Foo::foo log4perl-easy (13)
%L 13
%m main59foo13help26
%M Foo::foo
%p DEBUG
%P 5030
%r 45
%T Helper::help('main', 59, 'foo', 13) called at log4perl-easy line 13, 
Foo::foo('main', 59) called at log4perl-easy line 59
%x [undef]
### call Helper::help()
%c Helper
%C main
%d 2011/01/23 14:30:24
%F log4perl-easy
%H p43400e
%l main:: log4perl-easy (61)
%L 61
%m main61help26
%M main::
%p DEBUG
%P 5030
%r 46
%T Helper::help('main', 61) called at log4perl-easy line 61
%x [undef]



2011-01-23 14:22:11 dpchrist@p43400e ~/sandbox
$ cat log4perl-easy-category
#!/usr/bin/perl

$! = 1;

#############
package Foo;
#############
use strict;
use warnings;
use Log::Log4perl qw(:easy);
sub foo {
     DEBUG(       @_, 'foo', __LINE__);
     Helper::help(@_, 'foo', __LINE__);
}

###############
package Helper;
###############
use strict;
use warnings;
use Log::Log4perl qw(:easy);
sub help
{
     local $Log::Log4perl::caller_depth =
     $Log::Log4perl::caller_depth + 1;
     DEBUG(@_, 'help', __LINE__);
}

#############
package main;
#############
use strict;
use warnings;
use Log::Log4perl qw(:easy);

print "### no category\n";
Log::Log4perl->easy_init(
     {layout=>'%m category=%c %n'}
);
DEBUG(       'main', __LINE__);
Foo::foo(    'main', __LINE__);
Helper::help('main', __LINE__);

print "### category 'main'\n";
Log::Log4perl->easy_init(
     {layout=>'%m category=%c %n', category=>'main'}
);
DEBUG(       'main', __LINE__);
Foo::foo(    'main', __LINE__);
Helper::help('main', __LINE__);

print "### category 'Foo'\n";
Log::Log4perl->easy_init(
     {layout=>'%m category=%c %n', category=>'Foo'}
);
DEBUG(       'main', __LINE__);
Foo::foo(    'main', __LINE__);
Helper::help('main', __LINE__);



2011-01-23 14:22:51 dpchrist@p43400e ~/sandbox
$ perl log4perl-easy-category
### no category
main40 category=main
main41foo12 category=Foo
main41foo13help26 category=Helper
main42help26 category=Helper
### category 'main'
main48 category=main
### category 'Foo'
main57foo12 category=Foo



2011-01-23 14:22:56 dpchrist@p43400e ~/sandbox
$ cat /etc/debian_version
5.0.8



2011-01-23 14:23:23 dpchrist@p43400e ~/sandbox
$ perl -v

This is perl, v5.10.0 built for i486-linux-gnu-thread-multi

Copyright 1987-2007, Larry Wall

Perl may be copied only under the terms of either the Artistic License 
or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.



2011-01-23 14:23:26 dpchrist@p43400e ~/sandbox
$ perl -MLog::Log4perl -e 'print $Log::Log4perl::VERSION, "\n"'
1.16

[log4perl-devel] Unable to install on win32.Please help me.

[sunil k. g. <sun...@gm...>]

Hi,

I'm not able to install log4perl on my machine. The installed perl version
is 5.8.8 activestate.

I executed the following command. But it throws the following error and i
can't the install module.

>ppm repo add http://log4perl.sourceforge.net/ppm
Downloading ActiveState Package Repository packlist...failed 500 Can't
connect t
o ppm4.activestate.com:80 (Bad hostname 'ppm4.activestate.com')
Downloading log4perl.sourceforge.net packlist...failed 500 Can't connect to
log4
perl.sourceforge.net:80 (Bad hostname 'log4perl.sourceforge.net')
Downloading log4perl.sourceforge.net packlist...failed 500 Can't connect to
log4
perl.sourceforge.net:80 (Bad hostname 'log4perl.sourceforge.net')
Downloading log4perl.sourceforge.net packlist...failed 500 Can't connect to
log4
perl.sourceforge.net:80 (Bad hostname 'log4perl.sourceforge.net')
Repo 2 added.


Please help us.

Thanks
Sunil kumar

Re: [log4perl-devel] warning on uninitialized value when logging undef

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

On Tue, 23 Nov 2010, Kevin Goess wrote:

> Any opinion on this?  Or should we stay with the uninitialized
> warning, however unhelpful it is?

I'm in favor of getting a warning in this case, at least with 'use
warnings' mode.

It's similar to

     use warnings;
     print "The value is $value.\n";

where I would expect a warning if $value was undefined.

The warning should point me to the location of
the actual INFO call and not to somewhere within the guts of Log4perl,
though ... :)

-- Mike

Mike Schilli
m...@pe...

> This is kind of annoying thing that I noticed recently, if you do
> $logger->info($msg) and $msg is undefined then you get a warning:
>
> perl -W -Ilib -e 'use Log::Log4perl qw(:easy); Log::Log4perl->easy_init($INFO); INFO(undef)'
> Use of uninitialized value in join or string at lib/Log/Log4perl/Appender.pm line 167.
>
> and it's not even a very helpful warning since it's buried in the guts of Log4perl.
>
> Using git bisect (neat tool) I found while I (myself even!) had fixed the issue back in
> 029d7df8 in 2002, I broke it (me again!) in afb95ef7e in 2003.
>
> Anyway, this would be the correct fix for it now, if all we're going to do is make a
> string out of it, it's ok just to use the defined bits of the mssage.
>
...
>
> diff --git a/lib/Log/Log4perl/Appender.pm b/lib/Log/Log4perl/Appender.pm
> index 923836f..455fd09 100644
> --- a/lib/Log/Log4perl/Appender.pm
> +++ b/lib/Log/Log4perl/Appender.pm
> @@ -162,10 +162,13 @@ sub log {
>             #not defined, the normal case
>         if (! defined $self->{warp_message} ){
>                 #join any message elements
> -            $p->{message} =
> -                join($Log::Log4perl::JOIN_MSG_ARRAY_CHAR,
> -                     @{$p->{message}}
> -                     ) if ref $p->{message} eq "ARRAY";
> +            if (ref $p->{message} eq "ARRAY"){
> +               $p->{message} =
> +                    join($Log::Log4perl::JOIN_MSG_ARRAY_CHAR,
> +                        grep { defined $_ }
> +                            @{$p->{message}}
> +                    );
> +            }
>
>             #defined but false, e.g. Appender::DBI
>         } elsif (! $self->{warp_message}) {
>
>
> If nobody objects I can make a unit test for it as well and push it to Mike via github.
>
>
>
> --
> Kevin G.
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

Re: [log4perl-devel] logger state is global

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

On Thu, 18 Nov 2010, Tom Metro wrote:

> It came about because the $logger object doesn't actually convey the
> full state, so when serialized and passed to a remote method, the
> remote logging reverts to default logging settings.

Yeah, the way it's currently implemented, a logger is only meaningful
within an initialized Log4perl-system, there's some system-global magic
involved, and you cannot serialize a logger and plant it into
another Log4perl-enabled system at runtime easily (yet).

Can you explain more about what the use case is for serializing loggers
and passing them to remote systems? What properties of the logger might
be of interest to the remote system? Is the remote system running
Log4perl with exactly the same appenders or different ones?

> (On a side note, I had to rewrite easy_init() in order to make it
> subclass friendly. We can discuss that further in a separate thread,
> if interested.)

Sure.

> I assume that this practice of maintaining global state in Log4perl
> came about because it is convenient to be able to call get_logger() as
> a class method, rather than having the application pass an object
> around.  But it seems that it would be way better if Log4perl was
> internally designed to store all state in instance variables, and
> leave it to the application developer to decide whether they want to
> pass around objects, or dedicate a global variable to it.

Agreed.

> When I fixed the library code to use
> Log::Log4perl->get_logger($class), my first attempt was actually to
> pass a logger object to the library, and call
> $logger->get_logger($class), assuming get_logger($class) would clone
> $logger, set the category, and return a new logger. Instead it fails
> in Log::Log4perl->_new() when it tries to bless the already blessed
> object.

Yes, get_logger() is a class method, calling it by an object is not
defined. We should have a better error message, though.

> Ultimately I want a method I can call from my libraries where I can
> pass in a $logger parameter. The method then looks to see if $logger
> is set to anything, and if it is, clones it, sets the category, and
> returns the object.

Hmm, that's similar to how the class method is defined. If the logger
for the category exists, you get a copy, if it isn't, you get a new
instance. We could implement an object method that does what you've
suggested, can you post some code to display how your class hierarchy
looks like and how you call the metods of the derived class from your
application?

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] warning on uninitialized value when logging undef

[Kevin G. <cp...@go...>]

This is kind of annoying thing that I noticed recently, if you do $logger->info($msg) and $msg is 
undefined then you get a warning:

 perl -W -Ilib -e 'use Log::Log4perl qw(:easy); Log::Log4perl->easy_init($INFO); INFO(undef)'
Use of uninitialized value in join or string at lib/Log/Log4perl/Appender.pm line 167.

and it's not even a very helpful warning since it's buried in the guts of Log4perl.

Using git bisect (neat tool) I found while I (myself even!) had fixed the issue back in 
029d7df8 in 2002, I broke it (me again!) in afb95ef7e in 2003.

Anyway, this would be the correct fix for it now, if all we're going to do is make a 
string out of it, it's ok just to use the defined bits of the mssage.

Any opinion on this?  Or should we stay with the uninitialized warning, however unhelpful it is?

diff --git a/lib/Log/Log4perl/Appender.pm b/lib/Log/Log4perl/Appender.pm
index 923836f..455fd09 100644
--- a/lib/Log/Log4perl/Appender.pm
+++ b/lib/Log/Log4perl/Appender.pm
@@ -162,10 +162,13 @@ sub log {
             #not defined, the normal case
         if (! defined $self->{warp_message} ){
                 #join any message elements
-            $p->{message} = 
-                join($Log::Log4perl::JOIN_MSG_ARRAY_CHAR, 
-                     @{$p->{message}} 
-                     ) if ref $p->{message} eq "ARRAY";
+            if (ref $p->{message} eq "ARRAY"){
+               $p->{message} = 
+                    join($Log::Log4perl::JOIN_MSG_ARRAY_CHAR,
+                        grep { defined $_ }
+                            @{$p->{message}}
+                    ); 
+            }
             
             #defined but false, e.g. Appender::DBI
         } elsif (! $self->{warp_message}) {


If nobody objects I can make a unit test for it as well and push it to Mike via github.



--
Kevin G.

Re: [log4perl-devel] logger state is global

[Tom M. <tme...@gm...>]

Mike Schilli wrote:
>> The trigger for the problem turned out to be a 'use' call in the eval'ed
>> code that loaded a library which internally called easy_init() (yet
>> specifying the INFO logging level).
> 
> That's very confusing and should be avoided at all cost.
> We discourage people from doing that...

You are correct. The man page does discourage initializing the logger in
multiple places, and it was an oversight that this code did that.

It came about because the $logger object doesn't actually convey the
full state, so when serialized and passed to a remote method, the remote
logging reverts to default logging settings.

To work around that, a Log4perl subclass was created, with it's own
init() that applies the application's stock preferences via a call to
easy_init(), and then that subclass is invoked both from the main
program and from the class that is executed remotely.

(On a side note, I had to rewrite easy_init() in order to make it
subclass friendly. We can discuss that further in a separate thread, if
interested.)

The presence of the Log4perl subclass in the project made it all too
convenient to invoke Log4perl that way from a library. I've corrected
the library to use Log::Log4perl->get_logger($class) to obtain its
logger instead, and I've updated the documentation of our Log4perl
subclass to warn against its use in all but the main program.

(Most libraries in the project get their logger passed to them from the
main code, and don't make use of categories.)

I'm still puzzled why the original logger object was rendered useless
(such that it wouldn't even log fatal messages). The call to easy_init()
does reset the logger, but my code also configured it to INFO logging
level. Did it reset the old logger and create a new object, which then
only the library code saw, while the main code saw the reset logger?


> That library wasn't using 'normal Log4perl methods'...

I get your point, but I consider easy_init() to be a normal method. With
Perl it is almost always possible to monkey with the private namespace
of a module, but it suggests bad design if using the provided API makes
it possible for one library to stomp on another.

I assume that this practice of maintaining global state in Log4perl came
about because it is convenient to be able to call get_logger() as a
class method, rather than having the application pass an object around.
But it seems that it would be way better if Log4perl was internally
designed to store all state in instance variables, and leave it to the
application developer to decide whether they want to pass around
objects, or dedicate a global variable to it.


> But you're bringing up an interesting topic: What would be a good
> approach to allow a library to meddle with Log4perl's settings, in the
> absence or even presence of a previous initialization?

When I fixed the library code to use Log::Log4perl->get_logger($class),
my first attempt was actually to pass a logger object to the library,
and call $logger->get_logger($class), assuming get_logger($class) would
clone $logger, set the category, and return a new logger. Instead it
fails in Log::Log4perl->_new() when it tries to bless the already
blessed object.

Ultimately I want a method I can call from my libraries where I can pass
in a $logger parameter. The method then looks to see if $logger is set
to anything, and if it is, clones it, sets the category, and returns the
object. If not, it creates a new logger object for that category, and
applies the logger settings I've specified somewhere. And, either code
path should have absolutely no impact on any existing logger objects in
use elsewhere in the code.

As mentioned above, we also have the need to capture the full state in
the $logger object, so it can be serialized, and used remotely.

 -Tom

Re: [log4perl-devel] logger state is global

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

On Tue, 16 Nov 2010, Tom Metro wrote:

> 1. Ability to create a library module that can use Log4perl, such that
> if the calling code makes no use of Log4perl, it logs independently
> with locally specified defaults, but if the caller does use Log4perl,
> it picks up the callers settings.
Hi Tom,

the current Log4perl implementation assumes that the calling script
initializes Log4perl and libraries don't. Libraries make use of
Log4perl by issuing log statements, but they don't try to modify the
inititalization. If Log4perl isn't initialized in the main program, all
is quiet.

> The trigger for the problem turned out to be a 'use' call in the eval'ed
> code that loaded a library which internally called easy_init() (yet
> specifying the INFO logging level).

That's very confusing and should be avoided at all cost.

> This seems broken that a library using normal Log4perl methods can trash
> the logger in use by the calling code.

That library wasn't using 'normal Log4perl methods', but was clobbering
the settings. We discourage people from doing that, although we don't
stop anyone shooting themselves in the foot (or putting up a module on
CPAN that shoots everyone in the foot for that matter).

But you're bringing up an interesting topic: What would be a good
approach to allow a library to meddle with Log4perl's settings, in the
absence or even presence of a previous initialization?

Everything I've seen so far is just plain confusing to the end user. I'm
open to ideas, however.


-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] logger state is global

[Tom M. <tme...@gm...>]

I like the API Log::Log4perl provides, but using Log::Log4perl v1.28
I've encountered issues with the internal implementation that have been
very time consuming to resolve.

Most relate to the way Log4perl seems to store state in global or class
variables rather than in object or instance variables. This means that
unless you take extra steps to prevent it, library modules that call
upon Log4perl directly will stomp on the logger established by the
calling code.

This state mechanism also is incompatible with Class::Remote (a module
developed at Shopzilla for remote code execution, which apparently
hasn't been released to CPAN), as it attempts to serialize an object's
data and send it to the remote end.

Perhaps all this is a consequence of our use of easy_init(), though if
so, convenience methods shouldn't have the consequence of creating a
fragile system.

The general objectives I'd like to achieve are:

1. Ability to create a library module that can use Log4perl, such that
if the calling code makes no use of Log4perl, it logs independently with
locally specified defaults, but if the caller does use Log4perl, it
picks up the callers settings.

2. Fully serializable state.


Here's an example of an issue I ran into today. I had a block of code
being evaluated that contained an error. The eval() was followed by an
error check, which then called logdie() with $@. But post-evaluation,
logdie() or any other Log4perl method failed to produce any output,
resulting the program mysteriously exiting with no error.

A trace showed that $self->is_fatal(), as called by
Log::Log4perl::Logger->logdie(), which resolved to:
return sub { $return_token };
which apparently returned false, meaning that FATAL level logging is
disabled, which should never be the case.

The trigger for the problem turned out to be a 'use' call in the eval'ed
code that loaded a library which internally called easy_init() (yet
specifying the INFO logging level).

This seems broken that a library using normal Log4perl methods can trash
the logger in use by the calling code.

Is there a more correct way to be using the API to avoid this, or does
Log4perl need some internal refactoring?

 -Tom

Re: [log4perl-devel] Best way to prevent dying when disk is full.

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

On Mon, 8 Nov 2010, Kidwell,jr, Jack wrote:

> under any circumstances. Trivial tests show that a disk full condition
> causes logging to die.
>
> We want to use Log4perl because of it's features, so what is the
> best way to prevent Log4perl from dying.

There's a couple of ways Log4perl can die(), so you need to wrap

     eval { };

statements around these sections. One way is if ->init() fails, that one
you can easily enclose in an eval {}. When it comes to logging to
a file, this is trickier, because the Log::Log4perl::Appender::File
appender checks if writing to the file succeeds and dies if this fails.

What you can do in this case is define a class that inherits from it and
wraps an eval {} around the log method:

#!/usr/bin/perl -w
use strict;

package NeverDieFileAppender;
use base qw( Log::Log4perl::Appender::File );

sub log {
     my($self, @args) = @_;

     local $Log::Log4perl::caller_depth =
           $Log::Log4perl::caller_depth + 1;

     eval { $self->SUPER::log(@args) };
}

package main;

use Log::Log4perl qw(:easy);
Log::Log4perl->init( \q{
     log4perl.logger = DEBUG, App
     log4perl.appender.App = NeverDieFileAppender
     log4perl.appender.App.filename = out.dat
     log4perl.appender.App.layout = PatternLayout
     log4perl.appender.App.layout.ConversionPattern = %F-%L: %m%n
});

DEBUG "waah";

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] Best way to prevent dying when disk is full.

[Kidwell,jr, J. <Jac...@ca...>]

Hi,

We have a requirement that logging shall not cause program termination under any circumstances. Trivial tests show that a disk full condition causes logging to die.

We want to use Log4perl because of it's features, so what is the best way to prevent Log4perl from dying.

Thanks!

Jack Kidwell

Re: [log4perl-devel] Log::Log4perl has duplicate entries

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

On Wed, 3 Nov 2010, Huang, Jack wrote:

> It looks like both the root and the Test_Log4perl categories are
> logging the same messages from Test_Log4perl if the message levels are
> higher than the log level configured for Test_Log4perl. Can we log
> such messages just once?

Yeah, you need to use the 'additivity' flag as described here:

     http://search.cpan.org/dist/Log-Log4perl/lib/Log/Log4perl/FAQ.pm#I_keep_getting_duplicate_log_messages!_What%27s_wrong?

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] Log::Log4perl has duplicate entries

[Huang, J. <hu...@qu...>]

Hello,

It looks like both the root and the Test_Log4perl categories are logging the same messages from Test_Log4perl if the message levels are higher than the log level configured for Test_Log4perl. Can we log such messages just once?

Thanks!
Cunzhi Huang

---- sample output -------------
[2010/11/02 22:02:34]  WARN  log4perl.pl  Test_Log4perl::test  21 - warn
[2010/11/02 22:02:34]  WARN  log4perl.pl  Test_Log4perl::test  21 - warn
[2010/11/02 22:02:37]  DEBUG  log4perl.pl  main::main_test  10 - debug
[2010/11/02 22:02:37]  INFO  log4perl.pl  main::main_test  11 - info
[2010/11/02 22:02:37]  WARN  log4perl.pl  Test_Log4perl::test  21 - warn
[2010/11/02 22:02:37]  WARN  log4perl.pl  Test_Log4perl::test  21 - warn
[2010/11/02 22:02:40]  DEBUG  log4perl.pl  main::main_test  10 - debug
[2010/11/02 22:02:40]  INFO  log4perl.pl  main::main_test  11 - info
[2010/11/02 22:02:40]  WARN  log4perl.pl  Test_Log4perl::test  21 - warn
[2010/11/02 22:02:40]  WARN  log4perl.pl  Test_Log4perl::test  21 - warn
[2010/11/02 22:02:43]  DEBUG  log4perl.pl  main::main_test  10 - debug
[2010/11/02 22:02:43]  INFO  log4perl.pl  main::main_test  11 - info
[2010/11/02 22:02:43]  WARN  log4perl.pl  Test_Log4perl::test  21 - warn
[2010/11/02 22:02:43]  WARN  log4perl.pl  Test_Log4perl::test  21 - warn

--- config file ----
# root logger
log4perl.logger=DEBUG, LOGFILE
# override root logger
log4perl.logger.Test_Log4perl = INFO,  LOGFILE

log4perl.appender.LOGFILE=Log::Log4perl::Appender::File
log4perl.appender.LOGFILE.filename=/tmp/log4perl.log
log4perl.appender.LOGFILE.mode=append

log4perl.appender.LOGFILE.layout=PatternLayout
log4perl.appender.LOGFILE.layout.ConversionPattern=[%d]  %p  %F  %M  %L - %m%n

--- sample code ---
#!/usr/bin/perl -w
use strict;
use Log::Log4perl;

#
Log::Log4perl::init_and_watch('/root/tmp/perl/log4perl.conf',10);

sub main_test {
   my $log = Log::Log4perl::get_logger(); # root logger
   $log->debug("debug");
   $log->info("info");
}

{
   package Test_Log4perl;
   sub test {
      # need to change config file
      my $log = Log::Log4perl::get_logger("Test_Log4perl"); # for this class

      $log->debug("debug");
      $log->warn("warn");
   }
} # end of package

while (1) {
   main_test();
   Test_Log4perl::test();
   sleep 3;
}

[log4perl-devel] Log4perl 1.31 released

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

Hi Log4perl enthusiasts,

Log4perl 1.31 just has been released to CPAN. It fixes only one
annoying test problem on Windows:

1.31 (2010/10/27)
   *     (ms) Fixed the number of skipped tests for Windows for previous
         fix of [RT 60665].

Just didn't want to sit on it any longer, enjoy!

-- Mike

Mike Schilli
m...@pe...