Re: [log4perl-devel] env-vars in log4perl config file

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

ke...@go... wrote:

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

Sorry, I wasn't clear on that one, I meant the public logging API:

    $logger->debug("Here's, the dump: ==>",   
                              { filter => \&Data::Dumper::Dump,  value 
=> $someref },
                               "<==");

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

Slow yes, but it'd be called only once at Log::Log4perl init() time -- 
so its impact is negligable. Error-prone? I'm not aware of any problems.

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

The 3rd party module decides whether it wants a certain format or not. 
Log::Log4perl doesn't really need to interfere -- we just need to know, 
so we call the module's format-adapting routine correctly.

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

As an additional option to control the 3rd party module's behaviour, 
that's probably nice-to-have. But I think most modules (like DBI) know 
what they want and don't even want that to be modified by the system 
using the appender.

Also, Data::Dumper wouldn't be a typical choice for an input filter ([1] 
and [2] as outlined in the last mail should be totally separate issues).

input_filter should be more likely something like a method which accepts 
the arguments of the debug/info/...() call issued by the Log::Log4perl 
user as an arrayref and which then has the opportunity to juggle them 
around (like skip one, collapse some, etc.) and then Log::Log4perl would 
pass on the new array to the appender's log() method.

E.g., user says

    $logger->debug("1", "2", "3", "4");

then Log::Log4perl would pass that on to 
Log::Log4perl::Appender::DBI->input_filter as

    ["1", "2", "3", "4"]

which would modify it to skip the last element (e.g. because the DB 
table only has 3 rows):

    ["1", "2", "3"]

which would be passed on to DBI::log() as

    ("1", "2", "3")

which would end up in the DB as three different columns. Does that make 
sense?

-- 
-- Mike

Mike Schilli
log...@pe...