Hello, Discussion about a logging library started over some time ago. In the vault my implementation. As for now, I am implementing some of the requirements from the boost wiki (http://minilien.com/?rQB7NorvIs): Functional Requirements 3. Eliminate log statements from generated code through the definition a macro. 4. Full lazy evaluation 5. Sinks 7. Configurable log message attributes Design Requirements 1. Configurable log message attributes 2. Macro access Here is an example of use: // Code #include <fstream> #include <logging.hpp> using namespace boost::logging; namespace bl = boost::logging; void overheat(int d) { BOOST_LOG(2, bl::log, "overheat called"); BOOST_LOG(1, bl::warning, "Warning: Tube overheat! Shutdown system immediatly"); BOOST_LOG(1, bl::error, "ERROR: tube overheat: " << d << "d C. Shutdown should follow"); } int do_something() { BOOST_LOG(2, bl::log, "do_something called"); BOOST_LOG(2, bl::notice, "do_something is performing some fancy processing (useless log don't you think?)"); return 7; } int main(int argc, char **argv) { boost::logging::logger *l = boost::logging::logger::get_instance(); boost::logging::format display_format(bl::trace >> bl::eol); boost::logging::format file_format("[" >> bl::level >> "]," >> bl::filename >> "(" >> bl::line >> ")," >> bl::time >> "," >> bl::trace >> bl::eol); // log format l->add_format(display_format); l->add_format(file_format); boost::logging::sink file_sink(new std::ofstream("./output.log"), 3); file_sink.attach_qualifier(bl::log); file_sink.attach_qualifier(bl::error); l->add_sink(file_sink, file_format); boost::logging::sink display_sink(&std::cout, 1); display_sink.attach_qualifier(bl::notice); display_sink.attach_qualifier(bl::warning); l->add_sink(display_sink, display_format); BOOST_LOG(1, bl::log, "Application starting"); BOOST_LOG(1, bl::notice, "Application version 1.0.3 - Copyright(2007) World Company"); BOOST_LOG(1, bl::log, "do_something returned: " << do_something()); overheat(87); return 0; } Standard output: Application version 1.0.3 - Copyright(2007) World Company Warning: Tube overheat! Shutdown system immediatly Content of output.log: [1],g:\projects\loglite\test\logging_test_qualifier.cpp(57),2007-Aug-23 19:44:26.411856,Application starting [2],g:\projects\loglite\test\logging_test_qualifier.cpp(26),2007-Aug-23 19:44:26.451913,do_something called [1],g:\projects\loglite\test\logging_test_qualifier.cpp(60),2007-Aug-23 19:44:26.451913,do_something returned: 7 [2],g:\projects\loglite\test\logging_test_qualifier.cpp(19),2007-Aug-23 19:44:26.451913,overheat called [1],g:\projects\loglite\test\logging_test_qualifier.cpp(21),2007-Aug-23 19:44:26.461928,ERROR: tube overheat: 87d C. Shutdown should follow I am welcoming any comment if you think it worth it. The library can be found in the vault here: http://minilien.com/?QO9kodiNIs The google code page is here: http://code.google.com/p/loglite/ The checkout the svn repository: svn checkout http://loglite.googlecode.com/svn/trunk/ loglite Note that Andrey Semashev is also working on an implementation that you can find here: http://sourceforge.net/projects/boost-log Regards, JD
JD wrote:
I am welcoming any comment if you think it worth it. The library can be found in the vault here: http://minilien.com/?QO9kodiNIs The google code page is here: http://code.google.com/p/loglite/
This site says the library is licenced under LGPL. Is this something you're considering to change? Regards Hartmut
Hartmut Kaiser wrote:
This site says the library is licenced under LGPL. Is this something you're considering to change?
The hosting solution by Google ask you to choose between some licenses, and the boost one is not in the list. I selected this one thinking it's the most permissive, but anyway, what's important is what it is stated in the source file, and it's says the library is under boost license. Regards, JD
One requirement (imo) that seems to be missing or is under-emphasized is the following: -- Provide a simple, light, "compilable away", low-dependency header / "log source" interface for middle layer general purpose libraries (e.g. many of the Boost libraries, or a third party general purpose library). Both of the current "work in progress" logging libraries seem to be going full speed ahead with a relatively full-featured logging facility, satisfying a variety of needs and requirements. This is good. But all of the example code and use cases are oriented towards end application usage. A large part of my software career has consisted of writing general purpose libraries and frameworks, where the end applications using my libraries run in a variety of environments. This is also true of most of the Boost libraries. So the "BOOST_LOG" interface should be usable in any library (including a few in Boost where it would be invaluable - e.g. Asio, or Serialization). Since a library / function using "BOOST_LOG" might be used in a single-threaded app, or might be used in debugging only (where in release mode no logging is desired), or might be used where high performance and low overhead is an absolute priority, or might be used in a non-networked environment, or might be used where "memory only" logging is available (i.e. there's not a file system available), "BOOST_LOG" (or its equivalent) should be: 1. Capable of being completely compiled away. 2. Bring in the absolute minimum set of dependencies. 3. Be completely "sink agnostic" - i.e. the output of the logging can be configured to go to any of a number of potential sinks, including no sinks. 4. Be very performant - if logging is present but no sinks are turned on, the overhead should be very small (ideally cost no more than an if statement or two). Mutex locking for multi-threading should not be performed unless logging in a multi-threaded environment (or a threaded sink / service) is turned on. Configuration of the logging environment - e.g. which sinks are turned on, which optional attributes are turned on, etc, should be a different set / layer of Logging functionality, separate from the "BOOST_LOG" / log source client interface. The end application (or some higher library layer) controls this aspect. The logging implementations so far seem to be "code only" instead of concentrating on the rationale, use cases, and client interfaces. I think there's danger of another "log library rejection" without some "stepping back and re-thinking" (and I've forgotten most of the original log library review comments - I should go back and re-read, since I'm sure I'm repeating comments already said). I'll be happy to add any of these comments to the Wiki Boost Log area - let me know (I can also assist with library requirements and design - I've designed and developed at least two logging libraries in past projects). Cliff
Hello Cliff, First, my reply will be from my library position. Sorry, JD, I didn't have time to review your latest implementation yet. Second, I'd like to thank you, Cliff, for your verbose answer. Your feedback is very appreciated.
One requirement (imo) that seems to be missing or is under-emphasized is the following:
-- Provide a simple, light, "compilable away", low-dependency header / "log source" interface for middle layer general purpose libraries (e.g. many of the Boost libraries, or a third party general purpose library).
My implementation has the concept of sources, and loggers model it. Do you mean that loggers may be inappropriate to be used in libraries? If so, why? BTW, although it is not ready yet, I'm planning to implement both the "complile-away" and "single-threaded" features.
The logging implementations so far seem to be "code only" instead of concentrating on the rationale, use cases, and client interfaces. I think there's danger of another "log library rejection" without some "stepping back and re-thinking" (and I've forgotten most of the original log library review comments - I should go back and re-read, since I'm sure I'm repeating comments already said).
I'll be happy to add any of these comments to the Wiki Boost Log area - let me know (I can also assist with library requirements and design - I've designed and developed at least two logging libraries in past projects).
I can assure you, there was a considerable discussion on the requirements to the logging library Boost needs. We considered previous submissions reviews too. This resulted to Wiki page here: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Logging with all major corner stones and even some discussions. I think, many of your requirements are listed there - I'd be glad if you review this page and post your vision on it. You may also add your comments there too. -- Best regards, Andrey mailto:andysem@mail.ru
On Thu, 23 Aug 2007, JD wrote:
Discussion about a logging library started over some time ago. In the vault my implementation. As for now, I am implementing some of the requirements from the boost wiki (http://minilien.com/?rQB7NorvIs): ... I am welcoming any comment if you think it worth it. The library can be found in the vault here: http://minilien.com/?QO9kodiNIs The google code page is here: http://code.google.com/p/loglite/ The checkout the svn repository: svn checkout http://loglite.googlecode.com/svn/trunk/ loglite
Note that Andrey Semashev is also working on an implementation that you can find here: http://sourceforge.net/projects/boost-log
How do your projects compare to other logging frameworks? e.g. http://pantheios.sourceforge.net/ I've never tried this one, but they do have pretty plots comparing various frameworks. Just curious, Daniel
Hello dherring, Saturday, August 25, 2007, 12:43:11 AM, you wrote:
On Thu, 23 Aug 2007, JD wrote:
Discussion about a logging library started over some time ago. In the vault my implementation. As for now, I am implementing some of the requirements from the boost wiki (http://minilien.com/?rQB7NorvIs): .... I am welcoming any comment if you think it worth it. The library can be found in the vault here: http://minilien.com/?QO9kodiNIs The google code page is here: http://code.google.com/p/loglite/ The checkout the svn repository: svn checkout http://loglite.googlecode.com/svn/trunk/ loglite
Note that Andrey Semashev is also working on an implementation that you can find here: http://sourceforge.net/projects/boost-log
How do your projects compare to other logging frameworks? e.g. http://pantheios.sourceforge.net/
I've never tried this one, but they do have pretty plots comparing various frameworks.
Yes, I've considered this library: http://article.gmane.org/gmane.comp.lib.boost.devel/157288 -- Best regards, Andrey mailto:andysem@mail.ru
participants (5)
-
Andrey Semashev -
Cliff Green -
dherring＠ll.mit.edu -
Hartmut Kaiser -
JD