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.

Popular Posts

Featured Post

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...