What are the Key features of JSR 286 portlet specification?


JSR 286 comes with lots of new features that were missing in JSR168 API and badly required by portal developers. Few of them are

  • Resource serving- provides the ability for a portlet to serve a resource.
  • Events – enabling a portlet to send and receive events and perform state changes or send further events as a result of processing an event. 
  • Public render parameters – allowing portlets to share parameters with other portlets.
  • Portlet filters
  • Invoking a Portlet directly (but still through the Portal) 
  • PORTLET_SCOPED session for Servlets.
  • Java 5 annotation support in GenericPortlet.
  • Access to the Portlet Window ID.
  • PortletURL generation callback listeners.
  • “private” PortletModes and setting nextPossiblePortletModes.
  • Action scoped request attributes (still under FINAL work).
ResourceServingPortlet.serveResource(ResourceRequest, ResourceResponse)

  • Extends the render phase, NOT a new life-cycle phase
  • POST, PUT, DELETE supported
  • Should not change shared portlet state
  • Additional URL parameters are specific for the request
  • Full control over request and response headers
  • Can be used for binary data or “readonly” AJAX (cannot change navigational state)

Extended Cache

Allow public cached content for multiple users


Support validation based caching using ETag API:

.getExpirationTime(), .setExpirationTime().isPublicScope(), .setPublicScope(boolean)
.getETag(), .setETag(String).useCachedContent(), .setUseCachedContent(boolean)

Better Web Platform support
  • Allow servlet dispatching, including using forwards, from:
  • processAction
  • processEvent
  • render
  • serveResource
  • Optionally providing a PORTLET_SCOPEd session to Servlets
  • Extended JSP tag library using new taglib uri "http://java.sun.com/portlet_2_0"
  • Bridging and native integration underway for JSF (JSR-301) and Apache Wicket (1.3+)
Portlet Coordination – Portlet Events
  • Events must be defined in portlet.xml
  • After event definition, each portlet must declare what events it will publish or receive
  • Portal-defined events do not have to be defined in portlet.xml
  • Event naming:
  • Must use the W3C Q Name standard.
  • Receiving events can end with a * wildcard
  • Can declare default-event-namespace in portlet.xml and just use local names
  • A portlet declares the events it wants to receive or send in portlet.xml using Qnames or by using a default namespace:
<javaclass> java.lang.String</javaclass>
<qname xmlns:x=”http://acme.com/events”>x:foo</qname>

Sending non-declared events at run time is allowed too
  • Allows wiring of portlets at runtime
  • The portal / portlet container will act as broker
  • The portal or portlet container can also send events
  • Formally not 100% reliable, i.e. no guarantee of delivery (mainly for WSRP, “local” portals are less limited)
  • New 3rd life cycle phase: before rendering


EventPortlet.processEvent(EventRequest req, EventResponse res)
StateAwareResponse.setEvent(QName name, Serializable value)
StateAwareResponse.setEvent(String name, Serializable value)

Portlet Filters
  • Modeled after Servlet Filters
  • Modify request data by wrapping request
  • Modify response data by wrapping response
  • Intercept invocation of a portlet before and after it is called
  • Filters may be chained
  • Defined in portlet.xml
<filter-name>Event Filter</filter-name>
<filter-name>Event Filter</filter-name>
  • Must implement javax.portlet.Filter interface
  • Must provide a public no-arg constructor
  • init() method will be called on all Filters before being called on any Portlets
  • destroy() will be called if Filter is removed from service
  • doFilter() method called if processAction(), processEvent(), render(), or serveResource() would be called on Filtered Portlet

No comments:

Post a Comment

Recent Posts

Popular Posts

© 2011-2019 Web Portal Club