Blogs

Before starting this post I would like to recall a previous excellent article of Brett Swaim "Using log4j to ensure each portlet has it's own log file". In his post Brett summarizes (look at the article and comments) pros and cons of Log4j versus Liferay Logging Framework as the logging API to use in your custom plugins (portlets, web, hooks and so on).

In this article I would like to describe the SLF4J alternative. Starting from version 6.1.0 GA1 (LPS-24342) Liferay introduced SLF4J (http://www.slf4j.org) and the related Liferay Logging Framework SLF4J Adapter.

The combination of the two brings many benefits; in particular you can achieve:

• SLFJ4 API:

  • the SFL4J logging API to ensure portability

  • SFL4J can safely be used with service builder

• Liferay Logging Framework SLF4J Adapter:

  • adjust the logging on the fly through Control Panel

  • configure custom plugin logging without modifying portal files

  • let your plugin log in it's own separate log file

• Log4j and extras (Liferay Logging Framework relies on it):

  • format your log strings

  • rotate your log file

  • compress your rotated log files and store them in a separate directory.

Using SLF4J in your custom plugins

To use SLF4J in your portlets or in general in Liferay plugins, you just need to:

• Add SLF4J to your imports and declare a logger

• Add SLF4J dependencies to your plugin. You can do that manually copying slf4j-api.jar and util-slf4j.jar (the Liferay SLF4J adapter) into your plugin WEB-INF\lib directory or include them as portal dependencies in liferay-plugin-package.properties (Liferay will add it for you during the auto deployment phase - if you are using Maven just add them as provided dependencies).

Let your plugin log in a separate file without modify portal files

During hot deployment phase Liferay checks if “META-INF/portal-log4j.xml” exists in the classpath of your custom plugin (just create it under /WEB-INF/classes/META-INF/portal-log.xml). If it exists, the Liferay plugin hot deploy listener invoke the initLogger() that will reinitialize the Liferay logging system merging your appenders with those defined in Liferay.

To get it working successfully avoiding Log4j classloader exceptions (LPS-9376) you need to remove the log4j dependency from your plugin (or start your JMV with the system property -Dlog4j.ignoreTCL=true).To prevent Log4j being copied to WEB-INF\lib during the auto deploy process, there are couple of alternatives:

• add auto.deploy.copy.log4j=false to your portal-ext.properties (affects all plugins)

• add deploy-excludes=**/WEB-INF/lib/log4j.jar in the liferay-plugin-package.properties file of your plugin (affects only your plugin)

Leverage Log4j Companion Extras to format, rotate and compress rotated files

As you probably already know Liferay Logging Framework is based upon Log4j 1.2.x. Starting from version 6.1 (LPS-18970 and LPS-33129) Liferay introduced the Log4j Extras Companion handling its deployment in custom plugins as well. (Apache Extras Companion for Apache log4j is a collection of appenders, filters, layouts, and receivers for Apache log4j 1.2 originally developed in the discontinued Apache log4j 1.3 and backported to 1.2).

Then you can take advantage of:

• TimeBasedRollingPolicy, that offers:

  • automatic file compression. This feature is enabled if the value of the FileNamePattern option ends with .gz or .zip

  • decoupling the location of the active log file and the archived log files. Setting the ActiveFileName option you can decouple the location of the active log file and the location of the archived log files.

• EnhancedPatternLayout: A flexible layout configurable with pattern string. The goal of this class is to format a LoggingEvent and return the results in a StringBuffer.

You can find a working slf4j sample portlet here: https://github.com/denissignoretto/slf4j-logging-sample-portlet

Hopefully this article helps and expands the range of choices for logging in your Liferay projects !

Denis.