The routing statements are processed by the targets in order, the first matching rule will
decide a log messages fate for that target.
+
+ \section config_fallback Fallback routing
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
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.
+ message arrives in this state, the message will be logged to the console if it is above the
+ default runtime limit of it's stream. 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
AreaBase const & area, unsigned level,
std::string msg)
{
- if (fallbackRouting_)
- static_cast<Target &>(ConsoleTarget::instance()).v_write(
- (*timeSource_)(), stream.v_name(), area.v_name(), level, msg );
+ if (fallbackRouting_) {
+ if (level >= stream.defaultRuntimeLimit())
+ static_cast<Target &>(ConsoleTarget::instance()).v_write(
+ (*timeSource_)(), stream.v_name(), area.v_name(), level, msg );
+ }
else
area.write( (*timeSource_)(), stream, level, msg );
}