JSR
168 portlet interview questions and answers
JSR 168 is a specification from the Java Community Process
for the standardization of portlets. The specification was developed to provide
interoperability for running portlets on any vendor's implementation of the JSR
168 portlet container. The specification was approved in October of 2003.
Explain
the life cycle of JSR 168 portlet?
The life cycle of a portlet closely
resembles the life cycle of a servlet. There are, however, some differences.
The following section will describe the life cycle of a portlet from beginning
to end.
1. Instantiation
The portlet will be instantiated
during start-up. The portlet will be loaded using the same class loading that
is used for loading the Web application.
2. Initialization
The init() method of the Portlet class
is called when the portlet is first requested. Portal will pass a unique
Portletconfig object to the init method. During initialization any one time
setup for the portlet should be completed. This includes expensive operations
such as database connections.
There are two exceptions that may be
thrown during initialization. If either exception is thrown, the portlet will
not be placed into service and the destroy() method will not be called.
UnavailableException
The UnavalableException may indicate a
specific time out value. If WebSphere portal server wishes to attempt to place
this portlet back into service then it must at least wait for the specified
time to expire.
PortletException
All RuntimeException thrown during
initialization are treated as PortletExceptions. If PortletException is thrown
the portal server does not need to
wait any amount of time before attempting to place the portlet into service.
3. Request handling
JSR 168 portlets use a two phase
processing model. The phases are split between a render phase and an action
phase. The portlet can generate a link to itself by using a PortletURL object.
There are
two types of PortletURL, ActionURL and
a RenderURL. Using the RenderResponse object you can create a URL of either
type or you can also use the JSP tags, actionURL and renderURL. During request
handling a portlet may throw one of the following exceptions
PortletException
This exception indicates that error in
processing has occurred. All RuntimeExceptions are treated as a
PortletException. If this is thrown from the processAction() method, all
actions on the ActionResponse object will be ignored and the render method for
this portlet will not be call during this request. The render method for all
other portlets on the page will be invoked. If the portlet is cached, the
cached version may be returned instead of invoking the render method.
PortletSecurityException
This exception indicates that the user
does not have the proper rights for the portlet.
UnavailableException
This exception indicates that the
portlet is unavailable to process the request. Like in the init method, the
UnavailableException may indicate a time value that the portlet will be
unavailable for.
Render phase
A RenderURL will cause the portlet to
enter the render phase, this is also known as a render request. The render
phase is used for displaying content in the 282 IBM Rational Application
Developer V6 and Portal Tools portlet. During a render request, the render
method for all portlets on the page will be invoked, unless the portlet is
cached. The render method may not be call and the cached content of the portlet
could be returned. The processAction method will not be invoked during a render
request. The render phase is also entered when a request is made for the page
that the portlet resides.
Action phase
An actionURL will cause the portlet to
enter the action phase, also known as action request. The action phase is
typically used to modify the state of the portlet or to process a task. During
the action phase the processAction() method of the portlet is called. After the
process action completes, the render method is invoked for all portlets on the
page, unless the portlet is cached. The render method may not be called and the
cached content of the portlet could be returned. Action parameters are passed
into the processAction method via the ActionRequest object. These parameters
can represent a field in an HTML form or they can be parameters explicitly set
by the programmer. While in the action phase, the portlet mode and the window
state may be changed. Although they can be programmatically changed, the portal
server can override the change for any reason including the user may not have
the required rights. The user may also be redirected to another URL during the
action phase by using a request dispatcher. Action parameter are not passed to
the render phase unless they are explicitly specified. You should use the
setRenderParameter or setRenderParameters method of the ActionResponse to pass
parameters to the render phase. The parameters will be out of scope after the
render method completes.
4. End of service
When WebSphere portal server is
removing the portlet from service, the destroy() method of Portlet is invoked.
This gives the portlet an opportunity to clean up resources obtained in the
init method and save the persistent state. WebSphere portal server will wait
until all threads serving a request for this portlet have completed. If this
does not occur in a timely manner the portlet will be removed from service. The
destroy method may throw a RuntimeException. If this happens, the destroy is
considered to have completed successfully and the portlet is removed from
service.
Once the portlet is removed, the
portlet object is eligible for garbage collection.
There cannot be any further requests
for this portlet unless a new portlet object is instantiated.
Explain
the differences between servlets and portlets?
Servlets are associated with clear URL and portlets are not.
Generally servlets produce a full page html but portelts generate only html fragments which are combined in theme to form a full page html.
Servlets have only one session but portlets have two scoped session with portelt scope and application scope.
Servlets can set http header information but portlets cant.
Servelts have only one request handling phase i-e service method but portlets have two phases action phase and render phase.
Explain
JSR 168 windows states?
Window state determines how much
space the portlet will have to render its content. The portlet container will
provide the current window state to the portlet to allow the portlet the
display the appropriate content. JSR 168 supports three Window states, NORMAL,
MAXIMIZED, and MINIMIZED. Like portlet mode the Window state can be
programmatically changed in processAction() while processing an action request.
The state can also be requested while creating a render or action URL.
NORMAL
Normal indicates that the portlet will
be provided equivalent space on the page as other portlets. This portlet could
also be the only portlet on the page. The Show layout tools in WebSphere Portal
could be used to further customize the layout of the portlet on the page.
MAXIMIZED
Maximized state indicates that the
portlet will be the only portlet displayed on the page.
MINIMIZED
The default implementation of the
GenericPortlet class and the IBM supplied skins, are to show only the portlet
title bar when in the minimized state. The skins will not invoke the render
method and therefore will not display any of the portlets output.
Explain
JSR 168 portlet modes?
Portlets will perform different
tasks and create different output depending on the function they are currently
performing. Modes will allow the portlets to provide different function for the
task that is required. JSR 168 supports three modes, View, Edit, and Help. JSR
168 also supports custom modes. IBM WebSphere Portal at the time of this
writing only supports the custom mode configuration.
Portlet can change the mode
programmatically in the processAction method. You can also specify the mode
when creating an action or render link.
View
The View mode is used for
displaying content reflecting the current state of the portlet. View mode may
included multiple screens the user can navigate. The doView() method of the
GenericPortlet class is invoked for this mode. All portlets are required to
support the View mode.
Edit
The Edit mode is used for
customizing the behavior of the portlet by modifying the PortletPreferences
object. As with View mode the Edit mode may contain multiple screens for
navigation. The doEdit() method of the GenericPortlet class is invoked for this
mode. Portlets are not required to support the Edit mode.
Help
Help should be used to provide the
user with information about the portlet. This could be generic or it could
provide context-sensitive help. The doHelp() method of the GenericPortlet class
is invoked for this mode. Portlets are not required to support the Help mode4
Custom-portlet-mode
Configuration mode is used to
globally update a portlet configuration. In Configuration mode an administrator
can update the read-only PortletPreferences. Changes are reflected in all
occurrences of the portlet on all pages. The doDispatch() method of the
GenericPortlet class needs to be overridden to handle this custom mode.
The doDispatch() method calls the
doCustomConfigure() method of the portlet class if the current mode is
represented by the CUSTOM_CONFIG_MODE variable, else it calls the doDispatch of
GenericPortlet class to handle all other modes.
Write
portlet deployment descriptor?
<portlet>
<portlet-name>MyPortlet</portlet-name>
<display-name>MyPortlet
portlet</display-name>
<display-name
xml:lang="en">MyPortlet portlet</display-name>
<portlet-class>myportlet.MyPortletPortlet</portlet-class>
<init-param>
<name>wps.markup</name>
<value>html</value>
</init-param>
<expiration-cache>0</expiration-cache>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>view</portlet-mode>
<portlet-mode>edit</portlet-mode>
<portlet-mode>help</portlet-mode>
<portlet-mode>config</portlet-mode>
</supports>
<supported-locale>en</supported-locale>
<resource-bundle>myportlet.nl.MyPortletPortletResource</resource-bundle>
<portlet-info>
<title>MyPortlet
portlet</title>
</portlet-info>
<portlet-preferences>
<preference>
<name>.MyPortletPortletEditKey</name>
<value>Read-Write
Value</value>
</preference>
<preference>
<name>.MyPortletPortletConfigKey</name>
<value>Read-Only
Value</value>
<read-only>true</read-only>
</preference>
</portlet-preferences>
</portlet>
Explain
JSR 168 listeners?
JSR 168 portlets do not define any
portlet listeners, instead they use servlet
listeners. Servlet listeners should be
implemented in the portlet environment like
they are in the servlet environment.
The listeners should be added in the
web.xml or to any object that needs to
be informed when being added or
removed from the session should
implement HttpSessionBindingListener.
Detailed description of servlet
listeners are outside the scope of this book, but we
will briefly describe them here.
1.
HttpSessionBindingListener
Object that require notification when
being added or removed from the portlet session should implement this
interface. This interface defines two methods, Chapter 8. JSR 168 API 285
valueBound and valueUnbound. Both of
these methods are passed a HttpSessionBindingEvent object. From the
HttpSessionBindingEvent object you can get access to the name and value of the
object that has been added or removed from the session. You can also get the
session object. When using attribute that are store in the portlet scope, you
should use the PortletSessionUtil class to decode the attribute names.
2.
ServletContextListener
The ServletContextListener can be used
for the PortletContext. This listener contains contextInitialized and
contextDestroyed methods. An object of type ServletContextEvent is passed into
the initialized and destroyed methods. From this object you can get access to
the ServletContext. The contextInitialized method will be called when the
PortletContext is created and contextDestroyed
will be call when the PortletContext
is destroyed.
3.
ServletContextAttributeListener
This interface defines three methods,
added, removed and replaced. These methods are to be used when attributes have
been added, removed, and replaced. A ServletcontextAttributeEvent is passed to
these three methods. From this object you can get the name and value of the
attribute that has been added, updated or removed.
4.
HttpSessionListener
The HttpSessionListener provides two
methods sessionCreate and sessionDestroyed. These are invoked when the session
has been created and destroyed. A HttpSessionEvent object is passed into these
method. From the HttpSessionEvent you can get the HttpSession.
5.
HttpSessionAttributeListener
Like the
ServletContextAttributeListener, the HttpSessionAttributeListener defines the
same three methods attributeAdded, attributeRemoved, and attributeReplaced.
These methods are pass a HttpSessionBindingEvent object. You can get the name
and value of the attribute that has been added, removed or replaced.
Explain
JSR 168 portlet caching?
Caching improves performance by
reducing the load on the server. Caching is per user per portlet, a portlet
cached for one user will not be used for another user. A JSR 168 portlet must
use the portlet.xml to enable caching.
The expiration cache is defined in
seconds. In the example above, the contents of the portlet should be cached for
10 minutes. A value of zero indicates that the portlet caching is disabled. A
-1 value will cause the portlet cache to never expire. Any value above 0 will
be interpreted as the number of seconds the content should be cached for.
If the expiration-cache is defined in
the portlet.xml, the portlet may programmatically change the expiration time.
The request property expiration-cache should be used to modify the
caching values.
While the portlet content is cached and
the portlet is not a target of a request, the cached content will be used
during the render phase. If there is a request for the portlet, the cached
content will be disregarded and the render method of the portlet will be
invoked.
How
to pass the parameters from action to render?
Parameters from action request are not directly available
in render phase. Those parameters need to explicitly set. Following methods
allow propagation of parameters from action to render phase.
1. Void
setRenderParameter(java.lang.String key,java.lang.String value)
Parameters set using this method will
be used in all subsequent render requests until the portlet is targeted with a
new request. If there are no parameters set using this method then there will
be no render parameters for the RenderRequest.
This method is overloaded for render
parameters that contain a String[] (String array) for the values.
2. Void
setRenderParameter(java.util.Map parameter)
This method will have the same
function as the method listed above. This method accepts a Map of key value
pairs where the key must be of type String and the value must be of type
String[] (String array).
Explain
JSR 168 portlet session and possible scopes?
The portlet session object
provides session tracking for all requests coming from the same client. All
portlets of the same portlet application will share a portlet session for that
user. Portlets of other portlet application will not be able to access this
session object and therefore will not be able to share attributes.
PortletSession provides two static
variables to be used to when adding attributes. The two variables representing
the scopes are APPLICATION_SCOPE and PORTLET_SCOPE. Objects stored in the
APPLICATION_SCOPE are shared among all portlets of the same portlet
application. Attributes stored as PORTLET_SCOPE are available only to the
portlet, although the attribute is not completely hidden it is name spaced to
the specific portlet. The PortletSessionUtil class should be used to decode
portlet attributes stored in the PORTLET_SCOPE when called through the
HttpSession of the HttpSessionBindingListener.
.
The PortletSession and the
HttpSession can share attributes. This means that servlets and JSPs will have
access to attributes stored by the PortletSession at APPLICATION_SCOPE. The
PortletSession will also have access to attributes stored by servlets and JSPs.
Explain
the difference between portletConfig and portletContext?
The portlet config object is used
during initialization of the portlet. From the PortletConfig object you can
obtain the PortletContext and the resource bundle used for setting the title.
Unlike the PortletContext object, the PortletConfig will use the init
parameters defined in the portlet.xml and not the init parameters defined in
the web.xml.
The portlet may define some basic
information in the deployment descriptor that is used for the title bar. The
information may also be used for the categorization of the portlet. This information
can be directly stored in the deployment descriptor or it may be stored in an
external resource bundle. Resource bundles will be discussed in a later section
but was addressed here to acknowledge that the portlet config provides access
to this information.
Explain
portlet preferences object?
The PortletPreferences object is
used to provide a customized view of the portlet to the user. Preferences are
stored as name value pairs. They can be either defined in the portlet
deployment descriptor or programmatically. If the parameters are defined in the
deployment descriptor, they have the option of being read only. Read only
parameters can only be updated by the administrator while in Config mode. The
administrator can also modify the parameters using the admin portlets. If the
parameters are added programmatically they are not considered to be read-only.
Users can modify parameters only while in the Edit mode and only parameters
that are not read only. Changes made in Config mode by the administrator will
affect all instances of the portlet on all pages.
Explain
portlet preferencesValidator?
Portlets that wish to validate
preferences should create a class that implements PreferencesValidator
interface. This class should then be added to the portlet deployment
descriptor.
The validate method of this class
will be called by the store method. If the validate class throws a Validator
exception the store will not complete and it will propagate the exception to
the portlet.
If the preferences are not valid
then this method should throw a ValidatorException. If the preferences are
valid this method should finish gracefully. It is the responsibility of the
portlet developer to add a error description to the ValidatorException if
needed.
Answers
inspired from IBM redbook: IBM
Rational Application Developer V6
Portlet Application Development and
Portal Tools
Download link:
