Logging (EN)

Introduction

The project uses SL4J with the default Wildfly implementation (log4J).
Here are my best practices. Of course, those are mine, and not necessarily the bests.

Configuration

The logger is configured in the /src/main/resources/lo4j.properties file.
You can also configure it in the standalone.xml of you Wildfly server and ignore this configuration file, thus having a configuration corresponding to you environment.

In this project, for each log line, I log:

• The timestamp
• The text "QuickstartLog" which allow to easily see our log (and color them with grepConsole)
• The LOG LEVEL
• A request ID generated in RequestIDFilter
• The mail of the user sending the query if it has been authentified (fetched in AccessTokenFilter)
• The message of the log

I also log automatically every new entering requests thanks to the RequestLoggerFilter class.

Usage

@Inject
private Logger log;

public void hello(){
   log.debug("Entering hello");
}

Avoid heriting the logger. You will loose information about the class associated with the logger.

Good practices

Log level

In production, only INFO, WARN, and ERROR log level are displayed. I use the logger as followed :

• DEBUG : Used to log entering and leaving a method and every useful information for development stage.

public String printDocument(Document doc, Mode mode) {
    log.debug("Entering printDocument(doc={}, mode={})", doc, mode);
    String id = //Lengthy printing operation
    log.debug("Leaving printDocument(): {}", id);
    return id;
}

• INFO : Used when an important process is occurring and we want this information in production. ex: Starting the server and displaying the application configuration
• WARN : Used when a non critical error or a handled error occurs. This error should not block the process. ex: Wrong password when a user is connecting.
• ERROR : Used when a non handle error occurs and stop the process. Exceptions for exemple
• FATAL : Used when an error completely stop the application (very rare in web development)

Advices

• It's important to log as much USEFULL information as possible (not to much though)
• Logs must be readable by everyone (especially INFO and higher) and short.
• It's important to log the message AND the parameters in the same log line. So you don't loose parameters in the user flow in production.

FYI, I managed to remove the debugger from my tools since I'm thinking about what and how I log.

Parameterized logging

Don't use string concatenation. Your string will be built EVEN IF the log level is not enabled.

log.info("user " + username + "is now logged); // BAD
log.info("user {} is now logged", username); // GOOD

Complex parameter logging (toString)

When you want to log a complex object, you should override the toString() method, to display, for exemple the JSON representation of the object. You then pass the object as a parameter of the logger (not the toString() method !)
By passing the whole object, you execute the toString() method only when the log level is enabled.

log.info("{}", user.toString()); // BAD - toString() will be executed even if the log level is enabled
log.info("{}", user); // GOOD - toString() will be executed after the log level check

Complex parameter logging (heavy process)

When you want to log a heavy process result, which is not toString(), you must verify the log leve before:

if (log.isDebugEnabled()) {
  log.debug(user.heavyprocess());
}

Avoid NPE

A NPE in a log parameter will stop the whole process. You do not want this to happen.

log.debug("user with name {} is connecting", user.getUsername()); // Avoid it !
log.debug("user {} is connecting", user); // Better

Exception logging

Log the exception with ERROR or FATAL log level and pass the exception as the last parameter.

log.error("exception : {}", e); // BAD
log.error("exception", e); // GOOD
log.error("exception while logging user {}", user, e); // GOOD

Ressources

https://stackify.com/java-logging-best-practices/ https://dzone.com/articles/9-logging-sins-in-your-java-applications https://www.javacodegeeks.com/2011/01/10-tips-proper-application-logging.html