Implementing UpgradingProcess for your Liferay Portlets!

Company Blogs March 30, 2010 By Ryan Park Staff

This is a short 2 step (rather large step) tutorial on how to implement a way to upgrade your Portlets using hooks and Liferay's UpgradeProcess. I'll also assume that you've created your portlet in our Plugins SDK.

Step 1 - Settings

First, we'll need to modify liferay-hook.xml to point to a so that we can tell Liferay what the build number of our portlet is and what classes to run as part of our upgrade process. After we define some properties, Liferay will take care of the rest and the upgrade will be trigged when we deploy our portlet. So to begin, navigate to: my-portlet/docroot/WEB-INF/ and find liferay-hook.xml.

If you do not have one create one! Then copy and paste the below lines in. If you already have a liferay-hook.xml. Make sure that the portal-properties element is set.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hook PUBLIC "-//Liferay//DTD Hook 6.0.0//EN"


Next navigate to your If you've just created your liferay-hook.xml and you've used the code above, you'll need to create one at my-portlet/docroot/WEB-INF/src/ In this file, we'll set the following:


Read below for the descriptions for each property. Set this value to the current build number of your portlet. Hopefully your projects build number increases as you release because making this value decrease is specifically coded to not work :) In other words, Liferay assumes that the latest build will have a higher build number and your portlet not upgrade if the build number of the newly deployed portlet is less than that of the old portlet. For portlets that do not have a release build number already stored in Liferay, this is the value that your newly deployed portlet will assume the old portlet's build number was. Therefore, set this value to the build number of the previously deployed portlet thereby causing the proper upgrade classes to run. For new deployments, I recommend that you set it to the same value as so that no upgrade classes run.

upgrade.processes This is a comma delimited list of classes that will run when you deploy your portlet according to the build number associated with the class. Please put your classes from least to greatest as they will run in order. This is important if you want to upgrade from build 100 to 150 because running them out of order will cause errors if the running script depends on the last script.

What we can assume from the sample file is that the upgrade process is to assume that the previous build number was 100 if it is not already defined by the last portlet deployed. We also see that the current build number is 110 and that we expect park.ryan.hook.upgrade.UpgradeProcess_1_1_0 to run if the build number is less than 110.

Step 2 - Upgrade Classes

Next we'll discuss the UpgradeProcess_1_1_0 class. This is the class that we told Liferay to run as part of our upgrade process in the property, upgrade.processes. So let us create a Java file in /docroot/WEB-INF/src/park/ryan/hook/upgrade/ and name it

package park.ryan.hook.upgrade;

import com.liferay.portal.kernel.upgrade.UpgradeProcess;

public class UpgradeProcess_1_1_0 extends UpgradeProcess {
	public int getThreshold() {
		return 110;

	protected void doUpgrade() throws Exception {
		// your upgrade code here.

Without getting into the workings of Java, your upgrade class will extend the Liferay's abstract class UpgradeProcess. 2 methods need to be overwritten for this class to be useful.

getThreshold() This method should simply return the build number that this class is going to upgrade to. If the current build number of your portlet is greater than this value, this upgrade class will be skipped over and will move to the next one defined by upgrade.processes. After successful completion, the release build number for your portlet will be updated with its new build number. In our example and assuming a build number is not saved, this class will run because the property for the previous build number was set to 100 and after completion of the upgrade the build number will be set to 110.

doUpgrade() Don't write anything in this method, this method will never ever run :)

Just kidding! This method, like its name implies, will do the upgrade. So, all your upgrade code will be entered in here. That's pretty much it for using UpgradeProcess in your portlets but as a bonus I'll give an example on how to add a column to your database and to set a default value.

protected void doUpgrade() throws Exception {
	runSQL("alter table sampleUpgradeTable add sampleUpgradeColumn LONG");
	runSQL("update sampleUpgradeTable set sampleUpgradeColumn = 0");

Notice that there are keywords such as LONG that will be translated for the appropriate DB connected to Liferay. For example in mysql, "LONG" will become "bigint". Pretty nifty and simple to implement stuff if you ask me.

A Quick Recap

Defining the appropriate properties in will trigger the upgrade process for your portlet. When these keys are defined, Liferay will look for the upgrade classes you've set and written to do the upgrade. After successful completion of the upgrade, the portlet will finish deploying (hopefully to a nicely upgraded portlet).

I'd like to thank you for stopping by! If you need good working examples they can be found in Liferay Portal and some plugins, namely so-hook and so-portlet. You'll need Liferay 6.0 for this cool new feature. Leave comments if you have questions!

A Hello From JavaOne

Company Blogs June 2, 2009 By Ryan Park Staff

Just a quick hello from JavaOne.

Liferay at JavaOne


We're on our way to the Moscone Center! My first JavaOne.


At last! The Moscone Center.


Getting ready on the floor. Ce looks confused already.


Nothing that coffee can't fix.


Liferay! Get your Liferay!

Cleaning up the theme velocity clutter

Company Blogs March 9, 2009 By Ryan Park Staff

New to the next release of 5.1 and 5.2 are more streamlined templates. We’ve condensed all the includes and some code into 2 includes to cut the confusion and the clutter. Though a small update, I thought it would be important to let anyone who is developing a theme in Liferay know because some lines of text have been moved around and this could cause some needless frustration.

In portal_normal.vm there used to be a lot of things going on – some lines of css and multiple includes. Well, we’ve found that for the majority of themes people are going to leave these lines alone. Therefore, we've moved code into the general top head and the bottom includes.



is going to include the folowing code:

#css ($css_main_file)

<script type="text/javascript">
    // <![CDATA[
    // ]]>

#if ($company_logo != "")
    <style type="text/css">
        /* <![CDATA[ */
            #banner .logo a {
                background: url($company_logo) no-repeat;
                display: block;
                font-size: 0;
                height: ${company_logo_height}px;
                text-indent: -9999em;
                width: ${company_logo_width}px;

        /* ]]> */



is now including:

#js ($js_main_file)

So for anyone who has modified or removed those lines and are seeing them in their themes, it is because we’ve made them manditory in all themes. And, for those who have modified portal_normal.vm but not the above code, you should remove the moved code so that they're not included twice.

Showing 3 results.