[boost] [logging] Review of proposed logging library

From: Arnstein Ressem (aressem_at_[hidden])
Date: 2008-02-12 03:47:54

I have reviewed the current logging library. Some of my functional
requirements are:
- different writers: stdout, file, rolling file [OK]
- possibility to dynamically change log levels [OK]
- logging from separate modules of the code with annotation [OK]
- filtering based upon modules and levels [OK]
- possibility to adjust log levels for modules separately [OK]
- logging statements for non enabled levels should not be evaluated [OK]
- thread safety when logging from different threads [OK]
- configuration from configuration file(s) [NOT OK]
- logger hierarchies with property/config propagation [NOT OK]
- possibility to use printf syntax when logging [NOK OK]

* What is your evaluation of the design?
The logging library is very flexible and usable. It is possible to
integrate the library by using different levels of detail. In it's
simplest form it is very easy to use. When trying to use the more
advanced parts of the library, the learning curve quickly becomes
steeper (but manageable). The logging library also allows to trade off
flexibility to performance. The flexibility allows the user of the
library to write small pieces of code that can be used to implement
application specific requirements. This is important because logging
requirements will vary largely between applications.

The major parts missing are logger hierarchies with support for
configuration propagation and configuration of these hierarchies from
config files. This is a feature supported by the C++ equivalents of log4j.

The design in terms of classes and files seems fine by me. I like that
the library is headers only. The use of macros will always be a
discussion point, but it is convenient for a logging library. I do not
have big issues with this. The separation of loggers, filters,
formatters and writers appeal to me. Splitting the headers into forward
declarations and definitions is very good to reduce compile time for big
projects.

* What is your evaluation of the implementation?
I have only had a brief look at the internal implementation. Extensive
use of templates and name spaces (too much?). The author seems very
knowledgeable of C++ and the logging domain.

* What is your evaluation of the documentation?
Thorough documentation with a lot of examples and tutorials. I was able
to find what I was looking for most of the time. Maybe a bit of
reorganizing is needed because the front page seems a bit overwhelming
at first. Formalization of some sentences  and comments would be nice if
the library gets accepted into boost.

* What is your evaluation of the potential usefulness of the library?
Very useful. A good standard logging library is needed. There are a lot
of logging libraries out there, but their user bases and vitality differ
greatly. Having boost::logging would make the decision of which logging
library to use easier for a lot of developers. I would expect that the
user base of this library would rapidly grow larger than a lot of other
logging libraries.

* Did you try to use the library? With what compiler? Did you have any
problems?
I compiled the tests on CentOS 5 x86_64 with gcc 4.1. Gcc issues some
warnings about not having virtual destructors and sign mismatches. After
scanning the review threads these seems to be fixed in the svn trunk. I
had one test fail (testing.capture-output), but did not investigate this
any further.

I also did a quick spin with valgrind (3.3.0):
valgrind --tool=memcheck --leak-check=full ./mul_levels_one_logger

Valgrind reports a lot of conditional jumps/moves based upon
uninitialized values and usage of uninitialized variables. This has to
be fixed.

I adapted one application to use the boost::logging. The library seems
to work as advertised, but I had to write some filter code to adapt the
logging to the functionality needed (module annotation with different
log levels in each module).

* How much effort did you put into your evaluation?
I put about 6 hours into the evaluation.

* Are you knowledgeable about the problem domain?
I believe so. I have used different logging libraries and have written
wrappers for applications.

* Do you think the library should be accepted as a Boost library?
Yes, but compiler and valgrind warnings has to be fixed before
submission. Also all the tests must be verified to run without errors on
all supported platforms.

A big thanks to John for putting the effort into making a useful logging
library.

Regards,
Arnstein