Commit Message

Log-capturing used to set the root logger level to the configured capturing level, so that it is sufficiently low to capture the desired level.
However when the root logging level is already lower, this will in fact increase the level, changing the level of all other registered handlers.

This change fixes this: Not to directly set the root logging level, but instead only decrease it if necessary.

Discussion

Honestly, I don't think that the root level should be touched at all in here. For me it seems like that behave assumes that there will ever be only one of those 2 handlers: the capturing handler, or the default stream handler.

However, as soon as someone (like me) needs to use other handlers, such as file handlers, the root level must not be changed, otherwise those other handlers don't get to see the level they're configured for.

See the before_all() code in the feature file. This is the only way I came up with to support:

• logging DEBUG level into a file
• capturing a configured level (e.g. INFO) in capture-mode
• console output with a configured level (e.g. INFO) in non-capture-mode

Note that with this requirement I also can't use Configuration.setup_logging(), because this sets up the default stream handler which is tied to the root logging level. This function also manipulates the root level. I'm personally wondering, if this function is actually more harmful (=causing confusion) than that it is helpful. Also it hides the not too minor detail that no console handler is created (by logging.basicConfig()), when in --logcapture mode - because then, log_capture has already added a handler, and logging.basicConfig() only creates a handler when none is present yet.

Quite much hidden stuff in there... the above change (or removing setting the root logger) seems to be definitely required to allow users to manage the handlers freely.