From: Kevin G. <ke...@go...> - 2003-01-13 17:51:51
|
msc...@ao... wrote: > In a message dated 1/10/2003 8:24:13 PM Eastern Standard Time, "Wiggins d'Anconia" <wi...@da...> writes: > > > 1) If a message chunk is supposed to be run through a > "message filter", specify it as a hashref, with entries for "filter" and "value": > > log("Here's, the dump: ==>", > { filter => \&Data::Dumper::Dump, > value => $someref }, > "<=="); I'm confused, where would this be called? Is this part of the public API or the internal one? > 2) Some appenders expect message chunks in a specific > format. DBI wants columns, for Screen and other > Log::Dispatch appenders we want to collapse all chunks to a > single string. > > If an appender class defines an input_filter() method > (which we detect at appender init time via can() and then > cache it), all input will be passed through this method by > Log4perl before forwarding message chunks to the > appender's log method. > > DBI's input_filter() would then just return the arguments > passed to it, which Log4perl would then pass on to log(). Ahh, very nice. Then the DBI appender wouldn't have to use an arrayref to protect against collapsing the list into a string. But I have an alternative to checking to see whether the appender class defines a method. Calling class->can() is slow (?) and error-prone, and since we're trying to take advantage of third-party appender modules, we don't always have the option to define our method in their class. How about an appender-specific config option, like #leave incoming data alone log4perl.appender.A2.input_filter = 0 #or muck about with the data log4perl.appender.A2.input_filter = sub {Data::Dumper(shift)} The default would be to collapse a list into a string, calling any coderefs along the way, unless the appender class defines a class variable called something like LOG4PERL_INPUT_FILTER, in which case that would be the default, overrideable by data within the config. So Appender::DBI could define $Log::Log4perl::Appender::DBI::LOG4PERL_INPUT_FILTER = 0 and then the logging methods would just be $logger->info(1234,'bob smith','created account'); > These suggestions would require some changes to the current > development release, sorry I'm coming up with them so late > in the game, but it's probably still ok to change it > because we haven't rolled out the new functionality yet. That's fine, that's why they call it "development" ;-) -- Happy Trails . . . Kevin M. Goess (and Anne and Frank) 904 Carmel Ave. Albany, CA 94706 (510) 525-5217 |