JSR 168 FAQ
Table Of Contents
What is a portal ?
A portal can be best described as a web site that acts as a
"point of entry" or a gate to a larger system. While it seems pretty
difficult to define a portal in the strictest sense, these are some of
the common features of portals:
- Content aggregation:
Portals tend to aggregate content from multiple,
disparate sources and provide one unified view of the same.
This refers to the ability of the portal to tailor the
content/services that it offers according to the user of the portal.
Most if not all portals, offer some form of searching of
it's content and sometimes even content from external sources.
- Single Sign On:
Allows users to authenticate once to the portal and
thereby allows access to many other systems without the need for
Do I need a portal server to build a portal ? What is a
portal server ?
No, you don't. You can build a portal using any web based
technology: J2EE, Dot Net , PHP or plain old CGI.
A portal server however provides a base infrastructure for
rapidly developing/deploying portals. It also provides, out of the box
implementations of most of the services that any portal would require.
What is a JSR 168 Portlet ?
Prior to JSR 168, almost all portal platforms offered their
own proprietary approach to create pluggable components. For example,
IBM had IBM portlets, Sun(iPlanet) had Providers, SAP had iViews and
Plumtree had Gadgets. TBD
What are the benefits of JSR 168?
Portal integration components based on the new standard will
enable interoperability independent of the portal vendor solution --
and enable enterprises to more easily use portal platforms for the
secure delivery of personalized Web services and aggregated content
between multiple internal and external portal deployments.
- For Developers:
The new standard will allow developers to reuse existing integration
methods for faster addition of data, applications, and services from
multiple back-end sources. Developers and independent software vendors
(ISVs) will benefit from reduced development time and cost since the
specification is based on Java APIs and extends J2EE capabilities to
- For Customers:
Enterprises will benefit from greater efficiency and ROI since
personalized, aggregated content can be delivered from portal platforms
to end-users from a multitude of sources previously difficult to
- For Integrators:
Integrators will have an easier time integrating and aggregating
content for their Portal customers, facilitating the delivery of web
What is a portlet container and where will I find one?
A portlet container runs portlets and provides them with the
required runtime environment. A portlet container contains portlets and
manages their lifecycle. It also provides persistent storage for
portlet preferences. A portlet container receives requests from the
portal to execute requests on the portlets hosted by it.
A portlet container is not responsible for aggregating the
content produced by the portlets. It is the responsibility of the
portal to handle the aggregation.
A portal and a portlet container can be built together as a
single component of an application suite or as two separate components
of a portal application.
Do I need a portal server to deploy/test my portlets?
Yes, Portlets only generate markup fragments, not complete
documents. The Portal aggregates portlet markup fragments into a
complete portal page. Also,Portlets are not directly bound to a URL and
so web clients interact with portlets through a portal system.
Can I get the HttpServletRequest from Portlet?
The PortletRequest object is supposed to give you everything
you need.. e.g. parameters, attributes, dispatching, etc. As per the
spec, you should not need the HttpServletRequest.
Although, different portlet-container implementation provide
some kind of hack to get hold of HttpServletRequest. e.g. in Pluto you
can cast the RenderRequest to HttpServletRequest as
(HttpServletRequest)plutoRenderRequest ... BUT, be aware that it will
introduce dependency on Pluto, which is against spirit of the spec.
Can I use session in portlets?
Yes, the specification defines a PortletSession interface
that allows a portal/portlet-container to use any of the session
tracking approaches (such as HTTP Cookies, SSL Sessions or URL
rewriting) to track a user’s session. The PortletSession interface
defines two scopes for storing objects, APPLICATION_SCOPE and
Use APPLICATION_SCOPE, if you want to access attributes
which have been placed within the session in external resources like
your servlet. While the portlet scoped attributes, although available
to other resources, are used for attributes that are meant for the
portlets use only.
What's difference between
PortletConfig.getInitParameter() and PortletContext.getInitParameter()?
Context-wide init-params share the same context space as
Servlets and JSPs belonging to the same application and they are
defined in the web.xml file. You can get them using
Portlet-wide initialization parameters on the other hand
belong in the portlet.xml file and you can get them using
How can I set/retrieve a cookie from a portlet?
No you cant.There is no direct way to set/retrieve a cookie
value from a portlet.
Cookies are used a mechanism for session tracking. The
portlet specification does not mandate the portal server to use any
particular session tracking mechanism. In fact, the portal server is
free to use whatever mechanism it chooses: Cookies, URL rewriting,
Https Sessions etc. Portlet developers are expected to use the
PortletSession object and leave it to the portal server to deal with
the underlying mechanism.
Can I set a cookie from an included Servlet/ JSP ?
This will not work. The Portlet Spec (PLT 16.3.3) mandates
that the addCookie() call on an included
Servlet or JSP does no operation. If this does work on some containers,
then it should be considered a bug and should not be relied upon.
Is there a hack to get/set cookies ?
- PortletRequest Properties:
The getProperties() method of the PortletRequest would
return the HTTP headers,
if available. This can be used to retrieve the cookie values in most
containers. This behavior cannot be relied upon as there might be
circumstances where they are unavailable.
you can have code that can set/retrieve cookies and if needed, pass it
over to the portlet
How do I achieve inter-portlet communication ?
Inter-portlet communication refers to the ability by which
portlets can communicate with each other
in a spec compliant way. There are currently two approaches to achieve
inter-portlet communication. The exact approach you choose would depend
on the problem you are trying to address
- Using the PortletSession:
A PortletSession is created for each user per portlet
application. This makes the PortletSession useful for communicating all
user related information among different portlets in the same portlet
When you set attributes in a PortletSession you have two
options: To use a PORTLET scope (this is the default) or to use an
APPLICATION scope. If you want the particular attribute to be shared
among portlets, you need to use the APPLICATION scope.
For example, consider CityPortlet and WeatherPortlet,
two portlets in the same application.
In processAction() of CityPortlet
In the WeatherPortlet, you can retrieve the changed city
name by getting it from the PortletSession:
In doView() of WeatherPortlet
Pretty simple, but here is a caveat.The portlet spec
does not mandate any order in which the doView() (or for that matter
doEdit() or doHelp() ) be called for multiple portlets on the same
portal page. This means if you were to set an attribute in the doView()
method of CityPortlet you may or may not get the attribute in the
doView() of WeatherPortlet (depending on the portal server and perhaps
the layout that you are using).The spec, however, does mandates that
the processAction() be called before any rendering method is called.
Therefore you need to ensure that any state change that needs to be
propagated across multiple portlets in the same portlet application is
confined to the processAction() method.
- Using the PortletContext:
A PortletContext (very similar to a ServletContext) is
shared between all users and all portlets in a portlet application.You
can get and set attributes from the PortletContext and this can be used
as a global point of communication.
For example, if the WeatherPortlet uses a webservice
which is currently unavailable. You might have code like this:
In doView() of WeatherPortlet
In this case, all instances of WeatherPortlet
irrespective of which user is seeing it, would see the error message.ADD
What if I need two portlets from two different portlet
applications to communicate with each other ?
This situation occurs rarely and if it does, you may need to
review your packaging structure. Do you really want to couple two
unrelated portlets? If they are dependent wouldn't you rather package
them in the same application?
If you still need the portlets to communicate, you will have
to use some other standard J2EE communication mechanisms like JNDI ,
Database with JDBC, messaging through JMS etc