One of the nice things about having deployed to a Java Application Server (Wildfly, in my case) was that it handled logging, creating a server.log, console.log, and audit.log files. I’m beginning a slow look at moving to a raw uberjar-based deployment method and will need to be on top of my logging (for which I’ll use Timbre). I’ve previously received some great answers about logging libraries and calls, but now I would like to know more about the IO choices people have made, and any “hows” necessary to describe those choices. For example, what logs do you write to disk and do you share them between applications? How do you perform log rotation (which is beyond the scope of libraries like Timbre)? How do you use log levels as part of this?
We switched from Timbre to log4j2 and adapters that route everything through that – so all of the “best practices” of Java logging apply and there’s plenty of material out there about that.
We switched because Timbre is really a bunch of “magic” and non-standard in the greater JVM ecosystem. We also wanted to trim our long list of dependencies and Timbre brings in a whole bunch of utility libraries from the same author.
1 Like
Any favorite sources that describe your logging setup? I assume you set all the configurations through xml?
We use .properties files (and we have several variants on the classpath – from our app’s resources folder) so we can specify different property files via JVM -D options. I’m allergic to XML 
I mostly stuck to the log4j2 docs but I think I found a couple of Java-related blogs about logging best practices as well. I don’t remember which ones (I just did a Bing search at the time and browsed several results).
1 Like
For those who may visit here to read this, here are some links I found useful:
1 Like
I’d second the use of log4j2 with tools.logging. Works great. Logback is also a good choice, and has nice documentation.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.