A PHP Error was encountered

Severity: Notice

Message: unserialize(): Error at offset 0 of 185 bytes

Filename: libraries/phpflickr.php

Line Number: 302

A PHP Error was encountered

Severity: Notice

Message: unserialize(): Error at offset 0 of 185 bytes

Filename: libraries/phpflickr.php

Line Number: 302

A PHP Error was encountered

Severity: Notice

Message: unserialize(): Error at offset 0 of 185 bytes

Filename: libraries/phpflickr.php

Line Number: 302

A PHP Error was encountered

Severity: Notice

Message: Undefined variable: flickr_photo

Filename: models/flickr_model.php

Line Number: 25

How to use logging in Liferay - Blog - Webdesign E-KON
No Dutch
Startpagina » Blog » How to use logging in Liferay Share/Bookmark

How to use logging in Liferay

Op 25 november 2010 door Kristof Verbraeken in categorie Liferay

How to use logging in Liferay

Why use logging?

One of the challenges in any programming environment is to be able to debug the code effectively. While developing Java applications you can print to standard output (System.out.println("This is a debug message!") to observe the execution of the program or look at the stack trace when an error (java.lang.Exception) occurs in the application or you can also use breakpoints in development tools (e.g. Eclipse).

Suppose an application is not running properly in the production environment, yet in the development, test and/or staging environment everything is working fine. If you decide to print to standard output or to a log file, you need to worry about commenting out that code in production to reduce the overhead associated with those calls.

Another solution for this is to define a Boolean variable (let’s say debug). If the value of the variable is true, the application prints a whole set of debug messages. You need to recompile the application every time you want to switch the behavior of the application. Despite the fact that this is a “better” solution then the previous one: it still remains a cumbersome approach…

So, here’s where the Java logging API comes to the rescue!

With the Java logging API you don’t need to recompile your application every time you want to disable or enable debugging. You can also set different levels for logging messages and even specify the kind of messages you want to log. You can change the runtime level of the logging information with a configuration file. This information can be written to a file, a database, a socket, a screen console or any combination of these output devices.

This way you can easily discover when and where a problem occurs within the application.

Logging in Liferay

For Liferay applications (portlet plug-ins, hook plug-ins, web plug-ins, …) you don’t need to use the Java logging API directly. Liferay contains a wrapper for this API in the com.liferay.portal.kernel.log package.

The com.liferay.portal.kernel package is compiled to portal-kernel.jar and this JAR file is put on the global class path of the application server (JBoss, Tomcat, …) by default, so every application can make use of this library.

What follows below is an example of how to use the logging in a Struts2 portlet.

package be.ekon.portlet.test.action;

import org.apache.struts2.dispatcher.DefaultActionSupport;
import com.liferay.portal.kernel.log.Log;
import com.liferay.portal.kernel.log.LogFactoryUtil;

public class ViewAction extends DefaultActionSupport {
	private static Log log = LogFactoryUtil.getLog(ViewAction.class);

	public String execute() throws Exception {
		String str = "abc";
		log.info("This is just an info message! Everything works fine!");
		log.debug("Debug info! We will use this java.lang.String: \"" 
		+ str + "\" to test our application!");
		log.warn("Warning! We come to a dangerous zone where an exception 
		can be thrown!");
		try {
			int n = Integer.parseInt(str);
			log.info("The number n is " + n + "!");
		} catch(NumberFormatException nfe) {
		} finally {
			log.fatal("This fatal message is always shown!");
		return DefaultActionSupport.SUCCESS;

As you can see, the com.liferay.portal.kernel.log.Log object is declared as a static object within the Struts2 action class. You can access the Log object in a static way. You can use this approach in any kind of plug-in for Liferay.

In the execute method several messages are sent to the log file using several methods of the Log object:

  • Log.info(Object arg0): displays an info message.
  • Log.debug(Object arg0): displays a debug message.
  • Log.warn(Object arg0): display a warning.
  • Log.error(Object arg0): displays an error.
  • Log.fatal(Object arg0): display a fatal error.

You can also provide any method above with the exception itself or the exception and your own custom message, e.g.:

  • Log.info(Throwable arg0): prints out the exception in the log file.
  • Log.info(Object arg0, Throwable arg1): prints out the exception and a custom message in the log file.

You can configure these log levels, which is discussed in this article on the Liferay Wiki.

In a production environment you probably won’t need to display info and debug messages, so you can just disable displaying this “level” of errors.

We used this kind of logging in all of our Liferay projects and along with the custom configuration is working fine for our customers.

Does anyone else have other thoughts and opinions about this approach?

I hope this post was useful to anyone.




IGC ()

Thanks, very clean explanation, that helped a lot!

Khoa ()

For instance, if LR runs throu MyCustomPortlet class(only this class), the application should log and write out a file named MyLogFileName.log. And the rest classes, it should logged into the defult LR log.

How can I config it?

Thanks a lot.

Fehri ()


Florian ()

This excellent website certainly has all the information I wanted concerning
this subject and didn't know who to ask. Maglie Calcio Inter

Reactie plaatsen

( Je email is veilig bij ons! )

A PHP Error was encountered

Severity: Warning

Message: Invalid argument supplied for foreach()

Filename: views/index.php

Line Number: 181