|
From: Kevin G. <ke...@go...> - 2003-01-23 16:56:56
|
> * looks like we can't use "sub {...}" as the syntax for
> filter_message coderefs because it's taken by the perl hooks already
> which are executed at config time. filter_message, on the other hand,
> needs to run at log time. For now, I've changed the code to expect a
> function *name* instead of a code ref -- see the latest addition to
> the Log::Log4perl::Appender docs ... thoughts?
PropertyConfigurator is already special-casing away the cspecs:
$val = eval_if_perl($val) if $key !~ /\.cspec\./;
why no just add another special case? Something like
$val = eval_if_perl($val)
if $key !~ /\.(cspec\.[^\.]+|filter_message)$/;
I just noticed this in the Appender.pm docs:
B<Please note that the standard appenders in the Log::Dispatch
hierarchy will choke on a bunch of messages passed to them as an
array reference. You can't use C<filter_message = 0> (or the
function name syntax defined below) on them.
but the standard appenders will work fine as long as the filter_message
function returns a string, not an arrayref, right?
And it just occurred to me, if we're eventually going to implement log4j
event filters, are we going to get naming confusion between
filter_message and filter? Should we consider other options for
filter_message? alter_message, munge_message, refashion_message?
--
Happy Trails . . .
Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA 94706
(510) 525-5217
|