Boost logo

Boost :

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-08-15 22:20:27


Darryl Green <darryl.green <at> aanet.com.au> writes:

>
> I think what is needed is a set of connections (logs connect to
> appenders/modifiers) ordered by the log name which may include wildcards. Log
> name (segments) containing wildcards should be ordered before exact names so
> the more specific rules override the less specific ones.
>

I'm putting together an alternate manager to implement something like the above.

The semantics will be that you specify logging rules like:

// create/register (but don't connect to any logs) an appender
log_appender("display") = write_to_cout;
log_appender("bazfile") = write_to_file("baz.log");

manipulate_logs("foo.bar.*")
   .connect_appender("display");

manipulate_logs("foo.bar.baz")
   .disconnect_appender("display")
   .connect_appender("bazfile")

// one can delete the actual appender
// which will disconnect it first!
log_appender("display").erase();

The connecting/disconnecting of appenders maintains a (per appender) set of
rules for matching logs. The size of the rule set is bounded (assuming the set
of log names is) by removing redundant rules whenever a modification to the
rule set is made. The rules are applied in the order they are specified.

Clearly this means changing manipulate_logs, and changing the manager
concept/interface. I'm finding it hard to see how a really "alternate" manager
could be written given the rather restrictive set of required interfaces. I
think manipulate_logs() should simply provide access to completely manager
defined functionality.

I also find the manipulation of logs by specifying the pattern to match a
number of logs, then applying a number of appenders to them to be less than
appealing, I think the "inverse" interface should also be provided ie.

appender("display")
   .connect("foo.bar.*")
   .disconnect("foo.bar.baz");
appender("bazfile")
   .connect("foo.bar.baz");

Would have the same result as the manipulate_logs lines above.

I'll include this too.

Darryl Green.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk