log4perl-devel — Ongoing log4perl development

[log4perl-devel] Re: Recognize Perl/Java appenders

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

OK, I just implemented that and a few other tweaks.  It's probably 
precipitous to include them in your pending release, just to be 
conservative.

I got rid of the warnings printed during 014ConfErrs.t about 'ambiguous 
use of require without parens, tweaked the error messages given for bad 
config files, and added hooks to JavaMap so users can add their own.

Changes are checked in, a diff is attached if anybody's curious.

Mike Schilli wrote:
> On Mon, 9 Jun 2003, Kevin Goess wrote:
> 
> 
>>That's a good point, but that solution gives Java programmers the same
>>problem, if they want to make an appender in a simple namespace.
>>
>>How bout if we make it explicit, something like
>>    if ($Log::Log4perl::JavaMap::translate{$appenderclass}){
>>        #then it's Java
>>    }else{
>>        #it's Perl
>>
>>actually <type...type...type>  like the attached?
> 
> 
> I like it -- although I'm not sure if that's a likely case. After all,
> someone would have to write a new Java class and most likely a Perl
> class to map it to in order use it.
> 
> 
>>Hmmm, but the user would need a way to add their custom class's name to
>>the java map.  I guess they could just do that before they call init(),
>>I should document that, shouldn't I?  Or maybe even make a real accessor
>>method for the %translate hash, what do you think?
> 
> 
> I'm fine either way, whatever works :).
> 
> -- Mike
> 
> Mike Schilli
> log...@pe...
> http://perlmeister.com
> http://log4perl.sourceforge.net


-- 
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217

[log4perl-devel] Log-Log4perl 0.34

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

Hi all,

Log::Log4perl 0.34 contains an important bug fix, and has been pushed to
the web site. Here's what's been changed:

0.34 06/08/2003
    * (ms) James FitzGibbon <jam...@ta...> noticed a major
           bug in Log::Log4perl::Appender::File and provided a patch. Problem
           was that 0.33 was reusing the same file handle for every opened file,
           causing all messages to end up in the same file.

If you're all ok with it, I'm gonna push it to CPAN tomorrow.

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net

[log4perl-devel] Log::Log4perl::AutoCategorize-0.01

[Jim C. <jc...@di...>]

Folks,

Ive pulled the trigger, the attached module is now on its way to PAUSE.

Changes from 008 to 01 are predominantly POD rework,
but I also added the following prefix to each item in test-coverage report.

    #log4perl.category.

this makes the test-coverage report easily editable to a complete
list of all your calls to the logger.

Re: [log4perl-devel] Bug in Log::Log4perl::Appender::File v0.33

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

On Sat, 7 Jun 2003, James FitzGibbon wrote:

> When v0.33 came out, I switched over my file-based loggers from
> Log::Dispatch::File to Log::Log4perl::Appender::File.
> ...
> The problem is that Log::Log4perl::Appender::File always open the same
> filehandle 'FH', so a logging configuration that has two instances of
> the appender end up sending all messages to the file referenced by the
> last instance to be created.

Ouch. Thanks for reporting that. Here's a patch (I stole the 'local'-trick
from Log::Dispatch::File), we should push a new release soon:

Index: Changes
===================================================================
RCS file: /cvsroot/log4perl/Log-Log4perl/Changes,v
retrieving revision 1.127
diff -a -u -r1.127 Changes
--- Changes	31 May 2003 18:18:54 -0000	1.127
+++ Changes	7 Jun 2003 18:55:22 -0000
@@ -2,8 +2,13 @@
 Revision history for Log::Log4perl
 ##################################################

+0.34 (not yet released)
+    * (ms) James FitzGibbon <jam...@ta...> noticed a major
+           bug in Log::Log4perl::Appender::File and sent a patch. Problem
+           was that it was reusing the same file handle for every opened file,
+           so all messages were ending up in the same file.

-0.33
+0.33 05/30/2003
     * (kg) CPAN rt#2636, coordinating XML::DOM version required across modules
            and unit tests
     * (ms) Removed Log::Dispatch dependency, added standard
Index: lib/Log/Log4perl/Appender/File.pm
===================================================================
RCS file: /cvsroot/log4perl/Log-Log4perl/lib/Log/Log4perl/Appender/File.pm,v
retrieving revision 1.1
diff -a -u -r1.1 File.pm
--- lib/Log/Log4perl/Appender/File.pm	29 May 2003 08:37:11 -0000	1.1
+++ lib/Log/Log4perl/Appender/File.pm	7 Jun 2003 18:55:22 -0000
@@ -26,10 +26,12 @@
         $arrows = ">>";
     }

-    open FH, "$arrows$self->{filename}" or
+    my $fh = do { local *FH; *FH; };
+
+    open $fh, "$arrows$self->{filename}" or
         die "Can't open $self->{filename} ($@)";

-    $self->{fh} = \*FH;
+    $self->{fh} = $fh;

     bless $self, $class;
 }
Index: t/026FileApp.t
===================================================================
RCS file: /cvsroot/log4perl/Log-Log4perl/t/026FileApp.t,v
retrieving revision 1.4
diff -a -u -r1.4 026FileApp.t
--- t/026FileApp.t	31 May 2003 18:51:29 -0000	1.4
+++ t/026FileApp.t	7 Jun 2003 18:55:23 -0000
@@ -25,9 +25,9 @@
     mkdir("$WORK_DIR", 0755) || die "can't create $WORK_DIR ($!)";
 }

-my $testfile = File::Spec->catfile(qw(t tmp test26.log));
+my $testfile = File::Spec->catfile($WORK_DIR, "test26.log");

-BEGIN {plan tests => 5}
+BEGIN {plan tests => 6}

 END { unlink $testfile;
       unlink "${testfile}_1";
@@ -126,7 +126,7 @@
     $log->info("Shu-wa-chi!");

     for(qw(1 2)) {
-        open FILE, "<${testfile}_$_" or die "Cannot create ${testfile}_$_";
+        open FILE, "<${testfile}_$_" or die "Cannot open ${testfile}_$_";
         $content = join '', <FILE>;
         close FILE;

@@ -137,4 +137,34 @@
     # We don't have Log::Dispatch, skip these cases
     ok(1);
     ok(1);
+}
+
+#########################################################
+# Check if the 0.33 Log::Log4perl::Appender::File bug is
+# fixed which caused all messages to end up in the same
+# file.
+#########################################################
+$data = <<EOT;
+log4perl.category = INFO, FileAppndr1, FileAppndr2
+log4perl.appender.FileAppndr1          = Log::Log4perl::Appender::File
+log4perl.appender.FileAppndr1.filename = ${testfile}_1
+log4perl.appender.FileAppndr1.mode     = append
+log4perl.appender.FileAppndr1.layout   = Log::Log4perl::Layout::SimpleLayout
+
+log4perl.appender.FileAppndr2          = Log::Log4perl::Appender::File
+log4perl.appender.FileAppndr2.filename = ${testfile}_2
+log4perl.appender.FileAppndr2.mode     = append
+log4perl.appender.FileAppndr2.layout   = Log::Log4perl::Layout::SimpleLayout
+EOT
+
+Log::Log4perl::init(\$data);
+$log = Log::Log4perl::get_logger("");
+$log->info("Shu-wa-chi!");
+
+for(qw(1 2)) {
+    open FILE, "<${testfile}_$_" or die "Cannot open ${testfile}_$_";
+    $content = join '', <FILE>;
+    close FILE;
+
+    ok($content, "INFO - Shu-wa-chi!\n");
 }

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net

[log4perl-devel] Bug in Log::Log4perl::Appender::File v0.33

[James F. <jf...@ma...>]

When v0.33 came out, I switched over my file-based loggers from 
Log::Dispatch::File to Log::Log4perl::Appender::File.

The configuration I'm using looks like this when dumped as a hashref:

0  HASH(0x9adcf4)
    'log4perl.appender.dpa00102' => 'Log::Log4perl::Appender::File'
    'log4perl.appender.dpa00102.Threshold' => 'INFO'
    'log4perl.appender.dpa00102.filename' => 'dpa00102.log'
    'log4perl.appender.dpa00102.layout' => 
'Sys3D::Logger::Layout::Common'
    'log4perl.appender.dpa00102_debug' => 'Log::Log4perl::Appender::File'
    'log4perl.appender.dpa00102_debug.filename' => 'dpa00102_debug.log'
    'log4perl.appender.dpa00102_debug.layout' => 
'Sys3D::Logger::Layout::Common'
    'log4perl.appender.dpa00102_debug.layout.ConversionPattern' => 
'debug'
    'log4perl.logger' => 'DEBUG, dpa00102_debug, dpa00102'

When I started using this configuration, I noticed that all of my log 
messages started going to the same file.  Each logging statement was 
logged twice in this case, though each had it's own proper format (the 
custom layout module referenced above is just a subclass of 
PatternLayout):

06/07/2003 10:53:24 INFO  dpa00102.pl[22997/th0] START
06/07/2003 10:53:24.584 INFO  dpa00102.pl[22997/th0] (main::): START 
(dpa00102.pl/11)

The problem is that Log::Log4perl::Appender::File always open the same 
filehandle 'FH', so a logging configuration that has two instances of 
the appender end up sending all messages to the file referenced by the 
last instance to be created.

If I load up the above config and then dump 
%Log::Log4perl::Logger::APPENDER_BY_NAME, you can see how the glob is 
re-used:

0  HASH(0x7c69cc)
    'dpa00102' => Log::Log4perl::Appender=HASH(0xe66ff0)
       'appender' => Log::Log4perl::Appender::File=HASH(0xe671b8)
          'Threshold' => 'INFO'
          'autoflush' => 1
          'fh' => GLOB(0xe617a0)
             -> *Log::Log4perl::Appender::File::FH
                   FileHandle({*Log::Log4perl::Appender::File::FH}) => 
fileno(7)
          'filename' => 'dpa00102.log'
          'min_level' => 'debug'
          'mode' => 'append'
          'name' => 'dpa00102'
       'layout' => Sys3D::Logger::Layout::Common=HASH(0xe67188)
          'CSPECS' => 'cCdFHIlLmMnpPrtxX%'
          'dontCollapseArrayRefs' => undef
          'format' => undef
          'info_needed' => HASH(0xe60294)
          [...]
          'message_chompable' => 1
          'printformat' => '%s %-5s %s[%s/th%s] %s%s'
          'stack' => ARRAY(0xe67158)
             0  ARRAY(0xe6729c)
                0  'd'
                [...]
       'level' => 20000
       'name' => 'dpa00102'
       'warp_message' => undef
    'dpa00102_debug' => Log::Log4perl::Appender=HASH(0xe51740)
       'appender' => Log::Log4perl::Appender::File=HASH(0xe5177c)
          'autoflush' => 1
          'fh' => GLOB(0xe617a0)
             -> REUSED_ADDRESS
          'filename' => 'dpa00102_debug.log'
          'min_level' => 'debug'
          'mode' => 'append'
          'name' => 'dpa00102_debug'
       'layout' => Sys3D::Logger::Layout::Common=HASH(0xe5fb7c)
          'CSPECS' => 'cCdFHIlLmMnpPrtxX%'
          'dontCollapseArrayRefs' => undef
          'format' => undef
          'info_needed' => HASH(0xe517e8)
          [...]
          'message_chompable' => 0
          'printformat' => '%s %-5s %s[%s/th%s] %s(%s): %s (%s/%s)%s'
          'stack' => ARRAY(0xe517a0)
             0  ARRAY(0xe602d0)
                0  'd'
                [...]
       'level' => 10000
       'name' => 'dpa00102_debug'
       'warp_message' => undef

The solution is to make sure that a new glob is used each time, which 
can be done in a number of ways, though Symbol::geniosym probably makes 
the most sense.  Changing the code that opens the file to this:

      require Symbol;
      my $fh = Symbol::geniosym;
      open $fh, "$arrows$self->{filename}" or
          die "Can't open $self->{filename} ($@)";

I've tested this and the problem described above does go away with this 
approach.

Regards.

--
j.

Re: [log4perl-devel] Calling $logger->info() from DESTROY method of a Perl object

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

On Wed, 4 Jun 2003 gm...@gm... wrote:

> This boils down to the fact that the class BE keeps a class hash (implemented as
> an "our" or "my" lexical variable with package/file scope) that contains an
> array with references to each BE object instance.  The reference to the array
> can be retrieved with BE->ALL.

That explains most of it, although I'm still puzzled why the debugger
doesn't show it.

> Any time a BE object goes out of scope, the @{BE->ALL} array still holds a
> reference to it, so DESTROY doesn't get to run until the entire program
> completes, at which time all other items in the interpreter (including
> Log::Log4perl) are already gone.  Hence the problem, which is totally unrelated
> to Log::Log4perl.
>
> I've fixed the problem for two scenarios:

How about a wrapper class, each object carrying a BE object? If those
wrapper objects go out of scope, their DESTROY is called, and you can do
the cleanup of the contained BE object manually (e.g. by removing the
entry in ALL).

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net

Re: [log4perl-devel] Calling $logger->info() from DESTROY method of a Perl object

[<gm...@gm...>]

The problem has been solved - I did it to myself.

This boils down to the fact that the class BE keeps a class hash (implemented as
an "our" or "my" lexical variable with package/file scope) that contains an
array with references to each BE object instance.  The reference to the array
can be retrieved with BE->ALL.

Any time a BE object goes out of scope, the @{BE->ALL} array still holds a
reference to it, so DESTROY doesn't get to run until the entire program
completes, at which time all other items in the interpreter (including
Log::Log4perl) are already gone.  Hence the problem, which is totally unrelated
to Log::Log4perl.

I've fixed the problem for two scenarios:

1. Normal program termination
2. Aborts (signals, etc)

- All entries in @{BE->ALL} are made to be weak references
- In the main program, I keep references to all of the objects I'm creating
- In the case of normal program completed, I make sure to undef all of the
  object references, causing DESTROY to be run on them all before program
  termination
- In the case of abnormal program termination, I wrap all object calls in
  eval blocks, so die'ing in the object returns control to the main program,
  which undef's each object before termination.  Thus, DESTROY still gets to
  run properly for each object before program termination.

I need to find a resource that describes how to do this more elegantly.  Can't
find a good reference for dealing with exceptions and handling object references
properly in Object Oriented Perl.  Any suggestions?

At any rate, this is now determined NOT to be a problem with Log::Log4perl,
unless someone who knows better thinks differently.  Thanks for the comments
that led to the final solution.

Gordon 


Quoting Mike Schilli <log...@pe...>:

> On Tue, 3 Jun 2003, Gordon Marler wrote:
> 
> > # tri-natured: function, class method, or object method
> > sub _classobj {
> >   my $objclass = shift || __PACKAGE__;
> >   my $class = ref($objclass) || $objclass;
> >   no strict "refs";  # to convert sym ref to real one
> >   return \%$class;
> > }
> >
> > for my $datum (keys %{ _classobj() } ) {
> >   # turn off strict refs so that we can register a method
> >   # in the symbol table
> >   no strict "refs";
> >   *$datum = sub {
> >     use strict "refs";
> >     my $self = shift->_classobj();
> >     $self->{$datum} = shift if @_;
> >     return $self->{$datum};
> >   }
> > }
> 
> Ok, the previously posted suggestions should fix the problem described here,
> but just out of curiosity:
> 
> The reason for the warning message is very obscure. If you call the test
> program test.pl, consisting of
> 
>    use BE;
>    $be = new BE;
>    undef $be;
>    print "\nfinished\n";
> 
> you'll get
> 
>    (in cleanup) Can't call method "log" on an undefined value at (eval 14)
> line 37 during global destruction
> 
> with the BE.pm code previously posted by Gordon and attached at the end of
> this email.
> 
> However, if you're using the debugger, and run it like
> 
>     perl -d test.pl
>     DB<1> r
> 
> you'll just get
> 
>     finished
>     Debugged program terminated.  Use q to quit or R to restart,
> 
> Seems like the perl core gets confused with the reference count somehow.
> Would be interesting if we can isolate the problem to a couple of lines
> of code so we could submit it to p5p for further investigation ...
> 
> -- Mike
> 
> Mike Schilli
> log...@pe...
> http://perlmeister.com
> http://log4perl.sourceforge.net
> 
> 
> ############################################################
> # Code for BE.pm
> ############################################################
> 
> package BE;
> 
> use Log::Log4perl qw(:easy);
> 
> %BE = (
>   logger         => "",
>   ConfigFile     => "/etc/lb_lutab",
>   # List of all BE objects
>   ALL            => [ ],
> );
> 
>  #tri-natured: function, class method, or object method
> sub _classobj {
>   my $objclass = shift || __PACKAGE__;
>   my $class = ref($objclass) || $objclass;
>   no strict "refs";  # to convert sym ref to real one
>   return \%$class;
> }
> 
> for my $datum (keys %{ _classobj() } ) {
>   # turn off strict refs so that we can register a method
>   # in the symbol table
>   no strict "refs";
>  *$datum = sub {
>     use strict "refs";
>     my $self = shift->_classobj();
>     $self->{$datum} = shift if @_;
>    return $self->{$datum};
>   }
> }
> 
> # Constructor
> sub new {
>   my ($caller,%arg) = @_;
>   my $caller_is_obj = ref($caller);
>   my $class = $caller_is_obj || $caller;
>   my ($logger);
> 
>   unless (BE->logger) {
>     Log::Log4perl->easy_init($DEBUG);
>     my $logger = Log::Log4perl->get_logger('BE');
>     print "logger is $logger\n";
>     BE->logger($logger);
>   }
> 
>   $logger = Log::Log4perl->get_logger('BE');
> 
>   my $instance = {
>     _name           => $arg{name}    ||  # Name of this BE
>                        undef,
>      #... Other members of the object ...
>     _logger         => undef,
>   };
> 
>   # Save a copy of BE->logger here so the reference to the logger can
>   # for use inside DESTROY
>   $instance->{_logger} = $logger;
> 
>   # Append this to the Class list of all BEs
>   my ($all) = BE->ALL();
>   push @{$all}, $instance;
>   BE->ALL($all);
>   bless $instance, $class;
> 
> }
> 
> sub DESTROY {
>   my ($self) = @_;
>   my ($logger) = Log::Log4perl->get_logger("BE");
>   $logger->info("Entering DESTROY method for " . __PACKAGE__ . "\n");
> }
> 
> 1;
> 
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Re: [log4perl-devel] Calling $logger->info() from DESTROY method of a Perl object

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

On Tue, 3 Jun 2003, Gordon Marler wrote:

> # tri-natured: function, class method, or object method
> sub _classobj {
>   my $objclass = shift || __PACKAGE__;
>   my $class = ref($objclass) || $objclass;
>   no strict "refs";  # to convert sym ref to real one
>   return \%$class;
> }
>
> for my $datum (keys %{ _classobj() } ) {
>   # turn off strict refs so that we can register a method
>   # in the symbol table
>   no strict "refs";
>   *$datum = sub {
>     use strict "refs";
>     my $self = shift->_classobj();
>     $self->{$datum} = shift if @_;
>     return $self->{$datum};
>   }
> }

Ok, the previously posted suggestions should fix the problem described here,
but just out of curiosity:

The reason for the warning message is very obscure. If you call the test
program test.pl, consisting of

   use BE;
   $be = new BE;
   undef $be;
   print "\nfinished\n";

you'll get

   (in cleanup) Can't call method "log" on an undefined value at (eval 14) line 37 during global destruction

with the BE.pm code previously posted by Gordon and attached at the end of
this email.

However, if you're using the debugger, and run it like

    perl -d test.pl
    DB<1> r

you'll just get

    finished
    Debugged program terminated.  Use q to quit or R to restart,

Seems like the perl core gets confused with the reference count somehow.
Would be interesting if we can isolate the problem to a couple of lines
of code so we could submit it to p5p for further investigation ...

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net


############################################################
# Code for BE.pm
############################################################

package BE;

use Log::Log4perl qw(:easy);

%BE = (
  logger         => "",
  ConfigFile     => "/etc/lb_lutab",
  # List of all BE objects
  ALL            => [ ],
);

 #tri-natured: function, class method, or object method
sub _classobj {
  my $objclass = shift || __PACKAGE__;
  my $class = ref($objclass) || $objclass;
  no strict "refs";  # to convert sym ref to real one
  return \%$class;
}

for my $datum (keys %{ _classobj() } ) {
  # turn off strict refs so that we can register a method
  # in the symbol table
  no strict "refs";
 *$datum = sub {
    use strict "refs";
    my $self = shift->_classobj();
    $self->{$datum} = shift if @_;
   return $self->{$datum};
  }
}

# Constructor
sub new {
  my ($caller,%arg) = @_;
  my $caller_is_obj = ref($caller);
  my $class = $caller_is_obj || $caller;
  my ($logger);

  unless (BE->logger) {
    Log::Log4perl->easy_init($DEBUG);
    my $logger = Log::Log4perl->get_logger('BE');
    print "logger is $logger\n";
    BE->logger($logger);
  }

  $logger = Log::Log4perl->get_logger('BE');

  my $instance = {
    _name           => $arg{name}    ||  # Name of this BE
                       undef,
     #... Other members of the object ...
    _logger         => undef,
  };

  # Save a copy of BE->logger here so the reference to the logger can
  # for use inside DESTROY
  $instance->{_logger} = $logger;

  # Append this to the Class list of all BEs
  my ($all) = BE->ALL();
  push @{$all}, $instance;
  BE->ALL($all);
  bless $instance, $class;

}

sub DESTROY {
  my ($self) = @_;
  my ($logger) = Log::Log4perl->get_logger("BE");
  $logger->info("Entering DESTROY method for " . __PACKAGE__ . "\n");
}

1;

Re: [log4perl-devel] Calling $logger->info() from DESTROY method of a Perl object

[Gordon M. <gm...@gm...>]

Thanks for the advice - I'll take it to heart and make the recommended
change in #1 at the very least.

Note that in trying to simplify this issue, I eventually remove the
"Class" attributes hash %BE (defined as "our %BE").  I use this to try
to keep track of several things related to this application, such as:
1. Total number of BE object instances
2. Config data that is global

Seems that if I remove this entirely, the DESTROY problem disappears. 
I'll look into this more after I implement your suggested changes.

Gordon

On Tue, 2003-06-03 at 13:25, Mike Schilli wrote:
> On Tue, 3 Jun 2003, Gordon Marler wrote:
> 
> > I noticed that the Log4perl was pretty much a singleton pattern a while
> > back, so my object's constructor looks like this:
> > ...
> > # Constructor
> > sub new {
> > ...
> >   unless (BE->logger) {
> >     Log::Log4perl::init_and_watch('/usr/LBBE/bootdiskmanager/bin/log.conf',10);
> >         my $logger = Log::Log4perl->get_logger('BE');
> >         BE->logger($logger);
> >   }
> >   $logger = Log::Log4perl->get_logger('BE');
> > ...
> >   $instance->{_logger} = $logger;
> 
> I see two problems with this approach:
> 
> 1) As mentioned in my previous post, Log::Log4perl->init() (or
>    init_and_watch) should only be called in the main program, not in
>    libraries or classes. Reason for this is that there can (currently)
>    only be *one* configuration file. If you call Log::Log4perl->init()
>    multiple times (what you will do implicitely if someone else doesn't
>    comply with this Log4perl mandate either), the last call to init()
>    will overwrite all previous settings.
>    Bottom line: Log::Log4perl->init() (or init_and_watch) should only
>                 be called in the main program.
> 
> 2) my $logger = Log::Log4perl->get_logger('BE');
>    will always return a reference to the *same* object, no matter how
>    often you call it or which class/object instance you're calling it from.
>    This instance should *never* be stored anywhere or deleted.
>    Always retrieve them via get_logger().
> 
> 3) Your particular problem seems to be related with the way your accessors
> work, I haven't tracked it down yet entirely, but it works with "regular"
> instance variables. Tonight, I'm gonna look into it again, but it shouldn't
> be relevant because you can fix the problem by fixing 1) and 2).
> 
> -- Mike
> 
> Mike Schilli
> log...@pe...
> http://perlmeister.com
> http://log4perl.sourceforge.net
-- 
Gordon Marler <gm...@gm...>

Re: [log4perl-devel] Calling $logger->info() from DESTROY method of a Perl object

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

On Tue, 3 Jun 2003, Gordon Marler wrote:

> I noticed that the Log4perl was pretty much a singleton pattern a while
> back, so my object's constructor looks like this:
> ...
> # Constructor
> sub new {
> ...
>   unless (BE->logger) {
>     Log::Log4perl::init_and_watch('/usr/LBBE/bootdiskmanager/bin/log.conf',10);
>         my $logger = Log::Log4perl->get_logger('BE');
>         BE->logger($logger);
>   }
>   $logger = Log::Log4perl->get_logger('BE');
> ...
>   $instance->{_logger} = $logger;

I see two problems with this approach:

1) As mentioned in my previous post, Log::Log4perl->init() (or
   init_and_watch) should only be called in the main program, not in
   libraries or classes. Reason for this is that there can (currently)
   only be *one* configuration file. If you call Log::Log4perl->init()
   multiple times (what you will do implicitely if someone else doesn't
   comply with this Log4perl mandate either), the last call to init()
   will overwrite all previous settings.
   Bottom line: Log::Log4perl->init() (or init_and_watch) should only
                be called in the main program.

2) my $logger = Log::Log4perl->get_logger('BE');
   will always return a reference to the *same* object, no matter how
   often you call it or which class/object instance you're calling it from.
   This instance should *never* be stored anywhere or deleted.
   Always retrieve them via get_logger().

3) Your particular problem seems to be related with the way your accessors
work, I haven't tracked it down yet entirely, but it works with "regular"
instance variables. Tonight, I'm gonna look into it again, but it shouldn't
be relevant because you can fix the problem by fixing 1) and 2).

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net

Re: [log4perl-devel] Calling $logger->info() from DESTROY method of a Perl object

[Jim C. <jc...@di...>]

Gordon Marler wrote:

>I've been using Log::Log4perl for several months now, with great success
>- great job!
>
>I've designed my Perl object to contain a reference to a Log::Log4perl
>object, and this seems to work for all methods in the object except
>DESTROY.  Here's an example of what my DESTROY method looks like (the
>name of my object and it's package is "BE"):
>
>sub DESTROY {
>  my ($self) = @_;
>  my ($logger) = Log::Log4perl->get_logger("BE");
>  $logger->info("Entering DESTROY method for " . __PACKAGE__ . "\n");
>}
>
>
>However, when my script ends, I get the following error message as the
>DESTROY method of my object gets called:
>
>        (in cleanup) Can't call method "log" on an undefined value at
>(eval 271) line 42 during global destruction.
>
>  
>

a couple things to consider:

change the order of use, so that the END block in question runs before 
Log::Log4perl
is unloaded.

is your DESTROY being called 'really late' ? 
ie as a part of process cleanup rather than a variable going out of scope ?
If so, Id look to make it (ie $it->DESTROY) a my var,
 in a package that is reclaimed early in the process end.

FWIW - Im using a logger object from an END block succesfully,
in Log::Log4perl::AutoCategorize.  I put a beta out just recently  :-)
You may want to look there.  (and send me your perftest/timeit.sh 
results please)

Re: [log4perl-devel] Calling $logger->info() from DESTROY method of a Perl object

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

Gordon Marler wrote:
> I see what you're getting at - unfortunately, the change to using:
> 
> my ($logger) = $self->{_logger};
> 
> still fails, as $self->{_logger} is "undef"!  As the Data::Dumper output
> I included indicates, the Log4perl reference in $self->{_logger} has
> been garbage collected by Perl before my object's DESTROY method ever
> gets called.


Doh!  You're right, sorry.  I tried reconstructing your situation from 
the subsequent code samples you sent and it seems to go ok:

   use BE;
   $be = new BE;
   undef $be;  #logs message from DESTROY just fine
   print "\nfinished\n";

So there must be something else going on.  Nothing immediately occurs to 
me that might cause the behavior you're seeing, but if I think of 
something I'll let you know.


	


-- 
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217

Re: [log4perl-devel] Calling $logger->info() from DESTROY method of a Perl object

[Gordon M. <gm...@gm...>]

I noticed that the Log4perl was pretty much a singleton pattern a while
back, so my object's constructor looks like this:

our %BE = (
  logger         => "",
  ConfigFile     => "/etc/lb_lutab",
  # List of all BE objects
  ALL            => [ ],
);

# tri-natured: function, class method, or object method
sub _classobj {
  my $objclass = shift || __PACKAGE__;
  my $class = ref($objclass) || $objclass;
  no strict "refs";  # to convert sym ref to real one
  return \%$class;
}

for my $datum (keys %{ _classobj() } ) {
  # turn off strict refs so that we can register a method
  # in the symbol table
  no strict "refs";
  *$datum = sub {
    use strict "refs";
    my $self = shift->_classobj();
    $self->{$datum} = shift if @_;
    return $self->{$datum};
  }
}

# Constructor
sub new {
  my ($caller,%arg) = @_;
  my $caller_is_obj = ref($caller);
  my $class = $caller_is_obj || $caller;
  my ($logger);

  unless (BE->logger) {
	Log::Log4perl::init_and_watch('/usr/LBBE/bootdiskmanager/bin/log.conf',10);
    	my $logger = Log::Log4perl->get_logger('BE');
    	BE->logger($logger);
  }
  $logger = Log::Log4perl->get_logger('BE');

  my $instance = {
    _name           => $arg{name}    ||  # Name of this BE
                       undef,     
     ... Other members of the object ...      
    _logger         => undef,
  };

  # Save a copy of BE->logger here so the reference to the logger can
survive
  # for use inside DESTROY
  $instance->{_logger} = $logger;

  # Append this to the Class list of all BEs
  my ($all) = BE->ALL();
  push @{$all}, $instance;
  BE->ALL($all);
  bless $instance, $class;

}

Note the following:

If this is the first BE object in the system, then we have to explicitly
create the logger (singleton) and tuck it away. I also put a reference
to it in my object's instance, so all of my objects have individual
references to the logger.

Thus, the logger should stay around until the very last BE object calls
it's DESTROY method.  This doesn't seem to be the case, as when the last
BE object enters DESTROY, $self->{_logger} has the value "undef".  Not
good.

On Tue, 2003-06-03 at 11:47, Mike Schilli wrote:
> On Tue, 3 Jun 2003, Gordon Marler wrote:
> 
> > I've been using Log::Log4perl for several months now, with great success
> > - great job!
> 
> Thanks! :)
> 
> > I've designed my Perl object to contain a reference to a Log::Log4perl
> > object, and this seems to work for all methods in the object except
> > DESTROY.  Here's an example of what my DESTROY method looks like (the
> > name of my object and it's package is "BE"):
> >
> > sub DESTROY {
> >   my ($self) = @_;
> >   my ($logger) = Log::Log4perl->get_logger("BE");
> >   $logger->info("Entering DESTROY method for " . __PACKAGE__ . "\n");
> > }
> 
> Hmm ... I'm not quite sure how you're storing references to Log::Logp4erl
> objects in your object -- there's really no "Log::Log4perl objects".
> 
> Typically, you call
> 
>     use Log::Log4perl;
>     Log::Log4perl->init(...);
> 
> at the beginning of your program and then, within your class code,
> you use
> 
>     package MyClass;
> 
>     use Log::Log4perl;
> 
>     sub method {
>         my ($logger) = Log::Log4perl->get_logger("BE");
>         $logger->info("message");
>     }
> 
> There's really no "Log::Log4perl objects" -- instead, Log4perl uses
> a singleton mechanism for its loggers.
> 
> You didn't submit your class' constructor method, so I can only speculate:
> the problem might be related to storing this "Log::Log4perl reference".
> Instead, just initialize Log::Log4perl once at the start of the main (!)
> program and call the loggers in your custom class like shown above, that
> should fix the problem.
> 
> Hope that helps!
> 
> -- Mike
> 
> Mike Schilli
> log...@pe...
> http://perlmeister.com
> http://log4perl.sourceforge.net
-- 
Gordon Marler <gm...@gm...>

[log4perl-devel] Log::Log4perl 0.33 on its way to CPAN

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

Hi all,

0.33 is on its way to CPAN, here's the Change notes again:

    0.33 05/30/2003
    * (kg) CPAN rt#2636, coordinating XML::DOM version required across modules
           and unit tests
    * (ms) Removed Log::Dispatch dependency, added standard
           Log::Log4perl::Appender appenders File and Screen.
           Log::Dispatch is still supported for backwards compatibility
           and special purpose appenders implemented within this hierarchy.

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net

Re: [log4perl-devel] Calling $logger->info() from DESTROY method of a Perl object

[Gordon M. <gm...@gm...>]

I see what you're getting at - unfortunately, the change to using:

my ($logger) = $self->{_logger};

still fails, as $self->{_logger} is "undef"!  As the Data::Dumper output
I included indicates, the Log4perl reference in $self->{_logger} has
been garbage collected by Perl before my object's DESTROY method ever
gets called.


On Tue, 2003-06-03 at 11:18, Kevin Goess wrote:
> > sub DESTROY {
> >   my ($self) = @_;
> >   my ($logger) = Log::Log4perl->get_logger("BE");
> >   $logger->info("Entering DESTROY method for " . __PACKAGE__ . "\n");
> > }
> > 
> > However, when my script ends, I get the following error message as the
> > DESTROY method of my object gets called:
> > 
> >         (in cleanup) Can't call method "log" on an undefined value at
> > (eval 271) line 42 during global destruction.
> 
> > Since I'm keeping a reference to the Log::Log4perl object inside my
> > object, 
> 
> If that's what you're doing, then use the reference instead of asking 
> the in-the-process-of-being-garbage-collected log4perl structs for one. 
>   Try it like this:
> 
>   sub DESTROY {
>     my ($self) = @_;
>     my ($logger) = $self->{_logger}; #using exising reference
>     $logger->info("Entering DESTROY method for " . __PACKAGE__ . "\n");
>   }
> 
> 
-- 
Gordon Marler <gm...@gm...>

Re: [log4perl-devel] Calling $logger->info() from DESTROY method of a Perl object

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

On Tue, 3 Jun 2003, Gordon Marler wrote:

> I've been using Log::Log4perl for several months now, with great success
> - great job!

Thanks! :)

> I've designed my Perl object to contain a reference to a Log::Log4perl
> object, and this seems to work for all methods in the object except
> DESTROY.  Here's an example of what my DESTROY method looks like (the
> name of my object and it's package is "BE"):
>
> sub DESTROY {
>   my ($self) = @_;
>   my ($logger) = Log::Log4perl->get_logger("BE");
>   $logger->info("Entering DESTROY method for " . __PACKAGE__ . "\n");
> }

Hmm ... I'm not quite sure how you're storing references to Log::Logp4erl
objects in your object -- there's really no "Log::Log4perl objects".

Typically, you call

    use Log::Log4perl;
    Log::Log4perl->init(...);

at the beginning of your program and then, within your class code,
you use

    package MyClass;

    use Log::Log4perl;

    sub method {
        my ($logger) = Log::Log4perl->get_logger("BE");
        $logger->info("message");
    }

There's really no "Log::Log4perl objects" -- instead, Log4perl uses
a singleton mechanism for its loggers.

You didn't submit your class' constructor method, so I can only speculate:
the problem might be related to storing this "Log::Log4perl reference".
Instead, just initialize Log::Log4perl once at the start of the main (!)
program and call the loggers in your custom class like shown above, that
should fix the problem.

Hope that helps!

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net

Re: [log4perl-devel] Calling $logger->info() from DESTROY method of a Perl object

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

> sub DESTROY {
>   my ($self) = @_;
>   my ($logger) = Log::Log4perl->get_logger("BE");
>   $logger->info("Entering DESTROY method for " . __PACKAGE__ . "\n");
> }
> 
> However, when my script ends, I get the following error message as the
> DESTROY method of my object gets called:
> 
>         (in cleanup) Can't call method "log" on an undefined value at
> (eval 271) line 42 during global destruction.

> Since I'm keeping a reference to the Log::Log4perl object inside my
> object, 

If that's what you're doing, then use the reference instead of asking 
the in-the-process-of-being-garbage-collected log4perl structs for one. 
  Try it like this:

  sub DESTROY {
    my ($self) = @_;
    my ($logger) = $self->{_logger}; #using exising reference
    $logger->info("Entering DESTROY method for " . __PACKAGE__ . "\n");
  }





-- 
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217

[log4perl-devel] Calling $logger->info() from DESTROY method of a Perl object

[Gordon M. <gm...@gm...>]

I've been using Log::Log4perl for several months now, with great success
- great job!

I've designed my Perl object to contain a reference to a Log::Log4perl
object, and this seems to work for all methods in the object except
DESTROY.  Here's an example of what my DESTROY method looks like (the
name of my object and it's package is "BE"):

sub DESTROY {
  my ($self) = @_;
  my ($logger) = Log::Log4perl->get_logger("BE");
  $logger->info("Entering DESTROY method for " . __PACKAGE__ . "\n");
}


However, when my script ends, I get the following error message as the
DESTROY method of my object gets called:

        (in cleanup) Can't call method "log" on an undefined value at
(eval 271) line 42 during global destruction.

Since I'm keeping a reference to the Log::Log4perl object inside my
object, I'm curious as to why the Log::Log4perl object is getting
destroyed before my object enters the DESTROY method.  Just to check, I
used Data::Dumper to print the state of the object while entering other
methods, and then when entering the DESTROY method - note the
difference:

Upon entering any normal method:
$VAR1 = bless( {
                 '_diskgroup' => 'rootdg',
                 '_logger' => bless( {
                                       'DEBUG' => sub { "DUMMY" },
                                       'additivity' => 1,
                                       'ALL' => sub { "DUMMY" },
                                       'appender_names' => [
                                                            
'ConsoleAppndr',
                                                            
'FileAppndr2'
                                                           ],
                                       'FATAL' =>
$VAR1->{'_logger'}{'DEBUG'},
                                       'ERROR' =>
$VAR1->{'_logger'}{'DEBUG'},
                                       'WARN' =>
$VAR1->{'_logger'}{'DEBUG'},
                                       'INFO' =>
$VAR1->{'_logger'}{'DEBUG'},
                                       'level' => 10000,
                                       'layout' => undef,
                                       'category' => 'BE',
                                       'num_appenders' => 14,
                                       'OFF' =>
$VAR1->{'_logger'}{'DEBUG'}
                                     }, 'Log::Log4perl::Logger' ),
                 '_mountpoint' => '/.lbbe.orig',
                 '_bootable' => '1',
                 '_complete' => '1',
                 '_filesystems' => {
                                     '/' => [
                                              'rootvol',
                                              'c0t0d0s0'
                                            ]
                                   },
                 '_device' => 'c0t0d0',
                 '_name' => 'orig',
                 '_creation' => undef,
                 '_dgid' => '1038429905.1025.ns3'
               }, 'BE' );

Upon entering the DESTROY method:
$VAR1 = bless( {
                 '_diskgroup' => 'rootdg',
                 '_logger' => undef,
                 '_mountpoint' => '/.lbbe.orig',
                 '_bootable' => '1',
                 '_complete' => '1',
                 '_filesystems' => {
                                     '/' => [
                                              'rootvol',
                                              'c0t0d0s0'
                                            ]
                                   },
                 '_device' => 'c0t0d0',
                 '_name' => 'orig',
                 '_creation' => undef,
                 '_dgid' => '1038429905.1025.ns3'
               }, 'BE' );

Note how _logger is now undef.


Any ideas on how to work around this problem?  I'd rather not resort to
just using print() inside the DESTROY method.

-- 
Gordon Marler <gm...@gm...>

Re: [log4perl-devel] Log::Log4perl::AutoCategorize

[Jim C. <jc...@di...>]

Mike Schilli wrote:

>On Fri, 30 May 2003, Jim Cromie wrote:
>
>  
>
>>Yeah, the optimizer part took some time to Grok.
>>I hope that the code and the comments will take you thru the hard parts,
>>let me know if otherwize.
>>    
>>
>
>Jim, nice work! Here's a couple of item I stumbled across, in the order
>I encountered them:
>
:-D

thx Mike & Kevin.  Yours are the 1st other set of eyeballs on it.

     Did you get a chance to run 'make test' ?
     On what platform(s) ?
     Did it just work ?
     Did you run perftests/timeit.sh ? (can you send me results ?)

>* You might want to explain what 'static method style' is.
>  
>
heh - static method is what I called it for lack of a better description.

'static method' is equivalent (at an approximate level)  to 'class method';

ie:       Class->method()   # what Ive called static (probably needs 
better name)
vs:       $obj->method()    # std instance method
vs:      Class::Method()     # Fully Qualified, class method.

I dont think there is a preferred name for this construct, would welcome 
corrections or
pod-citations, or even opinions as to what best conveys that the best.


>* You write: "Log::Log4perl provides easy_init(), which achieves some
>  simplification of categories, but you are still faced with creating
>  them once" -- but this function doesn't really do anything for categories.
>  The stealth logger feature included via 'use Log::Log4perl qw(:easy);'
>  is probably what you're referring to -- although you don't have to
>  'create' categories, it just uses the class names.
>  
>
heh - I guess I should write a use-case of it, following the specific 
example in perftest/t2.pl.
Then with a few tips, I could re-write it for a fair comparison wrt 
style, performance, etc..

>* As mentioned before, I like the coverage feature a lot. What's the
>  "unseen log", though, and how does it work?
>  
>

When function name munging is done (at use/check time), each munged name 
is recorded
as a key in an %unseen hash.   As each function-name is 1st seen by 
AUTOLOAD,
and vivified into a subroutine, the name is deleted from %unseen.    
What remains at
end-time are munged function names that were never called, so were never 
seen by AUTOLOAD.

>* Looks like in
>        # for example, debug Frob.pm, but only info on Frob::nicate()
>        log4perl.category.Frob = DEBUG
>        log4perl.category.Frob.nicate.debug = INFO
>  -- there's no appender, would be informative to see what the recommended
>  way of defining them is (and think of messages "bubbling up" :).
>  
>
hmm.  I left out any appender precisely to focus on how successive 
layers of categories would
filter the items - most debug from Frob:: would logged, but not from 
nicate(), cuz of the
more specific config-item.  And so on.    Ill try to clarify it, and 
re-test the phrasing on you all.

>* I didn't understand what you meant by this: "Its probably a bit
>  confusing at 1st to have debug=INFO, but this is intentional; it tells
>  you the logging level thats coded (so you dont have to go back to the
>  source everytime), and therefore what is done if the config-line is
>  commented out."
>  
>
self-fullfilling prophesy on the confusion, eh ?

The category that AUTOLOAD constructs includes the logging-level as 
extracted from the function,
(ex: info from Logger->info_00013).   Because its part of the category, 
it ends up in the coverage logs,
and can be cut-pasted into the config-file, where it serves to convey 
both; 'this is what it does now',
and 'this is what it does by default'. 

The 'does now' part is debug=INFO (ie this debug message is suppressed, 
cuz INFO is higher than debug)
The 'default' part is as follows : the code contains a debug call at 
package X, method Y, line Z, and if you
were to comment out this config-line, it would bubble up, and be dealt 
with according to other
config items. 

>* Question: If a module author decides to ship his module with
>  Log::Log4perl::AutoCategorize, will it work if the main program
>  (1) doesn't use it?
>  (2) uses plain Log::Log4perl?
>  
>

REALLY good question, cuz its really important to coexist, and I hadnt 
thought to test for it.

For 1, Id expect it would just pick up the default config.
For 2, I suspect that Imight load right over existing config, which 
would be bad.

which brings me to a set of Qs;

1 .Are you currently considering an include mechanism so that
    a config could be broken down into chunks that control the app's 
subsystems ?

2. Would the include scheme work for overrides & subclasses ?
    Id like it to be possible to specify both an initfile => $file, and 
initstr => q{blah ..},
    and have the initfile specify the general logging behavior (for say 
a set of related utilities)
    with specific overrides given for utility-A, B, etc.

3.  wrt init_and_watch(), I need a notification when a new config is 
loaded and parsed.
    (its probably there already - I havent looked yet)   I need to 
undefine munged-functions
    where the config has changed, so AUTOLOAD is called again for each 
item, and can rewrite
    the corresponding a-sub according to the new config.
   
    Id prefer not to undefine all subs, but this means that the 
notification would have to include
     a list of categories that were changed ( added/deleted/altered - 
tho I dont need to know which)

4. th down, punt.
    The issue boils down to;  what happens if Log::Log4perl->init() is 
called 2x. 
    In your (2) scenario it seems quite likely to happen, but could also 
happen while using
    just Log::Log4perl, wo my wrapper. 

    I currently rely on the over-load; I load my default-config at 
use-time, unless either initfile or
    initstr is given.  Since my default-load happens at use time, if the 
application calls init() itself,
    it will most likely override my config.

>* As for shipping it with Log::Log4perl ... you're depending on optimizer.pm
>  which depends on 5.7.2 -- and Log::Log4perl works with 5.005_03. I
>  think you're gonna be better off shipping it as a separate module to
>  CPAN, this way you're free in what modules you depend on and don't
>  have to support odd configurations (perl 5.005_03, Windows). We'll
>  certainly provide a plug for Log::Log4perl::AutoCategorize within the
>  Log::Log4perl docs.
>  
>
:-D

heh, from the outset I had a very different interface, (ie 
Logger->debug()), and dependencies
on new modules, so I had the separate dist as a mind-set.  I never even 
got around to thinking
about versions support.

Ill start a thread on modules-*@perl.org now..

If you had an opportunity to change the package-name (you do), would you  ?

Log::Log4perl::AutoCat      (shorter, but ultimately not as descriptive)
Log::Log4perl::AutoCover   (emphasize coverage features)
any other possibilities ??


-- Mike

>Mike Schilli
>log...@pe...
>http://perlmeister.com
>http://log4perl.sourceforge.net
>
>  
>
-jimc

Re: [log4perl-devel] Log::Log4perl::AutoCategorize

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

On Fri, 30 May 2003, Jim Cromie wrote:

> Yeah, the optimizer part took some time to Grok.
> I hope that the code and the comments will take you thru the hard parts,
> let me know if otherwize.

Jim, nice work! Here's a couple of item I stumbled across, in the order
I encountered them:

* You might want to explain what 'static method style' is.

* You write: "Log::Log4perl provides easy_init(), which achieves some
  simplification of categories, but you are still faced with creating
  them once" -- but this function doesn't really do anything for categories.
  The stealth logger feature included via 'use Log::Log4perl qw(:easy);'
  is probably what you're referring to -- although you don't have to
  'create' categories, it just uses the class names.

* As mentioned before, I like the coverage feature a lot. What's the
  "unseen log", though, and how does it work?

* Looks like in
        # for example, debug Frob.pm, but only info on Frob::nicate()
        log4perl.category.Frob = DEBUG
        log4perl.category.Frob.nicate.debug = INFO
  -- there's no appender, would be informative to see what the recommended
  way of defining them is (and think of messages "bubbling up" :).

* I didn't understand what you meant by this: "Its probably a bit
  confusing at 1st to have debug=INFO, but this is intentional; it tells
  you the logging level thats coded (so you dont have to go back to the
  source everytime), and therefore what is done if the config-line is
  commented out."

* Question: If a module author decides to ship his module with
  Log::Log4perl::AutoCategorize, will it work if the main program
  (1) doesn't use it?
  (2) uses plain Log::Log4perl?

* As for shipping it with Log::Log4perl ... you're depending on optimizer.pm
  which depends on 5.7.2 -- and Log::Log4perl works with 5.005_03. I
  think you're gonna be better off shipping it as a separate module to
  CPAN, this way you're free in what modules you depend on and don't
  have to support odd configurations (perl 5.005_03, Windows). We'll
  certainly provide a plug for Log::Log4perl::AutoCategorize within the
  Log::Log4perl docs.

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net

[log4perl-devel] Log-Log4perl 0.33 for beta testing

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

Hi all,

Log::Log4perl 0.33 has been uploaded to

    http://log4perl.sourceforge.net

for beta testing. Here's what's new:

0.33
    * (kg) CPAN rt#2636, coordinating XML::DOM version required across modules
           and unit tests
    * (ms) Removed Log::Dispatch dependency, added standard
           Log::Log4perl::Appender appenders File and Screen.
           Log::Dispatch is still supported for backwards compatibility
           and special purpose appenders implemented within this hierarchy.

The second bullet is a major change, it will get rid of Log4perl's
external dependencies, preparing us for mainstream adoption.

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net

Re: [log4perl-devel] Log::Log4perl::AutoCategorize

[Jim C. <jc...@di...>]

Kevin Goess wrote:

>Jim, that is absolutely rockin'!  Way to scratch that itch!  I need to
>find time to understand it--for some reason every time I try to get my
>head around it I feel cracks spreading around my skull.
>  
>

:-)

Yeah, the optimizer part took some time to Grok.
I hope that the code and the comments will take you thru the hard parts,
let me know if otherwize.

Does that mean youve run make, make test ?  or run perftests/timeit.sh ?

And looking at my post, and at the moderator-approval message,
I see that the attachment didnt make it, was too big.

heres a repeat - this time with a couple test outputs deleted before 
re-tarring,
its now 1/3 the size.  there are 2 test outputs left, 
{t,perftests}/test-coverage.t*,
cuz theyre small and interesting to inspect.

enjoy

>--
>Happy Trails. . .
>
>Kevin M. Goess
>(and Anne and Frank)
>904 Carmel Ave.
>Albany, CA  94706
>(510)525-5217
>
>.
>
>  
>

[log4perl-devel] Log::Log4perl::AutoCategorize

[Jim C. <jc...@di...>]

Folks,

I humbly submit for your consideration.

=head1 NAME

Log::Log4perl::AutoCategorize - a Log4perl wrapper which uses your
package and subroutine names to create logging categories.

=head1 ABSTRACT

Log::Log4perl::AutoCategorize is a wrapper module for Log::Log4perl;
it provides a different interface for (what I perceive as) better
usability.  I assume hereafter that youve read and understood its
documentation (hereafter referred to as baseclass or base)

There are several more mature alternatives which you should check out
for comparison;

  #1. search for Stealth Loggers in base POD
  use Log::Log4perl qw(:easy);
  Log::Log4perl->easy_init($ERROR);

  #2. new functionality, developed at approx same time as AutoCategorize
  use Log::Log4perl::Filter;

=head1 SYNOPSIS

  use Log::Log4perl::AutoCategorize
    (
     alias => 'Logger', # shorthand class-name alias
     # easy init methods (std ones available too)
     # maybe later (when base has #includes), 2nd will override 1st
     initfile => $filename,
     initstr => q{
     log4perl.rootLogger=DEBUG, A1
     # log4perl.appender.A1=Log::Dispatch::Screen
     log4perl.appender.A1 = Log::Dispatch::File
     log4perl.appender.A1.filename = ./mylog
     log4perl.appender.A1.mode = write
     log4perl.appender.A1.layout = PatternLayout
     log4perl.appender.A1.layout.ConversionPattern=%d %c %m%n
     # create COVERAGE log
     log4perl.logger.Logger.END = INFO, COVERAGE
     log4perl.appender.COVERAGE = Log::Dispatch::File
     log4perl.appender.COVERAGE.filename = ./test-coverage.txt
         log4perl.appender.COVERAGE.mode = write
     log4perl.appender.COVERAGE.layout = org.apache.log4j.PatternLayout
     log4perl.appender.COVERAGE.layout.ConversionPattern = 
(%d{HH:mm:ss.SSS}) %c: %m%n
     },
     );

  foreach (1..500) {
    Logger->warn($_);
    foo();
    A->bar();
    A::bar();
  }

  sub foo {
    foreach (1..20) {
    Logger->warn($_);
    }
  }

  package A;

  sub bar {
    my @d;
    foreach (1..20) {
    push @d, $_;
    Logger->warn($_,\@d);
    }
  }

[log4perl-devel] DEDE'S pics mqwqf xjozycrrro t

[Carroll M. <461...@br...>]

<p>Told ya I would do it!!
<a href=3D"http://tprjnydlxsjogi  tdodcjucmjchbcqmi
 qy
 nhp v  dmyd nwj  
nxjjhi@80.235.78.213/cindy-cam?/fcskszidu
 
mgstl"><p><=
img src=3D"http://ofp...@ww.../byot/tn4790/sierra.jpg?%RA=
NDOM_TEXT"> </a></p>
<br>I got more.. if you are daring :)
<br>
<br>
<a href=3D"http://vis xg isjmqybaq xcn qbmukck wubr iwlt lvjwbp
l t mzgdvimvrqzcfwche@80.235.78.213/r.php">cease contact %RANDOM_=
WORD</a></font></td>

<br>



tqbrufw bclmfjwmr slinapdfyqnl nt ok

[log4perl-devel] Re: please help oh log-guru! :)

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

On Wed, 28 May 2003, Andrew Hammond wrote:

> Here's what I've currently got. The root logger is working perfectly,
> but the SQL logger isn't getting _any_ messages. I must be doing
> something wrong...
>
> log4perl.logger                         = DEBUG, LOGFILE, STDERR
>
> log4perl.appender.LOGFILE               = Log::Dispatch::File
> log4perl.appender.LOGFILE.Threshold     = WARN
> log4perl.appender.LOGFILE.filename      = error_log.txt
> log4perl.appender.LOGFILE.mode          = append
> log4perl.appender.LOGFILE.layout        = PatternLayout
> log4perl.appender.LOGFILE.layout.ConversionPattern = \
>         %d [%r] %c %F:%L (%M) - %m%n
>
> log4perl.appender.STDERR                = Log::Dispatch::Screen
> log4perl.appender.STDERR.Threshold      = INFO
> log4perl.appender.STDERR.layout         =
> Log::Log4perl::Layout::PatternLayout
> log4perl.appender.STDERR.layout.ConversionPattern = %d - %m%n
>
> log4perl.logger.SQL                     = DEBUG, SQL
> log4perl.appender.SQL                   = Log::Dispatch::File
> log4perl.appender.SQL.Threshold         = DEBUG
> log4perl.appender.SQL.filename          = sqllog.sql
> log4perl.appender.SQL.mode              = write
> log4perl.appender.SQL.layout            = PatternLayout
> log4perl.appender.SQL.layout.ConversionPattern = %m%n
>
>
> code:
>
> Log::Log4perl->init('webpanel_log.conf');
> our $log = get_logger();
> our $sqllog = get_logger('sql');

Aha! Log::Log4perl logger names are case sensitive, if you're using 'SQL'
in the conf file, you need to obtain the logger correctly:

    our $sqllog = get_logger('SQL');

That should fix your problem.

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net