in reply to Log::Log4Perl best practices

Should there be this much overhead? When I see all this repeated code, I don't like it. This adds 4 lines to each program (not a big deal) but it also adds 4 lines to each .t script (?!?!) and 2 lines to module...surely it shouldn't require this much repeated code?
Log::Log4perl can be used in different ways, just pick the one that suits you:

For simple scripts, people like using :easy mode. This approach is also discussed in this FAQ and uses

Here's an example:
use Log::Log4perl qw(:easy); Log::Log4perl->easy_init( { level => $DEBUG, file => ">>test.log" } ); DEBUG("Debug this!");
Calling DEBUG() instead of obtaining a logger reference via get_logger($category) and then calling $logger->debug() is what Log4perl calls using stealth loggers. Stealth loggers are also recommended to be used in modules, just say
package MyPackage; use Log::Log4perl qw(:easy); sub method { DEBUG "Doing something!"; }
and you've got full-fledged logging in place. Stealth loggers use Log4perl categories equal to the current package. Performance stays the same.

The main program is responsible for calling init() or easy_init(). If it doesn't, Log::Log4perl will keep sleeping.

As for spreading like Kudzu through your application, that's a common issue with logging systems. Log::Log4perl reduces the exposure by not requiring to pass a handler around, but provides a singleton mechanism.

However, ideally, logging would be completely orthogonal to your application logic. You may have heard of aspect oriented programming (AOP), that's how it's done. Log4perl might provide a way to do that in the future.