The `dynamicLogLevel` isn't taken in account when using `swift-log` about cocoalumberjack

[ffried]

First of all thanks for a well-written issue, that clearly describes the problem and the solution you're looking for!

The reason for this is that the swift-log backend (CocoaLumberjackSwiftLogBackend) intentionally is a completely separate target from CocoaLumberjackSwift - and the latter has the dynamicLogLevel feature.
Both targets offer a different kind of "frontend" to the Objective-C target CocoaLumberjack.

swift-log states, that whether log messages are logged or not should normally not be under the control of a log handler:

This is why we don't have something like dynamicLogLevel in our log handler. The dynamicLogLevel is basically the equivalent of swift-log's Logger.logLevel property. Since CocoaLumberjackSwift does not have a Logger object, the dynamicLogLevel resides on the top level.

As for what I'd recommend:

Use dynamicLogLevel for usages with the DDLogXYZ functions only. If you need to filter log messages later on, you could e.g. configure your DDLoggers with a DDLogFormatter that simply returns nil for messages below (or above for that matter) a certain level. This results in the log message not being logged.

Another option would be what you already started: To use a subclass of DDLog and filter the messages there. I'd just recommend not to use dynamicLogLevel for filtering here, but instead add your own property for a global log level.

In both cases: make sure you do protect this "global" log level correctly against concurrent access!
Btw. this is an issue that dynamicLogLevel has at the moment: It's not actually protected against concurrent modification.

[bvirlet]

Thanks @ffried for the detailed response, I really appreciate.

We've been using dynamicLogLevel to have a "Debug log" toggle in the app so that we can get debug logs if needed from our users. So I need the debug log toggle to toggle a global state, and it should now affect both DDLogXYZ functions and the swift-log's loggers (we are progressively introducing swift-log). I'm already using a user defaults as this global state (when it's changed, it changes dynamicLogLevel), so I could read this user default in my DDLog subclass instead of reading dynamicLogLevel.

[ffried]

That sounds like a good solution. UserDefaults should be thread-safe as well.