[log4perl-devel] Re: Docs/Test cases for message_filter

[Kevin G. <ke...@go...>]

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