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.