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
- a simplified init method without a configuration file and
- logging functions instead of objects/method calls
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 sayuse Log::Log4perl qw(:easy); Log::Log4perl->easy_init( { level => $DEBUG, file => ">>test.log" } ); DEBUG("Debug this!");
and you've got full-fledged logging in place. Stealth loggers use Log4perl categories equal to the current package. Performance stays the same.package MyPackage; use Log::Log4perl qw(:easy); sub method { DEBUG "Doing something!"; }
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.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: Log::Log4Perl best practices
by water (Deacon) on Jun 03, 2004 at 10:25 UTC |
In Section
Seekers of Perl Wisdom