Logging

Logging in Apache Tomcat
Logging in Liferay
Piping to Log4j using SLF4J
Using Logger

You can do logging in Vaadin application using the standard java.util.logging facilities. Configuring logging is as easy as putting a file named logging.properties in the default package of your Vaadin application ( src in an Eclipse project or src/main/java or src/main/resources in a Maven project). This file is read by the Logger class when a new instance of it is initialize.

Logging in Apache Tomcat

For logging Vaadin applications deployed in Apache Tomcat, you do not need to do anything special to log to the same place as Tomcat itself. If you need to write the Vaadin application related messages elsewhere, just add a custom logging.properties file to the default package of your Vaadin application.

If you would like to pipe the log messages through another logging solution, see Piping to Log4j using SLF4J below.

Logging in Liferay

Liferay mutes logging through java.util.logging by default. In order to enable logging, you need to add a logging.properties file of your own to the default package of your Vaadin application. This file should define at least one destination where to save the log messages.

You can also log through SLF4J, which is used in and bundled with Liferay. Follow the instructions in Piping to Log4j using SLF4J.

Piping to Log4j using SLF4J

Piping output from java.util.logging to Log4j is easy with SLF4J ( http://slf4j.org/). The basic way to go about this is to add the SLF4J JAR file as well as the jul-to-slf4j.jar file, which implements the bridge from java.util.logging, to SLF4J. You will also need to add a third logging implementation JAR file, that is, slf4j-log4j12-x.x.x.jar, to log the actual messages using Log4j. For more info on this, please visit the SLF4J site.

In order to get the java.util.logging to SLF4J bridge installed, you need to add the following snippet of code to your UI class at the very top://TODO: Sure it’s UI class and not the servlet?

  static {
    SLF4JBridgeHandler.install();
  }

This will make sure that the bridge handler is installed and working before Vaadin starts to process any logging calls.

Warning

Please note!

This can seriously impact on the cost of disabled logging statements (60-fold increase) and a measurable impact on enabled log statements (20% overall increase). However, Vaadin doesn’t log very much, so the effect on performance will be negligible.

Using Logger

You can do logging with a simple pattern where you register a static logger instance in each class that needs logging, and use this logger wherever logging is needed in the class. For example:

public class MyClass {
  private final static Logger logger =
          Logger.getLogger(MyClass.class.getName());

  public void myMethod() {
    try {
      // do something that might fail
    } catch (Exception e) {
      logger.log(Level.SEVERE, "FAILED CATASTROPHICALLY!", e);
    }
  }
}

Having a static logger instance for each class needing logging saves a bit of memory and time compared to having a logger for every logging class instance. However, it could cause the application to leak PermGen memory with some application servers when redeploying the application. The problem is that the Logger may maintain hard references to its instances. As the Logger class is loaded with a classloader shared between different web applications, references to classes loaded with a per-application classloader would prevent garbage-collecting the classes after redeploying, hence leaking memory. As the size of the PermGen memory where class object are stored is fixed, the leakage will lead to a server crash after many redeployments. The issue depends on the way how the server manages classloaders, on the hardness of the back-references, and may also be different between Java 6 and 7. So, if you experience PermGen issues, or want to play it on the safe side, you should consider using non-static Logger instances.//As discussed in Forum thread 1175841 (24.2.2012).

Docs