Boost logo

Boost :

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.


> 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

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
> 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

> 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
> 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.


John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- -v1.6.3 (Resource Splitter)
-- - Click, Build, Run!

Boost list run by bdawes at, gregod at, cpdaniel at, john at