// $Id$
//
// Copyright (C) 2007
-// Fraunhofer Institut fuer offene Kommunikationssysteme (FOKUS)
-// Kompetenzzentrum fuer Satelitenkommunikation (SatCom)
+// Fraunhofer Institute for Open Communication Systems (FOKUS)
+// Competence Center NETwork research (NET), St. Augustin, GERMANY
// Stefan Bund <g0dil@berlios.de>
//
// This program is free software; you can redistribute it and/or modify
<em>Runtime</em> configuration on the other hand deals with routing all those messages, which
are enabled at compile time to the logging targets. If a message is not routed, it will be
discarded. This allows to additionally disable messages at run-time. Message routing is managed
- via the \ref Target interface.
+ via the \ref Targets interface.
\section config_compile Compile time configuration
The runtime configuration is performed by routing messages to one or more logging targets:
\code
- senf::log::ConsoleLog consoleLog;
+ senf::log::ConsoleLog & consoleLog (senf::log::ConsoleLog::instance());
senf::log::FileLog fileLog ("my.log");
consoleLog.route<senf::log::Debug>();
consoleLog.route<foo::Transactions, senf::log::IMPORTANT>();
fileLog.route<foo::Transactions>();
- \endcode Here we see an already relatively complex setup: All debug messages (that is, those,
- which are not disabled at compile time) are routed to the console. We also route important
- transactions to the console \e except transactions from the \c foo::SomeClass area. The \c
- fileLog simply receives all transaction log messages.
+ \endcode
+ Here we see an already relatively complex setup: All debug messages (that is, those, which are
+ not disabled at compile time) are routed to the console. We also route important transactions to
+ the console \e except transactions from the \c foo::SomeClass area. The \c fileLog simply
+ receives all transaction log messages.
The routing statements are processed by the targets in order, the first matching rule will
decide a log messages fate for that target.
+
+ There are two cases, where this setup may lead to inadvertently lost log messages:
+ \li When using a library which does internally use the Logger but not initializing the logger in
+ your application.
+ \li When log messages are created during initialization of static objects.
+ Since no route is set up in these cases, the messages will be dropped.
+
+ To counter this problem, the logger is initially in <em>fallback routing</em> state. If any log
+ message arrives in this state, the message will be unconditionally logged to the console. The
+ first routing statement on any target will take the logger out of this state and normal routing
+ will take place.
\see \ref senf::log::Target