It would be good to externalize and internationalize the messages too. Cheers,
Greg Trasuk. On Feb 12, 2014, at 6:33 PM, Dennis Reedy <dennis.re...@gmail.com> wrote: > While we're bringing up topics to discuss, I thought I'd throw this one out > there. Deploying systems into production (or just into serious test mode) > always brings up one issue pretty much consistently. What to do about > logging? The same questions/issues always seem to come up: > > - How do I know what went wrong and where? > - How do I get access to the service logs being created at each individual > machine? > - Can I trace an invocation across services (that might be on different > machines) using log messages, and how? > > I've transitioned over to SLF4J sometime ago, and found the options available > using either Logback or Log4J to completely outshine any capabilities of > java.util.logging (j.u.l), and start to make the above questions addressable > (without having to write your own customized logging framework). Some of the > top advatanges I've found are: > > - Pick the logging system at deploy tie (Logback,Log4J, j.u.l) > - Choice of appenders that are available to do log consolidation & management > - Better configuration for logging and loggers > - Having mapped diagnostic context available (if the underlying logging > system supports it as logback and log4J do) > - Performance advantages that logabck and Log4J offer > > For River to be a key player in the enterprise, it has to be able to use > logging framework that allows better management, visibility and control. For > that reason I'd like to suggest that we move River away from j.u.l to SLF4J. > > Regards > > Dennis >
