Re: adding logging to Mason (need advice)
Jonathan Swartz <[email protected]>
| Newsgroups | gmane.comp.web.mason.devel |
|---|---|
| Message-ID | <[email protected]> |
Ok, I think I've found a way to use log4perl and easily allow other
logging modules like Log::Dispatch.
Here's the proposed documentation for Admin.
Ok, I think I've come up with a good compromise that takes advantage of
log4perl's features while allowing use of Log::Dispatch or other modules.
http://www.masonhq.com/?LoggingAPIProposal
Feedback please.
Jon
Dave Rolsky wrote:
> On Sun, 17 Oct 2004, Jonathan Swartz wrote:
>
>
>>I was thinking about using log4perl (http://log4perl.sourceforge.net/)
>>for this purpose. It provides great control over which category of log
>>messages are generated, it integrates with all of the Log::Dispatch
>>appenders, and it seems to be well supported.
>
>
> Log4Perl seems like overkill (vs Log::Dispatch). The main advantage that
> I think it provides is that it lets you set up logging via a config file.
> But if you're using Mason you're already writing code anyway. It seems
> like l4p is aimed at providing a nice solution for apps to provide logging
> capabilities, as opposed to logging for libraries.
>
>
>>However, I've never done anything with this project so would appreciate
>>hearing about good or bad experiences.
>
>
> Nothing bad. The author seems like a nice guy.
>
>
>>Would it be easy to add a bunch of log4perl calls to Mason? Should we
>>require users to install log4perl or somehow make the calls only if
>>log4perl is available? Does all the flexibility lead to inefficiencies,
>>e.g., will debug logging calls end up hurting performance even when the
>>user has this turned off?
>
>
> If we call a method, even if that method does nothing, it'll be a
> performance hit.
>
> Also, how are you thinking of integrating this with Mason?
>
> I think a better way to approach this is to come up with a logging API
> that a log object must provide. Since both Log4Perl and Log::Dispatch
> provide methods named after log levels (warn, info, crit, error, etc) this
> seems like a good way to go. Then users just provide the object of their
> choice. If no object is provided we don't call any logging methods.
>
>
> -dave
>
> /*===========================
> VegGuide.Org
> Your guide to all that's veg.
> ===========================*/
>
>
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl