Re: [log4perl-devel] RFC: Log4perl Custom Filters Design Proposal

[Mike S. <msc...@ao...>]

Pet...@Dr... wrote:

>     I prefer to define constants for the return values (and put
>    all constants in a common class Log::Log4per::Constants).
>    A filter may return
>
>        Log::Log4perl::Constants::OK
>        Log::Log4perl::Constants::DECLINED
>    
>    The constants may be imported by default so that you can write
>
>        log4perl.filter.MyFilter        = sub {  \
>            my %p = @_;                         \
>            (%p{log4p_level} == WARN) ? OK : DECLINED;  \
>
Nice. Definitely the correct way of defining it and being flexible to 
add stuff in the future. On the other hand, I really like constructs like

    sub { /x/ and /y/ }

which gets really hairy/lengthy with constants.

>    2. Can we have a sub here as well? Maybe I want to make my 
>    logic dependent on localtime() or the moon phases or have a
>    switch() on hostnames to have development and production 
>    logic in one config file or...
>
You can do that in two different ways: Define the "advanced" logic in 
the filters used by the Bool filter (which I think I would prefer) but, 
since yesterday, the "logic" field in the Bool filter just gets "eval"ed 
as regular Perl code, so you can put in there whatever you like. The 
latest version from CVS sports almost everything already, please check 
it out!

>    3. What a about message redirection? Are there plans for the
>    future that a filter (or whatever) can forward a message to
>    another appender?
>
Interesting feature, I haven't thought of that yet (neither have the 
log4j folks). I gotta think about that. Can you imagine a use case? 
Also, we could implement that either as a Log4perl-centric feature based 
on filter return code (as you suggested) or as a function/method call 
inside the filter (redir_to_appender(blah)).

-- 
-- Mike

Mike Schilli
log...@pe...