log4perl-devel — Ongoing log4perl development

[log4perl-devel] Re: FAIL Log-Log4perl-0.28 sun4-solaris 2.8

[Mike S. <msc...@ao...>]

Looks like this is related, can you also please check the other warning 
with syslog shown below?
Since CPAN doesn't allow for updating the same version, we should 
probably just go ahead and prepare 0.29 right away. Want to roll in your 
patch into the tip? It's no biggie if we fix it real soon.

Longer term, I think we also need to run tests for the different cases 
of optional modules being present or absent.

-- Mike
Mike Schilli
log...@pe...

Jos...@ru... wrote:

>This distribution has been tested as part of the cpan-testers
>effort to test as many new uploads to CPAN as possible.  See
>http://testers.cpan.org/
>
>Please cc any replies to cpa...@pe... to keep other
>test volunteers informed and to prevent any duplicate effort.
>    
>--
>This is an error report generated automatically by CPANPLUS,
>version 0.042.
>
>Below is the error stack during 'make test':
>
>PERL_DL_NONLAZY=1 /usr/local/perl/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
>t/001Level...........ok
>t/002Logger..........ok
>t/003Layout..........ok
>t/004Config..........ok
>t/005Config-Perl.....ok
>t/006Config-Java.....ok
>t/007LogPrio.........ok
>t/008ConfCat.........ok
>t/009Deuce...........ok
>t/010JConsole........ok
>t/011JFile...........ok
>t/012Deeper..........ok
>t/013Bench...........ok
>t/014ConfErrs........ok
>t/015fltmsg..........ok
>t/016Export..........ok
>t/017Watch...........ok
>t/018Init............ok
>t/019Warn............ok
>t/020Easy............ok
>t/021AppThres........ok
>t/022Wrap............ok
>t/023Date............ok
>t/024WarnDieCarp.....ok
>t/025CustLevels......ok
>t/026FileApp.........ok
>t/027Watch2..........ok
>t/028Additivity......ok
>t/029SysWide.........ok
>t/030LDLevel.........ok
>t/031NDC.............ok
>t/032JRollFile.......ok
>t/033UsrCspec........ok
>t/034DBI.............ok
>t/035JDBCAppender....ok
>t/036JSyslog.........unix passed to setlogsock, but path not available at /usr/local/perl/lib/site_perl/5.8.0/Log/Dispatch/Syslog.pm line 66
>ok
>t/037JWin32Event.....Log::Dispatch::Win32EventLog not installed, skipping..
>ok
>t/038XML-DOM1........# Test 1 got: '$VAR1 = {
>          'appender' => {
>                          'BUF0' => {
>                                    'layout' => {
>                                                  'value' => 'Log::Log4perl::Layout::SimpleLayout'
>                                                },
>                                    'value' => 'Log::Log4perl::Appender::TestBuffer',
>                                    'Threshold' => {
>                                                   'value' => 'ERROR'
>                                                 }
>                                  },
>                          'A1' => {
>                                  'layout' => {
>                                                'value' => 'Log::Log4perl::Layout::SimpleLayout'
>                                              },
>                                  'value' => 'Log::Log4perl::Appender::TestBuffer'
>                                },
>                          'A2' => {
>                                  'layout' => {
>                                                'value' => 'Log::Log4perl::Layout::SimpleLayout'
>                                              },
>                                  'value' => 'Log::Log4perl::Appender::TestBuffer'
>                                },
>                          'FileAppndr1' => {
>                                           'Append' => {
>                                                       'value' => 'false'
>                                                     },
>                                           'layout' => {
>                                                         'ConversionPattern' => {
>                                                                                'value' => '%d %4r [%t] %-5p %c %t - %m%n'
>                                                                              },
>                                                         'value' => 'Log::Log4perl::Layout::PatternLayout'
>                                                       },
>                                           'value' => 'org.apache.log4j.FileAppender',
>                                           'File' => {
>                                                     'value' => 't/tmp/DOMtest'
>                                                   }
>                                         }
>                        },
>          'additivity' => {
>                            'a' => {
>                                   'b' => {
>                                          'c' => {
>                                                 'd' => {
>                                                        'value' => '0'
>                                                      }
>                                               }
>                                        }
>                                 }
>                          },
>          'threshold' => {
>                           'value' => 'DEBUG'
>                         },
>          'category' => {
>                          'a' => {
>                                 'b' => {
>                                        'c' => {
>                                               'd' => {
>                                                      'value' => 'WARN, A1'
>                                                    }
>                                             },
>                                        'value' => 'INFO, A1'
>                                      }
>                               },
>                          'value' => 'WARN, FileAppndr1',
>                          'xa' => {
>                                  'b' => {
>                                         'c' => {
>                                                'd' => {
>                                                       'value' => 'INFO, A2'
>                                                     }
>                                              },
>                                         'value' => 'WARN, A2'
>                                       }
>                                },
>                          'animal' => {
>                                      'value' => 'INFO, FileAppndr1',
>                                      'dog' => {
>                                               'value' => 'INFO, FileAppndr1,A2'
>                                             }
>                                    }
>                        }
>        };
>' (t/038XML-DOM1.t at line 135)
>#   Expected: '$VAR1 = {
>          'appender' => {
>                          'BUF0' => {
>                                      'layout' => {
>                                                    'value' => 'Log::Log4perl::Layout::SimpleLayout'
>                                                  },
>                                      'value' => 'Log::Log4perl::Appender::TestBuffer',
>                                      'Threshold' => {
>                                                       'value' => 'ERROR'
>                                                     }
>                                    },
>                          'A1' => {
>                                    'layout' => {
>                                                  'value' => 'Log::Log4perl::Layout::SimpleLayout'
>                                                },
>                                    'value' => 'Log::Log4perl::Appender::TestBuffer'
>                                  },
>                          'A2' => {
>                                    'layout' => {
>                                                  'value' => 'Log::Log4perl::Layout::SimpleLayout'
>                                                },
>                                    'value' => 'Log::Log4perl::Appender::TestBuffer'
>                                  },
>                          'FileAppndr1' => {
>                                             'Append' => {
>                                                           'value' => 'false'
>                                                         },
>                                             'layout' => {
>                                                           'ConversionPattern' => {
>                                                                                    'value' => '%d %4r [%t] %-5p %c %t - %m%n'
>                                                                                  },
>                                                           'value' => 'Log::Log4perl::Layout::PatternLayout'
>                                                         },
>                                             'value' => 'org.apache.log4j.FileAppender',
>                                             'File' => {
>                                                         'value' => 't/tmp/DOMtest'
>                                                       }
>                                           }
>                        },
>          'additivity' => {
>                            'a' => {
>                                     'b' => {
>                                              'c' => {
>                                                       'd' => {
>                                                                'value' => '0'
>                                                              }
>                                                     }
>                                            }
>                                   }
>                          },
>          'threshold' => {
>                           'value' => 'DEBUG'
>                         },
>          'category' => {
>                          'a' => {
>                                   'b' => {
>                                            'c' => {
>                                                     'd' => {
>                                                              'value' => 'WARN, A1'
>                                                            }
>                                                   },
>                                            'value' => 'INFO, A1'
>                                          }
>                                 },
>                          'value' => 'WARN, FileAppndr1',
>                          'xa' => {
>                                    'b' => {
>                                             'c' => {
>                                                      'd' => {
>                                                               'value' => 'INFO, A2'
>                                                             }
>                                                    },
>                                             'value' => 'WARN, A2'
>                                           }
>                                  },
>                          'animal' => {
>                                        'dog' => {
>                                                   'value' => 'INFO, FileAppndr1,A2'
>                                                 },
>                                        'value' => 'INFO, FileAppndr1'
>                                      }
>                        }
>        };
>'
>FAILED test 1
>    Failed 1/1 tests, 0.00% okay
>Failed Test     Stat Wstat Total Fail  Failed  List of Failed
>-------------------------------------------------------------------------------
>t/038XML-DOM1.t                1    1 100.00%  1
>#  t/038XML-DOM1.t line 135 is: ok(Dumper($xmldata),Dumper($propsdata));
>Failed 1/38 test scripts, 97.37% okay. 1/368 subtests failed, 99.73% okay.
>make: *** [test_dynamic] Error 29
>
>
>Additional comments:
>
>--
>
>Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
>  Platform:
>    osname=solaris, osvers=2.8, archname=sun4-solaris
>    uname='sunos sunu991 5.8 generic_108528-14 sun4u sparc '
>    config_args='-de'
>    hint=recommended, useposix=true, d_sigaction=define
>    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
>    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
>    use64bitint=undef use64bitall=undef uselongdouble=undef
>    usemymalloc=n, bincompat5005=undef
>  Compiler:
>    cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
>    optimize='-O',
>    cppflags='-fno-strict-aliasing -I/usr/local/include'
>    ccversion='', gccversion='3.0', gccosandvers='solaris2.8'
>    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
>    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
>    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
>    alignbytes=8, prototype=define
>  Linker and Libraries:
>    ld='gcc', ldflags =' -L/usr/local/lib '
>    libpth=/usr/local/lib /usr/lib /usr/ccs/lib
>    libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc
>    perllibs=-lsocket -lnsl -ldl -lm -lc
>    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
>    gnulibc_version=''
>  Dynamic Linking:
>    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
>    cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'
>  
>

Re: [log4perl-devel] Log::Log4perl 0.28 out there!

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

Aaargh.  I was *sure* I had checked this, I even got out of bed late 
last night to be sure, but apparently I checked in the wrong place. 
There's a line of debugging output in an obscure place in 
PropertyConfigurator.pm, and there's a bunch of debugging crap in 
DOMConfigurator.  Aaaargh.

It also turns out Data::Dumper isn't reliable the way I'm using it for 
the XML-DOM tests.

I only noticed all this after I'd checked in a bunch of newer stuff this 
morning, so I branched CVS as "rel-0-28" and fixed it.  Attached is the 
diff if you want to see the changes.  I think we should do another 
release based on that branch (do cvs update -r rel-0-28 to change your 
working copy to the branch).

Mea culpa, mea culpa, mea maxima culpa.


msc...@ao... wrote:
> Hi all,
> 
> the Log::Log4perl core development team proudly announces: 
> 
>     Log::Log4perl 0.28 is out there!
> 
> There's a bunch of exciting new features:
> 
> * A new DBI database appender
> * Perl hooks in the Log4perl configuration file
> * Message output filters ({filter => foo, value => $val})
> 
> ... and a truckload of plumbing and maintenance stuff:
> 
> Changes:
> 0.28 (01/28/2003)
>     * (ms) '#' in the conf file are now
>       interpreted as comment starters only if
>       they're at the start of a line with optional
>       whitespace. The previous setting (comments
>       starting anywhere) had problems with code
>       containing '#''s, like in layout.cref = sub
>       { $#_ = 1 }
>     * (ms) warp_message accepts code refs or
>       function names
>     * (kg) Split config bits into 
>       PropertyConfigurator and implemented
>       DOMConfigurator for XML configs.
>     * (kg) Adding appender.warp_message parameter 
>       as a help to DBI appender
>     * (kg) Added NoopLayout to help DBI appender
>     * (ms) Added message output filters:
>       log({filter => \&filter, value => $value})
>     * (kg) t/024WarnDieCarp was assuming / as 
>       directory separator, failed on Win32
>     * (kg) implemented JavaMaps for 
>       NTEventLogAppender, SyslogAppender
>     * (kg) found and addressed circular ref 
>       problem in Logger->reset
>     * (kg) moved TestBuffer under Appender/ 
>       directory along with DBI 
>     * (kg) fixed docs, Pattern layout, %f not 
>       supported, s/b %F
>     * (kg) added Log::Log4perl::Appender::DBI to
>       implement JDBCAppender
>     * (ms) Every value in the config file can now
>       be a perl function, dynamically replaced by
>       its return value at configuration parse time
>     * (ms) NDC now prints entire stack, not just
>            top element (as mandated by Log4j)
>     * (ms) Allow trailing spaces after a
>       line-breaking '\' in the config file to be
>       fault-tolerant on cut-and-pasted code
> 
> As we speak, Log::Log4perl 0.28 is on its way to CPAN. Also, it's available from the log4perl.sourceforge.net homepage.
> 
> Let us know how you like it!
> 


-- 
Happy Trails . . .

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

[log4perl-devel] Log::Log4perl Recipe of the Week (#14)

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

Welcome to the Log::Log4perl recipe of the week. Today:

============================================================
Log::Log4perl Recipe of the Week (#14):

How can I drill down on references before logging them?
============================================================

If you've got a reference to a nested structure or object,
then you probably don't want to log it as "HASH(0x81141d4)"
but rather dump it as something like

    $VAR1 = {
              'a' => 'b',
              'd' => 'e'
            };

via a module like Data::Dumper. While it's syntactically
correct to say

    $logger->debug(Data::Dumper::Dumper($ref));

this call imposes a huge performance penalty on your
application if the message is suppressed by Log::Log4perl,
because Data::Dumper will perform its expensive operations
in any case, because it doesn't know that its output will be
thrown away immediately.

As of Log::Log4perl 0.28, there's a better way: Use the
message output filter format as in

    $logger->debug( {filter => \&Data::Dumper::Dumper,
                     value  => $ref} );

and Log::Log4perl won't call the filter function unless the
message really gets written out to an appender. Just make
sure to pass the whole slew as a reference to a hash
specifying a filter function (as a sub reference) under the
key "filter" and the value to be passed to the filter
function in "value"). When it comes to logging,
Log::Log4perl will call the filter function, pass the
"value" as an argument and log the return value. Saves you
serious cycles.


Have fun! Until next week.

-- Mike

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

[log4perl-devel] Log::Log4perl 0.28 out there!

[<msc...@ao...>]

Hi all,

the Log::Log4perl core development team proudly announces: 

    Log::Log4perl 0.28 is out there!

There's a bunch of exciting new features:

* A new DBI database appender
* Perl hooks in the Log4perl configuration file
* Message output filters ({filter => foo, value => $val})

... and a truckload of plumbing and maintenance stuff:

Changes:
0.28 (01/28/2003)
    * (ms) '#' in the conf file are now
      interpreted as comment starters only if
      they're at the start of a line with optional
      whitespace. The previous setting (comments
      starting anywhere) had problems with code
      containing '#''s, like in layout.cref = sub
      { $#_ = 1 }
    * (ms) warp_message accepts code refs or
      function names
    * (kg) Split config bits into 
      PropertyConfigurator and implemented
      DOMConfigurator for XML configs.
    * (kg) Adding appender.warp_message parameter 
      as a help to DBI appender
    * (kg) Added NoopLayout to help DBI appender
    * (ms) Added message output filters:
      log({filter => \&filter, value => $value})
    * (kg) t/024WarnDieCarp was assuming / as 
      directory separator, failed on Win32
    * (kg) implemented JavaMaps for 
      NTEventLogAppender, SyslogAppender
    * (kg) found and addressed circular ref 
      problem in Logger->reset
    * (kg) moved TestBuffer under Appender/ 
      directory along with DBI 
    * (kg) fixed docs, Pattern layout, %f not 
      supported, s/b %F
    * (kg) added Log::Log4perl::Appender::DBI to
      implement JDBCAppender
    * (ms) Every value in the config file can now
      be a perl function, dynamically replaced by
      its return value at configuration parse time
    * (ms) NDC now prints entire stack, not just
           top element (as mandated by Log4j)
    * (ms) Allow trailing spaces after a
      line-breaking '\' in the config file to be
      fault-tolerant on cut-and-pasted code

As we speak, Log::Log4perl 0.28 is on its way to CPAN. Also, it's available from the log4perl.sourceforge.net homepage.

Let us know how you like it!

-- 
-- Mike

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

[log4perl-devel] Doc Update

[<wi...@da...>]

Found a possible doc update, in the version of the docs I have (2002-12-02) the following list appears:

     Here's the list of appender modules currently available via
     "Log::Dispatch":

            Log::Dispatch::ApacheLog
            Log::Dispatch::DBI (by Tatsuhiko Miyagawa)
            Log::Dispatch::Email,
            Log::Dispatch::Email::MailSend,
            Log::Dispatch::Email::MailSendmail,
            Log::Dispatch::Email::MIMELite
            Log::Dispatch::File
            Log::Dispatch::RollingFile (by Mark Pfeiffer)
            Log::Dispatch::Handle
            Log::Dispatch::Screen
            Log::Dispatch::Syslog
            Log::Dispatch::Tk (by Dominique Dumont)

As best I can tell Log::Dispatch::RollingFile has been replaced by Log::Dispatch::FileRotate (granted there appear to be other new ones too)??

http://danconia.org

Re: [log4perl-devel] Proc::Daemon::Init

[Wiggins d'A. <wi...@da...>]

Msc...@ao... wrote:
> In a message dated 1/28/03 1:51:34 PM Pacific Standard Time, 
> wi...@da... writes:
> 
>> While developing an application I am hoping to use the 
>> Proc::Daemon::Init module along with Log4perl, but it seems whenever I 
>> use Proc::Daemon's Init function the log4perl logger does not work, I 
>> am assuming because I am calling 'init' before Proc::Daemon has done 
>> its thing, and in particular because of #6 below.  
> 
> 
> 
> Correct. If you close Log4perl's file descriptors, it won't be able to 
> write to the log files which it opened at Log4perl init time (which I 
> assume you've called *before* closing the file descriptors). You need to 
> call Log::Log4perl->init(...) *after* closing open file descriptors.
> 

Thanks. After commenting out a few various chunks of code I figured that 
is what the problem was.  I worked it out to call Log4perl's init after 
the Proc::Daemon Init and it appears to work correctly.

> Will there be a problem with not having a controlling terminal
> 
>> (can't see a reason for it, except in the case of trying to use a 
>> Log::Dispatch::Screen appender, or the like).
> 
> That's fine, in fact, that's a pretty standard setup for Log::Log4perl.
> 

Sure seems like it would have to be, good to have confirmation though.

http://danconia.org

Re: [log4perl-devel] place severity in email subject?

[Mark B. <md...@ji...>]

[ widened to include Dave Rolsky; Dave feel free to join/ignore as you
  see fit ]

>> On Tue, 28 Jan 2003 12:47:36 EST,
>> Mschilli1 (M) wrote:

M> In a message dated 1/28/03 7:52:16 AM Pacific Standard Time,
M> md...@ji... writes:

M>  Is there a relatively simple way to insert the message severity
M>  into the Log::Dispatch::Email appender?
     
M>    For example, we want $log->debug("foo") to send an email with
M>    the subject line "$0: [DEBUG] log email", $log->warn("bar") to
M>    have the subject "$0: [WARN] log email", etc.
     
M> That's all up to the appender to define. Unfortunately, the
M> currently available ones (Log::Dispatch::Email::MailSend etc.) all
M> define the "subject" line at appender initialization time but won't
M> allow you to modify it dynamically with every log request.  What
M> you could do (and that's actually easier than it sounds like at
M> first) is write your own mail appender -- basically just one method
M> that sends out the mail, using something like Mail::Send, that's
M> it.

M> Does that sound reasonable? Any questions let me know.

Yes, aside from one design issue: in the case of buffered objects,
what should the subject line severity be?

In Log::Dispatch::Email there are the methods,

  sub log_message
  {
      my $self = shift;
      my %p = @_;
  
      if ($self->{buffered})
      {
   	  push @{ $self->{buffer} }, $p{message};
      }
      else
      {
	  $self->send_email(@_);
      }
  }

and 

  sub flush
  {
      my $self = shift;
  
      if ($self->{buffered} && @{ $self->{buffer} })
      {
	  my $message = join '', @{ $self->{buffer} };

  	  $self->send_email( message => $message );
          $self->{buffer} = [];
      }
  }

I was thinking I could just make the buffer an array of arrays, e.g.,

 push @{ $self->{buffer} }, [$p{log4p_level},$p{message}];

and then fix up flush() to match. But then what would one send to send_email()?

  $self->send_email( subject => undef, message => $message );

where the undefined subject above would need some indicator of the
maximum level of the log message(s) contained in the body of the
message.

I'm beginning to see why Dave Rolsky may have left this
unimplemented.

Ideas?

--
 -mb-

Re: [log4perl-devel] Proc::Daemon::Init

[<Msc...@ao...>]

In a message dated 1/28/03 1:51:34 PM Pacific Standard Time, 
wi...@da... writes:

> While developing an application I am hoping to use the Proc::Daemon::Init 
> module along with Log4perl, but it seems whenever I use Proc::Daemon's Init 
> function the log4perl logger does not work, I am assuming because I am 
> calling 'init' before Proc::Daemon has done its thing, and in particular 
> because of #6 below.  

Correct. If you close Log4perl's file descriptors, it won't be able to write 
to the log files which it opened at Log4perl init time (which I assume you've 
called *before* closing the file descriptors). You need to call 
Log::Log4perl->init(...) *after* closing open file descriptors.

Will there be a problem with not having a controlling terminal 
> (can't see a reason for it, except in the case of trying to use a 
> Log::Dispatch::Screen appender, or the like).
> 

That's fine, in fact, that's a pretty standard setup for Log::Log4perl.

-- Mike
Mike Schilli
log...@pe...

[log4perl-devel] Proc::Daemon::Init

[<wi...@da...>]

Hey all, 

While developing an application I am hoping to use the Proc::Daemon::Init module along with Log4perl, but it seems whenever I use Proc::Daemon's Init function the log4perl logger does not work, I am assuming because I am calling 'init' before Proc::Daemon has done its thing, and in particular because of #6 below.  Is my hunch correct?  Will there be a problem with not having a controlling terminal (can't see a reason for it, except in the case of trying to use a Log::Dispatch::Screen appender, or the like).

>From the Proc::Daemon docs:

"The Proc::Daemon::Init function does the following:

   1. Forks a child and exits the parent process.
   2. Becomes a session leader (which detaches the program from the controlling terminal).
   3. Forks another child process and exits first child. This prevents the potential of acquiring a controlling terminal.
   4. Changes the current working directory to "/".
   5. Clears the file creation mask.
   6. Closes all open file descriptors. "

Thanks for your insights or suggestions on a better way to handle  any of this,

http://danconia.org

Re: [log4perl-devel] place severity in email subject?

[<Msc...@ao...>]

In a message dated 1/28/03 7:52:16 AM Pacific Standard Time, 
md...@ji... writes:

> Is there a relatively simple way to insert the message severity into
> the Log::Dispatch::Email appender?
> 
> For example, we want $log->debug("foo") to send an email with the
> subject line "$0: [DEBUG] log email", $log->warn("bar") to have the
> subject "$0: [WARN] log email", etc. 
> 

That's all up to the appender to define. Unfortunately, the currently 
available ones (Log::Dispatch::Email::MailSend etc.) all define the "subject" 
line at appender initialization time but won't allow you to modify it 
dynamically with every log request.

What you could do (and that's actually easier than it sounds like at first) 
is write your own mail appender -- basically just one method that sends out 
the mail, using something like Mail::Send, that's it.

Check out 

    <A HREF="http://log4perl.sourceforge.net/releases/Log-Log4perl/docs/html/Log/Log4perl/FAQ.html#how_can_i_write_my_own_appender">
http://log4perl.sourceforge.net/releases/Log-Log4perl/docs/html/Log/Log4perl/F

AQ.html#how_can_i_write_my_own_appender</A>

on how to write the appender and keep in mind to use a package containing a 
":" like "Log::Dispatch::MyMailAppender" and that the parameter hash coming 
in to log_message() carries an item "log4p_level" which is set to "ERROR" or 
"WARN" or whatever the level of the current message is. Does that sound 
reasonable? Any questions let me know.

-- Mike
Mike Schilli
log...@pe...

Re: [log4perl-devel] place severity in email subject?

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

Yes, but you have to use the current (soon-to-be-released) version of 
log4perl from our cvs.  The problem is making the severity information 
available to the your email subclass at the time it's doing the logging. 
  I was having the same problem implementing the DBI appender, so we 
added the feature:

If your derived email class looks like this

package Log::Dispatch::Email::MySender;

use Log::Dispatch::Email;
use base qw( Log::Dispatch::Email );


sub log {
     my $self = shift;
     my %args = @_;

     #save the level so we can get at it later
     $self->{log4p_level} = $args{log4p_level};

     #continue processing as before
     $self->SUPER::log(@_);
     return;
}

sub send_email {
     my $self = shift;
     my %p = @_;

     my $prog = $0;
     $prog =~ s/"//g; #security!!
     print qq{sending mail: /bin/mail -s "$prog [$self->{log4p_level}] 
log email" @{$self->{to}}\n};

}



Mark Borges wrote:
> Is there a relatively simple way to insert the message severity into
> the Log::Dispatch::Email appender?
> 
> For example, we want $log->debug("foo") to send an email with the
> subject line "$0: [DEBUG] log email", $log->warn("bar") to have the
> subject "$0: [WARN] log email", etc. 
> 
> Currently, the recipient of the email is forced to read the body of
> the message to learn its severity. 
> 
> Thanks.
> 
> P.S. I know, suppressing the email of DEBUG and INFO messages via
>      threshold may be more desirable, but that is an ongoing debate
>      in our group.
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel


-- 
Happy Trails . . .

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

[log4perl-devel] place severity in email subject?

[Mark B. <md...@ji...>]

Is there a relatively simple way to insert the message severity into
the Log::Dispatch::Email appender?

For example, we want $log->debug("foo") to send an email with the
subject line "$0: [DEBUG] log email", $log->warn("bar") to have the
subject "$0: [WARN] log email", etc. 

Currently, the recipient of the email is forced to read the body of
the message to learn its severity. 

Thanks.

P.S. I know, suppressing the email of DEBUG and INFO messages via
     threshold may be more desirable, but that is an ongoing debate
     in our group.

Re: [log4perl-devel] Docs/Test cases for message_filter

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

Msc...@ao... wrote:

> In a message dated 1/24/03 5:44:19 PM W. Europe Standard Time, 
> jc...@di... writes:
>
>> I dont yet grok this filtering, ( I havent tried yet - so thats
>> understandable),
>> but its potentially related to the AutoCategorization feature I sent
>> earlier.
>
>
>
> I don't see the connection -- how are they related? Also, regarding 
> performance, please note that this filter function usually isn't 
> called at all (see documentation in Log::Log4perl::Appender).

Ill admit, the connection is tenous, but..
I took filtering as more flexible suppression of selected messages, 
which was one of my goals in wrapping Log4perl.

>
>>
>> If you recall, my patch  wrapped Log4perl with another class.
>> that class handled all logging requests via AUTOLOAD;
>
>
>
>
> Yeah, I recall, however I didn't quite follow your explanation of how 
> to make the severe runtime penalty go away via optimizer.pm. However, 
> I'm still interested, so if you've got some working code I can play 
> with, I'll be happy to take a look. Also, please note that log/nolog 
> decisions might very well change during runtime (config_and_watch for 
> example).


I would use optimizer.pm to change
    $logger->debug (@args)
to
    $logger->debug_uniq_100 (@args)

everywhere it occurrs (with different unique number)

thus when AUTOLOAD is called ( its a virtual function), it creates the 
method with the unique name.
thus all other invokes get their own copy of the method (suitably 
customized to eliminate recurrent work).
So AUTOLOAD is only called once per invoker, thereafter much more direct.

code (which produced earlier output) is attached.
Note that it has NO LOG4PERL functionality, which is why I didnt send it b4,
I send it now so you can run it.  Hopefully the POD will explain it more 
fully than above.

btw - optimizer.pm probably requires 5.8, which may be another problem 
for use in Log::Log4perl

config_and_watch is cool - I shoulda seen it at the top of the POD (and 
known it was useful enough to be there).
Its not a show-stopper : by caching the newly minted methods , I can 
clear them out of the Symbol Table
when a refresh is needed.  Thereafter, the method wont exist, and 
AUTOLOAD will remake it.

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

[log4perl-devel] Re: actual bug in new Logger.pm

[<msc...@ao...>]

In a message dated 1/24/2003 1:14:34 PM Eastern Standard Time, Kevin Goess <ke...@go...> writes:

>\$message   = [map { ref \$_ eq "HASH"
>        && exists \$_->{filter}
>        && ref \$_->{filter} eq "CODE" ?

You had it right here but checked it in differently :) -- so it failed test #49 in 002Logger.t. Here's the fix, I've checked it in:

diff -a -u -r1.44 Logger.pm
--- lib/Log/Log4perl/Logger.pm  24 Jan 2003 20:09:55 -0000      1.44
+++ lib/Log/Log4perl/Logger.pm  25 Jan 2003 16:35:55 -0000
@@ -211,7 +211,9 @@
       #     => coderef()
       #
 
-      \$message   = [map { ref \$_ eq "HASH" && exists \$_->{filter} && \$_->{filter} eq 'CODE' ?
+      \$message   = [map { ref \$_ eq "HASH" && 
+                           exists \$_->{filter} && 
+                           ref \$_->{filter} eq 'CODE' ?
                                \$_->{filter}->(\$_->{value}) :
                            ref \$_ eq "CODE" ?
                                \$_->() : \$_ 

-- 
-- Mike

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

Re: [log4perl-devel] actual bug in new Logger.pm

[<Msc...@ao...>]

In a message dated 1/24/03 10:16:47 AM Pacific Standard Time, ke...@go... 
writes:

> Mike, I found a problem with this guy in Logger.pm
> 
> \$message   = [map { ref \$_ eq "HASH" ?
> 

Yup, think I brought that up a while ago (misspelling "filter" like 
"feelter", remember :) but it fell through the cracks somehow ... your fix 
looks good!

-- Mike
log...@pe...

[log4perl-devel] actual bug in new Logger.pm

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

Mike, I found a problem with this guy in Logger.pm

\$message   = [map { ref \$_ eq "HASH" ?
                          \$_->{filter}->(\$_->{value}) :
                      ref \$_ eq "CODE" ?
                          \$_->() : \$_
                     } \@_];

If an innocent hashref unexpectely gets into the logging statement

$logger->fatal('fatal message',1234,'foo',{aaa => 'aaa'});

then it tries to call the method on the innocent hashref and dies

Can't use string ("") as a subroutine ref while "strict refs" in use at 
(eval 118) line 17.

So instead we need to do something like this ugliness (maybe it's time 
to unroll the map into a loop)

\$message   = [map { ref \$_ eq "HASH"
		&& exists \$_->{filter}
		&& ref \$_->{filter} eq "CODE" ?
                          \$_->{filter}->(\$_->{value}) :
                      ref \$_ eq "CODE" ?
                          \$_->() : \$_
                     } \@_];


-- 
Happy Trails . . .

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

Re: [log4perl-devel] Docs/Test cases for message_filter

[<Msc...@ao...>]

In a message dated 1/24/03 5:44:19 PM W. Europe Standard Time, 
jc...@di... writes:

> I dont yet grok this filtering, ( I havent tried yet - so thats 
> understandable),
> but its potentially related to the AutoCategorization feature I sent 
> earlier.

I don't see the connection -- how are they related? Also, regarding 
performance, please note that this filter function usually isn't called at 
all (see documentation in Log::Log4perl::Appender).

> 
> If you recall, my patch  wrapped Log4perl with another class.
> that class handled all logging requests via AUTOLOAD;


Yeah, I recall, however I didn't quite follow your explanation of how to make 
the severe runtime penalty go away via optimizer.pm. However, I'm still 
interested, so if you've got some working code I can play with, I'll be happy 
to take a look. Also, please note that log/nolog decisions might very well 
change during runtime (config_and_watch for example).

--- Mike

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

Re: [log4perl-devel] Docs/Test cases for message_filter

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

msc...@ao... wrote:

>Hey Kevin,
>
>just finished a couple of changes:
>

I dont yet grok this filtering, ( I havent tried yet - so thats 
understandable),
but its potentially related to the AutoCategorization feature I sent 
earlier.

If you recall, my patch  wrapped Log4perl with another class.
that class handled all logging requests via AUTOLOAD;

     $logCat = $AUTOLOAD . glom(caller())
    then tested that $logCat for writability

    IIRC:
     if ( $logger->is_$logCat()) { # ok log it.


All prohibitively expensive...


enter AUTOMUNGE - (my name for it)

Ive now succeeded (partly) in using   optimizer.pm   from to alter the 
optree
where AUTOLOAD is called,

with this MUNGE in place,  every invocation gets a unique function-name
to call, so fn_001 and fn_002 can be customized.  The customization could
be able to consider *ALL* the log/dont-log criteria, and produce a yes/no
decision.  All no's could be reduced to a no-op.

All of above requires that log/no-log decisions dont have to change during
runtime, a reasonable constraint I hope.

Number of custom-funcs is linear with size of Log-config, not number
of places in client-code where a Logging call is made.  This is cuz of
scoping rules - the log-conf may choose not to override any configs that
apply more broadly - and AUTOLOAD can detect that shared config and
use its custom loggers - not building new subs.



with AUTOCATEGORIZE in place,   you have  detailed control of what gets
written ( ie log filtering )



heres some output from my experiment:


# optimizer phase - examines chains of ops which make a function call
# rejects some, works on others.
# more optree-fu needed.

junkop-chain:  pushmark const null
junkop-chain:  pushmark const padsv
junkop-chain:  pushmark const null
junkop-chain:  pushmark const padsv
junkop-chain:  pushmark const null
junkop-chain:  pushmark const null

# by visual inspection of perl -MO=Concise a2.pl
# I found that pushmark, const+, method_named is
# the/an opcode pattern for AUTOLOAD invoke

matched op-chain:  pushmark const method_named
package: A
munged-method-name: my_debug_001

# created &A::my_debug_001()

matched op-chain:  pushmark const method_named
package: A
munged-method-name: my_info_002
matched op-chain:  pushmark const method_named
package: A
munged-method-name: my_info_003
matched op-chain:  pushmark const method_named
package: A
munged-method-name: something_004
matched op-chain:  pushmark const method_named
package: A
munged-method-name: other_005
matched op-chain:  pushmark const const method_named
package: A
munged-method-name: other_006
matched op-chain:  pushmark const const const method_named
package: A
munged-method-name: ary3_007
junkop-chain:  pushmark const const const anonlist null
junkop-chain:  pushmark const anonlist null
junkop-chain:  pushmark const const const anonhash null
junkop-chain:  pushmark const anonhash null
junkop-chain:  pushmark const entersub
junkop-chain:  pushmark const gv
junkop-chain:  pushmark const nextstate
junkop-chain:  pushmark const nextstate
junkop-chain:  pushmark const null
junkop-chain:  pushmark const nextstate

1:  
# first run - AUTOLOAD is creating pre-munged functions here,
# cuz the name is already customized in the optree.

creating <my_debug_001> my_debug_001_main_a2pl_19
 calling <my_debug_001> my_debug_001_main_a2pl_19 (aval)
creating <my_info_002> my_info_002_main_a2pl_20
 calling <my_info_002> my_info_002_main_a2pl_20 (1)
creating <my_info_003> my_info_003_main_a2pl_21
 calling <my_info_003> my_info_003_main_a2pl_21 (2)
creating <something_004> something_004_main_a2pl_22
 calling <something_004> something_004_main_a2pl_22 (anything)
creating <other_005> other_005_main_a2pl_23
 calling <other_005> other_005_main_a2pl_23 (1thing)
creating <other_006> other_006_main_a2pl_25
 calling <other_006> other_006_main_a2pl_25 (1 2)
creating <ary3_007> ary3_007_main_a2pl_26
 calling <ary3_007> ary3_007_main_a2pl_26 (1 2 3)
creating <ary1> ary1_main_a2pl_27
 calling <ary1> ary1_main_a2pl_27 (ARRAY(0x8130c24))
 calling <ary1> ary1_main_a2pl_27 (HASH(0x8130c24))
creating <missed_none_args> missed_none_args_main_a2pl_31
 calling <missed_none_args> missed_none_args_main_a2pl_31 ()
creating <classmeth> classmeth_main_a2pl_32
 calling <classmeth> classmeth_main_a2pl_32 ()
creating <classmeth2> classmeth2_main_a2pl_33
 calling <classmeth2> classmeth2_main_a2pl_33 (2)
2:
 calling <my_debug_001> my_debug_001_main_a2pl_19 (aval)
 calling <my_info_002> my_info_002_main_a2pl_20 (1)
 calling <my_info_003> my_info_003_main_a2pl_21 (2)
 calling <something_004> something_004_main_a2pl_22 (anything)
 calling <other_005> other_005_main_a2pl_23 (1thing)
 calling <other_006> other_006_main_a2pl_25 (1 2)
 calling <ary3_007> ary3_007_main_a2pl_26 (1 2 3)
 calling <ary1> ary1_main_a2pl_27 (ARRAY(0x8241360))
 calling <ary1> ary1_main_a2pl_27 (HASH(0x8241360))
 calling <missed_none_args> missed_none_args_main_a2pl_31 ()
 calling <classmeth> classmeth_main_a2pl_32 ()
 calling <classmeth2> classmeth2_main_a2pl_33 (2)
done
[jimc@harpo auto]$

[log4perl-devel] Log::Log4perl Recipe of the Week (#13)

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

Welcome to the Log::Log4perl recipe of the week. Today:

============================================================
Log::Log4perl Recipe of the Week (#13):

How can I write my own appender?
============================================================

First off, there's a lot of Log4perl-compatible appenders
already available on CPAN: Just run a search for
"Log::Dispatch" on http://search.cpan.org and chances are
that what you're looking for has already been developed,
debugged and been used successfully in production -- no need
for you to reinvent the wheel.

Also, Log::Log4perl ships with a nifty database appender
named Log::Log4perl::Appender::DBI -- check it out if
talking to databases is your desire.

But if you're up for a truly exotic task, you might have to
write an appender yourself. That's very easy -- it takes no
longer than a couple of minutes for the basic framework.

Say, we wanted to create an appender of the class
"Log::Dispatch::ColorScreen", which logs messages to the
screen in a configurable color. Just create a new class in
"Log/Dispatch/ColorScreen.pm" and let it inherit from the
base class "Log::Dispatch::Output":

    package Log::Dispatch::ColorScreen;

    use Log::Dispatch::Output;
    use base qw( Log::Dispatch::Output );

Now let's assume that your Log::Log4perl configuration file
"test.conf" looks like this:

    log4perl.logger = INFO, ColorApp

    log4perl.appender.ColorApp=Log::Dispatch::ColorScreen
    log4perl.appender.ColorApp.color=blue

    log4perl.appender.ColorApp.layout = PatternLayout
    log4perl.appender.ColorApp.layout.ConversionPattern=%d %m %n
 
This will cause Log::Log4perl on "init()" to look for a
class Log::Dispatch::ColorScreen and call its constructor
new(). Let's add new() to Log/Dispatch/ColorScreen.pm:

    sub new {
        my($class, %options) = @_;
    
        my $self = { %options };
        bless $self, $class;
    
        $self->_basic_init( %options );
    
        return $self;
    }

To initialize this appender, Log::Log4perl will call and
pass all attributes of the appender as defined in the
configuration file to the constructor as name/value pairs
(in this case just one):

    Log::Dispatch::ColorScreen->new(color => "blue");

The new() method listed above stores the contents of the
%options hash in the object's instance data hash (referred
to by $self) and calls "_basic_init" with all name/value
pairs to initialize the appender in the Log::Dispatch world.
That's all for initializing a new appender with
Log::Log4perl.

Second, Log::Dispatch::ColorScreen needs to expose a
"log_message()" method, which will be called by
Log::Log4perl every time it thinks the appender should fire.
Along with the object reference (as usual in Perl's object
world), log_message() will receive a list of name/value
pairs, of which only the one under the key "message" shall
be of interest for now since it is the message string to be
logged. At this point, Log::Log4perl has already taken care
of joining the message to be a single string.

For our special appender Log::Dispatch::ColorScreen, we're
using the Term::ANSIColor module to colorize the output:

    use Term::ANSIColor;

    sub log_message {
        my($self, %params) = @_;
    
        print colored($params{message},
                      $self->{color});
    }

The color (as configured in the Log::Log4perl configuration
file) is available as $self->{color} in the appender object.
Don't forget to return

    1;

at the end of ColorScreen.pm and you're done. Install the
new appender somewhere where perl can find it (like
Log/Dispatch/ColorScreen.pm) and try it with a test script
like

    use Log::Log4perl qw(:easy);
    Log::Log4perl->init("test.conf");
    ERROR("blah");

to see the new colored output. Is this cool or what?


Have fun! Until next week.

-- Mike

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

[log4perl-devel] Re: Docs/Test cases for message_filter

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

 > * looks like we can't use "sub {...}" as the syntax for
 > filter_message coderefs because it's taken by the perl hooks already
 > which are executed at config time. filter_message, on the other hand,
 > needs to run at log time. For now, I've changed the code to expect a
 > function *name* instead of a code ref -- see the latest addition to
 > the Log::Log4perl::Appender docs ... thoughts?

PropertyConfigurator is already special-casing away the cspecs:

	$val = eval_if_perl($val) if $key !~ /\.cspec\./;

why no just add another special case? Something like

	$val = eval_if_perl($val)
		if $key !~ 	/\.(cspec\.[^\.]+|filter_message)$/;


I just noticed this in the Appender.pm docs:

    B<Please note that the standard appenders in the Log::Dispatch
    hierarchy will choke on a bunch of messages passed to them as an
    array reference. You can't use C<filter_message = 0> (or the
    function name syntax defined below) on them.

but the standard appenders will work fine as long as the filter_message 
function returns a string, not an arrayref, right?


And it just occurred to me, if we're eventually going to implement log4j 
event filters, are we going to get naming confusion between 
filter_message and filter?   Should we consider other options for 
filter_message?  alter_message, munge_message, refashion_message?



-- 
Happy Trails . . .

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

[log4perl-devel] Docs/Test cases for message_filter

[<msc...@ao...>]

Hey Kevin,

just finished a couple of changes:

* added Log::Log4perl::Appender::TestArrayBuffer as a test appender capable of handling array refs.

* added test cases in 015fltmsg.t (for some strange reason 015 was still available :).

* looks like we can't use "sub {...}" as the syntax for filter_message coderefs because it's taken by the perl hooks already which are executed at config time. filter_message, on the other hand, needs to run at log time. For now, I've changed the code to expect a function *name* instead of a code ref -- see the latest addition to the Log::Log4perl::Appender docs ... thoughts?

* While I wrote the test cases, I felt regrets that we don't have a generic interface (other than in the DBI appender) to run PatternLayout substitutions on multiple-argument appender calls. Like $log->debug("%d", "%m") -- could we do that somehow? Brain storming ideas? :)

-- 
-- Mike

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

Re: [log4perl-devel] Patch for suggested new behaviour

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

Mike Schilli wrote:
> Somewhere in a log4j conf file sample you say
> 
>    log4j.appender.DBAppndr.filter_message = 1
> 
> but that should be a code ref, right?

Doh! Should be "= 0 ", good catch, fixed, thanks.  So if filter_message 
is undefined they get current behavior (join on ''), if it's 0/false 
then the list is left alone, if it's a coderef then the coderef is run 
on the list.


(re: DOMConfigurator)
>> > Also, is there a URL to the original spec we could add?
>>
>> Not really, their only "spec" is the log4j DTD...
 >
> I see. Maybe a short example would illustrate it enough for new users to 
> get the concept - - maybe even in the main Log4perl documentation, with 
> a link to the "real" doc. When I get around to it ...

Oh, that makes sense, but why didn't I think of it?  I added an example 
to the SYNOPSIS.



-- 
Happy Trails . . .

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

Re: [log4perl-devel] Patch for suggested new behaviour

[Mike S. <msc...@ao...>]

ke...@go... wrote:

> > * Also, I thought that filter_message would be a code ref which could
> > be used to manipulate logger arguments? I think the appender should
> > be able to correct any log statement argument list (like limit it to
> > the number of arguments it expects etc.)
>
> Yes, it is, see Appender.pm line 135:
>
>    #filter_message is defined and true
>     }else{
>         $p->{message} =
>             $self->{filter_message}->($p->{message}); #syntax ok for 
> perl5?
>     } 

Just inspected your changes to the docs, now it's much clearer! One 
piece is left over, though: Somewhere in a log4j conf file sample you say

    log4j.appender.DBAppndr.filter_message = 1

but that should be a code ref, right?

>
>
> But it still needs testing, documentation, and accessor methods in 
> appender.  I can do them unless you get around to it first. 

I'll have a closer look tonight ...

> > * could you please add some comments to the "Changes" file (also
> > about the XML-DOM addition)
>
> Done, thanks for reminding me.  Did I forget anything? 

Looks good!

> > * I've corrected Ceki's name in the DOMConfiguration docs with
> > umlauts, these crazy Europeans are so adamant about it :)
>
> I was wondering how to approach those. I'm don't think using character 
> 0xFC for u-with-diaeresis will translate into systems using other 
> non-ISO8859 character sets (like DOS using CP437 or Macs using 
> MacRoman).  But I didn't feel like rebooting into Windows just to 
> check the file in EDIT, so that's cool.

I've eliminated "DOS" and "Mac" from my dictionary :). Not having 
umlauts on the US keyboard is tough, I'm facing the problem when I write 
in German. For now, I'm using the notation a^ o^ u^ A^ O^ U^ s^ for 
Umlauts and a Perl conversion script like

#!/usr/bin/perl -n -i -w

  s/a\^/\344/g;
  s/o\^/\366/g;
  s/u\^/\374/g;

  s/A\^/\304/g;
  s/O\^/\326/g;
  s/U\^/\334/g;

  s/s\^/\337/g;

  print $_;

which I run on the edited file afterwards. Works pretty good!

>
>
> > Also, is there a URL to the original spec we could add?
>
> Not really, their only "spec" is the log4j DTD and I didn't want to 
> write a link to that since it's buried in their site and could very 
> well move around.  When I finish implementing our additions, I'm going 
> to circulate a log4perl DTD for comments and then include it in our 
> distribution.  But I did add a note to see t/038XML-DOM1.t for examples. 

I see. Maybe a short example would illustrate it enough for new users to 
get the concept - - maybe even in the main Log4perl documentation, with 
a link to the "real" doc. When I get around to it ...

-- 
-- Mike

Mike Schilli
log...@pe...

[log4perl-devel] Re: auto-cat

[Mike S. <msc...@ao...>]

jc...@di... wrote:

> Mike,
>
> do you want to carry this conversation over to log4perl-devel ?
> if so, cc them in, and Ill follow it over. 

Sure ... everybody, please see below ...

>
>
>>
>> Ah, now I understand. I like the idea of being able to manipulate 
>> logging behaviour at this very granular level. However, the 
>> performance impact is overwhelming:
>>
>> Every log statement, no matter if it's actually active or not, will 
>> cause a call to caller() and get_logger(). This way, it doesn't 
>> really matter if you enable or disable logging, the load on the 
>> system will always like if you enabled DEBUG logging all over the 
>> place. That's something log4j has been designed to avoid. Is there a 
>> way of getting around this?
>>
>
> Ive taken a 2nd swing at getting around the everytime AUTOLOAD, caller 
> problem.
>
> attached is a generic explanation which I put to perlmonks today, and 
> will put to perl-porters later,
> after another round of nearest-neighbor reality checks.
>
> I also posted an earlier version of this to perlmonks.org, if youve 
> ever ben there
>
>------------------------------------------------------------------------
>
>#!/usr/local/bin/perl -w
>use strict;
>no strict 'refs';
>
>=for request for assistance
>
>im trying to work out an auto-categorization feature for
>Log::Log4perl::AutoCategorize, a notional extension to its namesake.
>
>My exploratory version used AUTOLOAD on every Logger->invoke, and used
>caller() to dynamically extract caller context, which is then used for
>logging decisions.
>
>This works nicely, except for speed; it would be great to capture this
>info once, either at compile phase, or on 1st invocation of an
>autoload-vivified subroutine.
>
>=head GOAL
>
>use Log::Log4perl::AutoCategorize ( alias_as => 'Logger' );
>
># want simple invocation
>Logger->debug(@_);
>
># to invoke a late-vivified, custom-named function
>Logger->debug_<$callerpkg,$caller_sub,$caller_ln>(@_);
>
># which will be mapped at 1st use according to the config
># sub {return undef} is CONSTANT;
>
>=head1 PROBLEM
>
>I mentally file this as a function-name munging problem cuz I hope it
>happens at compile time.  That said, Im trying to solve it with
>1st-time AUTOLOAD handling, cuz thats what I know.  So, with these
>blinders applied;
>
>Munging:
>    changing the subroutine-ref added to %__PACKAGE_::
>    
>
>Inner:
>    producing munged name from user context.
>    lexical context should be available.
>    A::AUTOLOAD adds new sub to symbol table, either munged or unmunged
>
>Outer (heres where my problems are):
>
>    wo munging, symtab entry is call-once to AUTOLOAD
>    w munging, munged name is not available on 2nd try
>
>    getting Logger->debug() to invoke AUTOLOAD repeatedly.
>    w munging, this is given, as lookup fails
>
>    in sub cooperative_dynamic_name_invoke() below, Im doing the munge
>    externally, 
>
>
>
>=head1 Hunch
>
>I think optimizer.pm, B::Generate are probably the tools, but Ive got
>insufficient fu of B::* to understand where to start (I have read, and
>will reread.  I hope that this might be an 'intersting app' of
>optimizer.pm; with sufficient merit to garner porter interest.
>
>  1. when to 'require optimizer extend ...'
>    whats it mean to do so in INIT{} or CHECK {} blocks ?
>    or do it directly in AUTOLOAD {} ?
>
>  2. how to recognize (particularly at compile time) whether AUTOLOAD
>     would eventually be called, or how to get the lexical scope
>     during compilation.  a compile-time analogue to caller() would be
>     cool.
>
>=cut
>
>package A;
>use Data::Dumper;
>use vars qw($AUTOLOAD);
>use Carp 'cluck';
>
>sub AUTOLOAD {
>    # compile and goto& munged method-name
>    # 
>    (my $meth = $AUTOLOAD) =~ s/.*:://;
>    return if $meth eq 'DESTROY';
>    my ($package, $filename, $line, $subroutine) = caller(0);
>
>    my $buf = "<$meth>: $package, $filename, $line, $subroutine\n";
>    $buf =~ s|[\./]||g;
>    print "creating: $buf";
>
>    *{'A::'.$meth} = sub {
>    print "invoked: $buf"; # force string interpolation, no closure (dont need)
>    # print "\twith ", Dumper (\@_);
>    };
>    goto &{'A::'.$meth};
>}
>
>package main;
>A::auto("string{}");
>cooperative_dynamic_name_invoke();
>print "done\n";
>
>sub cooperative_dynamic_name_invoke {
>
>    # macro-like invoke of auto-names
>    # invoker help needed; by creating custom sub-name
>    # for each lexical invocation
>
>    foreach (1..2) {
>    
>    # autoload compiles sub on 1st iteration
>    # (and vivifies name in symbol table)
>    #  2nd time, new asub called directly
>    
>    my $munge = "dyn_name_000"; # wo reinit, would just make 3,4
>    $munge++;           # this doesnt give string++, but irrelevant to test
>    $munge = undef;
>    A->$munge("1st try");
>    
>    $munge++;
>    A->$munge("2nd try\n");
>    
>    $munge++;
>    A->$munge("3rd try\n");
>    
>    }
>}
>
>__END__
>    
>
>
>=cut
>
>use optimizer extend => sub {
>    print "dump ", Dumper \@_
>    if 0
>        #or $_[0]->name() eq "goto"
>        #or ref $_[0] =~ /CV/i
>            ;
>    # =~ /__ANON__/;
>};
>
>sub loop {
>    foreach (1..2) {
>    # if hashref were CONSTANT, and not rebuilt for each invocation,
>    # it could preserve the 
>      A::fancy({arb=>1},1);
>      A::fancy({ok=>2},2);
>      A::auto({});
>      A::auto({});
>    }
>    use Data::Dumper;
>    print Dumper (\%A::);
>}
>
>
>
>__END__
>
>  
>


-- 
-- Mike
Mike Schilli
log...@pe...

Re: [log4perl-devel] Patch for suggested new behaviour

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

 > * Also, I thought that filter_message would be a code ref which could
 > be used to manipulate logger arguments? I think the appender should
 > be able to correct any log statement argument list (like limit it to
 > the number of arguments it expects etc.)

Yes, it is, see Appender.pm line 135:

    #filter_message is defined and true
     }else{
         $p->{message} =
             $self->{filter_message}->($p->{message}); #syntax ok for perl5?
     }

But it still needs testing, documentation, and accessor methods in 
appender.  I can do them unless you get around to it first.



 > * could you please add some comments to the "Changes" file (also
 > about the XML-DOM addition)

Done, thanks for reminding me.  Did I forget anything?

     * (kg) Split config bits into PropertyConfigurator and implemented
            DOMConfigurator for XML configs.
     * (kg) Adding appender.filter_message parameter as a help to DBI
            appender
     * (kg) Added NoopLayout to help DBI appender



 > * I've corrected Ceki's name in the DOMConfiguration docs with
 > umlauts, these crazy Europeans are so adamant about it :)

I was wondering how to approach those. I'm don't think using character 
0xFC for u-with-diaeresis will translate into systems using other 
non-ISO8859 character sets (like DOS using CP437 or Macs using 
MacRoman).  But I didn't feel like rebooting into Windows just to check 
the file in EDIT, so that's cool.

 > Also, is there a URL to the original spec we could add?

Not really, their only "spec" is the log4j DTD and I didn't want to 
write a link to that since it's buried in their site and could very well 
move around.  When I finish implementing our additions, I'm going to 
circulate a log4perl DTD for comments and then include it in our 
distribution.  But I did add a note to see t/038XML-DOM1.t for examples.


 > * in the DBI appender's docs, the sentence "You can mix up the order
 > the placeholders with %x specifiers as you see fit" seems to be
 > missing an "of" and I'm confused about what the %x specifier does in
 > this context.
 > * What happens in case PatternLayout is chosen instead of NoopLayout?
 > Probably needs to be documented.


Oh, boy, that documentation was truly awful.  Thanks for the proofread. 
  I expanded/rewrote that section, it's checked in and listed below for 
your convenience.  Any better?  Any criticism welcome!

----------------------------------------------------------------

Normally a list of things in the logging statement gets concatenated 
into a single string, but setting C<filter_message> to 0 and using the
NoopLayout means that in

     $logger->warn( 1234, 'warning message', 'bgates' );

the individual list values will still be available for the DBI appender 
later on.  (If C<filter_message> is not set to 0, the default behavior 
is to join the list elements into a single string.   If PatternLayout or 
SimpleLayout are used, their attempt to C<render()> your layout will 
result in something like "ARRAY(0x841d8dc)" in your logs.  More 
information on C<filter_message> is in Log::Log4perl::Appender.)


In your insert SQL you can mix up '?' placeholders with conversion 
specifiers (%c, %p, etc) as you see fit--the logger will match the 
question marks to params you've defined in the config file and populate 
the rest with values from your list.  If there are more '?' placeholders 
than there are values in your message, it will use undef for the rest. 
For instance,


         log4j.appender.DBAppndr.sql =                 \
            insert into log4perltest                   \
            (loglevel, message, datestr, subpoena_id)\
            values (?,?,?,?)
         log4j.appender.DBAppndr.params.1 = %p
         log4j.appender.DBAppndr.params.3 = %d

         log4j.appender.DBAppndr.filter_message=0


         $logger->info('arrest him!', $subpoena_id);

results in the first '?' placholder being bound to %p, the second to
"arrest him!", the third to the date from "%d", and the fourth to your
$subpoena_id.  If you forget the $subpoena_id and just log

         $logger->info('arrest him!');

then you just get undef in the fourth column.




msc...@ao... wrote:
 > In a message dated 1/20/2003 12:40:27 PM Eastern Standard Time, Kevin
 > Goess <ke...@go...> writes:
 >
 >
 >> The new stuff is checked in, all tests pass.
 >
 >
 > That's great news, thanks! Couple of notes:
 >
 > * in the DBI appender's docs, the sentence "You can mix up the order
 > the placeholders with %x specifiers as you see fit" seems to be
 > missing an "of" and I'm confused about what the %x specifier does in
 > this context.
 >
 > * What happens in case PatternLayout is chosen instead of NoopLayout?
 > Probably needs to be documented.
 >
 > * Also, I thought that filter_message would be a code ref which could
 > be used to manipulate logger arguments? I think the appender should
 > be able to correct any log statement argument list (like limit it to
 > the number of arguments it expects etc.)
 >
 > * could you please add some comments to the "Changes" file (also
 > about the XML-DOM addition)
 >
 > * I've corrected Ceki's name in the DOMConfiguration docs with
 > umlauts, these crazy Europeans are so adamant about it :) Also, is
 > there a URL to the original spec we could add?
 >
 > BTW, I'm gonna add a couple of test cases for the new { filter =>
 > \&filter, value => $value} syntax.
 >
 > All test cases run fine on my box, too, looks good so far!
 >
 > -- Mike
 >
 > ############################ # Mike Schilli             # #
 > log...@pe... # # http://perlmeister.com   # #
 > log4perl.sourceforge.net # ############################
 >


-- 
Happy Trails . . .

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