1. portlet api
  2. liferay api
  3. liferay forums
  4. MySql notes
  5. template


  1. basic 168 pdf
  2. template




see if I can find how to write jsr 168 portlets

jsr 168 spec

sun docs

download page

. Comes with a version that is pre bundled with tomcat 1.5

. Un zip it

. Set java_home to your jdk 15

. Run the startup.bat in the bin directory

. There is no separate installation program that I could find out.


[email protected]/test

Understand liferay's extension enviornment

Understand ant

Understand the interaction between ant and eclipse


find the following here

-  JSR 168 
-  Build JSR 168-Compliant Portlets Now! 
-  Sample Portlet Code 
-  Related Content 
-  Introductory pdf article on how to write jsr 168 portlets

Might be key to understanding portlet architecture. Especially how they are deployed etc.

They seem to encourage deployment as war files. How are these wars different from servlet wars? Can you manually copy the war files? Can they share session?

article, architecture etc.

Hoping I can find out what the architecture for groups is

Are groups part of portlet spec?

What is the data model for Liferay groups?



How do I undeploy or uninstall a portlet war?

What is auto deploy scanner? What is the hot deploy directory?

Can I add a portlet twice? if so how?

Can preferences be automatically edited?

Do some research on portal-ext.properties

Also have to figure out how the security works

How can you isolate the portal for portlets completely? Or how can you abstract the portal information into a java api and then provide an implementation for each portatl.

Here is a nice thread from liferay discussion

When a request and response are transferred to the jsp page, how do they differ? What additional objects are there on the page?

it seem to cache stuff.

public interface PortletSessionThe PortletSession interface provides a way to identify a user across more than one request and to store transient information about that user.

A PortletSession is created per user client per portlet application.

A portlet can bind an object attribute into a PortletSession by name. The PortletSession interface defines two scopes for storing objects:


All objects stored in the session using the APPLICATION_SCOPE must be available to all the portlets, servlets and JSPs that belongs to the same portlet application and that handles a request identified as being a part of the same session. Objects stored in the session using the PORTLET_SCOPE must be available to the portlet during requests for the same portlet window that the objects where stored from. Attributes stored in the PORTLET_SCOPE are not protected from other web components of the portlet application. They are just conveniently namespaced.

The portlet session is based on the HttpSession. Therefore all HttpSession listeners do apply to the portlet session and attributes set in the portlet session are visible in the HttpSession and vice versa.

Read more here


Problem with portlet preferences (reloading of them especially)


This means the preferences are cached. You can change the portlet.xml. But to no avail.

Apparently you can delete the portlet preferences table and restart liferay to have the changes take affect.

Apparently you can not add multiple instances. A future version is expected to do this.

A note on undeploying portlets

Will reset work for resetting the preferences?

Viewing hypersonic database of liferay

Is it in memory?

How do you enable edit preferences?

Name conflicts in request parameters and attributes?

URIs, HTML element name attributes, and JavaScript resources must be namespace-encoded. Since portlets can exist on a page, and it is possible that more than one portlet will produce content with likenamed elements, there is a risk of namespace collision between elements, causing functional problems the page. Use the portlet:namespace tag to encode such resources with the portlet instance name.

But what about url parameters into the portlet? Why is that not mentioned?

The Java Portlet Specification introduces the term Portlet Window. It is defined as a means to include more than one portlet, maybe even the same, multiple times on a page. The window is the view into the portlet. More information on portal pages and portlet windows can be found in Section 2.2. Technically, the portlet windows allow us to scope all available data of a portlet and ultimately assign it to one specific window. This allows the user to put the same portlet more than once on her pages without the portlet window A overwriting the state of portlet window B. The data scoped by the portlet window are:

Navigational state

You can find a more detailed discussion about the different portlet states and data in Section 2.4.1. In addition, a portlet can access a request scoping via the PortletResponse.getNamespace() method. This is supposed to be used from a portlet to guarantee that returned markup will be unique on a page. For example, you could access a namespace to prefix a JavaScript method, but if you have the same portlet twice on a page, JavaScript would generate a duplicate method name. For all cases, you can use the ExternalContext from JSF to get to the respective objects such as PortletSession or PortletResponse, which then in turn automatically scope your data. The following listing shows how this is achieved when you have a FacesContext at hand. If you do not have a faces context you can use the static getCurrentInstance() method to get a handle of it.

ExternalContext extCtx = facesContext.getExternalContext();
RenderRequest request = (RenderRequest)extCtx.getRequest();
RenderResponse response = (RenderResponse)extCtx.getResponse();
PortletSession session = Request.getPortletSession();
String prefix = response.getNamespace();

Please note, that there is a slight misalignment between the Java Portlet Specification and JSF in this regard. In a lot of cases JSF tags write JavaScript methods into the output stream but will not leverage the getNamespace() method in the portlet scenario. As a result a JSF portlet cannot be displayed more than once on a page. To overcome this problem, it might be possible to namespace the id attributes of all JSF tags that write JavaScript into the response stream. This is possible because JSF uses the id of the actual UI element to namespace the JavaScript method.

getParameter api

Only parameters targeted to the current portlet are accessible.

If a portlet receives a request from a client request targeted to the portlet itself, the 10 parameters must be the string parameters encoded in the URL (added when creating the PortletURL) and the string parameters sent by the client to the portlet as part of the client request.xlviii The parameters the request object returns must be "x-www-formurlencoded" decoded.xlix

The portlet-container must not propagate parameters received in an action request to 15 subsequent render requests of the portlet.l If a portlet wants to do that, it can use render URLs or it must use the setRenderParameter or setRenderParameters methods of the ActionResponse object within the processAction call. If a portlet receives a render request that is the result of a client request targeted to another portlet in the portal page, the parameters must be the same parameters as of the 20 previous render request.li

If a portlet receives a render request following an action request as part of the same client request, the parameters received with render request must be the render parameters set during the action request.lii

Commonly, portals provide controls to change the portlet mode and the window state of 25 portlets. The URLs these controls use are generated by the portal. Client requests triggered by those URLs must be treated as render URLs and the existing render parameters must be preserved.liii

A portlet must not see any parameter targeted to other portlets.liv

See on page 44 of the spec

Are the init parameters cached as well?

How to check liferay log files?

How could I use portlet urls from plain html?

Are there any javascript routines that can construct these urls?

some notes on render urls

As can be seen from the above link the url parameters are uniquely encoded with the portlet instance id.

This answers the parameter question raised above.

See how to get the user_info from portlet request

what are liferay jar files to compile with?

Can a jar file say it depends on something else inside the jar file?

Looks like as a result you will also need the commons lang.jar

What is the commons lang used for?

The form needs to be a "post" to call actionURL

An ActionRequest could be a RenderRequest as well. See if you are assuming that an "actionRequest" can not be a "renderRequest" underneath. More on this later.

Extending liferay tables

One of the most common needs of users of Liferay is to extend certain functionality for their needs. this article will cover extending the user table to accept their hometown newspaper. Clearly this is just an example, and could be changed to include the name of their spouse, dog, cat, or whatever is wanted.

The idea here is to create a new table which has your custom field(s) for the user table. If you are adding hometown newspaper for example, you would create a new table in the Liferay database that has a unique id column, your hometown newspaper column, and a reference to the user that is associated with this data.

You can do this by running our service builder to create the extended user class, and then in the LocalServiceImpl file you would add the data you needed to the extra table.

liferay support


understand xdoclet technology

Read the architecture and document their generated classes in your own terms

Running multiple portals

Installing liferay on mysql

19:14:33,715 ERROR [velocity:143] Method processColumn threw exception for ref ence $processor in template com.liferay.portlet.layoutconfiguration.util.Runti PortletUtil at [15,65]