improve logging system to nicely play with log4cxx
|Target version:||Robotics Service Bus - rsb-0.18|
Current implementation of logging doesn't play nice with log4cxx,
i.e. a LoggingSystem that already provides hierarchical loggers.
In this case explicitly setting the log levels down the hierarchy,
overrules any settings made in log4cxx's own config files.
- loggers are created lazily on demand
LoggerTreeNodemaintains the hierarchy (and explicitly set log levels).
However, Loggers themselves will be only created by
LoggingSystem::createLoggerexpects second argument now with desired log level.
LoggingSystems like log4cxx want to ignore this argument, but rely on their hierarchy.
LoggingSystem::needsRecursiveLevelSetting()is used to choose
- recursive TreeLevelUpdater for non-hierarchic LoggingSystems
- SimpleLevelUpdater for hierarchic systems
- Do not use shared_ptrs for
This was only used to know whether a level was explicitly set. Use a bool instead.
parentLevelargument was never used --> removed, can be retrieved by
- visiting includes called node -> reduces code duplication
As long as no log levels are set explicitly by rsc means, the
LoggingSystem can continue to use its own configuration mechanism.
setLevel() overwrites these settings, but only for the current node.
#4 Updated by J. Wienke over 6 years ago
- % Done changed from 90 to 50
I am not exactly sure about the consequences of this as this would effectively result in two different places that can be used to define logger levels. The current logging API was designed so that implementors of
LoggingSystem instances never need to think about the hierarchy of loggers. This was all performed externally and
LoggingSystem@s merely serve as output devices (and formats). Therefore, the intended separation of concerns is that the RSC configuration mechanism defines the levels and their heirarchy and @LoggingSystem instances deal with the question of how to output logging systems to somewhere.
With your proposed changes, this separation of concerns is washed out since now also logging systems can and define the levels and their hierarchy and I suspect that there are many corner cases and conceptual things that can be overlooked when doing so. Moreover, it might be harder to understand for users which part effectively defines the level of a logger. One corner case we already saw in your code is that it is now possible to define levels with log4cxx that are not visible in RSC at all, because
LoggerProxy::getLevel never asks the real Logger implementation for the level. This way, logging statements might even be unintentionally missed because client code can make the generation of strings for logging dependent on the effective level of a logger to prevent unnecessary computational load.
But to prevent all these complicated details, we should first find out why this approach actually necessary at all: Why do you think is it necessary to also define effective levels with log4cxx configuration files? Or stated the other way around: Isn't it sufficient to define levels via the RSC config and only define output formats via the log4cxx configuration?
Apart from that I am fine with 240b4175 and have committed this one on master