|
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
|