log: Avoid side effects by using own logger instance - fixes #8907 #8908
Conversation
ncw
left a comment
There was a problem hiding this comment.
Thanks for fixing this. Using rclone as a library is probably the least well supported way of using rclone but we need to play nice if people do :-)
I put some queries inline.
| h := NewOutputHandler(os.Stderr, opts, logFormatDate|logFormatTime) | ||
|
|
||
| // Set the slog default handler | ||
| slog.SetDefault(slog.New(h)) |
There was a problem hiding this comment.
If we don't call this then rclone or any of its dependencies won't get properly logged if they are using log.Print or log.Fatal.
From the docs
Setting a logger as the default with
slog.SetDefault(logger)will cause the top-level functions like Info to use it. SetDefault also updates
the default logger used by the log package, so that existing applications that
use log.Printf and related functions will send log records to the logger's
handler without needing to be rewritten.
There was a problem hiding this comment.
I do understand, however, we are using rclone as a library and overriding the default slog logger will mess with all our logging and causes the issues mentioned in #8907.
How about we are setting this handler the default from the rclone application? I can add a function to fs...
Just for protocol, using a default logging facility in a library is bad style and should be avoided. Add a logger interface and allow overriding the logger in the library and then set that logger from the application is a much better pattern as it allows the application to choose how to log stuff.
| slog.SetDefault(slog.New(h)) | ||
|
|
||
| // Make log.Printf logs at level Notice | ||
| slog.SetLogLoggerLevel(fs.SlogLevelNotice) |
There was a problem hiding this comment.
I don't see an equivalent for this line in your patch? Unless the Default logger is Notice level which I don't see in the docs?
There was a problem hiding this comment.
Well this line overrides the log-bridge of slog! This should not be done within the library but rather in the application so others can use the library without their logging being changed...
|
Any thoughts on the review notes @srebhan ? I think this is an important fix but I want to make sure we get it right. |
|
I responded to your comments @ncw. I see your point of this PR changing behavior but the current approach is somewhat limited due to the structure. I could put up a PR reworking logging such that the logger can be customized from the application and is not defined in the library itself. What do you think? |
What is the purpose of this change?
Commit dfa4d94 replaced the old logging with the more modern
slogpackage. However, this change is intrusive for applications usingslogas their default logging facility, causing side effects and a fragile construct when usingsloglogging with custom output functions.This PR sets up a custom logger, avoiding side effects from overriding the
slogdefault logger.Was the change discussed in an issue or in the forum before?
resolves #8907
Checklist