-
Notifications
You must be signed in to change notification settings - Fork 301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different log levels for different groups of loggers #215
Comments
As I'm working to implement this functionality in my own LogHandler, I realize that the LogHandler's |
These are good points which I totally agree with. In my project I tried to start repeating it like: At a main entry point
in my classes
I've planned to add a YAML-config parser which extracts a logger config and to update LoggingSystem.bootstrap that it will set a log level for a passed label comparing it to configured labels on YAML. |
I got some of the behavior I wanted with this class. If you create loggers with dotted names (e.g. LogHandlerCoordinator.instance.set(rootThreshold: .debug)
LogHandlerCoordinator.instance.set(threshold: .warn, for: "com.mycompany.myapp.section1") |
@JetForMe as you discovered already this would be a function of the log-backend and not the log-api (this library). for example, https://github.com/apple/swift-log/blob/main/Tests/LoggingTests/TestLogger.swift#L57 is a test log-backend that does a simplified version of this approach. of course, we would need a good log-backend that does this well. the log-backend that is included in swift-log is for development only and should not be used for real production applications |
One of the powerful features of Java's log4j is that different logging levels can be set for large swaths of the code. This is accomplished with a couple of things:
myapp.app.model.entities.Employee
myapp.app.model
should log at TRACE, everything else at ERROR.These levels can be set at run time, making it easy to turn up or down the logging on parts of the code you need to focus on, without obscuring the output with too many messages from uninteresting code.
I don't see a way for swift-log to do that.
The text was updated successfully, but these errors were encountered: