a) All logging goes via a Logger singleton.
In contradiction to Darryl Green ;)
b) The output destination of the Logger is configurable at runtime. We currently have LogOutputters for file, console, and network. These LogOutputters are roughly equivalent to your appenders.
Yup
c) All log messages belong to a particular topic. Topics are arranged hierarchically, which is important when considering log levels.
Yup, just like what I use as log names.
d) All log messages also have a particular log level. These range from 'CRITICAL' all the way down to 'DEBUG4' (yes, we have four different levels of debug messages). Log levels and log topics are orthogonal to each other.
To do
e) A particular log topic can have a minimum log level specified, and any messages on that topic with levels below that level will not be logged. If a log topic does not have a level explicitly set, it inherits its level from its parent in the hierarchy, working its way up the tree until it finds a topic that has a level set. Hence, topic '/sm/message/builder' will inherit from '/sm/message', and if that has no level set then they both inherit from '/sm'. The root topic always
Yes, exactly how I've implmemented log hierarchies now. This will also apply to levels (that is, if you set the level for "app", "app.debug" will inherit it, unless you specify it specifically)
has a level specified, even if it is the default of 'INFO'. Note that in our scheme it is impossible to turn off CRITICAL messages.
I will want to allow turning off certain logs (that is, setting their level to DISABLED). If so, all messages will be ignored. In case you have CRITICAL messages, I assume they will go to 1 or 2 logs, which I assume you'll never turn off.
g) Log messages are sent to the LogOutputters in a structured format, with date/time, pid/tid, topic, level, and message all seperate. The LogOutputters determine how these values are formatted.
Have you taken a look at how the Logging Lib does this right now (modifiers/appenders)? Does it seem ok as is?
h) We have the ability to adjust log levels by topic while a program is running.
Will be there.
i) As a corollary to (h), and in contrast to what a lot of people have said, we do *not* turn off logging in our production code. However, note that all our programs are strictly 'in-house' so this is probably an unusual requirement.
Nor do I turn it off. But a lot of people have asked for this feature, so I implemented it.
j) We do not do any kind of log rotation within the logging system itself. However, we do have external programs that rotate logs for us on a daily basis, and our file LogOutputter has the ability to insert a timestamp into a logfile name or append rather than overwrite on startup.
There's log rotation in the latest version. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter) -- http://www.torjo.com/cb/ - Click, Build, Run!