Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

acme (189)

  (email not shown publicly)

Leon Brocard (aka acme) is an orange-loving Perl eurohacker with many varied contributions to the Perl community, including the GraphViz module on the CPAN. YAPC::Europe was all his fault. He is still looking for a Perl Monger group he can start which begins with the letter 'D'.

Journal of acme (189)

Thursday August 28, 2008
01:57 AM

Which logging module?

[ #37289 ]

One of Perl's mottos is "there is more than one way to do it". This is of course a great thing, except when there are two ways to do it and I can't decide which is the better one or the most popular one. Such is it with logging modules - there are two stong candidates: Log::Dispatch and Log::Log4perl. Both do about the same thing, which makes it annoying to decide between the two. Which one do you use? Which one should become the best practice CPAN module for logging?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I'd pick Log::Dispatch, to avoid promoting Log::Log4perl as being a good name for a Cpan module: repeating the top-level namespace obviously doesn't help with knowing what the module does ("When you said 'Log' the first time I wasn't sure whether this really is a logging module, but now you've said 'Log::Log' I can see that you mean it"?); and putting "4perl" at the end, that's to distinguish it from all those Cpan modules which aren't for use with Perl is it?

    (Yes, I know why Log::Log4perl is called what it

  • I've been thinking a lot about the same thing, and I'd really like to see something like an agnostic logging interface where users could use either as they liked, just as DBI does for databases.

    I'd like to put in logging calls into my modules, but without a dependency on any logging module. If an application uses Log::Dispatch, my module level calls get converted into Log::Dispatch things. If they use Log4perl, then my module does the right thing for that. If they don't use either, there is a default null

    • I'd really like to see something like an agnostic logging interface where users could use either as they liked, just as DBI does for databases.

      Be careful what you wish for. I've been doing lots of Java recently and exposed to the pain of commons-logging []. I wouldn't want to see that repeated…

  • It's well-designed, and works perfectly.

    Log::Log4Perl looks big, complex, although it may load components intelligently, and hence, dare I say it, has all the hall-marks of the disaster known as Cobol-for-Dummies, previously known as Java.

  • I take it that we're talking about best practice for unix style logging modules?
    • Perl runs fine on win32. When running an application, you want all the the logs in one place. Using one of these modules it should be possible for all the applications in your module to log in a consistent place (even if they are written by other people), be that a file, syslog, or whatever.
  • log::log4perl to set up the infrastructure and different log::dispatch loggers attached to the different logging classes and/or levels.

    bgp is for those who can't keep it static long enough