Liferay is a web portal system. Liferay is JSR 168 compliant. Liferay is implemented as a java compliant web application. Liferay is typically installed as a root context in Tomcat. More popular installation packages of Liferay come with a bundled tomcat. Although that is technically true, the download instead contains a tomcat with a preinstalled Liferay as its root context.

Installing Liferay involves unzipping this tomcat and starting the tomcat from the tomcat bin directory. The only real prerequisite is that there is a jdk installed and java_home set. Subsequently you can see Liferay in action by going to


The default view of this site is for users or guests that haven't logged in yet. This is the public face of the portal web site. Liferay comes with a built in test user for testing the sign in process. One can also sign up for an account. Once installed the portal can be configured using its internal portlets and themes.

The out-of-the box Liferay comes with hypersonic sql. Nevertheless it is highly advisable to use mysql as soon as possible. The main issue you will run into otherwise is that you may not find good tools to manipulate the database.

This document will cover the basic mysql installation as well and also running command line prompt for mysql and using the mysql tools for such things as creating the database etc.

Reading this file gives an idea the range of technologies and facilities used by Liferay

Use this for knowing the good startup pattern for liferay

The following topics are covered here

jsr 168 portlets
writing portlets

Main tomcat invocation batch file

Study this file if you want to specialize this file for your needs. This file in turn calls catalina.bat as follows

call catalina.bat start

Which means you can do the following instead to see tomcat in the same window

call catalina.bat run


catalina.bat run
Description to be entered
Description to be entered

How to use AspirePortlet in Liferay

Samplecode: IFrame Portlet

10) Samplecode: JSPPortlet


Samplecode: JSP Portlet

Samplecode: Some portlet definitions

A simple Hello world portlet

Map userInfo = (Map) request.getAttribute(PortletRequest.USER_INFO);
String givenName = (userInfo!=null)
? (String) userInfo.get(? : ??;
String lastName = (userInfo!=null)
? (String) userInfo.get(? : ??;
sample: constructing a render url

The following topics are covered here

jsr 168 portlets
writing portlets

For discussing/working with jetspeed2

It is really difficult to figure out the url structure of a Jetspeed url. Hopefully these code samples will be of some help.

The code here demonstrate the following

1. On a given portal window put a url link that will take you back to the same portlet code
2. Uses JetspeedlinkFactory
3. Uses the object caching of jetspeedlinkfactory
How to use Aspire Portlet. Draft 1.
Source code for AspirePortlet under JetSpeed
1. Turbine
2. ecs
3. velocity (possibly)
4. commons logging
5. jetspeed
Available in "jetspeed\web-inf\conf" directory as .xreg file. All xreg files will be loaded at start up in that directory.
A list of tests on the behaviour of portlets when they are displayed in a portlet container.
To be elaborated. But the doubts are briefly:
1. The portlet api seem to intrusive and intimately linked to portals
2. The protocols that a portlet must adhere to seem too many
3. The URI addressing scheme for portals seem to be tied to portal container


1. Will the webservices portal server solve this tight link between a portal and a portlet?

This link could help us understand the structure of jetspeed urls, in particular, various prebuilt actions.

In short the actions are

controls.Maximize - go to maximize mode for the specified portlet. 
controls.Minimize - go to minimize mode for the specified portlet. 
controls.Customize - go to customize mode for the specified portlet 
controls.Info - go to information mode for the specified portlet. 
controls.Print - go to print mode for the specified portlet. 
controls.Close - go to close mode for the specified portlet. 
controls.Restore - go to restore the specified portlet. 
     * Returns true if the request pertains to current portlet instance. It assumes that the portlet interested in
     * recognizing its own requests, has a hidden input "js_peid". For backwards compatibility, if "js_peid" was
     * not set, this method will return TRUE.
     * @param rundata
     * @return boolean
Description to be entered
The jetspeed stack trace, incase if anyone is wondering who calls who.

Portlets are Java-based Web components, managed by a portlet container, that process requests and generate dynamic content. Portals use portlets as pluggable user interface components that provide a presentation layer to information systems. The next step, after servlets in Web application programming, portlets enable modular and user-centric Web applications. The goal of JSR (Java Specification Request) 168, the Portlet Specification, is to enable interoperability between portlets and portals. This specification defines the contract between portlet and portlet container, and a set of portlet APIs that address personalization, presentation, and security. The specification also defines how to package portlets in portlet applications. Part 1 of this two-part series describes the Portlet Specification and explains its underlying concepts. In Part 2, the authors explain the specification's reference implementation and show some portlet examples. (3,300 words; August 1, 2003)

In this second and final article in Stefan Hepper and Stephan Hesmer's portlet series, the authors move beyond the Portlet API basics outlined in Part 1 to detail the API's reference implementation (RI), known as Pluto. They also offer a series of example portlets to illustrate how you can extend the API's standard functions. (1,700 words; September 5, 2003)

Hopefully this article will throw somelight on where portlets are headed.

It is a mess. You will see lot of updates on this topic here.