[log4perl-devel] logger state is global

[Tom M. <tme...@gm...>]

I like the API Log::Log4perl provides, but using Log::Log4perl v1.28
I've encountered issues with the internal implementation that have been
very time consuming to resolve.

Most relate to the way Log4perl seems to store state in global or class
variables rather than in object or instance variables. This means that
unless you take extra steps to prevent it, library modules that call
upon Log4perl directly will stomp on the logger established by the
calling code.

This state mechanism also is incompatible with Class::Remote (a module
developed at Shopzilla for remote code execution, which apparently
hasn't been released to CPAN), as it attempts to serialize an object's
data and send it to the remote end.

Perhaps all this is a consequence of our use of easy_init(), though if
so, convenience methods shouldn't have the consequence of creating a
fragile system.

The general objectives I'd like to achieve are:

1. Ability to create a library module that can use Log4perl, such that
if the calling code makes no use of Log4perl, it logs independently with
locally specified defaults, but if the caller does use Log4perl, it
picks up the callers settings.

2. Fully serializable state.


Here's an example of an issue I ran into today. I had a block of code
being evaluated that contained an error. The eval() was followed by an
error check, which then called logdie() with $@. But post-evaluation,
logdie() or any other Log4perl method failed to produce any output,
resulting the program mysteriously exiting with no error.

A trace showed that $self->is_fatal(), as called by
Log::Log4perl::Logger->logdie(), which resolved to:
return sub { $return_token };
which apparently returned false, meaning that FATAL level logging is
disabled, which should never be the case.

The trigger for the problem turned out to be a 'use' call in the eval'ed
code that loaded a library which internally called easy_init() (yet
specifying the INFO logging level).

This seems broken that a library using normal Log4perl methods can trash
the logger in use by the calling code.

Is there a more correct way to be using the API to avoid this, or does
Log4perl need some internal refactoring?

 -Tom