debug log infrustructure for a library

[Damien Cymbal]

Hi,

I am working on a network application library that is structured like this:

There is a series of about 10-15 utility or building-block classes
that consumers can use to get at primitive functionality for creating
their own clients.

On top of this, there is provided a client class that makes use of the
primitive classes and provides a higher level abstraction to a consumer.

What I am currently struggling with is how to perform a consistent and
useful interface for reporting debug messages to the consumer.

Initially I had a system where the consumer had a global hook that it
could set to get the messages. This works well if only one client is
in use, but it doesn't satisfy the desire to provide individual hooks
to multiple clients or threads.

Passing an actual logging reference into each component for logging
just seems way too instrusive.

I suppose this is one of those classic cross-cutting issues in software
development. Can anyone provide any added thoughts on how they have solved
this problem in the past? Any recommendations for other open-source libs
that have done a nice job of handling this that I could look at?

Thanks.

 

[Gianni Mariani]

Passing an actual logging reference into each component for logging
just seems way too instrusive.

This is the way to do it.

In a recent life we created a base class that had pointers to the
configuration and logging systems that were used to set up logging for
all the components in the system.

By providing some tools to do this mostly transparently, it worked like
magic.

Mind you, not all classes inherited from the "Environment" class. It
required design jusdgement which classes needed them and which classes
clould use it's parent. Also, to determine if somthing logged or no was
done in such a way that it could be determined from configuration
"parameters" within the class itself, so you only paid for the cost of
logging when logging was turned on. On top of that you could set a
compile time parameter that would eliminate code altogether for logging
levels you did not want in your final code.

'tis very cool. ;-)

Anyway, getting back to you question - yep - intrusive - all objects
that need to log need to know how to get to the "logging and
configuration" environment.