Closed archseer closed 10 years ago
So, this is actually the main difference between v2 and v1. If you give v2 a filename to log to, that's where it logs. There's no more generated filename, except for the backup files. You can always just look at the value of Filename on the lumberjack.Logger struct, that's where it'll log.
The only time this is not the case is if you give lumberjack an empty string and have it log to a temp file, and I don't really recommend that for production use.
Does that solve the problem?
I see, I guess it does make more sense for us to manually set the filename, especially so since we're using more than one logger in the same process, which would result in conflicts if we used the default name.
Right, this can be closed then, thank you for the help!
Hi! We over at Flynn are using lumberjack as our rolling logger for container output. I'm trying to get our codebase to use v2, as it offers a much cleaner API. This patch covers one use-case we came across, where we let lumberjack determine the filename, but we need some way to access the generated filename later in our codebase, when we're streaming back log output.