log4perl-devel — Ongoing log4perl development

Re: [log4perl-devel] A threading question.

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

On Thu, 16 Oct 2008, Rob Coops wrote:

> So my question is; is log4perl thread safe when using the standard
> file appender module with it?

I've never tested running Log4perl with Perl threads, so the answer is
probably "no" :).

It would be great if you could provide test results / bug reports of
running Log4perl with Perl threads, though.

That being said, there are synchronization mechanisms for file
appenders:

     http://log4perl.sourceforge.net/d/Log/Log4perl/FAQ.html#23804

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] A threading question.

[Rob C. <rc...@gm...>]

Hi list,

I'm new to this list so please forgive me if I am asking an obvious question
that every member of this list has asked at some point in time...

When I look at the FAQ for log4perl I see that there is a mention of
threading and having every thread log a thread specific message like a users
IP address. This leads me to believe that log4perl is thread safe yet I do
not see anywhere in the documentation or in the FAQ a definite Yes log4perl
is thread safe, and looking at the source code I do not see any obvious file
locking which makes me somewhat doubt that log4perl is thread safe.

So my question is; is log4perl thread safe when using the standard file
appender module with it?

Thank you,

Rob Coops.

Re: [log4perl-devel] Reducing the stack

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

Todd, I think this is what you want:

Using Log::Log4perl from wrapper classes
  If you don't use "Log::Log4perl" as described above, but from
  a wrapper class (like your own Logging class which in turn
  uses "Log::Log4perl"), the pattern layout will generate wrong data
  for %F, %C, %L and the like.  Reason for this is that Log::Log4perl"'s
  loggers assume a static caller depth to the application that's using
  them. If you're using one (or more) wrapper classes, "Log::Log4perl"
  will indicate where your logger classes called the loggers, not where
  your application called your wrapper, which is probably what you want
  in this case.  But don't despair, there's a solution: Just increase
  the value of $Log::Log4perl::caller_depth (defaults to 0) by one for
  every wrapper that's in between your application and "Log::Log4perl",
  then "Log::Log4perl" will compensate for the difference.



todd.e.rinaldo wrote:
> Hi,
> 
> I often have a helper routine in my code that logs an event and then  
> does stuff. In some cases, it would be helpful if the line number that  
> is logged was one level up from where I call debug.
> 
> My question: does functionality exist in l4p similar to Test::More  
> that would allow me to log events from higher in the stack than where  
> I called debug?
> 
> Test::More method:
> local $Test::Builder::Level++; 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel

Re: [log4perl-devel] Reducing the stack

[Anno S. <ann...@ma...>]

On 14.10.2008, at 20:22, todd.e.rinaldo wrote:

> Hi,
>
> I often have a helper routine in my code that logs an event and then
> does stuff. In some cases, it would be helpful if the line number that
> is logged was one level up from where I call debug.
>
> My question: does functionality exist in l4p similar to Test::More
> that would allow me to log events from higher in the stack than where
> I called debug?
>
> Test::More method:
> local $Test::Builder::Level++;

I don't think you can modify the behavior of %L, and hence SimpleLayout
in this way.  If you're ready to define your own layout, the feature can
be added via a custom placeholder (%A below).  See the appended code for
a way to do it.

Anno

----------------------------------------------------------------------
use Log::Log4perl qw(get_logger);
Log::Log4perl::init(\ *DATA);

log_this("here line " . __LINE__); # show real line number in log  
message
log_this("here line " . __LINE__); # again, one line down
exit;

sub log_this {
     get_logger()->info(shift); # %L will be this line number, %A won't
}

# helper sub for custom placeholder %A
sub line_one_above {
     my $i = 1;                                  # skip bottom level  
(main)
     ++ $i while caller($i) =~ /^Log::Log4perl/; # climb to user spoace
     ++ $i;                                      # one more (!)
     (caller($i))[2];                            # return line number
}

__DATA__
log4perl.rootLogger=INFO, screen_root

log4perl.appender.screen_root=Log::Log4perl::Appender::Screen
log4perl.appender.screen_root.layout=PatternLayout
log4perl.appender.screen_root.layout.ConversionPattern=%m at line %A  
(L=%L)%n

log4perl.PatternLayout.cspec.A = sub { line_one_above() }

[log4perl-devel] Logging from higher in the stack

[todd.e.rinaldo <tod...@gm...>]

> Hi,
>
> I often have a helper routine in my code that logs an event and then  
> does stuff. In some cases, it would be helpful if the line number  
> that is logged was one level up from where I call debug.
>
> My question: does functionality exist in l4p similar to Test::More  
> that would allow me to log events from higher in the stack than  
> where I called debug?
>
> Test::More method:
> local $Test::Builder::Level++;

[log4perl-devel] Reducing the stack

[todd.e.rinaldo <tod...@gm...>]

Hi,

I often have a helper routine in my code that logs an event and then  
does stuff. In some cases, it would be helpful if the line number that  
is logged was one level up from where I call debug.

My question: does functionality exist in l4p similar to Test::More  
that would allow me to log events from higher in the stack than where  
I called debug?

Test::More method:
local $Test::Builder::Level++; 

Re: [log4perl-devel] Change proposition: multiple configuration files

[Anno S. <ann...@ma...>]

On 05.10.2008, at 12:08, Anno Siegel wrote:

> When I posted the message reproduced below I managed to append a  
> botched
> version of my patch.  Here is a good one (demo.tgz was okay,  
> reposting for
> completeness).  Sorry about that.
>
> <log4perl_combo.patch>   <demo.tgz>

[etc]

Hmm... it's been over a week.  Am i missing anything?

Anno




> Anno
>
>
> On 03.10.2008, at 12:19, Anno Siegel wrote:
>
>> I'd like to add the ability to give multiple (partial) configuration
>> files to init() and init_and_watch(). In place of a single file, you
>> could specify an array(ref) of files, whose concatenation is used in
>> initialization, and which are all watched for changes.
>>
>> A user might say
>>
>>     init_and_watch([
>>         'my_std_root.conf',      # almost everything might use that
>> 	'my_application.conf',   # special to this application
>>         'that_module.conf',      # came with That::Module, which  
>> i'm using
>>     ], 'HUP');
>>
>> to invoke a few components. Editing or replacing any of them would be
>> noticed by the application (after a HUP). I believe that such a  
>> feature
>> would help in managing configuration files.
>>
>> The appended patch adds the feature to Log4perl, in a yet somewhat
>> sketchy way.  I'd like to hear opinions whether this would be a  
>> useful
>> addition and if it has a chance of being accepted.  If I'm on the  
>> wrong
>> trip and everything speaks for monolithic configuration files, please
>> say so.
>>
>> Here are some technicalities about the patch, of interest if you
>> intend to try this at home :)
>>
>> It's against v 1.18 from CPAN and can be applied from inside a fresh
>> build dir as "patch -p0 <log4perl_combo.patch".  It addds, under
>> lib/, the module Log/Log4perl/Config/Combo.pm, and it modifies
>> .../Config.pm and .../Watch.pm to understand the additional form
>> of file specification.  "prove -Ilib t/" should show that the
>> changes are compatible with the current behavior.
>>
>> To see the new behavior, unpack demo.tgz in the build dir (won't
>> work anywhere else) and cd into demo.  Inspect "runme", then run it
>> as "perl runme", in case the shebang doesn't work.  runme configures
>> l4p from the two files root.conf and one.conf and then produces  
>> sample
>> log events on demand. It takes an optional argument, the time or
>> signal to pass to init_and_watch(). The idea is to use another
>> shell to edit and/or replace the configuration files, then see if
>> the changes are honored. The directory reset_conf contains the
>> original configuration files again.
>>
>> Regards, Anno
> ---------------------------------------------------------------------- 
> ---
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/ 
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel

Re: [log4perl-devel] Change proposition: multiple configuration files

[Anno S. <ann...@ma...>]

When I posted the message reproduced below I managed to append a botched
version of my patch.  Here is a good one (demo.tgz was okay,  
reposting for
completeness).  Sorry about that.

[log4perl-devel] Wide Character errors

[Bill M. <mo...@ha...>]

I've seen examples of how to set utf8, such as in the faq:

    log4perl.appender.Logfile.utf8     = 1

and in a number of posts to this list.  But I can't find it
documented.

I have a config that logs to the screen, syslog, and to a file so I
have:

log4perl.appender.syslogAppender = Log::Dispatch::Syslog
log4perl.appender.syslogAppender.utf8     = 1
...

# Write to the screen.
#
log4perl.appender.screenAppender = Log::Log4perl::Appender::Screen
log4perl.appender.screenAppender.utf8     = 1


log4perl.appender.errorNotify = Log::Log4perl::Appender::File
log4perl.appender.errorNotify.utf8 = 1

Yet, I still get wide character errors (and with syslog it throws an
exception).

    Wide character in syswrite at /usr/lib/perl/5.8/Sys/Syslog.pm line 765.

I have centralized logging so I can encode_utf8 in one place to fix,
but I'm curious if there's a way to have Log4perl handle the encoding.



-- 
Bill Moseley
mo...@ha...
Sent from my iMutt

[log4perl-devel] Change proposition: multiple configuration files

[Anno S. <ann...@ma...>]

I'd like to add the ability to give multiple (partial) configuration
files to init() and init_and_watch(). In place of a single file, you
could specify an array(ref) of files, whose concatenation is used in
initialization, and which are all watched for changes.

A user might say

     init_and_watch([
         'my_std_root.conf',      # almost everything might use that
	'my_application.conf',   # special to this application
         'that_module.conf',      # came with That::Module, which i'm  
using
     ], 'HUP');

to invoke a few components. Editing or replacing any of them would be
noticed by the application (after a HUP). I believe that such a feature
would help in managing configuration files.

The appended patch adds the feature to Log4perl, in a yet somewhat
sketchy way.  I'd like to hear opinions whether this would be a useful
addition and if it has a chance of being accepted.  If I'm on the wrong
trip and everything speaks for monolithic configuration files, please
say so.

Here are some technicalities about the patch, of interest if you
intend to try this at home :)

It's against v 1.18 from CPAN and can be applied from inside a fresh
build dir as "patch -p0 <log4perl_combo.patch".  It addds, under
lib/, the module Log/Log4perl/Config/Combo.pm, and it modifies
.../Config.pm and .../Watch.pm to understand the additional form
of file specification.  "prove -Ilib t/" should show that the
changes are compatible with the current behavior.

To see the new behavior, unpack demo.tgz in the build dir (won't
work anywhere else) and cd into demo.  Inspect "runme", then run it
as "perl runme", in case the shebang doesn't work.  runme configures
l4p from the two files root.conf and one.conf and then produces sample
log events on demand. It takes an optional argument, the time or
signal to pass to init_and_watch(). The idea is to use another
shell to edit and/or replace the configuration files, then see if
the changes are honored. The directory reset_conf contains the
original configuration files again.

Regards, Anno

Re: [log4perl-devel] Logging to Multiple Log Files

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

On Wed, 17 Sep 2008, William Reardon wrote:

> Using log4perl, is it possible to have multiple log files/Logfile
> appenders?  E.g., most logging goes to 'my_application.log', but with
> something like 'get_logger( "SPECIAL" )' I can route messages to
> 'special.log'?

Sure, that's a common case: Just define another category and have its
messages routed to a second appender:

use Log::Log4perl qw(:easy);

     my $conf = q{
     log4perl.logger.foo = DEBUG, FooAppender
     log4perl.logger.bar = DEBUG, BarAppender

     log4perl.appender.FooAppender = Log::Log4perl::Appender::File
     log4perl.appender.FooAppender.filename = foo.log
     log4perl.appender.FooAppender.layout = SimpleLayout

     log4perl.appender.BarAppender = Log::Log4perl::Appender::File
     log4perl.appender.BarAppender.filename = bar.log
     log4perl.appender.BarAppender.layout = SimpleLayout
     };

     Log::Log4perl->init( \$conf );

     get_logger("foo")->debug("foo!");
     get_logger("bar")->debug("bar!");

gets you

     $ cat foo.log
     DEBUG - foo!

     $ cat bar.log
     DEBUG - bar!

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] Logging to Multiple Log Files

[William R. <wd...@po...>]

Using log4perl, is it possible to have multiple log files/Logfile 
appenders?  E.g., most logging goes to 'my_application.log', but with 
something like 'get_logger( "SPECIAL" )' I can route messages to 
'special.log'?

Apologies if this is a stupid question -- I tried search the docs & list 
archives and came up dry.

TIA!

-Bill

[log4perl-devel] init_and_watch, preinit_callback

[Aaron R. <aa...@aa...>]

Hi all,

I'm looking for an example of a preinit_callback that checks the
syntax of a config file.

I don't see a way to check the syntax of a file, so I'm not sure what
I can do in preinit_callback aside from trying to load the config via
init(). The docs say that init_and_watch may fail on reload, but the
code will fallback to an old config if it's already loaded.

So, I'm wondering what I can do in the preinit_callback.

Thanks for any advice!

--
Aaron

[log4perl-devel] Log::Log4perl 1.18 released

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

Hi Log4perl enthusiasts,

Log4perl 1.18 has just been released to the log4perl.com website.

The changes:

1.18 (2008/08/23)
     *   (ms) Added explanation that categories and loggers are the
         same thing (thanks to Rabbit).
     *   (ms) Fixed t/053Resurrect to work with 5.005_03
     *   (ms) Added preinit_callback function for init_and_watch()
     *   (ms) Applied patch by Andy Grundman which speeds up is_LEVEL()
         calls by skipping unnecessary string concatenations
         (http://rt.cpan.org/Ticket/Display.html?id=38537).
     *   (ms) Applied patch by Jae Gangemi addding a no_warning option
         to the socket appender
         (http://rt.cpan.org/Ticket/Display.html?id=34399).

If all goes well, it'll hit CPAN in a couple of days.

Enjoy!

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] easy_init problem

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

On Tue, 19 Aug 2008, Andrew wrote:

> As I understand it, calling the following:
>
> Log::Log4perl->easy_init({ level   => $DEBUG },
>  { level   => $INFO,
>    file    => ">> log.log" });
>
> should create two loggers, the first logging DEBUG and up messages to
> stderr and the second logging INFO and up to a file called log.log.

Unfortunately, having the same logger (the root logger in your case) use
two different log levels for two appenders involves a filter/threshold
and cannot be done with in easy mode.

The configuration file version of your easy mode setup would look
something like this:

     log4perl.logger = INFO, screen, file

     log4perl.appender.screen = Log::Log4perl::Appender::Screen
     log4perl.appender.screen.layout = SimpleLayout

     log4perl.appender.file = Log::Log4perl::Appender::File
     log4perl.appender.file.filename = foo.log
     log4perl.appender.file.layout = SimpleLayout

and if you want to send messages with a level of DEBUG and up to the 
screen and messages higher or equal than INFO to a file, you need to
open up the logger for DEBUG messages and reduce the exposure of the
file appender to INFO via an appender threshold setting:

     log4perl.logger = DEBUG, screen, file

     log4perl.appender.screen = Log::Log4perl::Appender::Screen
     log4perl.appender.screen.layout = SimpleLayout

     log4perl.appender.file = Log::Log4perl::Appender::File
     log4perl.appender.file.filename = foo.log
     log4perl.appender.file.layout = SimpleLayout
     log4perl.appender.file.Threshold = INFO

Unfortunately, there's no way to do that in easy mode yet unless you're
using two different loggers (categories):

     Log::Log4perl->easy_init( { level    => $INFO,
                                 file     => ">>test.log",
                                 category => "Bar::Twix",
                                 layout   => ’%F{1}-%L-%M: %m%n’

                               { level    => $DEBUG,
                                 file     => "STDOUT",
                                 category => "Bar::Mars",
                                 layout   => ’%m%n’ },
                             );

-- Mike

Mike Schilli
m...@pe...

>
> While this does create two loggers, one logging to stderr and one to a
> file, both loggers get whatever level is set last, no matter how I
> arrange this list of hashes.
>
> Any idea what's going on here? I'm using Log4perl 1.17.
>
> Here's a simple script showing this behavior:
>
> #! /usr/bin/perl
> use strict;
> use warnings;
>
> use Log::Log4perl qw(:easy);
> Log::Log4perl->easy_init({ level   => $DEBUG },
>  { level   => $INFO,
>    file    => ">> log.log" });
>
> my $log = Log::Log4perl::get_logger();
> $log->debug("debug line");
> $log->info("info line");
>

[log4perl-devel] easy_init problem

[Andrew <an...@gu...>]

As I understand it, calling the following:

Log::Log4perl->easy_init({ level   => $DEBUG },
  { level   => $INFO,
    file    => ">> log.log" });

should create two loggers, the first logging DEBUG and up messages to 
stderr and the second logging INFO and up to a file called log.log.

While this does create two loggers, one logging to stderr and one to a 
file, both loggers get whatever level is set last, no matter how I 
arrange this list of hashes.

Any idea what's going on here? I'm using Log4perl 1.17.

Here's a simple script showing this behavior:

#! /usr/bin/perl
use strict;
use warnings;

use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init({ level   => $DEBUG },
  { level   => $INFO,
    file    => ">> log.log" });

my $log = Log::Log4perl::get_logger();
$log->debug("debug line");
$log->info("info line");

Re: [log4perl-devel] Log4perl command line options (fwd)

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

Mike Schilli wrote:
> I have one suggestion: Since -d or -v are used by some scripts for
> different purposes, how about letting the script determine which options
> are covered?

Done.

http://search.cpan.org/~ctilmes/Log-Log4perl-CommandLine-0.03/

I've already seen a few things I want to change, but I think it
is coming along..

> Is it OK if I forward your post to the log4perl devel list?

Sure.  I just subscribed myself.

Curt

Re: [log4perl-devel] Log4perl command line options (fwd)

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

On Mon, 4 Aug 2008, Curt Tilmes wrote:

> I attended your talk at OSCON about Log4perl (which I enjoyed
> immensely, thank you!),

Hi Curt,

thanks, glad you liked it ;).

> and asked a question about command line options rather than config
> files.  I've thought about it a bit since then, and put together the
> attached module.

This is fantastic, I've always wanted something like that.

I have one suggestion: Since -d or -v are used by some scripts for
different purposes, how about letting the script determine which options
are covered? In this way,

     use Log::Log4perl::CommandLine qw(:all);

would activate all available command line options, while

     use  Log::Log4perl::CommandLine qw(v q d);

would activate -v, -q, and -d.

And, sure, feel free to use Log::Log4perl::CommandLine as the name, that
makes perfect sense.

Is it OK if I forward your post to the log4perl devel list?

Thanks for your Log4perl extension!

-- Mike

Mike Schilli
m...@pe...

> replace the configuration file interface (which is infinitely more
> configurable), but rather to make an easy way to 1) make use of
> Log4perl even if you don't want to think about the config files (or
> teach end users how to write them), and 2) provide an easy command
> line way to override a couple parts without continually editing/saving
> a new config file.
> 
> What do you think about the proposed module name:
>    Log::Log4perl::CommandLine
> 
> As implemented, I just call Getopt::Long to do all the command line
> option parsing,
> but I know you don't want to add dependencies on external modules for your 
> core
> Log4perl module.  This could be released independently if that was a concern.
> 
> To illustrate, I took the simple "drink soda" script from one of your
> tutorial articles
> and changed it like this:
> =================================
> use Log::Log4perl qw(:easy);
> use Log::Log4perl::CommandLine;
> 
> drink();
> drink("Soda");
> 
> sub drink {
>    my($what) = @_;
>
>    my $logger = get_logger();
>
>    if(defined $what) {
>        $logger->info("Drinking ", $what);
>    } else {
>        $logger->error("No drink defined");
>    }
> }
> ==================================
> 
> Now it is command line enabled, and you can do things like this:
> 
> % perl log.pl
> 2008/08/04 15:55:53 No drink defined
> 
> % perl log.pl -v    (or --verbose)
> 2008/08/04 15:55:56 No drink defined
> 2008/08/04 15:55:56 Drinking Soda
> 
> % perl log.pl -q   (or --quiet)
> 
> % perl log.pl --debug --logfile log.txt
> 2008/08/04 16:08:16 No drink defined
> 2008/08/04 16:08:16 Drinking Soda
> 
> % cat log.txt
> 2008/08/04 16:08:16 No drink defined
> 2008/08/04 16:08:16 Drinking Soda
> 
> % perl log.pl --trace My::Module
> [...]
> 
> What do you think?
> 
> Curt
>

[log4perl-devel] Log4perl command line options (fwd)

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

Here's a nice new Log4perl extension that just made it to CPAN:

-- Mike

Mike Schilli
m...@pe...

---------- Forwarded message ----------
From: Curt Tilmes <cu...@ti...>
To: log...@pe...
Subject: Log4perl command line options
Date: Mon, 4 Aug 2008 16:27:27 -0400

I attended your talk at OSCON about Log4perl (which I enjoyed
immensely, thank you!),
and asked a question about command line options rather than config files.

I've thought about it a bit since then, and put together the attached
module.  Everything
is still in flux.  This isn't intended to replace the configuration
file interface (which
is infinitely more configurable), but rather to make an easy way to 1)
make use of
Log4perl even if you don't want to think about the config files (or
teach end users
how to write them), and 2) provide an easy command line way to override a couple
parts without continually editing/saving a new config file.

What do you think about the proposed module name:
     Log::Log4perl::CommandLine

As implemented, I just call Getopt::Long to do all the command line
option parsing,
but I know you don't want to add dependencies on external modules for your core
Log4perl module.  This could be released independently if that was a concern.

To illustrate, I took the simple "drink soda" script from one of your
tutorial articles
and changed it like this:
=================================
use Log::Log4perl qw(:easy);
use Log::Log4perl::CommandLine;

drink();
drink("Soda");

sub drink {
     my($what) = @_;

     my $logger = get_logger();

     if(defined $what) {
         $logger->info("Drinking ", $what);
     } else {
         $logger->error("No drink defined");
     }
}
==================================

Now it is command line enabled, and you can do things like this:

% perl log.pl
2008/08/04 15:55:53 No drink defined

% perl log.pl -v    (or --verbose)
2008/08/04 15:55:56 No drink defined
2008/08/04 15:55:56 Drinking Soda

% perl log.pl -q   (or --quiet)

% perl log.pl --debug --logfile log.txt
2008/08/04 16:08:16 No drink defined
2008/08/04 16:08:16 Drinking Soda

% cat log.txt
2008/08/04 16:08:16 No drink defined
2008/08/04 16:08:16 Drinking Soda

% perl log.pl --trace My::Module
[...]

What do you think?

Curt

Re: [log4perl-devel] Suggestion: add trace as a valid Log::Dispatch log level

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

On Sun, 10 Aug 2008, Ben Tilly wrote:

> While it is not logically necessary to ever have it, see
> http://www.perlmonks.org/index.pl?node_id=703501 for an example of
> someone trying to configure things so that a trace goes somewhere, he
> tried to set
> log4perl.appender.StdOut.min_level=trace

Hi Ben,

thanks for the patch. It would need to be applied to Log::Dispatch, not
Log4perl, though.

Log::Dispatch is a different project. It works well with Log4perl, and
we use its appenders so that we don't have to re-invent the wheel.
It's managed by Dave Rolsky:

     http://search.cpan.org/~drolsky/Log-Dispatch/

I'm not sure if Dave is going add another level to Log::Dispatch, but
you can try :).

min_level is Log::Dispatch-specific, but the same thing can be done 
natively in Log4perl with an appender threshold:

     log4perl.appender.Screen1   = Log::Log4perl::Appender::Screen
     log4perl.appender.Screen1.layout = SimpleLayout
     log4perl.appender.Screen1.Threshold = ERROR

or if you want to define a range, use a LevelRange filter:

     http://log4perl.sourceforge.net/d/Log/Log4perl/Filter/LevelRange.html

Here's how to apply filters to Log4perl's appenders:

     http://log4perl.sourceforge.net/d/Log/Log4perl/Filter.html

And, just so you know, Log4perl has its own screen and file appenders,
Log::Log4perl::Appender::Screen and Log::Log4perl::Appender::File.

Especially the file appender has a lot more options than its
Log::Dispatch counterpart.

Use the one that suits your needs. :)

-- Mike

Mike Schilli
m...@pe...


>
> in the log file only to find that
>
> trace is not a valid Log::Dispatch log level at
> /Library/Perl/5.8.8/Log/Log4perl/Appender.pm line 77
>
> Which is highly confusing because the documentation for Log::Log4perl
> says very clearly that trace *is* a valid logging level.
>
> I told the questioner how to make it work, but still I think the fix
> should be made to avoid useless confusion.
>
> And yes, I looked at the code, and I'm aware that there is no
> non-hacky way to do it.  Still it can be done.  Here is a patch to do
> it.
>
> --- Dispatch.pm	2008-08-10 20:43:32.000000000 -0700
> +++ Dispatch.pm.fix	2008-08-10 20:39:22.000000000 -0700
> @@ -9,14 +9,14 @@
>
> use Carp ();
>
> -our $VERSION = '2.21';
> +our $VERSION = '2.22';
> our %LEVELS;
>
>
> BEGIN
> {
>     no strict 'refs';
> -    foreach my $l ( qw( debug info notice warning err error crit
> critical alert emerg emergency ) )
> +    foreach my $l ( qw( trace debug info notice warning err error
> crit critical alert emerg emergency ) )
>     {
>         *{$l} = sub { my $self = shift;
>                       $self->log( level => $l, message => "@_" ); };
>
>
> --- Dispatch/Output.pm	2008-08-10 20:43:54.000000000 -0700
> +++ Dispatch/Output.pm.fix	2008-08-10 20:43:48.000000000 -0700
> @@ -12,7 +12,7 @@
>
> use Carp ();
>
> -our $VERSION = '1.26';
> +our $VERSION = '1.27';
>
>
> sub new
> @@ -52,13 +52,17 @@
>                           } );
>
>     # Map the names to numbers so they can be compared.
> -    $self->{level_names} = [ qw( debug info notice warning error
> critical alert emergency ) ];
> +    # We would like trace to be first, but we can't change the historical
> +    # numbers for backwards compatibility reasons.
> +    $self->{level_names} = [ qw( debug info notice warning error
> critical alert emergency trace ) ];
>
>     my $x = 0;
>     $self->{level_numbers} = { ( map { $_ => $x++ } @{
> $self->{level_names} } ),
>                                err   => 4,
>                                crit  => 5,
> -                               emerg => 7 };
> +                               emerg => 7,
> +                               trace => -1 };
> +    die $self->{level_numbers}{trace};
>
>     $self->{name} = $p{name};
>
> @@ -70,7 +74,7 @@
>     $self->{max_level} =
>         ( exists $p{max_level} ?
>           $self->_level_as_number($p{max_level}) :
> -          $#{ $self->{level_names} }
> +          $#{ $self->{level_names} } - 1 # Skip trace
>         );
>
>     die "Invalid level specified for max_level" unless defined
> $self->{max_level};
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

[log4perl-devel] Suggestion: add trace as a valid Log::Dispatch log level

[Ben T. <bt...@gm...>]

While it is not logically necessary to ever have it, see
http://www.perlmonks.org/index.pl?node_id=703501 for an example of
someone trying to configure things so that a trace goes somewhere, he
tried to set

log4perl.appender.StdOut.min_level=trace

in the log file only to find that

trace is not a valid Log::Dispatch log level at
/Library/Perl/5.8.8/Log/Log4perl/Appender.pm line 77

Which is highly confusing because the documentation for Log::Log4perl
says very clearly that trace *is* a valid logging level.

I told the questioner how to make it work, but still I think the fix
should be made to avoid useless confusion.

And yes, I looked at the code, and I'm aware that there is no
non-hacky way to do it.  Still it can be done.  Here is a patch to do
it.

--- Dispatch.pm	2008-08-10 20:43:32.000000000 -0700
+++ Dispatch.pm.fix	2008-08-10 20:39:22.000000000 -0700
@@ -9,14 +9,14 @@

 use Carp ();

-our $VERSION = '2.21';
+our $VERSION = '2.22';
 our %LEVELS;


 BEGIN
 {
     no strict 'refs';
-    foreach my $l ( qw( debug info notice warning err error crit
critical alert emerg emergency ) )
+    foreach my $l ( qw( trace debug info notice warning err error
crit critical alert emerg emergency ) )
     {
         *{$l} = sub { my $self = shift;
                       $self->log( level => $l, message => "@_" ); };


--- Dispatch/Output.pm	2008-08-10 20:43:54.000000000 -0700
+++ Dispatch/Output.pm.fix	2008-08-10 20:43:48.000000000 -0700
@@ -12,7 +12,7 @@

 use Carp ();

-our $VERSION = '1.26';
+our $VERSION = '1.27';


 sub new
@@ -52,13 +52,17 @@
                           } );

     # Map the names to numbers so they can be compared.
-    $self->{level_names} = [ qw( debug info notice warning error
critical alert emergency ) ];
+    # We would like trace to be first, but we can't change the historical
+    # numbers for backwards compatibility reasons.
+    $self->{level_names} = [ qw( debug info notice warning error
critical alert emergency trace ) ];

     my $x = 0;
     $self->{level_numbers} = { ( map { $_ => $x++ } @{
$self->{level_names} } ),
                                err   => 4,
                                crit  => 5,
-                               emerg => 7 };
+                               emerg => 7,
+                               trace => -1 };
+    die $self->{level_numbers}{trace};

     $self->{name} = $p{name};

@@ -70,7 +74,7 @@
     $self->{max_level} =
         ( exists $p{max_level} ?
           $self->_level_as_number($p{max_level}) :
-          $#{ $self->{level_names} }
+          $#{ $self->{level_names} } - 1 # Skip trace
         );

     die "Invalid level specified for max_level" unless defined
$self->{max_level};

Re: [log4perl-devel] avoiding logging to parent appender

[Jonathan S. <sw...@po...>]

Damn, should have checked the FAQ. Thanks!

Jon

On Jul 23, 2008, at 9:40 AM, Mike Schilli wrote:

> On Wed, 23 Jul 2008, Jonathan Swartz wrote:
>
>> I want to have two log files:
>> * main.log, which gets all INFO and above messages in the system
>> * session.log, which gets all DEBUG and above messages in the
>
> Your two loggers are within the same hierarchy, so you need to put in
> a threshold/additivity setting to prevent DEBUG messages from bubbling
> up:
>
>    http://log4perl.sourceforge.net/d/Log/Log4perl/FAQ.html#a6c81
>
> -- Mike
>
> Mike Schilli
> m...@pe...
>
>
>> My.Session package
>>
>> Here's what I tried:
>>
>>   log_dir = /Users/swartz/perl/log4perl/dup
>>   log_layout = %d{dd/MMM/yyyy:HH:mm:ss.SS} [%p] %c - %m - %F:%L -
>> %X{script_name} - %P-%X{request_id}%n
>>
>>   log4perl.logger                                 = INFO, main
>>   log4perl.appender.main                          =
>> Log::Log4perl::Appender::File
>>   log4perl.appender.main.filename                 = ${log_dir}/
>> main.log
>>   log4perl.appender.main.layout                   = PatternLayout
>>   log4perl.appender.main.layout.ConversionPattern = ${log_layout}
>>
>>   log4perl.logger.My.Session                         = DEBUG, session
>>   log4perl.appender.session                          =
>> Log::Log4perl::Appender::File
>>   log4perl.appender.session.filename                 = ${log_dir}/
>> session.log
>>   log4perl.appender.session.layout                   = PatternLayout
>>   log4perl.appender.session.layout.ConversionPattern = ${log_layout}
>>
>> with this script:
>>
>>   #!/usr/bin/perl
>>   use Log::Log4perl;
>>   use warnings;
>>   use strict;
>>   Log::Log4perl::init('log.conf');
>>
>>   my $log = Log::Log4perl->get_logger('My.Session');
>>   $log->debug('session message');
>>
>> But it logs 'session message' to both main.log and session.log, which
>> is somewhat surprising since the main.log section was set for 'INFO'.
>>
>> Is there a way for the My.Session debug messages to only go to
>> session.log, not to main.log?
>>
>> Thanks!
>> Jon
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> log4perl-devel mailing list
>> log...@li...
>> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>>
>

Re: [log4perl-devel] avoiding logging to parent appender

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

On Wed, 23 Jul 2008, Jonathan Swartz wrote:

> I want to have two log files:
> * main.log, which gets all INFO and above messages in the system
> * session.log, which gets all DEBUG and above messages in the

Your two loggers are within the same hierarchy, so you need to put in
a threshold/additivity setting to prevent DEBUG messages from bubbling
up:

     http://log4perl.sourceforge.net/d/Log/Log4perl/FAQ.html#a6c81

-- Mike

Mike Schilli
m...@pe...


> My.Session package
>
> Here's what I tried:
>
>    log_dir = /Users/swartz/perl/log4perl/dup
>    log_layout = %d{dd/MMM/yyyy:HH:mm:ss.SS} [%p] %c - %m - %F:%L -
> %X{script_name} - %P-%X{request_id}%n
>
>    log4perl.logger                                 = INFO, main
>    log4perl.appender.main                          =
> Log::Log4perl::Appender::File
>    log4perl.appender.main.filename                 = ${log_dir}/
> main.log
>    log4perl.appender.main.layout                   = PatternLayout
>    log4perl.appender.main.layout.ConversionPattern = ${log_layout}
>
>    log4perl.logger.My.Session                         = DEBUG, session
>    log4perl.appender.session                          =
> Log::Log4perl::Appender::File
>    log4perl.appender.session.filename                 = ${log_dir}/
> session.log
>    log4perl.appender.session.layout                   = PatternLayout
>    log4perl.appender.session.layout.ConversionPattern = ${log_layout}
>
> with this script:
>
>    #!/usr/bin/perl
>    use Log::Log4perl;
>    use warnings;
>    use strict;
>    Log::Log4perl::init('log.conf');
>
>    my $log = Log::Log4perl->get_logger('My.Session');
>    $log->debug('session message');
>
> But it logs 'session message' to both main.log and session.log, which
> is somewhat surprising since the main.log section was set for 'INFO'.
>
> Is there a way for the My.Session debug messages to only go to
> session.log, not to main.log?
>
> Thanks!
> Jon
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

[log4perl-devel] avoiding logging to parent appender

[Jonathan S. <sw...@po...>]

I want to have two log files:
* main.log, which gets all INFO and above messages in the system
* session.log, which gets all DEBUG and above messages in the  
My.Session package

Here's what I tried:

    log_dir = /Users/swartz/perl/log4perl/dup
    log_layout = %d{dd/MMM/yyyy:HH:mm:ss.SS} [%p] %c - %m - %F:%L -  
%X{script_name} - %P-%X{request_id}%n

    log4perl.logger                                 = INFO, main
    log4perl.appender.main                          =  
Log::Log4perl::Appender::File
    log4perl.appender.main.filename                 = ${log_dir}/ 
main.log
    log4perl.appender.main.layout                   = PatternLayout
    log4perl.appender.main.layout.ConversionPattern = ${log_layout}

    log4perl.logger.My.Session                         = DEBUG, session
    log4perl.appender.session                          =  
Log::Log4perl::Appender::File
    log4perl.appender.session.filename                 = ${log_dir}/ 
session.log
    log4perl.appender.session.layout                   = PatternLayout
    log4perl.appender.session.layout.ConversionPattern = ${log_layout}

with this script:

    #!/usr/bin/perl
    use Log::Log4perl;
    use warnings;
    use strict;
    Log::Log4perl::init('log.conf');

    my $log = Log::Log4perl->get_logger('My.Session');
    $log->debug('session message');

But it logs 'session message' to both main.log and session.log, which  
is somewhat surprising since the main.log section was set for 'INFO'.

Is there a way for the My.Session debug messages to only go to  
session.log, not to main.log?

Thanks!
Jon

[log4perl-devel] Log::Log4perl 1.17 released

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

Before taking off to OSCON in Portland where I'll give a talk on
Log4perl [1], I quickly pushed a mini-release (1.17) to CPAN with 
the following features:

     1.17 (2008/07/19)
         (ms) Fixed test suite to run on Strawberry Perl on Win32.
         (ms) Added 'l4p' as a valid prefix in configuration files (equal
              to 'log4j' and 'log4perl' now).

Stop by if you can make it, there's free T-Shirts :).

-- Mike

Mike Schilli
m...@pe...

[1] http://en.oreilly.com/oscon2008/public/schedule/detail/2470