Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by bluto (225) on 2006.02.07 11:32 (#46042)
    I've used Log::Dispatch for a long time and looked into switching to Log4perl. Both seemed fine for my needs.

    The main reason I didn't switch at the time was because I realized that Log4perl's config required too much knowledge of the app's internals (e.g. class layout, I think) for our admins to alter. It's probably more of an admin problem than a Log4perl problem. Since I needed to write a simpler config front-end for it anyway there seemed little reason for me to use one over the other. I stuck with what I knew worked in production (Log::Dispatch), but I actually tested running it on top of Log4perl without a problem.

    FWIW, during testing the Log4perl folks were very responsive and added a feature I requested surprisingly quickly (IIRC somthing that Log::Dispatch had). I almost feel guilty for not using it now...

    • The main reason I didn't switch at the time was because I realized that Log4perl's config required too much knowledge of the app's internals (e.g. class layout, I think)

      Actually, that's up for you to decide.

      To enable logging in particular areas of an application, you can use the class structure. But that's just a feature and not required at all.

      Instead, you can just enable/disable logging of the overall application or choose entirely different categories (i.e. make up your own hierarchy). The class