01 January, 2013

Java standards portlet


  • There are two JSR standards that govern portal/portlet behavior.
  • JSR-168 is the Portlet 1.0 Specification.
  • It was created out of a need to have a specification for displaying multiple applications on the same page.
  • JSR-286 is the Portlet 2.0 Specification which retains backwards
  • compatibility with 1.0 (JSR-168) portlets.
  • Adds new features based on the experience of the different portal vendors.
  • The portlet specification defines the life cycle of a portlet as well as its characteristics.

Core Architecture :
  • The core architecture will be the same across Java Standard compliant portals.
  • Portlets written to the standard will run on all compliant portlet containers.
Documentation :
  • The Portlet Specification will not change, and you can reliably refer to it for information.
  • Standard Portlet API for developers.


  • If you are familiar with Java servlet technology, you will see many similarities between servlets and portlets.
  • Portlets are packaged as a Web Archive (.WAR) file and deployed to an application server or servlet container.
  • The servlet container considers a portlet application to be just another web application that lives inside a Web ARchive (.WAR).
  • Portlets must provide a valid web.xml descriptor file, although the Liferay hot-deploy process does most of the work with configuring this file.
  • In addition to the standard web.xml deployment descriptor file, portlet applications require an additional descriptor file named portlet.xml.
  • This descriptor tells the portlet container what portlets are included in the application, what roles they support, what portlet modes they support, and more.
  • However, because a portlet's response is designed to be aggregated
    with responses from other portlets on the page, there are some key
    • Portlets are only responsible for rendering a fragment of the total page, so certain tags are not allowed (<html>, <head>, <body>).
    • Portlets may need to re-render, even if a user is not interacting with that portlet directly.
    • At design time, there is no way of knowing what page a portlet may be deployed on and what other portlet's may be on the page, this makes it impractical to create portlet URLs directly.
    • The Portlet API provides methods for creating all of the necessary Portlet URLs.

  • With servlets, the service() method processes all requests.
  • Because Portlets are designed to coexist on the page with other portlets, a user may not be interacting with a portlet directly, but that portlet may still generate a request based on interaction with another portlet on the page.
  • As a result, portlets have more then one type of method to process requests. These methods result in corresponding portlet phases.
  • JSR-168 (Portlet 1.0) introduced two phases:
    • Render Phase
    • Action Phase
  • JSR-286 (Portlet 2.0) adds two more phases:
    • Event Phase
    • Resource Serving Phase

  • init()
    • Initializes the portlet
  • render()
    • Renders the content
  • processAction()
    • Called when the user performs an action
  • processEvent()
    • Called when an event has been triggered
  • serveResource
    • Called when a ResourceURL is requested
  • destroy()
    • Releases the portlet object so it is eligible for garbage collection.


  • The init() method is called by the Liferay portlet container during the deployment of the portlet.
  • During this phase of the portlet life cycle, portlets typically initialize any back end resources or perform one-time activities.
  • Liferay portlets typically use the init() method to read initialization parameters from the portlet.xml.
  • These initialization parameters are used to describe the page flow of the portlet.
  • Because we've added some logging to this DemoPortlet, during the deployment and any subsequent re-deployment of this portlet, you should see a message in the Tomcat console indicating that the init() method has been called.


  • During the Render Phase, the portlet generates content based on its current state.
  • The Render Phase is called on all of the portlets on a page when that page is rendered.
  • The Render Phase is also called when any of the portlets on that page complete the Action phase or Event Processing phase.
  • Create a new page in the portal and add the JSR 286 Overview portlet to the page.
  • Watch the Tomcat console for message indicating the render method is being called.
  • Portlets typically enter the Render Phase as a result of a page refresh or after the completion of the Action Phase. However, there times when you may want trigger the Render Phase directly.
  • This can be accomplished by invoking a Render URL.


  • The portlet enters the Action Phase as a result of the user interacting with that portlet.
  • Specifically, the user interaction should result in a change of state in the portlet.
  • Only one portlet can go through the Action Phase during a single request/response cycle.
  • Once the Action Phase has completed, the portlet will then process any Events that may have been triggered by the Action Phase.
  • Once the Events have been processed or if there are no events triggered the portal will then call the Render Phase on all of the portlets on the page.
  • Portlets enter the Action Phase by invoking an Action URL


  • The Event Phase is used to process any Events triggered during the Action phase of the portlet lifecycle.
  • Events are used for Inter Portlet Communication (IPC).
  • Events can, in turn, trigger additional events.
  • Once all of the Events have been processed the portal will then call the
  • Render Phase on all of the portlets on the page.


  • The Resource Serving Phase allows portlets to serve dynamic content without the need calling the Render Phase on all of the portlets on the page.
  • In Portlet 1.0, portlet requests always returned a full portal page.
  • A Resource is requested via a ResourceURL.
  • The bytes written to the response will be sent directly to the client.
  • Resource serving is very useful for:
    • Creating images and other binary resources dynamically
    • Returning XML, JSON, HTML fragments for AJAX calls Etc.
  • Portlets enter the Resource Serving Phase by invoking a Resource URL.


  • The destroy() method is called by the Liferay portlet container when it is removed from service.
  • This phase of the portlet life cycle is designed to allow the portlet to release any resources and to save state if necessary.
  • To trigger the destroy() method, we will need to undeploy the portlet.
  • We can see a message in logger when the portlet enters the destroy() method.

Rate Me:

Liferay 7.3 compatibility matrix

Compatibility Matrix Liferay's general policy is to test Liferay Portal CE against newer major releases of operating systems, open s...