mschilli / log4perl Goto Github PK
View Code? Open in Web Editor NEWLog4j Implementation For Perl
Home Page: http://log4perl.com
License: Other
log4perl's Introduction
######################################################################
Log::Log4perl 1.49
######################################################################
NAME
Log::Log4perl - Log4j implementation for Perl
SYNOPSIS
# Easy mode if you like it simple ...
use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init($ERROR);
DEBUG "This doesn't go anywhere";
ERROR "This gets logged";
# ... or standard mode for more features:
Log::Log4perl::init('/etc/log4perl.conf');
--or--
# Check config every 10 secs
Log::Log4perl::init_and_watch('/etc/log4perl.conf',10);
--then--
$logger = Log::Log4perl->get_logger('house.bedrm.desk.topdrwr');
$logger->debug('this is a debug message');
$logger->info('this is an info message');
$logger->warn('etc');
$logger->error('..');
$logger->fatal('..');
#####/etc/log4perl.conf###############################
log4perl.logger.house = WARN, FileAppndr1
log4perl.logger.house.bedroom.desk = DEBUG, FileAppndr1
log4perl.appender.FileAppndr1 = Log::Log4perl::Appender::File
log4perl.appender.FileAppndr1.filename = desk.log
log4perl.appender.FileAppndr1.layout = \
Log::Log4perl::Layout::SimpleLayout
######################################################
ABSTRACT
Log::Log4perl provides a powerful logging API for your application
DESCRIPTION
Log::Log4perl lets you remote-control and fine-tune the logging
behaviour of your system from the outside. It implements the widely
popular (Java-based) Log4j logging package in pure Perl.
For a detailed tutorial on Log::Log4perl usage, please read
<http://www.perl.com/pub/a/2002/09/11/log4perl.html>
Logging beats a debugger if you want to know what's going on in your
code during runtime. However, traditional logging packages are too
static and generate a flood of log messages in your log files that won't
help you.
"Log::Log4perl" is different. It allows you to control the number of
logging messages generated at three different levels:
* At a central location in your system (either in a configuration file
or in the startup code) you specify *which components* (classes,
functions) of your system should generate logs.
* You specify how detailed the logging of these components should be
by specifying logging *levels*.
* You also specify which so-called *appenders* you want to feed your
log messages to ("Print it to the screen and also append it to
/tmp/my.log") and which format ("Write the date first, then the file
name and line number, and then the log message") they should be in.
This is a very powerful and flexible mechanism. You can turn on and off
your logs at any time, specify the level of detail and make that
dependent on the subsystem that's currently executed.
Let me give you an example: You might find out that your system has a
problem in the "MySystem::Helpers::ScanDir" component. Turning on
detailed debugging logs all over the system would generate a flood of
useless log messages and bog your system down beyond recognition. With
"Log::Log4perl", however, you can tell the system: "Continue to log only
severe errors to the log file. Open a second log file, turn on full
debug logs in the "MySystem::Helpers::ScanDir" component and dump all
messages originating from there into the new log file". And all this is
possible by just changing the parameters in a configuration file, which
your system can re-read even while it's running!
How to use it
The "Log::Log4perl" package can be initialized in two ways: Either via
Perl commands or via a "log4j"-style configuration file.
Initialize via a configuration file
This is the easiest way to prepare your system for using
"Log::Log4perl". Use a configuration file like this:
############################################################
# A simple root logger with a Log::Log4perl::Appender::File
# file appender in Perl.
############################################################
log4perl.rootLogger=ERROR, LOGFILE
log4perl.appender.LOGFILE=Log::Log4perl::Appender::File
log4perl.appender.LOGFILE.filename=/var/log/myerrs.log
log4perl.appender.LOGFILE.mode=append
log4perl.appender.LOGFILE.layout=PatternLayout
log4perl.appender.LOGFILE.layout.ConversionPattern=[%r] %F %L %c - %m%n
These lines define your standard logger that's appending severe errors
to "/var/log/myerrs.log", using the format
[millisecs] source-filename line-number class - message newline
Assuming that this configuration file is saved as "log.conf", you need
to read it in the startup section of your code, using the following
commands:
use Log::Log4perl;
Log::Log4perl->init("log.conf");
After that's done *somewhere* in the code, you can retrieve logger
objects *anywhere* in the code. Note that there's no need to carry any
logger references around with your functions and methods. You can get a
logger anytime via a singleton mechanism:
package My::MegaPackage;
use Log::Log4perl;
sub some_method {
my($param) = @_;
my $log = Log::Log4perl->get_logger("My::MegaPackage");
$log->debug("Debug message");
$log->info("Info message");
$log->error("Error message");
...
}
With the configuration file above, "Log::Log4perl" will write "Error
message" to the specified log file, but won't do anything for the
"debug()" and "info()" calls, because the log level has been set to
"ERROR" for all components in the first line of configuration file shown
above.
Why "Log::Log4perl->get_logger" and not "Log::Log4perl->new"? We don't
want to create a new object every time. Usually in OO-Programming, you
create an object once and use the reference to it to call its methods.
However, this requires that you pass around the object to all functions
and the last thing we want is pollute each and every function/method
we're using with a handle to the "Logger":
sub function { # Brrrr!!
my($logger, $some, $other, $parameters) = @_;
}
Instead, if a function/method wants a reference to the logger, it just
calls the Logger's static "get_logger($category)" method to obtain a
reference to the *one and only* possible logger object of a certain
category. That's called a *singleton* if you're a Gamma fan.
How does the logger know which messages it is supposed to log and which
ones to suppress? "Log::Log4perl" works with inheritance: The config
file above didn't specify anything about "My::MegaPackage". And yet,
we've defined a logger of the category "My::MegaPackage". In this case,
"Log::Log4perl" will walk up the namespace hierarchy ("My" and then
we're at the root) to figure out if a log level is defined somewhere. In
the case above, the log level at the root (root *always* defines a log
level, but not necessarily an appender) defines that the log level is
supposed to be "ERROR" -- meaning that *DEBUG* and *INFO* messages are
suppressed. Note that this 'inheritance' is unrelated to Perl's class
inheritance, it is merely related to the logger namespace. By the way,
if you're ever in doubt about what a logger's category is, use
"$logger->category()" to retrieve it.
Log Levels
There are six predefined log levels: "FATAL", "ERROR", "WARN", "INFO",
"DEBUG", and "TRACE" (in descending priority). Your configured logging
level has to at least match the priority of the logging message.
If your configured logging level is "WARN", then messages logged with
"info()", "debug()", and "trace()" will be suppressed. "fatal()",
"error()" and "warn()" will make their way through, because their
priority is higher or equal than the configured setting.
Instead of calling the methods
$logger->trace("..."); # Log a trace message
$logger->debug("..."); # Log a debug message
$logger->info("..."); # Log a info message
$logger->warn("..."); # Log a warn message
$logger->error("..."); # Log a error message
$logger->fatal("..."); # Log a fatal message
you could also call the "log()" method with the appropriate level using
the constants defined in "Log::Log4perl::Level":
use Log::Log4perl::Level;
$logger->log($TRACE, "...");
$logger->log($DEBUG, "...");
$logger->log($INFO, "...");
$logger->log($WARN, "...");
$logger->log($ERROR, "...");
$logger->log($FATAL, "...");
This form is rarely used, but it comes in handy if you want to log at
different levels depending on an exit code of a function:
$logger->log( $exit_level{ $rc }, "...");
As for needing more logging levels than these predefined ones: It's
usually best to steer your logging behaviour via the category mechanism
instead.
If you need to find out if the currently configured logging level would
allow a logger's logging statement to go through, use the logger's
"is_*level*()" methods:
$logger->is_trace() # True if trace messages would go through
$logger->is_debug() # True if debug messages would go through
$logger->is_info() # True if info messages would go through
$logger->is_warn() # True if warn messages would go through
$logger->is_error() # True if error messages would go through
$logger->is_fatal() # True if fatal messages would go through
Example: "$logger->is_warn()" returns true if the logger's current
level, as derived from either the logger's category (or, in absence of
that, one of the logger's parent's level setting) is $WARN, $ERROR or
$FATAL.
Also available are a series of more Java-esque functions which return
the same values. These are of the format "is*Level*Enabled()", so
"$logger->isDebugEnabled()" is synonymous to "$logger->is_debug()".
These level checking functions will come in handy later, when we want to
block unnecessary expensive parameter construction in case the logging
level is too low to log the statement anyway, like in:
if($logger->is_error()) {
$logger->error("Erroneous array: @super_long_array");
}
If we had just written
$logger->error("Erroneous array: @super_long_array");
then Perl would have interpolated @super_long_array into the string via
an expensive operation only to figure out shortly after that the string
can be ignored entirely because the configured logging level is lower
than $ERROR.
The to-be-logged message passed to all of the functions described above
can consist of an arbitrary number of arguments, which the logging
functions just chain together to a single string. Therefore
$logger->debug("Hello ", "World", "!"); # and
$logger->debug("Hello World!");
are identical.
Note that even if one of the methods above returns true, it doesn't
necessarily mean that the message will actually get logged. What
is_debug() checks is that the logger used is configured to let a message
of the given priority (DEBUG) through. But after this check, Log4perl
will eventually apply custom filters and forward the message to one or
more appenders. None of this gets checked by is_xxx(), for the simple
reason that it's impossible to know what a custom filter does with a
message without having the actual message or what an appender does to a
message without actually having it log it.
Log and die or warn
Often, when you croak / carp / warn / die, you want to log those
messages. Rather than doing the following:
$logger->fatal($err) && die($err);
you can use the following:
$logger->logdie($err);
And if instead of using
warn($message);
$logger->warn($message);
to both issue a warning via Perl's warn() mechanism and make sure you
have the same message in the log file as well, use:
$logger->logwarn($message);
Since there is an ERROR level between WARN and FATAL, there are two
additional helper functions in case you'd like to use ERROR for either
warn() or die():
$logger->error_warn();
$logger->error_die();
Finally, there's the Carp functions that, in addition to logging, also
pass the stringified message to their companions in the Carp package:
$logger->logcarp(); # warn w/ 1-level stack trace
$logger->logcluck(); # warn w/ full stack trace
$logger->logcroak(); # die w/ 1-level stack trace
$logger->logconfess(); # die w/ full stack trace
Appenders
If you don't define any appenders, nothing will happen. Appenders will
be triggered whenever the configured logging level requires a message to
be logged and not suppressed.
"Log::Log4perl" doesn't define any appenders by default, not even the
root logger has one.
"Log::Log4perl" already comes with a standard set of appenders:
Log::Log4perl::Appender::Screen
Log::Log4perl::Appender::ScreenColoredLevels
Log::Log4perl::Appender::File
Log::Log4perl::Appender::Socket
Log::Log4perl::Appender::DBI
Log::Log4perl::Appender::Synchronized
Log::Log4perl::Appender::RRDs
to log to the screen, to files and to databases.
On CPAN, you can find additional appenders like
Log::Log4perl::Layout::XMLLayout
by Guido Carls <[email protected]>. It allows for hooking up Log::Log4perl
with the graphical Log Analyzer Chainsaw (see "Can I use Log::Log4perl
with log4j's Chainsaw?" in Log::Log4perl::FAQ).
Additional Appenders via Log::Dispatch
"Log::Log4perl" also supports *Dave Rolskys* excellent "Log::Dispatch"
framework which implements a wide variety of different appenders.
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::FileRotate (by Mark Pfeiffer)
Log::Dispatch::Handle
Log::Dispatch::Screen
Log::Dispatch::Syslog
Log::Dispatch::Tk (by Dominique Dumont)
Please note that in order to use any of these additional appenders, you
have to fetch Log::Dispatch from CPAN and install it. Also the
particular appender you're using might require installing the particular
module.
For additional information on appenders, please check the
Log::Log4perl::Appender manual page.
Appender Example
Now let's assume that we want to log "info()" or higher prioritized
messages in the "Foo::Bar" category to both STDOUT and to a log file,
say "test.log". In the initialization section of your system, just
define two appenders using the readily available
"Log::Log4perl::Appender::File" and "Log::Log4perl::Appender::Screen"
modules:
use Log::Log4perl;
# Configuration in a string ...
my $conf = q(
log4perl.category.Foo.Bar = INFO, Logfile, Screen
log4perl.appender.Logfile = Log::Log4perl::Appender::File
log4perl.appender.Logfile.filename = test.log
log4perl.appender.Logfile.layout = Log::Log4perl::Layout::PatternLayout
log4perl.appender.Logfile.layout.ConversionPattern = [%r] %F %L %m%n
log4perl.appender.Screen = Log::Log4perl::Appender::Screen
log4perl.appender.Screen.stderr = 0
log4perl.appender.Screen.layout = Log::Log4perl::Layout::SimpleLayout
);
# ... passed as a reference to init()
Log::Log4perl::init( \$conf );
Once the initialization shown above has happened once, typically in the
startup code of your system, just use the defined logger anywhere in
your system:
##########################
# ... in some function ...
##########################
my $log = Log::Log4perl::get_logger("Foo::Bar");
# Logs both to STDOUT and to the file test.log
$log->info("Important Info!");
The "layout" settings specified in the configuration section define the
format in which the message is going to be logged by the specified
appender. The format shown for the file appender is logging not only the
message but also the number of milliseconds since the program has
started (%r), the name of the file the call to the logger has happened
and the line number there (%F and %L), the message itself (%m) and a
OS-specific newline character (%n):
[187] ./myscript.pl 27 Important Info!
The screen appender above, on the other hand, uses a "SimpleLayout",
which logs the debug level, a hyphen (-) and the log message:
INFO - Important Info!
For more detailed info on layout formats, see "Log Layouts".
In the configuration sample above, we chose to define a *category*
logger ("Foo::Bar"). This will cause only messages originating from this
specific category logger to be logged in the defined format and
locations.
Logging newlines
There's some controversy between different logging systems as to when
and where newlines are supposed to be added to logged messages.
The Log4perl way is that a logging statement *should not* contain a
newline:
$logger->info("Some message");
$logger->info("Another message");
If this is supposed to end up in a log file like
Some message
Another message
then an appropriate appender layout like "%m%n" will take care of adding
a newline at the end of each message to make sure every message is
printed on its own line.
Other logging systems, Log::Dispatch in particular, recommend adding the
newline to the log statement. This doesn't work well, however, if you,
say, replace your file appender by a database appender, and all of a
sudden those newlines scattered around the code don't make sense
anymore.
Assigning matching layouts to different appenders and leaving newlines
out of the code solves this problem. If you inherited code that has
logging statements with newlines and want to make it work with Log4perl,
read the Log::Log4perl::Layout::PatternLayout documentation on how to
accomplish that.
Configuration files
As shown above, you can define "Log::Log4perl" loggers both from within
your Perl code or from configuration files. The latter have the
unbeatable advantage that you can modify your system's logging behaviour
without interfering with the code at all. So even if your code is being
run by somebody who's totally oblivious to Perl, they still can adapt
the module's logging behaviour to their needs.
"Log::Log4perl" has been designed to understand "Log4j" configuration
files -- as used by the original Java implementation. Instead of
reiterating the format description in [2], let me just list three
examples (also derived from [2]), which should also illustrate how it
works:
log4j.rootLogger=DEBUG, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r %-5p %c %x - %m%n
This enables messages of priority "DEBUG" or higher in the root
hierarchy and has the system write them to the console.
"ConsoleAppender" is a Java appender, but "Log::Log4perl" jumps through
a significant number of hoops internally to map these to their
corresponding Perl classes, "Log::Log4perl::Appender::Screen" in this
case.
Second example:
log4perl.rootLogger=DEBUG, A1
log4perl.appender.A1=Log::Log4perl::Appender::Screen
log4perl.appender.A1.layout=PatternLayout
log4perl.appender.A1.layout.ConversionPattern=%d %-5p %c - %m%n
log4perl.logger.com.foo=WARN
This defines two loggers: The root logger and the "com.foo" logger. The
root logger is easily triggered by debug-messages, but the "com.foo"
logger makes sure that messages issued within the "Com::Foo" component
and below are only forwarded to the appender if they're of priority
*warning* or higher.
Note that the "com.foo" logger doesn't define an appender. Therefore, it
will just propagate the message up the hierarchy until the root logger
picks it up and forwards it to the one and only appender of the root
category, using the format defined for it.
Third example:
log4j.rootLogger=DEBUG, stdout, R
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%5p (%F:%L) - %m%n
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=example.log
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %c - %m%n
The root logger defines two appenders here: "stdout", which uses
"org.apache.log4j.ConsoleAppender" (ultimately mapped by "Log::Log4perl"
to Log::Log4perl::Appender::Screen) to write to the screen. And "R", a
"org.apache.log4j.RollingFileAppender" (mapped by "Log::Log4perl" to
Log::Dispatch::FileRotate with the "File" attribute specifying the log
file.
See Log::Log4perl::Config for more examples and syntax explanations.
Log Layouts
If the logging engine passes a message to an appender, because it thinks
it should be logged, the appender doesn't just write it out haphazardly.
There's ways to tell the appender how to format the message and add all
sorts of interesting data to it: The date and time when the event
happened, the file, the line number, the debug level of the logger and
others.
There's currently two layouts defined in "Log::Log4perl":
"Log::Log4perl::Layout::SimpleLayout" and
"Log::Log4perl::Layout::PatternLayout":
"Log::Log4perl::SimpleLayout"
formats a message in a simple way and just prepends it by the debug
level and a hyphen: ""$level - $message", for example "FATAL - Can't
open password file".
"Log::Log4perl::Layout::PatternLayout"
on the other hand is very powerful and allows for a very flexible
format in "printf"-style. The format string can contain a number of
placeholders which will be replaced by the logging engine when it's
time to log the message:
%c Category of the logging event.
%C Fully qualified package (or class) name of the caller
%d Current date in yyyy/MM/dd HH:mm:ss format
%F File where the logging event occurred
%H Hostname (if Sys::Hostname is available)
%l Fully qualified name of the calling method followed by the
callers source the file name and line number between
parentheses.
%L Line number within the file where the log statement was issued
%m The message to be logged
%m{chomp} The message to be logged, stripped off a trailing newline
%M Method or function where the logging request was issued
%n Newline (OS-independent)
%p Priority of the logging event (AKA log level)
%P pid of the current process
%r Number of milliseconds elapsed from program start to logging
event
%R Number of milliseconds elapsed from last logging event to
current logging event
%T A stack trace of functions called
%x The topmost NDC (see below)
%X{key} The entry 'key' of the MDC (see below)
%% A literal percent (%) sign
NDC and MDC are explained in "Nested Diagnostic Context (NDC)" and
"Mapped Diagnostic Context (MDC)".
Also, %d can be fine-tuned to display only certain characteristics
of a date, according to the SimpleDateFormat in the Java World
(<https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/
text/SimpleDateFormat.html>)
In this way, %d{HH:mm} displays only hours and minutes of the
current date, while %d{yy, EEEE} displays a two-digit year, followed
by a spelled-out day (like "Wednesday").
Similar options are available for shrinking the displayed category
or limit file/path components, %F{1} only displays the source file
*name* without any path components while %F logs the full path.
%c{2} only logs the last two components of the current category,
"Foo::Bar::Baz" becomes "Bar::Baz" and saves space.
If those placeholders aren't enough, then you can define your own
right in the config file like this:
log4perl.PatternLayout.cspec.U = sub { return "UID $<" }
See Log::Log4perl::Layout::PatternLayout for further details on
customized specifiers.
Please note that the subroutines you're defining in this way are
going to be run in the "main" namespace, so be sure to fully qualify
functions and variables if they're located in different packages.
SECURITY NOTE: this feature means arbitrary perl code can be
embedded in the config file. In the rare case where the people who
have access to your config file are different from the people who
write your code and shouldn't have execute rights, you might want to
call
Log::Log4perl::Config->allow_code(0);
before you call init(). Alternatively you can supply a restricted
set of Perl opcodes that can be embedded in the config file as
described in "Restricting what Opcodes can be in a Perl Hook".
All placeholders are quantifiable, just like in *printf*. Following this
tradition, "%-20c" will reserve 20 chars for the category and
left-justify it.
For more details on logging and how to use the flexible and the simple
format, check out the original "log4j" website under
SimpleLayout
<http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/SimpleLayo
ut.html> and PatternLayout
<http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLay
out.html>
Penalties
Logging comes with a price tag. "Log::Log4perl" has been optimized to
allow for maximum performance, both with logging enabled and disabled.
But you need to be aware that there's a small hit every time your code
encounters a log statement -- no matter if logging is enabled or not.
"Log::Log4perl" has been designed to keep this so low that it will be
unnoticeable to most applications.
Here's a couple of tricks which help "Log::Log4perl" to avoid
unnecessary delays:
You can save serious time if you're logging something like
# Expensive in non-debug mode!
for (@super_long_array) {
$logger->debug("Element: $_");
}
and @super_long_array is fairly big, so looping through it is pretty
expensive. Only you, the programmer, knows that going through that "for"
loop can be skipped entirely if the current logging level for the actual
component is higher than "debug". In this case, use this instead:
# Cheap in non-debug mode!
if($logger->is_debug()) {
for (@super_long_array) {
$logger->debug("Element: $_");
}
}
If you're afraid that generating the parameters to the logging function
is fairly expensive, use closures:
# Passed as subroutine ref
use Data::Dumper;
$logger->debug(sub { Dumper($data) } );
This won't unravel $data via Dumper() unless it's actually needed
because it's logged.
Also, Log::Log4perl lets you specify arguments to logger functions in
*message output filter syntax*:
$logger->debug("Structure: ",
{ filter => \&Dumper,
value => $someref });
In this way, shortly before Log::Log4perl sending the message out to any
appenders, it will be searching all arguments for hash references and
treat them in a special way:
It will invoke the function given as a reference with the "filter" key
("Data::Dumper::Dumper()") and pass it the value that came with the key
named "value" as an argument. The anonymous hash in the call above will
be replaced by the return value of the filter function.
Categories
Categories are also called "Loggers" in Log4perl, both refer to the same
thing and these terms are used interchangeably. "Log::Log4perl" uses
*categories* to determine if a log statement in a component should be
executed or suppressed at the current logging level. Most of the time,
these categories are just the classes the log statements are located in:
package Candy::Twix;
sub new {
my $logger = Log::Log4perl->get_logger("Candy::Twix");
$logger->debug("Creating a new Twix bar");
bless {}, shift;
}
# ...
package Candy::Snickers;
sub new {
my $logger = Log::Log4perl->get_logger("Candy.Snickers");
$logger->debug("Creating a new Snickers bar");
bless {}, shift;
}
# ...
package main;
Log::Log4perl->init("mylogdefs.conf");
# => "LOG> Creating a new Snickers bar"
my $first = Candy::Snickers->new();
# => "LOG> Creating a new Twix bar"
my $second = Candy::Twix->new();
Note that you can separate your category hierarchy levels using either
dots like in Java (.) or double-colons (::) like in Perl. Both notations
are equivalent and are handled the same way internally.
However, categories are just there to make use of inheritance: if you
invoke a logger in a sub-category, it will bubble up the hierarchy and
call the appropriate appenders. Internally, categories are not related
to the class hierarchy of the program at all -- they're purely virtual.
You can use arbitrary categories -- for example in the following
program, which isn't oo-style, but procedural:
sub print_portfolio {
my $log = Log::Log4perl->get_logger("user.portfolio");
$log->debug("Quotes requested: @_");
for(@_) {
print "$_: ", get_quote($_), "\n";
}
}
sub get_quote {
my $log = Log::Log4perl->get_logger("internet.quotesystem");
$log->debug("Fetching quote: $_[0]");
return yahoo_quote($_[0]);
}
The logger in first function, "print_portfolio", is assigned the
(virtual) "user.portfolio" category. Depending on the "Log4perl"
configuration, this will either call a "user.portfolio" appender, a
"user" appender, or an appender assigned to root -- without
"user.portfolio" having any relevance to the class system used in the
program. The logger in the second function adheres to the
"internet.quotesystem" category -- again, maybe because it's bundled
with other Internet functions, but not because there would be a class of
this name somewhere.
However, be careful, don't go overboard: if you're developing a system
in object-oriented style, using the class hierarchy is usually your best
choice. Think about the people taking over your code one day: The class
hierarchy is probably what they know right up front, so it's easy for
them to tune the logging to their needs.
Turn off a component
"Log4perl" doesn't only allow you to selectively switch *on* a category
of log messages, you can also use the mechanism to selectively *disable*
logging in certain components whereas logging is kept turned on in
higher-level categories. This mechanism comes in handy if you find that
while bumping up the logging level of a high-level (i. e. close to root)
category, that one component logs more than it should,
Here's how it works:
############################################################
# Turn off logging in a lower-level category while keeping
# it active in higher-level categories.
############################################################
log4perl.rootLogger=DEBUG, LOGFILE
log4perl.logger.deep.down.the.hierarchy = ERROR, LOGFILE
# ... Define appenders ...
This way, log messages issued from within "Deep::Down::The::Hierarchy"
and below will be logged only if they're "ERROR" or worse, while in all
other system components even "DEBUG" messages will be logged.
Return Values
All logging methods return values indicating if their message actually
reached one or more appenders. If the message has been suppressed
because of level constraints, "undef" is returned.
For example,
my $ret = $logger->info("Message");
will return "undef" if the system debug level for the current category
is not "INFO" or more permissive. If Log::Log4perl forwarded the message
to one or more appenders, the number of appenders is returned.
If appenders decide to veto on the message with an appender threshold,
the log method's return value will have them excluded. This means that
if you've got one appender holding an appender threshold and you're
logging a message which passes the system's log level hurdle but not the
appender threshold, 0 will be returned by the log function.
The bottom line is: Logging functions will return a *true* value if the
message made it through to one or more appenders and a *false* value if
it didn't. This allows for constructs like
$logger->fatal("@_") or print STDERR "@_\n";
which will ensure that the fatal message isn't lost if the current level
is lower than FATAL or printed twice if the level is acceptable but an
appender already points to STDERR.
Pitfalls with Categories
Be careful with just blindly reusing the system's packages as
categories. If you do, you'll get into trouble with inherited methods.
Imagine the following class setup:
use Log::Log4perl;
###########################################
package Bar;
###########################################
sub new {
my($class) = @_;
my $logger = Log::Log4perl::get_logger(__PACKAGE__);
$logger->debug("Creating instance");
bless {}, $class;
}
###########################################
package Bar::Twix;
###########################################
our @ISA = qw(Bar);
###########################################
package main;
###########################################
Log::Log4perl->init(\ qq{
log4perl.category.Bar.Twix = DEBUG, Screen
log4perl.appender.Screen = Log::Log4perl::Appender::Screen
log4perl.appender.Screen.layout = SimpleLayout
});
my $bar = Bar::Twix->new();
"Bar::Twix" just inherits everything from "Bar", including the
constructor "new()". Contrary to what you might be thinking at first,
this won't log anything. Reason for this is the "get_logger()" call in
package "Bar", which will always get a logger of the "Bar" category,
even if we call "new()" via the "Bar::Twix" package, which will make
perl go up the inheritance tree to actually execute "Bar::new()". Since
we've only defined logging behaviour for "Bar::Twix" in the
configuration file, nothing will happen.
This can be fixed by changing the "get_logger()" method in "Bar::new()"
to obtain a logger of the category matching the *actual* class of the
object, like in
# ... in Bar::new() ...
my $logger = Log::Log4perl::get_logger( $class );
In a method other than the constructor, the class name of the actual
object can be obtained by calling "ref()" on the object reference, so
package BaseClass;
use Log::Log4perl qw( get_logger );
sub new {
bless {}, shift;
}
sub method {
my( $self ) = @_;
get_logger( ref $self )->debug( "message" );
}
package SubClass;
our @ISA = qw(BaseClass);
is the recommended pattern to make sure that
my $sub = SubClass->new();
$sub->meth();
starts logging if the "SubClass" category (and not the "BaseClass"
category has logging enabled at the DEBUG level.
Initialize once and only once
It's important to realize that Log::Log4perl gets initialized once and
only once, typically at the start of a program or system. Calling
"init()" more than once will cause it to clobber the existing
configuration and *replace* it by the new one.
If you're in a traditional CGI environment, where every request is
handled by a new process, calling "init()" every time is fine. In
persistent environments like "mod_perl", however, Log::Log4perl should
be initialized either at system startup time (Apache offers startup
handlers for that) or via
# Init or skip if already done
Log::Log4perl->init_once($conf_file);
"init_once()" is identical to "init()", just with the exception that it
will leave a potentially existing configuration alone and will only call
"init()" if Log::Log4perl hasn't been initialized yet.
If you're just curious if Log::Log4perl has been initialized yet, the
check
if(Log::Log4perl->initialized()) {
# Yes, Log::Log4perl has already been initialized
} else {
# No, not initialized yet ...
}
can be used.
If you're afraid that the components of your system are stepping on each
other's toes or if you are thinking that different components should
initialize Log::Log4perl separately, try to consolidate your system to
use a centralized Log4perl configuration file and use Log4perl's
*categories* to separate your components.
Custom Filters
Log4perl allows the use of customized filters in its appenders to
control the output of messages. These filters might grep for certain
text chunks in a message, verify that its priority matches or exceeds a
certain level or that this is the 10th time the same message has been
submitted -- and come to a log/no log decision based upon these
circumstantial facts.
Check out Log::Log4perl::Filter for detailed instructions on how to use
them.
Performance
The performance of Log::Log4perl calls obviously depends on a lot of
things. But to give you a general idea, here's some rough numbers:
On a Pentium 4 Linux box at 2.4 GHz, you'll get through
* 500,000 suppressed log statements per second
* 30,000 logged messages per second (using an in-memory appender)
* init_and_watch delay mode: 300,000 suppressed, 30,000 logged.
init_and_watch signal mode: 450,000 suppressed, 30,000 logged.
Numbers depend on the complexity of the Log::Log4perl configuration. For
a more detailed benchmark test, check the "docs/benchmark.results.txt"
document in the Log::Log4perl distribution.
Cool Tricks
Here's a collection of useful tricks for the advanced "Log::Log4perl"
user. For more, check the FAQ, either in the distribution
(Log::Log4perl::FAQ) or on <http://log4perl.sourceforge.net>.
Shortcuts
When getting an instance of a logger, instead of saying
use Log::Log4perl;
my $logger = Log::Log4perl->get_logger();
it's often more convenient to import the "get_logger" method from
"Log::Log4perl" into the current namespace:
use Log::Log4perl qw(get_logger);
my $logger = get_logger();
Please note this difference: To obtain the root logger, please use
"get_logger("")", call it without parameters ("get_logger()"), you'll
get the logger of a category named after the current package.
"get_logger()" is equivalent to "get_logger(__PACKAGE__)".
Alternative initialization
Instead of having "init()" read in a configuration file by specifying a
file name or passing it a reference to an open filehandle
("Log::Log4perl->init( \*FILE )"), you can also pass in a reference to a
string, containing the content of the file:
Log::Log4perl->init( \$config_text );
Also, if you've got the "name=value" pairs of the configuration in a
hash, you can just as well initialize "Log::Log4perl" with a reference
to it:
my %key_value_pairs = (
"log4perl.rootLogger" => "ERROR, LOGFILE",
"log4perl.appender.LOGFILE" => "Log::Log4perl::Appender::File",
...
);
Log::Log4perl->init( \%key_value_pairs );
Or also you can use a URL, see below:
Using LWP to parse URLs
(This section borrowed from XML::DOM::Parser by T.J. Mather).
The init() function now also supports URLs, e.g.
*http://www.erols.com/enno/xsa.xml*. It uses LWP to download the file
and then calls parse() on the resulting string. By default it will use a
LWP::UserAgent that is created as follows:
use LWP::UserAgent;
$LWP_USER_AGENT = LWP::UserAgent->new;
$LWP_USER_AGENT->env_proxy;
Note that env_proxy reads proxy settings from environment variables,
which is what Log4perl needs to do to get through our firewall. If you
want to use a different LWP::UserAgent, you can set it with
Log::Log4perl::Config::set_LWP_UserAgent($my_agent);
Currently, LWP is used when the filename (passed to parsefile) starts
with one of the following URL schemes: http, https, ftp, wais, gopher,
or file (followed by a colon.)
Don't use this feature with init_and_watch().
Automatic reloading of changed configuration files
Instead of just statically initializing Log::Log4perl via
Log::Log4perl->init($conf_file);
there's a way to have Log::Log4perl periodically check for changes in
the configuration and reload it if necessary:
Log::Log4perl->init_and_watch($conf_file, $delay);
In this mode, Log::Log4perl will examine the configuration file
$conf_file every $delay seconds for changes via the file's last
modification timestamp. If the file has been updated, it will be
reloaded and replace the current Log::Log4perl configuration.
The way this works is that with every logger function called (debug(),
is_debug(), etc.), Log::Log4perl will check if the delay interval has
expired. If so, it will run a -M file check on the configuration file.
If its timestamp has been modified, the current configuration will be
dumped and new content of the file will be loaded.
This convenience comes at a price, though: Calling time() with every
logging function call, especially the ones that are "suppressed" (!),
will slow down these Log4perl calls by about 40%.
To alleviate this performance hit a bit, "init_and_watch()" can be
configured to listen for a Unix signal to reload the configuration
instead:
Log::Log4perl->init_and_watch($conf_file, 'HUP');
This will set up a signal handler for SIGHUP and reload the
configuration if the application receives this signal, e.g. via the
"kill" command:
kill -HUP pid
where "pid" is the process ID of the application. This will bring you
back to about 85% of Log::Log4perl's normal execution speed for
suppressed statements. For details, check out "Performance". For more
info on the signal handler, look for "SIGNAL MODE" in
Log::Log4perl::Config::Watch.
If you have a somewhat long delay set between physical config file
checks or don't want to use the signal associated with the config file
watcher, you can trigger a configuration reload at the next possible
time by calling "Log::Log4perl::Config->watcher->force_next_check()".
One thing to watch out for: If the configuration file contains a syntax
or other fatal error, a running application will stop with "die" if this
damaged configuration will be loaded during runtime, triggered either by
a signal or if the delay period expired and the change is detected. This
behaviour might change in the future.
To allow the application to intercept and control a configuration reload
in init_and_watch mode, a callback can be specified:
Log::Log4perl->init_and_watch($conf_file, 10, {
preinit_callback => \&callback });
If Log4perl determines that the configuration needs to be reloaded, it
will call the "preinit_callback" function without parameters. If the
callback returns a true value, Log4perl will proceed and reload the
configuration. If the callback returns a false value, Log4perl will keep
the old configuration and skip reloading it until the next time around.
Inside the callback, an application can run all kinds of checks,
including accessing the configuration file, which is available via
"Log::Log4perl::Config->watcher()->file()".
Variable Substitution
To avoid having to retype the same expressions over and over again,
Log::Log4perl's configuration files support simple variable
substitution. New variables are defined simply by adding
varname = value
lines to the configuration file before using
${varname}
afterwards to recall the assigned values. Here's an example:
layout_class = Log::Log4perl::Layout::PatternLayout
layout_pattern = %d %F{1} %L> %m %n
log4perl.category.Bar.Twix = WARN, Logfile, Screen
log4perl.appender.Logfile = Log::Log4perl::Appender::File
log4perl.appender.Logfile.filename = test.log
log4perl.appender.Logfile.layout = ${layout_class}
log4perl.appender.Logfile.layout.ConversionPattern = ${layout_pattern}
log4perl.appender.Screen = Log::Log4perl::Appender::Screen
log4perl.appender.Screen.layout = ${layout_class}
log4perl.appender.Screen.layout.ConversionPattern = ${layout_pattern}
This is a convenient way to define two appenders with the same layout
without having to retype the pattern definitions.
Variable substitution via "${varname}" will first try to find an
explicitly defined variable. If that fails, it will check your shell's
environment for a variable of that name. If that also fails, the program
will "die()".
Perl Hooks in the Configuration File
If some of the values used in the Log4perl configuration file need to be
dynamically modified by the program, use Perl hooks:
log4perl.appender.File.filename = \
sub { return getLogfileName(); }
Each value starting with the string "sub {..." is interpreted as Perl
code to be executed at the time the application parses the configuration
via "Log::Log4perl::init()". The return value of the subroutine is used
by Log::Log4perl as the configuration value.
The Perl code is executed in the "main" package, functions in other
packages have to be called in fully-qualified notation.
Here's another example, utilizing an environment variable as a username
for a DBI appender:
log4perl.appender.DB.username = \
sub { $ENV{DB_USER_NAME } }
However, please note the difference between these code snippets and
those used for user-defined conversion specifiers as discussed in
Log::Log4perl::Layout::PatternLayout: While the snippets above are run
*once* when "Log::Log4perl::init()" is called, the conversion specifier
snippets are executed *each time* a message is rendered according to the
PatternLayout.
SECURITY NOTE: this feature means arbitrary perl code can be embedded in
the config file. In the rare case where the people who have access to
your config file are different from the people who write your code and
shouldn't have execute rights, you might want to set
Log::Log4perl::Config->allow_code(0);
before you call init(). Alternatively you can supply a restricted set of
Perl opcodes that can be embedded in the config file as described in
"Restricting what Opcodes can be in a Perl Hook".
Restricting what Opcodes can be in a Perl Hook
The value you pass to Log::Log4perl::Config->allow_code() determines
whether the code that is embedded in the config file is eval'd
unrestricted, or eval'd in a Safe compartment. By default, a value of
'1' is assumed, which does a normal 'eval' without any restrictions. A
value of '0' however prevents any embedded code from being evaluated.
If you would like fine-grained control over what can and cannot be
included in embedded code, then please utilize the following methods:
Log::Log4perl::Config->allow_code( $allow );
Log::Log4perl::Config->allowed_code_ops($op1, $op2, ... );
Log::Log4perl::Config->vars_shared_with_safe_compartment( [ \%vars | $package, \@vars ] );
Log::Log4perl::Config->allowed_code_ops_convenience_map( [ \%map | $name, \@mask ] );
Log::Log4perl::Config->allowed_code_ops() takes a list of opcode masks
that are allowed to run in the compartment. The opcode masks must be
specified as described in Opcode:
Log::Log4perl::Config->allowed_code_ops(':subprocess');
This example would allow Perl operations like backticks, system, fork,
and waitpid to be executed in the compartment. Of course, you probably
don't want to use this mask -- it would allow exactly what the Safe
compartment is designed to prevent.
Log::Log4perl::Config->vars_shared_with_safe_compartment() takes the
symbols which should be exported into the Safe compartment before the
code is evaluated. The keys of this hash are the package names that the
symbols are in, and the values are array references to the literal
symbol names. For convenience, the default settings export the '%ENV'
hash from the 'main' package into the compartment:
Log::Log4perl::Config->vars_shared_with_safe_compartment(
main => [ '%ENV' ],
);
Log::Log4perl::Config->allowed_code_ops_convenience_map() is an accessor
method to a map of convenience names to opcode masks. At present, the
following convenience names are defined:
safe = [ ':browse' ]
restrictive = [ ':default' ]
For convenience, if Log::Log4perl::Config->allow_code() is called with a
value which is a key of the map previously defined with
Log::Log4perl::Config->allowed_code_ops_convenience_map(), then the
allowed opcodes are set according to the value defined in the map. If
this is confusing, consider the following:
use Log::Log4perl;
my $config = <<'END';
log4perl.logger = INFO, Main
log4perl.appender.Main = Log::Log4perl::Appender::File
log4perl.appender.Main.filename = \
sub { "example" . getpwuid($<) . ".log" }
log4perl.appender.Main.layout = Log::Log4perl::Layout::SimpleLayout
END
$Log::Log4perl::Config->allow_code('restrictive');
Log::Log4perl->init( \$config ); # will fail
$Log::Log4perl::Config->allow_code('safe');
Log::Log4perl->init( \$config ); # will succeed
The reason that the first call to ->init() fails is because the
'restrictive' name maps to an opcode mask of ':default'. getpwuid() is
not part of ':default', so ->init() fails. The 'safe' name maps to an
opcode mask of ':browse', which allows getpwuid() to run, so ->init()
succeeds.
allowed_code_ops_convenience_map() can be invoked in several ways:
allowed_code_ops_convenience_map()
Returns the entire convenience name map as a hash reference in
scalar context or a hash in list context.
allowed_code_ops_convenience_map( \%map )
Replaces the entire convenience name map with the supplied hash
reference.
allowed_code_ops_convenience_map( $name )
Returns the opcode mask for the given convenience name, or undef if
no such name is defined in the map.
allowed_code_ops_convenience_map( $name, \@mask )
Adds the given name/mask pair to the convenience name map. If the
name already exists in the map, it's value is replaced with the new
mask.
as can vars_shared_with_safe_compartment():
vars_shared_with_safe_compartment()
Return the entire map of packages to variables as a hash reference
in scalar context or a hash in list context.
vars_shared_with_safe_compartment( \%packages )
Replaces the entire map of packages to variables with the supplied
hash reference.
vars_shared_with_safe_compartment( $package )
Returns the arrayref of variables to be shared for a specific
package.
vars_shared_with_safe_compartment( $package, \@vars )
Adds the given package / varlist pair to the map. If the package
already exists in the map, it's value is replaced with the new
arrayref of variable names.
For more information on opcodes and Safe Compartments, see Opcode and
Safe.
Changing the Log Level on a Logger
Log4perl provides some internal functions for quickly adjusting the log
level from within a running Perl program.
Now, some people might argue that you should adjust your levels from
within an external Log4perl configuration file, but Log4perl is
everybody's darling.
Typically run-time adjusting of levels is done at the beginning, or in
response to some external input (like a "more logging" runtime command
for diagnostics).
You get the log level from a logger object with:
$current_level = $logger->level();
and you may set it with the same method, provided you first imported the
log level constants, with:
use Log::Log4perl::Level;
Then you can set the level on a logger to one of the constants,
$logger->level($ERROR); # one of DEBUG, INFO, WARN, ERROR, FATAL
To increase the level of logging currently being done, use:
$logger->more_logging($delta);
and to decrease it, use:
$logger->less_logging($delta);
$delta must be a positive integer (for now, we may fix this later ;).
There are also two equivalent functions:
$logger->inc_level($delta);
$logger->dec_level($delta);
They're included to allow you a choice in readability. Some folks will
prefer more/less_logging, as they're fairly clear in what they do, and
allow the programmer not to worry too much about what a Level is and
whether a higher level means more or less logging. However, other folks
who do understand and have lots of code that deals with levels will
probably prefer the inc_level() and dec_level() methods as they want to
work with Levels and not worry about whether that means more or less
logging. :)
That diatribe aside, typically you'll use more_logging() or inc_level()
as such:
my $v = 0; # default level of verbosity.
GetOptions("v+" => \$v, ...);
if( $v ) {
$logger->more_logging($v); # inc logging level once for each -v in ARGV
}
Custom Log Levels
First off, let me tell you that creating custom levels is heavily
deprecated by the log4j folks. Indeed, instead of creating additional
levels on top of the predefined DEBUG, INFO, WARN, ERROR and FATAL, you
should use categories to control the amount of logging smartly, based on
the location of the log-active code in the system.
Nevertheless, Log4perl provides a nice way to create custom levels via
the create_custom_level() routine function. However, this must be done
before the first call to init() or get_logger(). Say you want to create
a NOTIFY logging level that comes after WARN (and thus before INFO).
You'd do such as follows:
use Log::Log4perl;
use Log::Log4perl::Level;
Log::Log4perl::Logger::create_custom_level("NOTIFY", "WARN");
And that's it! "create_custom_level()" creates the following functions /
variables for level FOO:
$FOO_INT # integer to use in L4p::Level::to_level()
$logger->foo() # log function to log if level = FOO
$logger->is_foo() # true if current level is >= FOO
These levels can also be used in your config file, but note that your
config file probably won't be portable to another log4perl or log4j
environment unless you've made the appropriate mods there too.
Since Log4perl translates log levels to syslog and Log::Dispatch if
their appenders are used, you may add mappings for custom levels as
well:
Log::Log4perl::Level::add_priority("NOTIFY", "WARN",
$syslog_equiv, $log_dispatch_level);
For example, if your new custom "NOTIFY" level is supposed to map to
syslog level 2 ("LOG_NOTICE") and Log::Dispatch level 2 ("notice"), use:
Log::Log4perl::Logger::create_custom_level("NOTIFY", "WARN", 2, 2);
System-wide log levels
As a fairly drastic measure to decrease (or increase) the logging level
all over the system with one single configuration option, use the
"threshold" keyword in the Log4perl configuration file:
log4perl.threshold = ERROR
sets the system-wide (or hierarchy-wide according to the log4j
documentation) to ERROR and therefore deprives every logger in the
system of the right to log lower-prio messages.
Easy Mode
For teaching purposes (especially for [1]), I've put ":easy" mode into
"Log::Log4perl", which just initializes a single root logger with a
defined priority and a screen appender including some nice standard
layout:
### Initialization Section
use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init($ERROR); # Set priority of root logger to ERROR
### Application Section
my $logger = get_logger();
$logger->fatal("This will get logged.");
$logger->debug("This won't.");
This will dump something like
2002/08/04 11:43:09 ERROR> script.pl:16 main::function - This will get logged.
to the screen. While this has been proven to work well familiarizing
people with "Log::Logperl" slowly, effectively avoiding to clobber them
over the head with a plethora of different knobs to fiddle with
(categories, appenders, levels, layout), the overall mission of
"Log::Log4perl" is to let people use categories right from the start to
get used to the concept. So, let's keep this one fairly hidden in the
man page (congrats on reading this far :).
Stealth loggers
Sometimes, people are lazy. If you're whipping up a 50-line script and
want the comfort of Log::Log4perl without having the burden of carrying
a separate log4perl.conf file or a 5-liner defining that you want to
append your log statements to a file, you can use the following
features:
use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init( { level => $DEBUG,
file => ">>test.log" } );
# Logs to test.log via stealth logger
DEBUG("Debug this!");
INFO("Info this!");
WARN("Warn this!");
ERROR("Error this!");
some_function();
sub some_function {
# Same here
FATAL("Fatal this!");
}
In ":easy" mode, "Log::Log4perl" will instantiate a *stealth logger* and
introduce the convenience functions "TRACE", "DEBUG()", "INFO()",
"WARN()", "ERROR()", "FATAL()", and "ALWAYS" into the package namespace.
These functions simply take messages as arguments and forward them to
the stealth loggers methods ("debug()", "info()", and so on).
If a message should never be blocked, regardless of the log level, use
the "ALWAYS" function which corresponds to a log level of "OFF":
ALWAYS "This will be printed regardless of the log level";
The "easy_init" method can be called with a single level value to create
a STDERR appender and a root logger as in
Log::Log4perl->easy_init($DEBUG);
or, as shown below (and in the example above) with a reference to a
hash, specifying values for "level" (the logger's priority), "file" (the
appender's data sink), "category" (the logger's category and "layout"
for the appender's pattern layout specification. All key-value pairs are
optional, they default to $DEBUG for "level", "STDERR" for "file", ""
(root category) for "category" and "%d %m%n" for "layout":
Log::Log4perl->easy_init( { level => $DEBUG,
file => ">test.log",
utf8 => 1,
category => "Bar::Twix",
layout => '%F{1}-%L-%M: %m%n' } );
The "file" parameter takes file names preceded by ">" (overwrite) and
">>" (append) as arguments. This will cause
"Log::Log4perl::Appender::File" appenders to be created behind the
scenes. Also the keywords "STDOUT" and "STDERR" (no ">" or ">>") are
recognized, which will utilize and configure
"Log::Log4perl::Appender::Screen" appropriately. The "utf8" flag, if set
to a true value, runs a "binmode" command on the file handle to
establish a utf8 line discipline on the file, otherwise you'll get a
'wide character in print' warning message and probably not what you'd
expect as output.
The stealth loggers can be used in different packages, you just need to
make sure you're calling the "use" function in every package you're
using "Log::Log4perl"'s easy services:
package Bar::Twix;
use Log::Log4perl qw(:easy);
sub eat { DEBUG("Twix mjam"); }
package Bar::Mars;
use Log::Log4perl qw(:easy);
sub eat { INFO("Mars mjam"); }
package main;
use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init( { level => $DEBUG,
file => ">>test.log",
category => "Bar::Twix",
layout => '%F{1}-%L-%M: %m%n' },
{ level => $DEBUG,
file => "STDOUT",
category => "Bar::Mars",
layout => '%m%n' },
);
Bar::Twix::eat();
Bar::Mars::eat();
As shown above, "easy_init()" will take any number of different logger
definitions as hash references.
Also, stealth loggers feature the functions "LOGWARN()", "LOGDIE()", and
"LOGEXIT()", combining a logging request with a subsequent Perl warn()
or die() or exit() statement. So, for example
if($all_is_lost) {
LOGDIE("Terrible Problem");
}
will log the message if the package's logger is at least "FATAL" but
"die()" (including the traditional output to STDERR) in any case
afterwards.
See "Log and die or warn" for the similar "logdie()" and "logwarn()"
functions of regular (i.e non-stealth) loggers.
Similarily, "LOGCARP()", "LOGCLUCK()", "LOGCROAK()", and "LOGCONFESS()"
are provided in ":easy" mode, facilitating the use of "logcarp()",
"logcluck()", "logcroak()", and "logconfess()" with stealth loggers.
When using Log::Log4perl in easy mode, please make sure you understand
the implications of "Pitfalls with Categories".
By the way, these convenience functions perform exactly as fast as the
standard Log::Log4perl logger methods, there's *no* performance penalty
whatsoever.
Nested Diagnostic Context (NDC)
If you find that your application could use a global (thread-specific)
data stack which your loggers throughout the system have easy access to,
use Nested Diagnostic Contexts (NDCs). Also check out "Mapped Diagnostic
Context (MDC)", this might turn out to be even more useful.
For example, when handling a request of a web client, it's probably
useful to have the user's IP address available in all log statements
within code dealing with this particular request. Instead of passing
this piece of data around between your application functions, you can
just use the global (but thread-specific) NDC mechanism. It allows you
to push data pieces (scalars usually) onto its stack via
Log::Log4perl::NDC->push("San");
Log::Log4perl::NDC->push("Francisco");
and have your loggers retrieve them again via the "%x" placeholder in
the PatternLayout. With the stack values above and a PatternLayout
format like "%x %m%n", the call
$logger->debug("rocks");
will end up as
San Francisco rocks
in the log appender.
The stack mechanism allows for nested structures. Just make sure that at
the end of the request, you either decrease the stack one by one by
calling
Log::Log4perl::NDC->pop();
Log::Log4perl::NDC->pop();
or clear out the entire NDC stack by calling
Log::Log4perl::NDC->remove();
Even if you should forget to do that, "Log::Log4perl" won't grow the
stack indefinitely, but limit it to a maximum, defined in
"Log::Log4perl::NDC" (currently 5). A call to "push()" on a full stack
will just replace the topmost element by the new value.
Again, the stack is always available via the "%x" placeholder in the
Log::Log4perl::Layout::PatternLayout class whenever a logger fires. It
will replace "%x" by the blank-separated list of the values on the
stack. It does that by just calling
Log::Log4perl::NDC->get();
internally. See details on how this standard log4j feature is
implemented in Log::Log4perl::NDC.
Mapped Diagnostic Context (MDC)
Just like the previously discussed NDC stores thread-specific
information in a stack structure, the MDC implements a hash table to
store key/value pairs in.
The static method
Log::Log4perl::MDC->put($key, $value);
stores $value under a key $key, with which it can be retrieved later
(possibly in a totally different part of the system) by calling the
"get" method:
my $value = Log::Log4perl::MDC->get($key);
If no value has been stored previously under $key, the "get" method will
return "undef".
Typically, MDC values are retrieved later on via the "%X{...}"
placeholder in "Log::Log4perl::Layout::PatternLayout". If the "get()"
method returns "undef", the placeholder will expand to the string
"[undef]".
An application taking a web request might store the remote host like
Log::Log4perl::MDC->put("remote_host", $r->headers("HOST"));
at its beginning and if the appender's layout looks something like
log4perl.appender.Logfile.layout.ConversionPattern = %X{remote_host}: %m%n
then a log statement like
DEBUG("Content delivered");
will log something like
adsl-63.dsl.snf.pacbell.net: Content delivered
later on in the program.
For details, please check Log::Log4perl::MDC.
Resurrecting hidden Log4perl Statements
Sometimes scripts need to be deployed in environments without having
Log::Log4perl installed yet. On the other hand, you don't want to live
without your Log4perl statements -- they're gonna come in handy later.
So, just deploy your script with Log4perl statements commented out with
the pattern "###l4p", like in
###l4p DEBUG "It works!";
# ...
###l4p INFO "Really!";
If Log::Log4perl is available, use the ":resurrect" tag to have Log4perl
resurrect those buried statements before the script starts running:
use Log::Log4perl qw(:resurrect :easy);
###l4p Log::Log4perl->easy_init($DEBUG);
###l4p DEBUG "It works!";
# ...
###l4p INFO "Really!";
This will have a source filter kick in and indeed print
2004/11/18 22:08:46 It works!
2004/11/18 22:08:46 Really!
In environments lacking Log::Log4perl, just comment out the first line
and the script will run nevertheless (but of course without logging):
# use Log::Log4perl qw(:resurrect :easy);
###l4p Log::Log4perl->easy_init($DEBUG);
###l4p DEBUG "It works!";
# ...
###l4p INFO "Really!";
because everything's a regular comment now. Alternatively, put the magic
Log::Log4perl comment resurrection line into your shell's PERL5OPT
environment variable, e.g. for bash:
set PERL5OPT=-MLog::Log4perl=:resurrect,:easy
export PERL5OPT
This will awaken the giant within an otherwise silent script like the
following:
#!/usr/bin/perl
###l4p Log::Log4perl->easy_init($DEBUG);
###l4p DEBUG "It works!";
As of "Log::Log4perl" 1.12, you can even force *all* modules loaded by a
script to have their hidden Log4perl statements resurrected. For this to
happen, load "Log::Log4perl::Resurrector" *before* loading any modules:
use Log::Log4perl qw(:easy);
use Log::Log4perl::Resurrector;
use Foobar; # All hidden Log4perl statements in here will
# be uncommented before Foobar gets loaded.
Log::Log4perl->easy_init($DEBUG);
...
Check the "Log::Log4perl::Resurrector" manpage for more details.
Access defined appenders
All appenders defined in the configuration file or via Perl code can be
retrieved by the "appender_by_name()" class method. This comes in handy
if you want to manipulate or query appender properties after the
Log4perl configuration has been loaded via "init()".
Note that internally, Log::Log4perl uses the "Log::Log4perl::Appender"
wrapper class to control the real appenders (like
"Log::Log4perl::Appender::File" or "Log::Dispatch::FileRotate"). The
"Log::Log4perl::Appender" class has an "appender" attribute, pointing to
the real appender.
The reason for this is that external appenders like
"Log::Dispatch::FileRotate" don't support all of Log::Log4perl's
appender control mechanisms (like appender thresholds).
The previously mentioned method "appender_by_name()" returns a reference
to the *real* appender object. If you want access to the wrapper class
(e.g. if you want to modify the appender's threshold), use the hash
$Log::Log4perl::Logger::APPENDER_BY_NAME{...} instead, which holds
references to all appender wrapper objects.
Modify appender thresholds
To set an appender's threshold, use its "threshold()" method:
$app->threshold( $FATAL );
To conveniently adjust *all* appender thresholds (e.g. because a script
uses more_logging()), use
# decrease thresholds of all appenders
Log::Log4perl->appender_thresholds_adjust(-1);
This will decrease the thresholds of all appenders in the system by one
level, i.e. WARN becomes INFO, INFO becomes DEBUG, etc. To only modify
selected ones, use
# decrease thresholds of selected appenders
Log::Log4perl->appender_thresholds_adjust(-1, ['AppName1', ...]);
and pass the names of affected appenders in a ref to an array.
Advanced configuration within Perl
Initializing Log::Log4perl can certainly also be done from within Perl.
At last, this is what "Log::Log4perl::Config" does behind the scenes.
Log::Log4perl's configuration file parsers are using a publically
available API to set up Log::Log4perl's categories, appenders and
layouts.
Here's an example on how to configure two appenders with the same layout
in Perl, without using a configuration file at all:
########################
# Initialization section
########################
use Log::Log4perl;
use Log::Log4perl::Layout;
use Log::Log4perl::Level;
# Define a category logger
my $log = Log::Log4perl->get_logger("Foo::Bar");
# Define a layout
my $layout = Log::Log4perl::Layout::PatternLayout->new("[%r] %F %L %m%n");
# Define a file appender
my $file_appender = Log::Log4perl::Appender->new(
"Log::Log4perl::Appender::File",
name => "filelog",
filename => "/tmp/my.log");
# Define a stdout appender
my $stdout_appender = Log::Log4perl::Appender->new(
"Log::Log4perl::Appender::Screen",
name => "screenlog",
stderr => 0);
# Have both appenders use the same layout (could be different)
$stdout_appender->layout($layout);
$file_appender->layout($layout);
$log->add_appender($stdout_appender);
$log->add_appender($file_appender);
$log->level($INFO);
Please note the class of the appender object is passed as a *string* to
"Log::Log4perl::Appender" in the *first* argument. Behind the scenes,
"Log::Log4perl::Appender" will create the necessary
"Log::Log4perl::Appender::*" (or "Log::Dispatch::*") object and pass
along the name value pairs we provided to
"Log::Log4perl::Appender->new()" after the first argument.
The "name" value is optional and if you don't provide one,
"Log::Log4perl::Appender->new()" will create a unique one for you. The
names and values of additional parameters are dependent on the
requirements of the particular appender class and can be looked up in
their manual pages.
A side note: In case you're wondering if
"Log::Log4perl::Appender->new()" will also take care of the "min_level"
argument to the "Log::Dispatch::*" constructors called behind the scenes
-- yes, it does. This is because we want the "Log::Dispatch" objects to
blindly log everything we send them ("debug" is their lowest setting)
because *we* in "Log::Log4perl" want to call the shots and decide on
when and what to log.
The call to the appender's *layout()* method specifies the format (as a
previously created "Log::Log4perl::Layout::PatternLayout" object) in
which the message is being logged in the specified appender. If you
don't specify a layout, the logger will fall back to
"Log::Log4perl::SimpleLayout", which logs the debug level, a hyphen (-)
and the log message.
Layouts are objects, here's how you create them:
# Create a simple layout
my $simple = Log::Log4perl::SimpleLayout();
# create a flexible layout:
# ("yyyy/MM/dd HH:mm:ss (file:lineno)> message\n")
my $pattern = Log::Log4perl::Layout::PatternLayout("%d (%F:%L)> %m%n");
Every appender has exactly one layout assigned to it. You assign the
layout to the appender using the appender's "layout()" object:
my $app = Log::Log4perl::Appender->new(
"Log::Log4perl::Appender::Screen",
name => "screenlog",
stderr => 0);
# Assign the previously defined flexible layout
$app->layout($pattern);
# Add the appender to a previously defined logger
$logger->add_appender($app);
# ... and you're good to go!
$logger->debug("Blah");
# => "2002/07/10 23:55:35 (test.pl:207)> Blah\n"
It's also possible to remove appenders from a logger:
$logger->remove_appender($appender_name);
will remove an appender, specified by name, from a given logger. Please
note that this does *not* remove an appender from the system.
To eradicate an appender from the system, you need to call
"Log::Log4perl->eradicate_appender($appender_name)" which will first
remove the appender from every logger in the system and then will delete
all references Log4perl holds to it.
To remove a logger from the system, use
"Log::Log4perl->remove_logger($logger)". After the remaining reference
$logger goes away, the logger will self-destruct. If the logger in
question is a stealth logger, all of its convenience shortcuts (DEBUG,
INFO, etc) will turn into no-ops.
How about Log::Dispatch::Config?
Tatsuhiko Miyagawa's "Log::Dispatch::Config" is a very clever simplified
logger implementation, covering some of the *log4j* functionality. Among
the things that "Log::Log4perl" can but "Log::Dispatch::Config" can't
are:
* You can't assign categories to loggers. For small systems that's
fine, but if you can't turn off and on detailed logging in only a
tiny subsystem of your environment, you're missing out on a majorly
useful log4j feature.
* Defining appender thresholds. Important if you want to solve
problems like "log all messages of level FATAL to STDERR, plus log
all DEBUG messages in "Foo::Bar" to a log file". If you don't have
appenders thresholds, there's no way to prevent cluttering STDERR
with DEBUG messages.
* PatternLayout specifications in accordance with the standard (e.g.
"%d{HH:mm}").
Bottom line: Log::Dispatch::Config is fine for small systems with simple
logging requirements. However, if you're designing a system with lots of
subsystems which you need to control independently, you'll love the
features of "Log::Log4perl", which is equally easy to use.
Using Log::Log4perl with wrapper functions and classes
If you don't use "Log::Log4perl" as described above, but from a wrapper
function, 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 functions, "Log::Log4perl" will
indicate where your logger function called the loggers, not where your
application called your wrapper:
use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init({ level => $DEBUG,
layout => "%M %m%n" });
sub mylog {
my($message) = @_;
DEBUG $message;
}
sub func {
mylog "Hello";
}
func();
prints
main::mylog Hello
but that's probably not what your application expects. Rather, you'd
want
main::func Hello
because the "func" function called your logging function.
But don't despair, there's a solution: Just register your wrapper
package with Log4perl beforehand. If Log4perl then finds that it's being
called from a registered wrapper, it will automatically step up to the
next call frame.
Log::Log4perl->wrapper_register(__PACKAGE__);
sub mylog {
my($message) = @_;
DEBUG $message;
}
Alternatively, you can increase the value of the global variable
$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:
sub mylog {
my($message) = @_;
local $Log::Log4perl::caller_depth =
$Log::Log4perl::caller_depth + 1;
DEBUG $message;
}
Also, note that if you're writing a subclass of Log4perl, like
package MyL4pWrapper;
use Log::Log4perl;
our @ISA = qw(Log::Log4perl);
and you want to call get_logger() in your code, like
use MyL4pWrapper;
sub get_logger {
my $logger = Log::Log4perl->get_logger();
}
then the get_logger() call will get a logger for the "MyL4pWrapper"
category, not for the package calling the wrapper class as in
package UserPackage;
my $logger = MyL4pWrapper->get_logger();
To have the above call to get_logger return a logger for the
"UserPackage" category, you need to tell Log4perl that "MyL4pWrapper" is
a Log4perl wrapper class:
use MyL4pWrapper;
Log::Log4perl->wrapper_register(__PACKAGE__);
sub get_logger {
# Now gets a logger for the category of the calling package
my $logger = Log::Log4perl->get_logger();
}
This feature works both for Log4perl-relaying classes like the wrapper
described above, and for wrappers that inherit from Log4perl use
Log4perl's get_logger function via inheritance, alike.
Access to Internals
The following methods are only of use if you want to peek/poke in the
internals of Log::Log4perl. Be careful not to disrupt its inner
workings.
"Log::Log4perl->appenders()"
To find out which appenders are currently defined (not only for a
particular logger, but overall), a "appenders()" method is available
to return a reference to a hash mapping appender names to their
Log::Log4perl::Appender object references.
Dirty Tricks
infiltrate_lwp()
The famous LWP::UserAgent module isn't Log::Log4perl-enabled. Often,
though, especially when tracing Web-related problems, it would be
helpful to get some insight on what's happening inside
LWP::UserAgent. Ideally, LWP::UserAgent would even play along in the
Log::Log4perl framework.
A call to "Log::Log4perl->infiltrate_lwp()" does exactly this. In a
very rude way, it pulls the rug from under LWP::UserAgent and
transforms its "debug/conn" messages into "debug()" calls of loggers
of the category "LWP::UserAgent". Similarily, "LWP::UserAgent"'s
"trace" messages are turned into "Log::Log4perl"'s "info()" method
calls. Note that this only works for LWP::UserAgent versions <
5.822, because this (and probably later) versions miss debugging
functions entirely.
Suppressing 'duplicate' LOGDIE messages
If a script with a simple Log4perl configuration uses logdie() to
catch errors and stop processing, as in
use Log::Log4perl qw(:easy) ;
Log::Log4perl->easy_init($DEBUG);
shaky_function() or LOGDIE "It failed!";
there's a cosmetic problem: The message gets printed twice:
2005/07/10 18:37:14 It failed!
It failed! at ./t line 12
The obvious solution is to use LOGEXIT() instead of LOGDIE(), but
there's also a special tag for Log4perl that suppresses the second
message:
use Log::Log4perl qw(:no_extra_logdie_message);
This causes logdie() and logcroak() to call exit() instead of die().
To modify the script exit code in these occasions, set the variable
$Log::Log4perl::LOGEXIT_CODE to the desired value, the default is 1.
Redefine values without causing errors
Log4perl's configuration file parser has a few basic safety
mechanisms to make sure configurations are more or less sane.
One of these safety measures is catching redefined values. For
example, if you first write
log4perl.category = WARN, Logfile
and then a couple of lines later
log4perl.category = TRACE, Logfile
then you might have unintentionally overwritten the first value and
Log4perl will die on this with an error (suspicious configurations
always throw an error). Now, there's a chance that this is
intentional, for example when you're lumping together several
configuration files and actually *want* the first value to overwrite
the second. In this case use
use Log::Log4perl qw(:nostrict);
to put Log4perl in a more permissive mode.
Prevent croak/confess from stringifying
The logcroak/logconfess functions stringify their arguments before
they pass them to Carp's croak/confess functions. This can get in
the way if you want to throw an object or a hashref as an exception,
in this case use:
$Log::Log4perl::STRINGIFY_DIE_MESSAGE = 0;
eval {
# throws { foo => "bar" }
# without stringification
$logger->logcroak( { foo => "bar" } );
};
EXAMPLE
A simple example to cut-and-paste and get started:
use Log::Log4perl qw(get_logger);
my $conf = q(
log4perl.category.Bar.Twix = WARN, Logfile
log4perl.appender.Logfile = Log::Log4perl::Appender::File
log4perl.appender.Logfile.filename = test.log
log4perl.appender.Logfile.layout = \
Log::Log4perl::Layout::PatternLayout
log4perl.appender.Logfile.layout.ConversionPattern = %d %F{1} %L> %m %n
);
Log::Log4perl::init(\$conf);
my $logger = get_logger("Bar::Twix");
$logger->error("Blah");
This will log something like
2002/09/19 23:48:15 t1 25> Blah
to the log file "test.log", which Log4perl will append to or create it
if it doesn't exist already.
INSTALLATION
If you want to use external appenders provided with "Log::Dispatch", you
need to install "Log::Dispatch" (2.00 or better) from CPAN, which itself
depends on "Attribute-Handlers" and "Params-Validate". And a lot of
other modules, that's the reason why we're now shipping Log::Log4perl
with its own standard appenders and only if you wish to use additional
ones, you'll have to go through the "Log::Dispatch" installation
process.
Log::Log4perl needs "Test::More", "Test::Harness" and "File::Spec", but
they already come with fairly recent versions of perl. If not,
everything's automatically fetched from CPAN if you're using the CPAN
shell (CPAN.pm), because they're listed as dependencies.
"Time::HiRes" (1.20 or better) is required only if you need the
fine-grained time stamps of the %r parameter in
"Log::Log4perl::Layout::PatternLayout".
Manual installation works as usual with
perl Makefile.PL
make
make test
make install
DEVELOPMENT
Log::Log4perl is still being actively developed. We will always make
sure the test suite (approx. 500 cases) will pass, but there might still
be bugs. please check <http://github.com/mschilli/log4perl> for the
latest release. The api has reached a mature state, we will not change
it unless for a good reason.
Bug reports and feedback are always welcome, just email them to our
mailing list shown in the AUTHORS section. We're usually addressing them
immediately.
REFERENCES
[1] Michael Schilli, "Retire your debugger, log smartly with
Log::Log4perl!", Tutorial on perl.com, 09/2002,
<http://www.perl.com/pub/a/2002/09/11/log4perl.html>
[2] Ceki Gรผlcรผ, "Short introduction to log4j",
<http://logging.apache.org/log4j/1.2/manual.html>
[3] Vipan Singla, "Don't Use System.out.println! Use Log4j.",
<http://www.vipan.com/htdocs/log4jhelp.html>
[4] The Log::Log4perl project home page: <http://log4perl.com>
SEE ALSO
Log::Log4perl::Config, Log::Log4perl::Appender,
Log::Log4perl::Layout::PatternLayout,
Log::Log4perl::Layout::SimpleLayout, Log::Log4perl::Level,
Log::Log4perl::JavaMap Log::Log4perl::NDC,
AUTHORS
Please contribute patches to the project on Github:
http://github.com/mschilli/log4perl
Send bug reports or requests for enhancements to the authors via our
MAILING LIST (questions, bug reports, suggestions/patches):
[email protected]
Authors (please contact them via the list above, not directly): Mike
Schilli <[email protected]>, Kevin Goess <[email protected]>
Contributors (in alphabetical order): Ateeq Altaf, Cory Bennett, Jens
Berthold, Jeremy Bopp, Hutton Davidson, Chris R. Donnelly, Matisse
Enzer, Hugh Esco, Anthony Foiani, James FitzGibbon, Carl Franks, Dennis
Gregorovic, Andy Grundman, Paul Harrington, Alexander Hartmaier, David
Hull, Robert Jacobson, Jason Kohles, Jeff Macdonald, Markus Peter, Brett
Rann, Peter Rabbitson, Erik Selberg, Aaron Straup Cope, Lars Thegler,
David Viner, Mac Yang.
LICENSE
Copyright 2002-2013 by Mike Schilli <[email protected]> and Kevin Goess
<[email protected]>.
This library is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.
log4perl's People
Contributors
Stargazers
Watchers
Forkers
open-source-dude karenetheridge toddr charleydixon cebjyre metaperl kgoess rurban yoozoosato fgabolde rsrchboy jayallen xliangwu kes777 rokiroki mbeijen wolfgangpecho benrifkah tamias numericillustration dsteinbrunner rouzier mca oiami perlancar wchristian midlifexis zrusilla fgeueke bokutin mishin dakkar mmterpstra tarunmohanty eserte sadrak flueg rsperl salva jpoliv greatfireball lharey robrwo chorny willsheppard haarg simon04 jan-herout kivilahtio plicease-pr mateusduboli diablosoffens charlie-waffles itsuki-hayashi perceptyx bmodotdev allenk abraxxa tonycoz atoomic crossbuild xsven rwp0 abeez8191 sysfce2 dawid20201996log4perl's Issues
t/026FileApp.t Fails on Cygwin
The t/026FileApp.t should probably skip for
I was able to get make test to pass by adding three instances of: || $^O eq 'cygwin'
Log::Log4perl won't build for Strawberry Perl 5.30: Failed Tests
Tried using cpanm.
t/025CustLevels.t ......... ok
# Failed test 'header_text'
# at t/026FileApp.t line 459.
# got: 'This is a nice header.
# This is a nice header.
# DEBUG - waah!
# '
# expected: 'This is a nice header.
# DEBUG - waah!
# '
# Looks like you failed 1 test of 27.
t/026FileApp.t ............
Seems like a place where I'd be safe to use --force so low urgency. The line in question seems to be
is($content, "This is a nice header.\nDEBUG - waah!\n", "header_text");So it's likely a \n vs \r\n thing.
logwarn / error_warn / logcarp / logcluck don't warn unless log level is turned up
Hi,
So I came across this when I tried to use log4perl without initializing it (I wanted warnings and deaths, and when the modules user was using log4perl it all to be logged as well). The logdie and associated methods all die regardless of log level but the warn versions all require log4perl to be configured to log the message of that level before it will issue the warn statement. This seems wrong to me as I thought the intention of these methods was was to log your warnings as opposed to warn your log messages.
Originally I was just going to fork and put in a pull request for this and let that be accepted or rejected, but after I started working on it I found that t/024WarnDieCarp.t explicitly tests for the warnings not being made when the log level isn't high enough, so now I'm thinking this is intended behavior and just a really odd design decision.
So I'm keen to have a version of logwarn that warns regardless of log levels or initialization either by repairing the existing methods or implementing some new methods. I'm eager to do the work for either solution if you guys are happy to see either implemented.
So let me know whether either of these is ok or if I'm just confused.
Thanks
-Chris
Log::Log4perl::Filter::Boolean ignores order of filters in configuration
https://rt.cpan.org/Public/Bug/Display.html?id=110513
I use 2 boolean filters to combine simple regex-ignore filters (and chained them too):
log4perl.filter.AbortUserProtected = sub { m!test a! }
log4perl.filter.AbortUserInactive = sub { m!test b! }
log4perl.filter.AbortProjectInactive = sub { m!test c! }
log4perl.filter.ProblemNewState = sub { m!test d! }
log4perl.filter.ProblemPremiumProject = sub { m!test e! }
log4perl.filter.ProblemInactiveProject = sub { m!test f! }
log4perl.filter.IgnoreTicket6851 = Log::Log4perl::Filter::Boolean
log4perl.filter.IgnoreTicket6851.logic = AbortUserProtected || AbortUserInactive || AbortProjectInactive || ProblemNewState || ProblemPremiumProject || ProblemInactiveProject
log4perl.filter.WrongContentLength = sub { m!test 1! }
log4perl.filter.SessionMismatch = sub { m!test 2! }
log4perl.filter.SessionTooLarge = sub { m!test 3! }
log4perl.filter.InvalidBoundary = sub { m!test 4! }
log4perl.filter.InvalidFieldName = sub { m!test 5! }
log4perl.filter.InvalidUnicode = sub { m!test 6! }
log4perl.filter.IgnoreUnwanted = Log::Log4perl::Filter::Boolean
log4perl.filter.IgnoreUnwanted.logic = !WrongContentLength && !SessionMismatch && !SessionTooLarge && !InvalidBoundary && !InvalidFieldName && !InvalidUnicode && !IgnoreTicket6851
log4perl.appender.PanicApp.Filter = IgnoreUnwanted
in ~50% the loading of filters failed due to the following error:
Filter IgnoreTicket6851 required by Boolean filter, but not defined at /path/to/Log/Log4perl/Filter/Boolean.pm line 55.
After setting _INTERNAL_DEBUG => 1 in Log::Log4perl::Filter::Boolean i see the problem:
Compiling '!WrongContentLength && !SessionMismatch && !SessionTooLarge && !InvalidBoundary && !InvalidFieldName && !InvalidUnicode && !IgnoreTicket6851'
Filter IgnoreTicket6851 required by Boolean filter, but not defined at /path/to/Log/Log4perl/Filter/Boolean.pm line 55.
VS
Compiling 'AbortUserProtected || AbortUserInactive || AbortProjectInactive || ProblemNewState || ProblemPremiumProject || ProblemInactiveProject'
func= sub {
my($AbortProjectInactive, $AbortUserProtected, $AbortUserInactive, $ProblemNewState, $ProblemPremiumProject, $ProblemInactiveProject) = @_;
&$AbortUserProtected || &$AbortUserInactive || &$AbortProjectInactive || &$ProblemNewState || &$ProblemPremiumProject || &$ProblemInactiveProject;
}
Compiling '!WrongContentLength && !SessionMismatch && !SessionTooLarge && !InvalidBoundary && !InvalidFieldName && !InvalidUnicode && !IgnoreTicket6851'
func= sub {
my($InvalidFieldName, $SessionTooLarge, $WrongContentLength, $IgnoreTicket6851, $SessionMismatch, $InvalidBoundary, $InvalidUnicode) = @_;
!&$WrongContentLength && !&$SessionMismatch && !&$SessionTooLarge && !&$InvalidBoundary && !&$InvalidFieldName && !&$InvalidUnicode && !&$IgnoreTicket6851;
}
The order of the boolean filters is not picked from the configuration. It is by random.
Failing tests - Log-Log4perl-1.45
$ perl -v
This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux
Failed test 'gmtime != localtime'
at t/070UTCDate.t line 63.
got: '11:52:54
'
expected: anything else
Looks like you failed 1 test of 2.
t/070UTCDate.t ............
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/2 subtests
Test Summary Report
t/070UTCDate.t (Wstat: 256 Tests: 2 Failed: 1)
Failed test: 2
Non-zero exit status: 1
Files=73, Tests=718, 31 wallclock secs ( 0.22 usr 0.02 sys + 2.75 cusr 0.28 csys = 3.27 CPU)
Result: FAIL
Failed 1/73 test programs. 1/718 subtests failed.
Log::Log4perl::Appender::File is using two args open
We should consider enforcing three args open in Log4perl
this is coming from sub file_open Log::Log4perl::Appender::File
eval {
if($self->{syswrite}) {
sysopen $fh, "$self->{filename}", $sysmode or
die "Can't sysopen $self->{filename} ($!)";
} else {
open $fh, "$arrows$self->{filename}" or
die "Can't open $self->{filename} ($!)";
}
};Log::Log4perl::JavaMap::SyslogAppender Not Handling "socket"
I see where Sys::Syslog supports a host options on the setlogsock() call, and I see where Log::Dispatch::Syslog lets you pass an arrayref for the socket option that it will pass through to Sys::Syslog::setlogsock(). However, in looking at the code for Log::Log4perl::JavaMap::SyslogAppender, it doesn't look like it does anything with the $socket option/variable (either in terms of initializing it or using it/passing it to Log::Dispatch::Syslog. Is this an oversight or am I missing something obvious? Thanks.
File appender: Perl 5.24 warns when syswrite is used with :utf8 handles
Hi,
with Perl 5.24, any log write will cause a warning if the options "utf8" and "syswrite" are used together:
syswrite() is deprecated on :utf8 handles at /usr/share/perl5/Log/Log4perl/Appender/File.pm line 272
See https://rt.perl.org/Public/Bug/Display.html?id=125760 for the change in Perl.
Something like the following will silence the warning:
--- File.pm.orig 2017-01-17 16:35:18.869755923 +0000
+++ File.pm 2017-01-17 16:46:59.621725047 +0000
@@ -10,6 +10,7 @@
use Fcntl;
use File::Path;
use File::Spec::Functions qw(splitpath);
+use Encode qw(encode_utf8);
use constant _INTERNAL_DEBUG => 0;
##################################################
@@ -163,10 +164,6 @@
binmode $self->{fh}, $self->{binmode};
}
- if (defined $self->{utf8}) {
- binmode $self->{fh}, ":utf8";
- }
-
if(defined $self->{header_text}) {
if( $self->{header_text} !~ /\n\Z/ ) {
$self->{header_text} .= "\n";
@@ -268,11 +265,13 @@
my $fh = $self->{fh};
+ my $msg = $self->{utf8} ? encode_utf8($params{message}) : $params{message};
+
if($self->{syswrite}) {
- defined (syswrite $fh, $params{message}) or
+ defined (syswrite $fh, $msg) or
die "Cannot syswrite to '$self->{filename}': $!";
} else {
- print $fh $params{message} or
+ print $fh $msg or
die "Cannot write to '$self->{filename}': $!";
}
}
encode_utf8() is ancient, so it should not cause portability issues.
Config File Support for More Comment Formats
Log::Log4perl curently supports only the pound sign "#" to introduce comments.
Log::Log4perl's config file format is similar to an INI file and many INI files accept the semi-colon ";" as a comment character.
Also, Log::Log4perl is based on log4j which also supports the exclamation point "!" for comments.
I've looked at Log::Log4perl::Config::PropertyConfigurator which I believe is responsible for interpreting the syntax and I'm willing to do the work and add tests if anyone else thinks these additions would be useful.
Log::Log4perl::Logger->cleanup should not call DESTROY... or exist?
I was poking around inside the guts of Log::Log4perl and noticed this:
sub cleanup {
# Delete all loggers
foreach my $loggername (keys %$LOGGERS_BY_NAME) {
$LOGGERS_BY_NAME->{$loggername}->DESTROY();
delete $LOGGERS_BY_NAME->{$loggername};
}
The explicit call to DESTROY strikes me as an overly aggressive cleanup. If the logger is no longer in use, no longer referenced elsewhere, DESTROY will be called automatically when it's deleted from %LOGGERS_BY_NAME. If the logger IS still referenced, then some code somewhere is left with a busted logger object.
This makes cleanup unusable for long running processes to clean out the cache of unused loggers. See http://stackoverflow.com/questions/5914088/disposing-of-log4perl-logger-when-i-no-longer-need-it
Is there another reason for this? Perhaps to break a circular reference? It was added in 079329e but no rationale is given.
Since Log::Log4perl::Logger->cleanup is undocumented, and its only use is in an END block, and all it does is disassemble some hashes and call DESTROY on some objects that are about to be destroyed anyway... why does it exist at all?
In a related note, Log::Log4perl::Logger->DESTROY doesn't appear to do anything useful. It deletes things that will be automatically cleaned up in object destruction. Is that circular reference defense?
about header_text
I've been struggling to understand how to use header_text.
For example, the following
#!/usr/bin/env perl
use strict;
use warnings;
use Log::Log4perl qw(get_logger :levels);
my $logger = get_logger();
$logger->level($INFO);
my $layout = Log::Log4perl::Layout::PatternLayout->new("%d %p: %m{indent}%n");
my $appender = Log::Log4perl::Appender->new(
"Log::Dispatch::File",
header_text => "header cmh",
filename => "test.log",
mode => "write",
);
$appender->layout($layout);
$logger->add_appender($appender);
$logger->info("some information");
exit(0);produces
2017/09/18 20:16:54 INFO: some information
and I was hoping that header cmh might appear in it.
Have I misunderstood header_text?
semget fails when there a semaphore with semid 0
I ran in the same bug as Siarhei Kuchynski:
The following code in line 64 of Log::Log4perl::Util::Semaphore should fix this:
64 defined($self->{id} = semget( $self->{ikey}, 1, 0 ))
He observes:
"When a semaphore with specified key (0x6f6e616e) and semid = 0 already
exists, semget fails for this semaphore:
bash-4.0# ipcs -s
Verberge zitierten Text
------ Semaphore Arrays --------
key semid owner perms nsems
0x6f6e616e 0 root 777 1
with the following error message
semget(1869504878) failed: at
/usr/share/perl5/vendor_perl//Log/Log4perl/Util/Semaphore.pm line 64.
This is caused by line 64 of Log::Log4perl::Util::Semaphore.pm
63 print "Semaphore '$self->{key}' already exists\n" if INTERNAL_DEBUG;
64 $self->{id} = semget( $self->{ikey}, 1, 0 )
65 or die "semget(
semget returns ID 0 for the key 1869504878 and dies, though 0 should be
considered to be valid ID
According to http://perldoc.perl.org/functions/semget.html:
semget KEY,NSEMS,FLAGS
Calls the System V IPC function semget(2). Returns the semaphore id, or the
undefined value on error.
It seems that init method should call die only if semget returns undefined
value, not zero.
"
Unicode file names on Windows?
Using the file appender and a filename such as "ะฟัะธะผะตั.log" on Windows results in:
Can't open ??????.log (Invalid argument) at C:\...lib/Log/Log4perl/Appender/File.pm line 151.
It's fine with common Latin1 things but not Cyrillic etc. Is there a way to do this? In the application that uses this, I had to resort to Win32::Unicode::File in other places as this seems to be the only way to read/write files with such glyphs on Windows?
t/013Bench.t fails if Time::HiRes is not available
If Time::HiRes is not available, t/013Bench.t fails:
t/012Deeper.t ............. ok
Can't locate Time/HiRes.pm in @INC (you may need to install the Time::HiRes module) (@INC contains: /builddir/build/BUILD/Log-Log4perl-1.52/blib/lib /builddir/build/BUILD/Log-Log4perl-1.52/blib/arch /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /builddir/build/BUILD/Log-Log4perl-1.52/blib/lib/Log/Log4perl/Util/TimeTracker.pm line 19.
BEGIN failed--compilation aborted at /builddir/build/BUILD/Log-Log4perl-1.52/blib/lib/Log/Log4perl/Util/TimeTracker.pm line 22.
Compilation failed in require at /builddir/build/BUILD/Log-Log4perl-1.52/blib/lib/Log/Log4perl/Layout/PatternLayout.pm line 17.
BEGIN failed--compilation aborted at /builddir/build/BUILD/Log-Log4perl-1.52/blib/lib/Log/Log4perl/Layout/PatternLayout.pm line 17.
Compilation failed in require at /builddir/build/BUILD/Log-Log4perl-1.52/blib/lib/Log/Log4perl/Layout.pm line 5.
BEGIN failed--compilation aborted at /builddir/build/BUILD/Log-Log4perl-1.52/blib/lib/Log/Log4perl/Layout.pm line 5.
Compilation failed in require at /builddir/build/BUILD/Log-Log4perl-1.52/blib/lib/Log/Log4perl/Logger.pm line 11.
BEGIN failed--compilation aborted at /builddir/build/BUILD/Log-Log4perl-1.52/blib/lib/Log/Log4perl/Logger.pm line 11.
Compilation failed in require at /builddir/build/BUILD/Log-Log4perl-1.52/blib/lib/Log/Log4perl.pm line 14.
BEGIN failed--compilation aborted at /builddir/build/BUILD/Log-Log4perl-1.52/blib/lib/Log/Log4perl.pm line 14.
Compilation failed in require at t/013Bench.t line 10.
BEGIN failed--compilation aborted at t/013Bench.t line 10.
t/013Bench.t ..............
Dubious, test returned 22 (wstat 5632, 0x1600)
No subtests run
Undefined subroutine &Log::Log4perl::Logger::cleanup called at /builddir/build/BUILD/Log-Log4perl-1.52/blib/lib/Log/Log4perl.pm line 5.
END failed--call queue aborted at t/013Bench.t line 10.
I can see that lib/Log/Log4perl/Util/TimeTracker.pm loads Time::HiRes only if Log::Log4perl::Util::module_available returns true. Compiling TimeTracker.pm indeed succeeds. But Benchmark in the t/013Bench.t does something strange that confuses module_available():
$ perl -Ilib -e 'use Log::Log4perl;'
$ perl -Ilib -e 'use Benchmark; use Log::Log4perl;'
Can't locate Time/HiRes.pm in @INC (you may need to install the Time::HiRes module) (@INC contains: lib /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at lib/Log/Log4perl/Util/TimeTracker.pm line 19.
[...]
Use of uninitialized value $Log::Log4perl::JOIN_MSG_ARRAY_CHAR
I honestly don't understand why this warning is being generated - I've run the code through a debugger and that variable appears to be initialized. But here's a simple test program to generate it, if anyone wants to troubleshoot it.
use Log::Log4perl;
my $config = q(
log4perl.rootLogger = DEBUG, screen
log4perl.appender.screen = Log::Log4perl::Appender::Screen
log4perl.appender.screen.stderr = 0
log4perl.appender.screen.layout = Log::Log4perl::Layout::SimpleLayout
);
Log::Log4perl->init( $config );
my $logger = Log::Log4perl->get_logger();
$logger->debug("JOIN_MSG_ARRAY_CHAR: '", defined $Log::Log4perl::JOIN_MSG_ARRAY_CHAR ? $Log::Log4perl::JOIN_MSG_ARRAY_CHAR : "[undefined]", "'");
$logger->debug("Test: ", undef);
Config info for my setup...
Summary of my perl5 (revision 5 version 14 subversion 2) configuration:
Platform:
osname=linux, osvers=2.6.18-274.12.1.el5, archname=x86_64-linux
uname='linux hostname 2.6.18-274.12.1.el5 #1 smp tue nov 29 13:37:46 est 2011 x86_64 x86_64 x86_64 gnulinux '
config_args='-de -Dprefix=/home/dh/perl5/perlbrew/perls/perl-5.14.2'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.1.2 20080704 (Red Hat 4.1.2-51)', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64
libs=-lnsl -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.5.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.5'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'
Characteristics of this binary (from libperl):
Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
PERL_PRESERVE_IVUV USE_64_BIT_ALL USE_64_BIT_INT
USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF
Built under linux
Compiled at Jan 18 2012 17:34:52
%ENV:
PERLBREW_HOME="/home/dh/.perlbrew"
PERLBREW_PATH="/home/dh/perl5/perlbrew/bin:/home/dhagan/perl5/perlbrew/perls/perl-5.14.2/bin"
PERLBREW_PERL="perl-5.14.2"
PERLBREW_ROOT="/home/dh/perl5/perlbrew"
PERLBREW_VERSION="0.28"
@inc:
/home/dh/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2/x86_64-linux
/home/dh/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2
/home/dh/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2/x86_64-linux
/home/dh/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2
.
Log::Log4perl version 1.35 from cpan.
DBI appender max_col_size not applied to binds outside params
A configuration like so will not apply the max_col_size option and truncate the 7th bind field [message]:
log4perl.appender.DBI.sql = INSERT INTO log(logDate, filename, lineNum, logLevel, ip, userNum,message) VALUES (?,?,?,?,?,?,?)
log4perl.appender.DBI.params.1 = %d{yyyy-MM-dd HH:mm:ss}
log4perl.appender.DBI.params.2 = %F
log4perl.appender.DBI.params.3 = %L
log4perl.appender.DBI.params.4 = %p
log4perl.appender.DBI.params.5 = %X{ip}
log4perl.appender.DBI.params.6 = %X{user}
log4perl.appender.DBI.usePreparedStmt = 1
log4perl.appender.DBI.layout = Log::Log4perl::Layout::NoopLayout
log4perl.appender.DBI.warp_message = 0
log4perl.appender.DBI.max_col_size = 10
You can see in the code that the max_col_size is never applied to the "leftovers".
log4perl/lib/Log/Log4perl/Appender/DBI.pm
Line 255 in a361622
If I change the order of my binds however the max_col_size will be applied to the message field -
log4perl.appender.DBI.sql = INSERT INTO log(logDate, filename, lineNum, logLevel, ip, message, usernum) VALUES (?,?,?,?,?,?,?)
log4perl.appender.DBI.params.1 = %d{yyyy-MM-dd HH:mm:ss}
log4perl.appender.DBI.params.2 = %F
log4perl.appender.DBI.params.3 = %L
log4perl.appender.DBI.params.4 = %p
log4perl.appender.DBI.params.5 = %X{ip}
log4perl.appender.DBI.params.7 = %X{user}
log4perl.appender.DBI.usePreparedStmt = 1
log4perl.appender.DBI.layout = Log::Log4perl::Layout::NoopLayout
log4perl.appender.DBI.warp_message = 0
log4perl.appender.DBI.max_col_size = 10
Easy to fix and make a PR but I'm not sure if I am missing something else with how things are meant to work.
Would Like Auto-Instrumentation of Subroutines
Particularly when I am debugging a module that I haven't maintained before, I'd like to automatically instrument all the subroutines. Here's what I'd like to do:
package Foo::Bar;
use Log::Log4perl qw(:easy);
sub A {}
sub B {}
Log::Log4perl::auto_instrument();
1;This would look through the symbol table for Foo::Bar and replace each subroutine something like this:
*new_A = \&A;
sub A {
DEBUG "entering A, arguments are : " . join(' ', @_);
new_A(@_);
DEBUG "leaving A";
}Mike, I wanted to get your thoughts before contributing any code changes.
perl 5.16.1 -w complains "defined(@array) is deprecated at ..."
Use log4perl with perl 5.16.1, with -w option, perl complains such like:
defined(@array) is deprecated at /perl-lib-path/lib/Log/Log4perl/Config.pm line 864, line 558.
(Maybe you should just omit the defined()?)
There are following code found arround 864.
863 # give back 'undef' instead of an empty arrayref
864 unless( defined @log::Log4perl::ALLOWED_CODE_OPS_IN_CONFIG_FILE ) {
865 return;
866 }
So it should be:
864 unless( @log::Log4perl::ALLOWED_CODE_OPS_IN_CONFIG_FILE ) {
or
864 unless( scalar(@log::Log4perl::ALLOWED_CODE_OPS_IN_CONFIG_FILE) ) {
Don't die if writing of message failed
If you write message to logfile (File appender) and an exeption raised, then the application failed. But it's wrong. The application designed for solve some problems, not for writing to log. So it should continue to solve this problems, even if writing to log fails.
Well I propose replacing die to warn in method log of appender File. (Or adding the option that will switch die to warn.)
How to get appender file name using logger object?
I want to get appender file name using logger object.
my $log_conf = {
'log4perl.rootLogger' => "DEBUG, LOG1, SCREEN",
'log4perl.appender.SCREEN' => "Log::Log4perl::Appender::Screen",
'log4perl.appender.SCREEN.stderr' => "0",
'log4perl.appender.SCREEN.layout' => "Log::Log4perl::Layout::PatternLayout",
'log4perl.appender.SCREEN.layout.ConversionPattern' =>
"CloudAuTOM:%d{yyyy_MMM_d H:m:s}_" . get_ip_address() . "_%C::: %m %n",
'log4perl.appender.LOG1' => "Log::Log4perl::Appender::File",
'log4perl.appender.LOG1.filename' => file_path($file_name, $path),
#'log4perl.appender.LOG1.mode' => "append",
'log4perl.appender.LOG1.layout' => "Log::Log4perl::Layout::PatternLayout",
'log4perl.appender.LOG1.layout.ConversionPattern' =>
"CloudAuTOM:%d{yyyy_MMM_d H:m:s}_%C::: %m %n"
};
Log::Log4perl->init($log_conf);
my $logger = Log::Log4perl->get_logger($file_name);
# somewhat like below:
print $logger->filename; I went over doc and it says that I can access appenders using appender_by_name() class method.
I tried to access it using the command $logger->appender_by_name(), but it is returning me following error
Can't locate object method "appender_by_name" via package "Log::Log4perl::Logger"
Following is the dump of my logger object:
$VAR1 = bless( {
'TRACE' => sub { "DUMMY" },
'DEBUG' => sub { "DUMMY" },
'FATAL' => $VAR1->{'DEBUG'},
'additivity' => 1,
'level' => undef,
'layout' => undef,
'appender_names' => [],
'OFF' => $VAR1->{'DEBUG'},
'is_WARN' => sub { "DUMMY" },
'is_TRACE' => sub { "DUMMY" },
'is_OFF' => sub { "DUMMY" },
'is_DEBUG' => sub { "DUMMY" },
'ERROR' => $VAR1->{'DEBUG'},
'is_INFO' => sub { "DUMMY" },
'is_ERROR' => sub { "DUMMY" },
'is_ALL' => sub { "DUMMY" },
'WARN' => $VAR1->{'DEBUG'},
'INFO' => $VAR1->{'DEBUG'},
'num_appenders' => 0,
'is_FATAL' => sub { "DUMMY" },
'category' => 'autom_controller.log',
'ALL' => $VAR1->{'TRACE'}
}, 'Log::Log4perl::Logger' );
Circular require causes explosion
Successfully installed Log-Log4perl-1.46
1 distribution installed
sherlock$ perl -e 'use Log::Log4perl::Appender;'
Can't locate object method "new" via package "Log::Log4perl::Appender" at /home/matthewt/perl5/lib/perl5/Log/Log4perl/Logger.pm line 33.
Compilation failed in require at /home/matthewt/perl5/lib/perl5/Log/Log4perl/Config.pm line 8.
BEGIN failed--compilation aborted at /home/matthewt/perl5/lib/perl5/Log/Log4perl/Config.pm line 8.
Compilation failed in require at /home/matthewt/perl5/lib/perl5/Log/Log4perl/Appender.pm line 9.
BEGIN failed--compilation aborted at /home/matthewt/perl5/lib/perl5/Log/Log4perl/Appender.pm line 9.
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
The problem here is Appender loads Config loads Logger and then Logger tries to ->new on Appender - but because Logger's require of Appender has been ignored as already in progress, Appender's new method doesn't exist yet.
Require loops BAD :)
(also this particular require loop is the cause of http://stackoverflow.com/questions/31319263/is-it-possible-to-fatpack-script-using-loglog4perl-using-appfatpacker )
Synchronized Appender locking up system with semaphores
Hi,
We have a system which forks children and we found out that sometimes log4perl messages are interleaved (especially for long messages) so we added the "Synchronized" Appenders the the logfiles and created a different semaphore (4 char long .key) for each and every appender file based logger.
At first tests it looked perfectly ok, but once we put the code on our QA testing system it started to fail miserable, we had strange lockups all over the place and as I have not really found out how that semaphores stuff is working I also feel unable to fix this issue. But I think it seems somehow the locks don't get released but I don't even know how to trace this.
BTW: We are using Log4perl 1.46 provided by centos7.
Warning: Use of uninitialized value in join or string at lib/Log/Log4perl/Appender.pm line 167
Log4Perl still has this warning when logging undef:
perl -W -Ilib -e 'use Log::Log4perl qw(:easy); Log::Log4perl->easy_init($INFO); INFO(undef)'
Use of uninitialized value in join or string at lib/Log/Log4perl/Appender.pm line 167.It was last detailed in this mailing list thread:
http://www.mail-archive.com/[email protected]/msg00454.html
Using dots in property configuration names
Hi, I am using property configuration. And now I need to use dots in names for some fields. For example:
JsonLayout.field.browser.name = Firefox
In this case I want to get field like that:
field->{'browser.name'} == 'Firefox'
So I propose to use some char sequence as dot. For example if we gonna use '~1' char sequence as dot, than configuration, which will look like this:
JsonLayout.field.browser~1name = Firefox
And field hash will look like this:
field->{'browser.name'} == 'Firefox'
Can we do this? I can create pull request for this, if you like this idea
logconfess logs stacktrace on multiple lines
Using logconfess() ends in logging every part of the stacktrace in a single line:
2017/09/15 09:09:05 ich sterbe! at test_logfatal.pl.pm line 13.
2017/09/15 09:09:05 class1::foo("class1") called at test_logfatal.pl.pm line 21
2017/09/15 09:09:05 class2::foo("class2") called at test_logfatal.pl.pm line 28
2017/09/15 09:09:05 class3::foo("class3") called at test_logfatal.pl.pm line 39
2017/09/15 09:09:05 eval {...} called at test_logfatal.pl.pm line 39
Here is the example code:
use strict;
use warnings;
package class1;
use Log::Log4perl qw(get_logger);
sub foo() {
my $logger = get_logger();
$logger->logconfess("ich sterbe!");
}
package class2;
sub foo() { class1->foo(); }
package class3;
sub foo() { class2->foo(); }
package main;
use Carp;
use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init({level => Log::Log4perl::Level->INFO_INT});
my $logger = get_logger();
eval { class3->foo() };
if ($@) {
...
}
Using an email-appender this behaviour results in sending one email for every line of the stacktrace. Not nice.
How can I force logconfess to write one logmessage with stacktrace instead of multiple lines?
At the end I want to get only one email for the whole logmessage.
Allow to add appenders in more ease way
You have ease_init
Log::Log4perl->easy_init( { level => $DEBUG,
file => ">>test.log",
category => "Bar::Twix",
layout => '%F{1}-%L-%M: %m%n' },
{ level => $DEBUG,
file => "STDOUT",
category => "Bar::Mars",
layout => '%m%n' },
);
it will be very good to allow to add appenders in such way.
Log::Log4perl->add_appender( { ... } ); --- everything that easy_init do, except reseting current configuration
Allow option appender option in :easy interface
I want to use the :easy interface and log to a file with Log::Dispatch::File::Stamped instead of File and log to STDERR with ScreenColoredLevels instead of Screen. Please consider adding the ability to specify the appender in the :easy interface.
I think issue #21 was asking something similar.
Is log4perl affected by CVE-2021-44228? (log4j)
Hi, is there a possibility tht log4perl is also affected by the CVE-2021-44228?
I couldn't find any reference to JNDI or something similar.
Thanks in advance!
More information about CVE-2021-44228 here: https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/
Log::Log4perl::Catalyst has no version
At least CPAN.pm thinks that Log::Log4perl::Catalyst has no version:
cpan[1]> m Log::Log4perl::Catalyst
...
Module id = Log::Log4perl::Catalyst
CPAN_USERID MSCHILLI (Michael Schilli <[email protected]>)
CPAN_VERSION undef
CPAN_FILE E/ET/ETJ/Log-Log4perl-1.53.tar.gz
UPLOAD_DATE 2020-09-17
MANPAGE Log::Log4perl::Catalyst - Log::Log4perl Catalyst Module
INST_FILE /opt/perl-5.12.3/lib/site_perl/5.12.3/Log/Log4perl/Catalyst.pm
INST_VERSION 1.49
Probably the reason is this line: https://metacpan.org/source/ETJ/Log-Log4perl-1.53/lib/Log/Log4perl/Catalyst.pm#L7
PAUSE looks only at the isolated $VERSION line when getting a module's version (for security reasons). It does not know anything about the Log::Log4perl module and the $VERSION value set there.
Possible fixes are:
- set a fixed version here
- create META.* files with a "provides" section
head_text test fails on windows, likely newline issue
not ok 23 - header_text
# Failed test 'header_text'
# at t\026FileApp.t line 460.
# got: 'This is a nice header.
# This is a nice header.
# DEBUG - waah!
# '
# expected: 'This is a nice header.
# DEBUG - waah!
# '
Looks like a double-write, but i expect it's just something about getting confused by \r.
easy_init() silently ignores invalid arguments
Every argument to easy_init() should be either an integer (a log level value) or a hashref containing logger configuration options. It would be nice if it complained loudly if it got anything else.
Recently, I saw someone calling it like this:
easy_init( level => $WARN, format => ' ... ' ); # Not a hashref
The level parameter seemed to work, but the format was ignored. The fix was simple (just put all of the arguments within { ... }) but it would have been easier to find if the function had emitted some kind of warning when receiving invalid parameters.
I'll submit a pull request for this soon.
Appender mail crashes at reading configuration
Hello,
Attached are two test cases:
- testing console only (works fine)
- testing console + mail (crashed when initializing Log4perl object)
I updated Log4perl and Specio (see $VERSION values) and still get the crash:
PERL5LIB=$HOME/lib/perl/share/perl perl console-and-mail-log4perl.pl
$Log::Log4perl::VERSION=1.54
$Specio::VERSION=0.47
Validation failed for type named Bool declared in package Specio::Library::Builtins (/home/sblondeel/lib/perl/share/perl/5.28.1/Specio/Library/Builtins.pm) at line 69 in sub named (eval) with value 100
Trace begun at Specio::Exception->new line 57
Specio::Exception::throw('Specio::Exception', 'message', 'Validation failed for type named Bool declared in package Specio::Library::Builtins (/home/sblondeel/lib/perl/share/perl/5.28.1/Specio/Library/Builtins.pm) at line 69 in sub named (eval) with value 100', 'type', 'Specio::Constraint::Simple=HASH(0x5654cdc94ab0)', 'value', 100) called at (eval 150) line 79
Eval::Closure::Sandbox_4::ANON('min_level', 'debug', 'name', 'mail', 'buffered', 100, 'subject', 'Log4perl speaking', 'to', 'sblondeel+log4perl@localhost', 'l4p_post_config_subs', 'ARRAY(0x5654cd5116a8)', 'l4p_depends_on', 'ARRAY(0x5654cd50cee8)', 'Threshold', 'WARN') called at /usr/share/perl5/Log/Dispatch/Email.pm line 39
Log::Dispatch::Email::new('Log::Dispatch::Email::MailSend', 'min_level', 'debug', 'name', 'mail', 'buffered', 100, 'subject', 'Log4perl speaking', 'to', 'sblondeel+log4perl@localhost', 'l4p_post_config_subs', 'ARRAY(0x5654cd5116a8)', 'l4p_depends_on', 'ARRAY(0x5654cd50cee8)', 'Threshold', 'WARN') called at /home/sblondeel/lib/perl/share/perl/5.28.1/Log/Log4perl/Appender.pm line 83
Log::Log4perl::Appender::new('Log::Log4perl::Appender', 'Log::Dispatch::Email::MailSend', 'name', 'mail', 'l4p_post_config_subs', 'ARRAY(0x5654cd5116a8)', 'l4p_depends_on', 'ARRAY(0x5654cd50cee8)', 'to', 'sblondeel+log4perl@localhost', 'subject', 'Log4perl speaking', 'Threshold', 'WARN', 'buffered', 100) called at /home/sblondeel/lib/perl/share/perl/5.28.1/Log/Log4perl/Config.pm line 413
Log::Log4perl::Config::create_appender_instance('HASH(0x5654cd404690)', 'mail', 'HASH(0x5654cd511678)', 'ARRAY(0x5654cd5116a8)', undef) called at /home/sblondeel/lib/perl/share/perl/5.28.1/Log/Log4perl/Config.pm line 305
Log::Log4perl::Config::_init('Log::Log4perl::Config', '/tmp/log4perl-console.conf') called at /home/sblondeel/lib/perl/share/perl/5.28.1/Log/Log4perl/Config.pm line 36
Log::Log4perl::Config::init('Log::Log4perl::Config', '/tmp/log4perl-console.conf') called at /home/sblondeel/lib/perl/share/perl/5.28.1/Log/Log4perl.pm line 253
Log::Log4perl::init('Log::Log4perl', '/tmp/log4perl-console.conf') called at console-and-mail-log4perl.pl line 36
Log::Log4perl::Catalyst abort not working as expected.
I think there is already a PR for attempting to fix abort w/ Log::Log4perl::Catalyst. Albeit, I wanted to create an issue item for discussion, prior to a merge. This issue is also on the heel of using Catalyst::Plugin::Static::Simple.
It would appear, that abort does not work in the expected fashion of Catalyst::Log, rather it clears all of the appender's buffers when abort is called, when it should be at time = _flush(). Since there is no checking of $self->{abort} in flush, flush could have buffers which were populated after abort was called. This functionally seems to ignore abort's expected outcome. Currently, abort is more akin to a 'clear_buffers' type of function.
If I'm understanding the module correctly, would it be best to make a call to abort more of a setter, which flush then checks and operates on?
I'm thinking something like:
##################################################
sub _flush {
##################################################
my ($self) = @_;
for my $appender (values %Log::Log4perl::Logger::APPENDER_BY_NAME) {
next if $appender->{name} !~ /_$CATALYST_APPENDER_SUFFIX$/;
if ($self->{abort}) {
$appender->{appender}{buffer} = [];
}
else {
$appender->flush();
}
}
$self->abort(undef);
}
##################################################
sub abort {
##################################################
my $self = shift;
$self->{abort} = $_[0] if @_;
return $self->{abort};
}Thanks, @mschilli for producing this wonder module.
Pinging @bokutin
NAME in POD incorrect for ScreenColoredLevels
The NAME in the POD is 'Log::Log4perl::Appender::ScreenColoredLevel' but the module name is 'Log::Log4perl::Appender::ScreenColoredLevels'. It's only a single character change in documentation. I'll submit a PR for it.
Log::Log4perl::Filter::Boolean use wrong variable in error message
https://rt.cpan.org/Public/Bug/Display.html?id=110512
in Log::Log4perl::Filter::Boolean line 54:
my $filter = Log::Log4perl::Filter::by_name($1);
die "Filter $filter required by Boolean filter, but not defined"
unless $filter;
Use of uninitialized value $filter in concatenation (.) or string at /path/to/Log/Log4perl/Filter/Boolean.pm line 55.
Filter required by Boolean filter, but not defined at /path/to/Log/Log4perl/Filter/Boolean.pm line 55.
i guess $1 containes the name of the filter.
windows fix 11af71bc8e77d8f7c56f199dc8b81bb8ee1fe09e been left lingering for over a month
Please release the fix to CPAN, so i won't have to be angry at you twice. ;)
Bad file descriptor
Hello
I am getting this error on perl 5.18.1:
Can't close log/file.log (Bad file descriptor) at /usr/lib/perl5/site_perl/5.18.1/Log/Log4perl/Appender/File.pm line 282
However, it does not happen on earlier perl versions. Is there any way around this?
This is what the configuration file looks like:
log4perl.category.Foo.Foo1=INFO, LOGFILE
log4perl.category.Foo.Foo2=INFO, LOGFILE
log4perl.category.Foo.Foo3=INFO, LOGFILE
log4perl.category.modules=FATAL, LOGFILE
log4perl.category.Bar.Bar1=DEBUG, LOGFILE2
log4perl.appender.LOGFILE=Log::Log4perl::Appender::File
log4perl.appender.LOGFILE.filename=sub { logfile(); };
log4perl.appender.LOGFILE.mode=append
log4perl.appender.LOGFILE.layout=PatternLayout
log4perl.appender.LOGFILE.layout.ConversionPattern=[%d{dd/MMM HH:mm:ss.SSS}] %P|%c{1}:%L/%p - %m%n
log4perl.appender.LOGFILE2=Log::Log4perl::Appender::File
log4perl.appender.LOGFILE2.filename=sub { logfile('logfile2'); };
log4perl.appender.LOGFILE2.mode=append
log4perl.appender.LOGFILE2.layout=PatternLayout
log4perl.appender.LOGFILE2.layout.ConversionPattern=[%d{dd/MMM HH:mm:ss.SSS}] %P|%c{1}:%L/%p - %m%n
worng package for get_logger
in your Log::Log4perl->get_logger you may initialize:
my $level = $Log::Log4perl::caller_depth;
That will allow this to work:
$SIG{ __WARN__ } = sub {
local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1;
my $logger = Log::Log4perl->get_logger;
$logger->warn( '__WARN__ ', $Log::Log4perl::caller_depth, @_ );
};
With that init the get_logger will return logger with category where warn is called instead of package where $SIG{ WARN } is defined;
Also you can think more deeply. It seems, to my mind, you can escape from $WRAPPERS_REGISTERED. Users just required to localize $Log::Log4perl::caller_depth as I did in my example
Warning: close() on unopened filehandle FH at Log/Log4perl/Appender/File.pm line 257 during global destruction.
Using Log4Perl 1.40 with Perl 5.16.2 results in the warning:
"close() on unopened filehandle FH at Log/Log4perl/Appender/File.pm line 257 during global destruction."
According to the Perl 5.16.2 documentation for perlobj:
"If your DESTROY method issues a warning during global destruction, the Perl interpreter will append the string " during global destruction" the warning."
It appears the global destruction phase in Perl automatically closes open file handles causing the DESTROY method to output the warning when it attempts to close the file handle.
Failed test 'header_text'
C:\>perl -v
This is perl 5, version 20, subversion 1 (v5.20.1) built for MSWin32-x64-multi-thread
t/026FileApp.t ............ 1/27
# Failed test 'header_text'
# at t/026FileApp.t line 459.
# got: 'This is a nice header.
# This is a nice header.
# DEBUG - waah!
# '
# expected: 'This is a nice header.
# DEBUG - waah!
# '
# Looks like you failed 1 test of 27.
t/026FileApp.t ............ Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/27 subtests
(less 8 skipped subtests: 18 okay)
Test Summary Report
-------------------
t/026FileApp.t (Wstat: 256 Tests: 27 Failed: 1)
Failed test: 23
Non-zero exit status: 1
Files=73, Tests=740, 35 wallclock secs ( 0.44 usr + 0.05 sys = 0.48 CPU)
Result: FAIL
Failed 1/73 test programs. 1/740 subtests failed.
dmake.exe: Error code 255, while making 'test_dynamic'
MSCHILLI/Log-Log4perl-1.48.tar.gz
C:\STRAWB~1\c\bin\dmake.exe test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports MSCHILLI/Log-Log4perl-1.48.tar.gz
Stopping: 'install' failed for 'Log::Log4perl'.
Document how to set "undef_column_value"
Hi,
I couldn't find any documentation on how to set the "undef_column_value".
It causes problems when trying to convert the output to JSON as my expected field type is an integer which could be NULL if not available, however Log::Log4perl::Layout::PatternLayout converts everything that's undef to a string, i.e. "[undef]".
Many thanks.
Avoiding warning when init() is not called
Hi,
I have written a module that actually uses Log4Perl as logging system. This is how I use Log4Perl:
package MyPackage;
use Log::Log4perl;
my $logger = Log::Log4perl->get_logger();
...
$logger->info("foo bar");Now, I don't know if the logger it was initialized or not by the main program. If not, the main program receives:
Log4perl: Seems like no initialization happened. Forgot to call init()?
Is there a transparent way to use Log4perl only if the main has configured it? So that the get_logger() returns always an instance that doesn't do nothing.
Actually I have in the main program:
use Log::Log4perl;
$Log::Log4perl::Logger::INITIALIZED = 1;but I think that a module should be independent from who use it.
Thank you in advance,
Emanuele
additivity() doesn't work. why ?
Hello,
#!/usr/bin/perl
use strict;
use warnings;
use Log::Log4perl;
use Log::Log4perl::Level;
my $log_conf = q/
log4perl.rootLogger = INFO, Root
log4perl.appender.Root = Log::Log4perl::Appender::Screen
log4perl.appender.Root.layout = Log::Log4perl::Layout::PatternLayout
log4perl.appender.Root.layout.ConversionPattern = [Root] %m%n
/;
Log::Log4perl::init( \$log_conf );
my $logger = Log::Log4perl::get_logger();
my $logger2 = Log::Log4perl::get_logger('independentLogger');
my $stdout_appender = Log::Log4perl::Appender->new( 'Log::Log4perl::Appender::Screen', name => 'Independent' );
my $layout = Log::Log4perl::Layout::PatternLayout->new( '[Independent] %m%n' );
$stdout_appender->layout( $layout );
$logger2->add_appender( $stdout_appender );
$logger2->level( $INFO );
$logger2->additivity( 0 ); # doesn't work
$logger->info("foo");
$logger2->info("bar"); # outputs with independentLogger AND rootLogger :(While "additivity" in init() works :
#!/usr/bin/perl
use strict;
use warnings;
use Log::Log4perl;
my $log_conf = q/
log4perl.rootLogger = INFO, Root
log4perl.appender.Root = Log::Log4perl::Appender::Screen
log4perl.appender.Root.layout = Log::Log4perl::Layout::PatternLayout
log4perl.appender.Root.layout.ConversionPattern = [Root] %m%n
log4perl.logger.independentLogger = INFO, Independent
log4perl.additivity.independentLogger = 0
log4perl.appender.Independent = Log::Log4perl::Appender::Screen
log4perl.appender.Independent.layout = Log::Log4perl::Layout::PatternLayout
log4perl.appender.Independent.layout.ConversionPattern = [Independent] %m%n
/;
Log::Log4perl::init( \$log_conf );
my $logger = Log::Log4perl::get_logger();
my $logger2 = Log::Log4perl::get_logger('independentLogger');
$logger->info("foo");
$logger2->info("bar"); # works, outputs with independentLogger onlyWhy is... those things ?
`easy_init` with `autoflush`?
Would it be too much to add autoflush to easy_init?
To get automatic flushing atm, I have to write a config, which I know isn't the end of the world, but it doesn't fit well with my lazy use of :easy.
problem with Log::dispatch::Syslog in svn pre-commit hook
Hi,
I have the following
use Log::Log4perl;
my $conf = q(
log4perl.category = DEBUG, SYSLOG, Logfile
log4perl.appender.SYSLOG = Log::Dispatch::Syslog
log4perl.appender.SYSLOG.layout = Log::Log4perl::Layout::SimpleLayout
log4perl.appender.Logfile = Log::Log4perl::Appender::File
log4perl.appender.Logfile.filename = /tmp/test.log
log4perl.appender.Logfile.layout = Log::Log4perl::Layout::SimpleLayout
);
Log::Log4perl::init(\$conf);
my $logger = Log::Log4perl->get_logger();
$logger->error("logging...");
in an SVN pre-commit hook.
While it logs fine to the logfile, I do not get anything into syslog (rsyslogd precisely).
Running the hook on the commandline makes it log to syslog as expected, so I guess it is some problem with the environment.
Any ideas on how I could get this fixed?
Thanks a lot,
Sven
init-and-watch test case failing in version 1.28
Just encountered a non-reproducible failing test - The previous test run succeeded, and there were no changes in the repository between the two runs.
make[2]: Entering directory `/var/hudson/jobs/workspace/.../Log-Log4perl-1.28'
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
# Failed test 'init-and-watch caller level third'
# at t/027Watch2.t line 170.
# '2011/07/12 03:01:37 [undef] [undef]> third
# '
# doesn't match '(?-xism:027Watch2.t 168> third)'
# Failed test 'init-and-watch caller level third'
# at t/027Watch2.t line 181.
# '2011/07/12 03:01:39 [undef] [undef]> third
# '
# doesn't match '(?-xism:027Watch2.t 179> third)'
# Looks like you failed 2 tests of 20.
Log::Log4perl::DateFormat caches time zone offset
Log::Log4perl::DateFormat computes the time zone offset only once, so Lo4perl ends up logging incorrect datetimes when the object survives during time zone changes.
% faketime '2021-03-28 01:59:58' perl -MLog::Log4perl -E 'sub g {Log::Log4perl::DateFormat->new("yyyy-MM-ddTHH:mm:ss.SSSZ")}; my $outer = g(); for (1..5) { say join " ", $outer->format(time), g->format(time); sleep 1 }'
2021-03-28T01:59:58.000+0100 2021-03-28T01:59:58.000+0100
2021-03-28T01:59:59.000+0100 2021-03-28T01:59:59.000+0100
2021-03-28T03:00:00.000+0100 2021-03-28T03:00:00.000+0200
2021-03-28T03:00:01.000+0100 2021-03-28T03:00:01.000+0200
2021-03-28T03:00:02.000+0100 2021-03-28T03:00:02.000+0200header_text option in Log::Log4perl::Appender::File incompatible with syswrite option
If you set syswrite=1 on the Log::Log4perl::Appender::File appender, the header_text option ceases to work. If you look at the code:
sub file_open {
[...]
if(defined $self->{header_text}) {
[...]
my $fh = $self->{fh};
print $fh $self->{header_text};
}
}the cause is apparent. It is using print rather than syswrite, and you can't mix syswrite and STDIO on the same file descriptor.
Recommended fix would be to factor out the writter code from log() and call it from both log() and the above code.
"Modification of a read-only value attempted" during log in __DIE__ handler for compile-time errors
The following snippet will generate an error like this:
Modification of a read-only value attempted at /usr/share/perl5/Log/Dispatch/Output.pm line 32.
Snippet:
#!/usr/bin/perl -w
use strict;
use Log::Log4perl;
BEGIN {
my $config = q(
log4perl.logger=WARN, Debug
log4perl.appender.Debug=Log::Dispatch::File
log4perl.appender.Debug.filename=/tmp/debug.log
log4perl.appender.Debug.mode=append
log4perl.appender.Debug.layout=Log::Log4perl::Layout::SimpleLayout
);
Log::Log4perl::init(\$config);
my $logger = Log::Log4perl->get_logger('module');
$SIG{__DIE__} = sub {
my $err = join("", @_);
chomp $err;
$logger->fatal($err);
};
}
# die "I'm dying";
my $foo = $nonExistingVar;
If instead one enables the die line, and comments out the $nonExistingVar line, it works as expected, and the error gets put in the log.
This is caused by this bug in Params::Validate
https://rt.cpan.org/Public/Bug/Display.html?id=60467
Params::Validate is called by Log::Dispatch, which Log::Log4perl uses. So this but doesn't originate in Log4perl, I just saw it in Log4perl and wanted to mention it here, so that others won't go hunting like I had to. Go ahead and mark it as invalid or whatever similar state is appropriate for github.
[Bug] Log::Log4perl::Appender::File::file_switch() ignores the create_at_logtime option
Log-Log4perl-1.54
Switching the log file name using the file_switch() method, creates a new logfile even if the create_at_logtime option is set to true. Maybe the line 271 in Log::Log4perl::Appender::File should be changed from
$self->file_open();
to
$self->file_open() unless $self->{create_at_logtime};
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.