Hi Steve, Once I worked on a java program that controls the execution of a mathematical solver: it runs for extensive time and finishes with an output. At that opportunity, I wondered about the exactly the same logging issues mentioned by you and tried all them out. After a while, I convinced myself that typical log shall not go either to stdout, nor stderr, but preferably to a file per execution or a rolling file. For a while, I was tempted to print warn and error messages to stderr, while printing info, debug and trace messages to stdout. It sounded intuitive. However, this configuration did not evince any value to our work. I could not conceive any use case for having my log split into stderr and stdout, therefore I abandoned this approach. Even worse, if a channel is buffered, then stderr and stdout might get out of sync. That might confuse you if an error message (stderr) is print before a trace message (stdout) that describes the cause. If you run your program from a console and redirect a channel to a file, the information will be incomplete. And I think it is more value having all messages together for easier manipulation with a good log analysis tool, rather than premature separation of log messages during execution. For the same reason, I believe that stderr and stdout never should print both the same log message. Besides the issues explained above, it causes useless duplicated output. Therefore, for a "keep it simple" scenario, I would just print all log messages, regardless of log level, to either stdout or stderr. I prefer not using any of them, but a log file per execution, or a rolling file instead. One could claim the following use case: to provide user friendly messages separated from technical log messages. Note that log messages are usually not intended to be read by the user. A trivial solution would be printing user friendly messages to stdout and all log to stderr. This allows one to call the program and redirect stderr (log) into a separate file or device, while interacting with user friendly messages on the console. Be aware that his is not the intended use of stderr according to the Posix standards, though nobody would blame you. As long as well understood by the development team and your users, this could be assumed as your own standard. I used this approach for a while with reasonable satisfaction. Best regards, Daniel Felix Ferber http://techtavern.wordpress.com 2012/10/20 Steve Ramage <vcolo@sjrx.net>
**
I had a question about the conventions of logging. We have an application scientific in nature, and basically it runs some process for some amount of time, and then finishes with it's output. All output in the program is driven by logback, and we generally hide the complexity of logback from our users, and support very limited configuration as needed.
One issue is where error and warning messages should go for users.
One argument is that they should go to stderr. stdout should have INFO, DEBUG, and TRACE. There doesn't seem to be an easy way to do this in logback.
Another argument is that they should go to stderr. stdout should also have them, but also INFO, DEBUG, and TRACE. If the user is running directly then both get spammed together.
A final option is they should all go to stdout, as these are all log messages, and there is no need to split them
Now this isn't so much a religious argument, we are just more wondering what the conventions were, as we would like to follow them as much possible.
Thanks,
Steve Ramage
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user