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 ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ log4perl-devel mailing list log4perl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/log4perl-devel