The Portlet Lifecycle

The Portlet Lifecycle

Essentially any client request made to the portal will result in one or more portlets

being invoked. The portlet lifecycle is defined in the Portlet interface of the Portlet

API and provides the following interface.

init(PortletConfig config)

processAction(ActionRequest req, ActionResponse res)

render(RenderRequest req, RenderResponse res)

destroy()

Initialization and Shutdown

The portlet container is responsible for initializing all of the portlets. The

initialization may take place once the portlet container starts up or the first time a request

is made to a portlet. If an error occurs during the portlet initialization, the portlet is not

placed into service. Generally, the initialization method is used to start up any resources

that are useful for the duration of the portlet’s functioning. As an example, the creation of

a connection to a database or a web service is often best done in the init method. The

PortletConfig object provides portlet configuration information that has been

defined in the descriptor.

Similarly the portlet container may invoke the destroy method when it decides

the portlet should be removed from service. This normally happens when the portal is

being shutdown.

Request Handling

Generally in the portal lifecycle, the portlet container will initialize all of the

portlets when the portal is started and invoke the destroy method on all portlets when

the container is shutdown. However while the portal is running every client request made

to the portal will often result in one or more portlets creating a markup fragment to be

included in the final portal page.

A request can be broken into two phases, action handling or rendering markup.

An action request is an optional state that can be made to change the state of the

underlying portlet application. For instance an example login portlet would allow users

to provide their name and password and will display a submission form to send the

supplied information to the portal, resulting in an action request. The portlet container

will handle any action request first before any content is generated as shown in the UML

sequence diagram. Once the action request has completed, the portlet container generates

markup by invoking the render method of every portlet on the page in no particular

order excepting those portlets that have defined their content to be cached. The portal is

responsible for aggregating all portlet fragments and displaying a full portal page back to

the user’s browser. A client request does not have to result in a processAction invocation.

However, every client request to the portal must go through the render phase (unless the

portlet’s content is cached).

Both processAction and render methods supply a request and response object.

The ActionRequest and RenderRequest objects inherit from PortletRequest, a decorator1

for a HttpServletRequest object defined in the Servlet specification. The portlet request

provides much of the same functionality as a HttpServletRequest object that traditional

J2EE web application developers are familiar with as well as methods for querying the

1 A Decorator[GoF], also known as a Wrapper is a design pattern that provides additional

functionality to an object by sub-classing to provide additional methods and exposing

many of the same methods of the underlying (wrappee) object. The Java stream and file

I/O classes are good examples of decorators.

current window state or portlet mode. The primary difference between the ActionRequest

and the RenderRequest is that an ActionRequest may not write to the output stream, since

it is responsible only for performing business logic.

Any event triggered within portlet such as submitting a form or clicking a link

will result in either an action request or a render request being made. The Portet API

provides methods for the construction of URLs in the portal to cause either event to

occur.