Re: adding logging to Mason (need advice)
Jonathan Swartz <[email protected]>
| Newsgroups | gmane.comp.web.mason.devel |
|---|---|
| Message-ID | <[email protected]> |
> 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. The things that impressed me the most initially were (1) the ability to periodically check and reload the config file, and (2) the ability to specify log level and log destination on a per-category basis. These two things together mean that you can temporarily turn on logging of a certain class of debug messages on a production server without restarting the server. Log::Dispatch::Config has some of this, but Log4Perl implements it more completely. > 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. Yeah, I initially planned to do this, but the situation is a little more complicated. First, for efficiency the user would have to provide methods to check the log level; those methods differ between classes (Log::Dispatch::would_log versus Log::Log4perl::is_error etc.) Second, under l4p you actually have different logger objects depending on the category. Perhaps the way around this is to allow the user to provide an anonymous sub reference that takes a category as argument and returns a log object. There might be other features provided by each API that we couldn't take advantage of if we had to support the lowest common denominator. I figured l4p was a no-brainer because it explicitly supports appending to the Log::Dispatch dispatchers, so you get the best of both worlds. Jon ------------------------------------------------------- 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