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.

logger A C++ instance of a class derived from Logger, which is used by

Yup the OW code to output log messages.

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

Not sure why needed, I have appenders and modifiers. possible components.

Examples include "owcimomd", "owcimomd.http_server",

"owcimomd.http_server.local_auth", "vintela.computer_system_provider".

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

I assume this is equivalent to "log names", in my lib. 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.

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

Yes, I need to implement this ;) 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.

- Ability to configure a log for each component. e.g. A specific

Yup, need to implmement this. 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/P...)

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!