On Mon, 19 Jan 2009, Karsten Heymann wrote:

> The scripts run on multiple hosts and belong to several sets of
> projects with different logging requirements. To simplify the setup,
> I'm trying to use only one L4p config file for the whole setup. First
> of all, is this common practise?

It's certainly possible to do that, you just need to weigh easy
deployment against maintainability of the config file. This might work for 
two scripts, but if you have 100, it might become unwieldy.

> Now if i want to log script 1's log messages into logfile 1 and script
> 2's into logfile 2, i can easily do so by separating the logs in the
> l4p config file. But I see no way to log the logs of Lib1 to the
> logfile of the script that uses the Lib.

This is probably a case where the config file's maintainability suffers
when you put too much logic into it, just for the sake of having one
file instead of several, but one way of doing what you want would be
using a file name that depends on the calling script:

     # l4p.conf
     filename = sub { basename($0) . ".log" }
     log4perl.category= DEBUG, Logfile
     log4perl.appender.Logfile          = Log::Log4perl::Appender::File
     log4perl.appender.Logfile.filename = ${filename}
     log4perl.appender.Logfile.layout = Log::Log4perl::Layout::PatternLayout
     log4perl.appender.Logfile.layout.ConversionPattern = %d %F{1} %L> %m %n

and if you run a script "test.pl" like

     use strict;
     use File::Basename;
     Log::Log4perl->init( "l4p.conf" );

     DEBUG "foo";
     INFO "bar";

then it will create an logfile "test.pl.log" while if you call the same 
code from a script foobar.pl, it'll start logging in "foobar.pl.log".

> What also is missing is the ability to source additional l4p
> files. This would allow to ship a unchanged master file on all servers
> and include a file with local changes at the end. From what I read
> this isn't possible, unless i did oversee something?

Nobody stops you from reading in all *.conf files located in a
conf directory, lumping them together to a long string and feeding it to
Log4perl via ->init(\$string), but this will most likely be better
supported in the future.

-- Mike

Mike Schilli
m...@perlmeister.com

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel

Reply via email to