Java logging in development and production

Logging is tricky. Even some major open-source projects don’t do it correctly, so if you use their libraries, you end up with log files you didn’t ask for cluttering your machine.

Current best practices are to use a logging facade like commons-logging or slf4j to avoid these kind of problems by allowing libraries to conform to whatever logging strategy the application which uses the library is using. This means that if your app logs to myapp.log, then the library using slf4j will also log to myapp.log.

Here’s how we use slf4j in our projects:

Our libraries use slf4j-api – here’s the maven dependency you’ll need:


Our applications use slf4j-log4j12 – here’s the maven dependency you’ll need:


The code to log looks like this (its the same in libraries or applications):

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class MyClass {
	static Logger log = LoggerFactory.getLogger(MyClass.class);

	public Application() {"some logging info");

We want to have simple console logging during development. To do this we use a simple file containing only a console appender as shown below.

log4j.rootLogger=INFO, Stdout
log4j.appender.Stdout.layout.conversionPattern=%-5p - %-26.26c{1} - %mn

We put this file in a Settings folder in our home directory.

During development we need to get log4j to load this file so we get console logging. We do this by defining a system property “log4j.configuration” in the Eclipse Preferences/Installed JREs/Edit/Default VM Arguments (that way it applies for all development projects):


During production, we do this same thing, but this time we pass a log4j configuration with a rolling file appender as shown below:

log4j.rootLogger=INFO, R
log4j.appender.R.layout.ConversionPattern=%d %p %t %c - %m%n

So the startup in production looks something like this:

java -Dlog4j.configuration=file:///home/administrator/ -jar myapp.jar

Leave a Reply

Your email address will not be published.