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