[boost] logging v1.4 - some comments

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-08-08 00:27:12

Excuse the break in threading - gmane has lost/missed a lot of boost traffic.

Hi John,
I've only had a quick look at the latest version:

The m_destroyed hack needs to go - this should only be relevant for static (not 
scoped) logs and the real issue is that you need to do thread-safe singletons - 
ie. you need to use posix call_once or equivalent to contstruct the thing. 
Destruction is a bit tricky - not doing it seems a reasonable option, though 
stopping leak detectors from compaining would be nice.

The scoped log stuff doesn't seem to have been updated to support levels yet - 
in fact I'm not sure if it currently works?

I think (fancy that - given the way it was in analog ;-)) that the named 
appenders need to be managed - currently, you can create multiple appenders 
with the same name, then when you delete by name you delete all appenders with 
that name. I don't see the utility of that model, which when combined with the 
wildcard matching is really fairly hard to use. For example, suppose I have an 
appender that logs to some sort of display for "real time" tracing. First off, 
I say:

manipulate_logs("error.*").add_appender(displaywrite, "display")

Then I notice an error about some component foo and decide to look at more 
detail about foo:

manipulate_logs("*.foo").add_appender(displaywrite, "display")

Now I get anything logged to "error.foo" written to "display" twice.

I then say:

manipulate_logs("error.*").del_appender("display")

Because I want to concentrate on "foo" only. Now I find I don't get errors from 
foo displayed, only other less critical messaages.

Then, foo goes out of scope (it's a scoped log), only to come back into scope 
again. When it does, and it generates an error, I'm (not really) suprised to 
see it sent to "display"....

As the purpose of named appenders is to facilitate runtime modification of the 
appender set, surely the ability to make these modifications using *only* the 
name is reasonable. The fact that add requires a function while del only needs 
a name only highlights this.

Regardless of what the rules for combining appenders/modifiers/enabledness are, 
they need to be consistent and to work across scoped logs going in/out of scope.

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.

Note the above was from reading the docs + code - I haven't tried running it 
yet, and maybe I'm misunderstanding something.

Regards
Darryl.