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

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

In a message dated 1/10/2003 8:24:13 PM Eastern Standard Time, "Wiggins d'Anconia" <wi...@da...> writes:

> This seems like a great idea, similar to the way 
> [...] POE uses "Filters" 

I thought a little harder about this issue and figured we
really need semantics for two different items:

1) Some appenders expect a certain format of the message
chunks passed on to them (like DBI expects columns).

2) Some message chunks we want to run through filters
before logging them (like some refs we want to log as
Data::Dumper output).

With the current Log::Log4perl::Appender::DBI expecting the
message chunks to arrive as an arrayref, it's difficult to
distinguish the two.

I juggled with POE filters (great idea, Wiggins!), and came up with that: 

Here's some new syntax we could use to embody both
requirements:

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 },
    "<==");

Arg1 and arg3 of this call are regular strings, the 2nd arg
specifies that $someref is supposed to be run through the
sub Date::Dumper::Dump and its output is to be logged
(optionally "filter" could specify a class, which
implements some POE-style get() and put() methods).

This filter is being run *before* the message is passed on
to any appenders.

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.

Here's how we could distinguish these, without disrupting
traditional Log::Dispatch-appenders:

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

If the appender doesn't define an input_filter() method,
Log4perl will run the message chunks through a default
input_filter(), which will just join all chunks together to a
single string (again, instead of the method we could have a filter class, like POE).


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.

Kevin and all, should we go this route or can you
think of anything else we might want in the future? Now is
the time ... any new ideas are of course welcome!

-- 
-- Mike

############################
# Mike Schilli             #
# log...@pe... #
# http://perlmeister.com   #
# log4perl.sourceforge.net #
############################