Re: [boost] Logging library - your own scenario!

From: John Torjo (john.lists_at_[hidden])
Date: 2005-05-21 22:59:47

Dan, thanks for your thorough feedback!

 >>
 >
 > Here's what OpenWBEM does.
 >
 >
 > ------------------------------------------------------------------------
 >
 > 
-----------------------------------------------------------------------------
 > Definitions:
 > log
 >     n. The end-point that log messages are sent to.  Examples include 
a log file, syslog and the console.
 >     v. The act of generating and outputting a message. e.g. The error 
message was logged.
 >

Yup

 > logger
 >     A C++ instance of a class derived from Logger, which is used by 
the OW code to output log messages.
 >

Not sure why needed, I have appenders and modifiers.

 > component
 >     A string identifying the logical grouping of code within OW that 
generated a log message.     It is useful to organize components 
hierarchially, using a "." to separate ancestor and descendent.     The 
hierarchy is meaningless to OW from a configuration or API point of 
view, but it is helpful for log processing.
 >     The component "*" is reserved for configuration to mean all 
possible components.
 >     Examples include "owcimomd", "owcimomd.http_server", 
"owcimomd.http_server.local_auth", "vintela.computer_system_provider".
 >

I assume this is equivalent to "log names", in my lib.

 > category
 >     Associated with a message to indicate attributes of the log message.
 >     Also commonly refered to as log levels.
 >     The category "*" is reserved for configuration to mean all 
possible categories.
 >     Examples include Debug, Info, Warn, Error, FatalError, Trace, 
AuthenticationFailure, etc.
 >     The 4 categories "Debug", "Info", "Error", "FatalError" are 
treated as levels for configuration purposes.     If a log is configured 
for Debug, all 4 categories will be output.
 >     Otherwise there is no relationship between categories.
 >

Yes, I need to implement this ;)

 > message
 >     The text of a message. A message has the following attributes: 
component, category, source filename, source line number, date/time, 
process id, thread id.
 >

By default, I use a simpler approach (that is, the text is a string), 
but you can specify a custom log manager, and configure it to keep most 
if not all of the above.

 > message format
 >     A pattern which indicates the format of the log message and 
associated attributes.

In my case, "modifier" functions.

 >
 > 
-----------------------------------------------------------------------------
 > Feature requirements & Use case list:
 >
 > - Ability to log all messages at or below a threshold (one of the 4 
predefined categories) into a log.
 >

Yup, need to implmement this.

 > - Ability to configure a log for each component.  e.g. A specific 
provider's messages all go to a log. The log only contains the 
provider's messages.
 >

Already exists.

 > - Set different thresholds for different components of the cimom. 
e.g. If I'm interested in debugging one specific component, I can turn 
on debug logging for that specific component (say my provider I'm 
working on) and not have to wade through tons of other unwanted debug 
messsages.

Need to implement it.

 >
 > - Ability to configure a log for a specific category.  e.g. The error 
messages from all components go to a log.

Not sure I understand here. Could you give me an example?

 >
 > - Ability to configure a log with a "component"/"message category" 
combination. e.g. auditing of authentication: it would be nice to be 
able configure logging of all authentication failures and/or successes, 
and nothing else, to a certain log.
 >

So far, you can configure per "component".
For each "component", you'll be able to set a "message category" for 
which messages are logged. Messages below and with this category are 
logged, while messages above this category are ignored.
Setting the "message category" to DISABLED will ignore all messages that 
are sent to this log.

 > - User-defined logfile formats. Use the same formatting rules as log4j
 > (or log4perl, like specified at
 > 
http://search.cpan.org/~mschilli/Log-Log4perl-0.48/lib/Log/Log4perl/Layout/PatternLayout.pm)
 > Available data includes: [date and time] [pid/thread-id] [category] 
[component] [log message]
 >

You can do this with modifiers. In the future, I plan to create a small 
library on top of logging lib, which will make it very easy to define 
logfile formats, and configure logging.
(I say in the future, because I don't think I'll have the time to finish 
it in time for the review)

 > - Ability to output to a log that can be processed by log4j 
compatible log
 >   processing tools (e.g. Chainsaw)
 >

Hmmm... Need to dig into this...

 > - Ability to configure the console logging when the cimom is run in 
debug mode
 >   (with -d)

What's cimom?
I've looked on the web, is it "Common Information Model
Object Manager (CIM OM)."? (did not have time to do some heavy searching 
though)

 >
 > 
-----------------------------------------------------------------------------
 > On to the design:
 >
 > Each log message will have an associated component, category, source 
filename, source line number, date/time, process id, thread id.
 >
 > { "Debug", "Info", "Error", "FatalError" } are the set of predefined 
message categories.  This set may be treated as levels, so that a 
message with a higher level category is also considered matching a lower 
level category (i.e. a FatalError is also categorized as a Debug level). 
Additional categories may be used, but they are independent of any other 
category. They are also the most commonly used, so the API will have 
convenience functions for them.
 >
 > A log is configured with a name, components, categories, format, type 
and any specific logger information such as a filename. If a component 
== "*", then it will match all components.  If a category == "*", then 
it will match all message categories.
 >
Yup, will do.

 > For owcimomd, there is a predefined log named "main". The 
owcimomd.log_level and owcimomd.log_location config items will be 
deprecated but still supported, and they will affect this log if set.
 >
 > For owcimomd, there is a predefined log named "debug". This log will be
 > enabled when owcimomd is run with a -d.  The default will be all 
categories
 > and levels.
 >
 > When a message is sent to a logger, it will be evaluated against each 
log's configuration and if it matches, the message will be formatted 
according to the format configuration and output to the log.
 >
Need to dig deeper, to see what you mean.

 > 
-----------------------------------------------------------------------------
 > Configuration
 > [...]

As said, I'd like to create a small lib on top of logging lib, to allow 
such easy configuration.

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!