This post originated from an RSS feed registered with Java Buzz by Sam Dalton. Original Post: Session on JSR-168 : The Porlets Specification Feed Title: import java.*; Feed URL: http://www.samjdalton.com/pebble/rss.xml Feed Description: Random, Infrequent Bloggings of a Techie Latest Java Buzz Posts Latest Java Buzz Posts by Sam Dalton Latest Posts From import java.*;

Just been to the most enjoyable Tech Session so far. The session discussed the recently completed JSR-168 for Portlets. The session went into depth about the specifications areas of concern, and about the portlet/portlet server architecture. The specification defines the container to hold portlets (which is a web application deployed on a regular Servlet container), the portlet API, a portlet tag library.

The philopophy so far seems to be to use as much from J2EE (1.3) as possible, so as not to reinvent the wheel and most of the portlet API consists of facades over the servlet API. Portlets are designed to run in the context of a portal, so things like portlet layout and request mapping are outside of the concerns of JSR-168.

The portlet interface is very simple, and similar in intention to the Servlet interface:

public interface Portlet {
   init(PortletConfig)

   processAction(ActionRequest, ActionResponse)

   render(RenderRequest, RenderResponse)

   destroy()
}

As you can see the portlet has seperate methods for action handling and content rendering. This is because a portlet might be updated as a result of something other than user input (for example a stock ticker), so may need to be re-rendered.

The JSR-168 reference implementation is Pluto from Apache, and is available here.