Boost logo

Boost :

From: Spencer.Collyer_at_[hidden]
Date: 2005-05-04 03:52:04


> >Thanks!!!
> >
> >Also, an application should have multiple levels at the same
> time (i.e.,
> >an app may want to have a different level of debug logging per
> >component, library, class, whatever).
> >_______________________________________________
> >
> >
> This is an interesting request, and I assume it'll change the way I
> implement multiple levels.
>
> Is this a desireable feature? What do you all think?
>
> In other words, if I understand correctly, you want to be able to set
> the level of each log (independently of other logs).
> In this case, instead of enabling/disabling logs, I can
> simply set the
> level of the logs -- and have a level called DISABLED (which is
> equivalent to disabling one log)

Just de-lurking for a moment here, but I'd like to add my vote for a
form of this.

At my work we have a logging library that has concepts of log topics and
log levels. These are orthogonal - any particular log message is
associated with one topic and has one level, but the messages for a
given topic can have any level specified. The topics are arranged in a
tree-like hierarchy, and if a minimum logging level is specified for a
topic it also affects any subtopics of that topic which have not had a
logging level specifically set.

This allows us to easily tune the amount of logging information produced
so that only the items we are specifically working on get logged at a
high debugging level, without interference from components we are not
interested in. This makes tracking problems considerably easier, as only
the relevant information is output.

Just my twopen'orth.

S>

------------------------------------------------------------------------
For more information about Barclays Capital, please
visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays
Group does not accept legal responsibility for the contents of this
message. Although the Barclays Group operates anti-virus programmes,
it does not accept responsibility for any damage whatsoever that is
caused by viruses being passed. Any views or opinions presented are
solely those of the author and do not necessarily represent those of the
Barclays Group. Replies to this email may be monitored by the Barclays
Group for operational or business reasons.

------------------------------------------------------------------------


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk