WebSphere Portal Class Notes
Abstract Portlet - Idea of a portlet, i.e. the source code.
Concrete Portlet - Installed portlet, not on a page yet.
Concrete Portlet Instance - Portlet on a page.
WebSphere Portal Architecture on page 15-4
Use the jetspeed classes, MVC* classes are depreciated
PortletAPI - the big picture on page 9-25
Namespace Encoding done with response.encodeNamespace()
URL encoding done with response.encodeURL()
Portlet Caching on page 14-16
Many resources are listed on page 21-4
web.xml - Web Application Deployment Descriptor
init-param - Accessed through the PortletConfig object
servelet-mapping/url-patturn is not used, but required
portlet.xml - Portlet Deployment Descriptor
portlet id must be unique in the whole portal environment
Standard layout from WSAD
html - .jsp files that create html output
wml - .jsp files that create wml output
tld directory - tld files
classes directory - Class files in correct package
lib directories - Extra libraries needed.
Portlet Class (set in portlet.xml)
Each portlet must implement a class that does all of its processing. Each portlet class will implement the
following methods to provide the functionality required.
init() - Executes once at load time. The single instance created is shared with all users.
initConcrete() - After construction but before portlet is accessed for the first time. This is per
service() - called when portlet is required to render its contents. Dispatches to one of these
methods based on the portlet mode.
doView() - Normal viewing of the portlet.
Typically ends with getPortletConfig().getContext().include(
"/jsp/View.jsp", request, response);
doEdit() - User options.
doHelp() - Information on using the portlet.
doConfigure() - Admin options.
destroyConcrete() - Portlet taken out of service
destroy() - Portlet terminated. Just before GC and finalize().
Portlet and Servlet Methods and Lifecycle
This table compares the methods of a servlet with those of a portal. At the same time, the lifecycle of a
portlet is also shown. All methods between and including beginPage() and endPage() are repeated until the
user logs out or the portlet is removed from the system.
Servelets Portlets Lifecycle
init() init() Portal initialized (once per portlet)
login() User login (must implement PortletSessionListener)
beginPage() User requests page (must implement PortletPageListener). This hook allows
service() service() Generate fragment for this portlet
Portlets are aggregated into one page.
endPage() Allow portlet to add code to the end of the page (must implement
logout() User logout (must implement PortletSessionListener)
destroy() destroyConcrete( Cleanup when no longer needed.
The following objects are used in portal development. The first section is used to read and store data. The
second sections lists some objects that are used to understand what is going on inside the portal
Object Write Duration Associate Page (Methods)
PortletRequest Yes User Request User Request 9-28
PortletResponse Yes User Request User Request 9-31
PortletSession Yes User Session Concrete Portlet User Instance 9-34
PortletConfig No Persistent Portlet 10-10
PortletContext No Persistent Portlet Application 10-14
PortletSettings Yes Persistent Concrete Portlet 10-17
PortletApplicationSettings Yes Persistent Concrete Portlet Application 10-17
PortletData Yes Persistent Concrete Portlet Instance 10-17
Object Description Page (Methods)
Client Represents the users client application 10-31
PortletLog Access to the log files 10-34
PortletException Base of exception tree 10-36
PortletURI Represents a URI to a specific portlet mode. 9-36
Four Modes and Three States
The four modes are Configure, Edit, View and Help. There are four methods in the portal class to provide
code for each mode.
The three states describe how Portal will display the portlet. These states are normal, maximized and
These listeners may be implemented to add functionality to the portlet.
Interface Description Page
PortletSessionListener Initialize or cleanup PortletSession 11-5
PortletPageListener Add to shared resources on the page 11-7
PortketTitleListener Provide a dynamic title for portlet 11-10
ActionListener Allow portlet to receive PortletActions. 14-9
WindowListener Process changes to the portlet state 14-15
MessageListener Accept messages from any portlet on the same page. 14-11
PortletSettingsAttributesListener Receive changes to concrete portlet
PortletApplicationSettingsAttributesListener Receive changes to concrete portlet application
Events and Actions
There are two phases to processing. First is event processing then comes content generation processing. It
is guaranteed that trigger actions and window events occure before any messages are delivered and all
event processing will complete before content generation phase begins.
Currently, the API uses an interface (PortletAction, implemented by DefaultPortletAction) for a whole
object to use as an action. The next version will use only a string because that is all that is needed.
Normally, data generated in the action processing is needed in the content generation phase. It is a BP to
store the data in the request object. Do not use instance variables since the instance is shared for all users.
Used to allow portlets to communicate with other portlets. A message may be to a single receiver or
broadcast to all portlets on the same page. Portlet must implement the MessageListener interface in order
to receive messages. A message may only be sent during the event processing phase.
Portlet Services (Custom, Vault Service and Collaboration)
Portlet services are discussed in unit 16. They provide a way to grant access to shared resources through a
developer created interface.
Unit 17 talks about a provided Portlet Service called Vault Service. Using segments and slots, a given user
may store any number of user/password combinations used to access services outside the portal
Unit 18 describes the collaboration components that allow multiple users to communicate through
Websphere Portal Server. Unit 19 describes the Lotus collaboration components.
This document describes the best practices discussed in class. The document at
Development Best Practices and Coding Guidelines) describes the full set of best practices.
Portlets are Servelets so the same BPs apply.
Portlets are multithreaded.
No instance/class variables
Static private final class variables are OK
Shared resource access must be synchronized
Don't sync whole method, just needed block
MVC Still Applies
Do not use JSPPortlet
Extend PortletAdapter, AbstractPortlet or MVCportlet.
Use the JSP only as the view.
Know which data object to use
Provide persistence services as PortalService
Portlet UID must be unique
A - JSP Custom Tags
B - Customizing Portal (Themes for the page and Skins for the portlets)
C - Migration from WebSphere Portal 2.1 to 4.1