IBM WebSphere Portal Development

IBM Web Experience Factory (formerly WebSphere Portlet Factory) Introduction

2012-05-07T00:28:00.001-07:00

WebSphere Portlet Factory is used for rapidly building portlets on top of a service-oriented architecture. Developers at all skill levels (including those with beginner Java™, J2EE, and portlet development skills) can take advantage of the software automation technology offered by Portlet Factory to develop complex portlet applications. Portlets created with WebSphere Portlet Factory are dynamic, robust Java 2 Enterprise Edition (J2EE) applications that react automatically to change, and can be further modified by business users in real time, to meet changing business requirements without requiring any coding, duplicating or versioning of assets. By eliminating the need to code all of these implementations and their variations, WebSphere Portlet Factory simplifies the development, deployment, and change management process, saving companies time and money.
There is a learning curv in Portlet factory but once you will get experties and familiar with most of the builders the then you will realize it's rapid development power. Here we have some good reference links to start the portlet factory:
1. Web Experience Factory
2. Quick Start for using IBM WebSphere Portlet Factory with IBM WebSphere Application Server CE

Enjoy :-)

Resource serving

2011-11-30T06:27:00.002-08:00

The resource serving feature provides the ability for a JSR 286 portlet to serve a resource.
Portlets can create two different kinds of resource links in order to serve resources:

1. Direct links to the resource in the same portlet web application. These links are constructed by the portlet and encoded with the PortletResponse.encodeURL() method. (This method might not return a valid URL. And direct links are not guaranteed to pass through the portal server and will not have the portlet context available. Direct links should be used for use cases where the access to the portlet context and access through the portal is not needed, as they are more efficient than resource serving requests via resource URLs through the portal.)
2. Resource URL links pointing back to the portlet. Via these links the serveResource method of the ResourceServingPortlet interface is called and the portlet can serve the resource. Thus resources served via resource URLs may be protected by the portal security and can leverage the portlet context. Static resources should still be served with direct links in order to allow portal applications to configure and optimize static resource serving in a consistent manner.
(Ref: JSR286 portlet specification, Click here to download the full specification.)

Event

2011-11-30T06:27:00.001-08:00

JSR 286 portlet has introduced the event feature in it earlier in JSR 168 portlet spec, the only way to achieve eventing between portlets was through a portlet session. This was possible between portlets that are in the same web application. But in JSR defines a lifecycle for events, so that eventing is possible between portlets that are in different web applications.
(Ref: JSR286 portlet specification, Click here to download the full specification.)

Public render parameters

2011-11-30T06:06:00.000-08:00

The JSR 286 portlet specification has introduced the Public render parameters concept: which allow portlets to share parameters with other portlets. That means we can achieve the Coordination between Portlets through the Public render parameters. Basically in JSR 168, the render parameters set in processAction is only available in the render of the same portlet. But in JSR 286 with the Public Render Parameters feature, the render parameters set in the processAction of one portlet will be available in render of other portlets also.
Following are the steps to create portlets that use the public render parameters:
Step-1. We will declare the render parameters to be shared in the portlet.xml file by setting the public render parameters at the portlet application level.
……

. . .

product-id

……
Step-2. Now specify the render parameter that the portlet would like to share in the portlet section.
……..

......

product-id

. . .

product-id

. . .

Strep-3 And now finally set the render parameter in the processAction() method:
public class ProductsPortlet extends GenericPortlet {
. . .
public void processAction(ActionRequest req, ActionResponse res) throws IOException, PortletException {
. . .
res.setRenderParameter("product-id", product);
}
. . .
}

Enjoy coding :-)

Difference between PortletConfig.getInitParameter() and PortletContext.getInitParameter()

2011-11-14T10:30:00.000-08:00

Context initialization parameters are defined in the web.xml file. They share the same context space as Servlets and JSPs belonging to the same application and we can get them using PortletContext.getInitParameter() method.
Portlet-wide initialization parameters are defined in the portlet.xml file and we can get them using PortletConfig.getInitParameter() method.

Enjoy coding :-)

XMLAccess to deregister the web modules from WebSphere Portal Server.

2011-10-21T08:41:00.000-07:00

This is an add-on on my previous post 'How to deploy an EAR file on WebSphere Portal Server?' The same way we can write XMLAccess script to deregister the portlets/web modules (.war file) from WebSphere Portal Server. Following is a sample xml file for doing the same:

xml version="1.0" encoding="UTF-8"?>

<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"

type="update" create-oids="true">

<web-app action="delete" uid="<Pur here correct Web Module id>"/>

portal>

request>

Note: 1. you can add multiple tags to remove the web modules (.war files) from portal server. For each web module it will be a separate tag. 2. Put ‘delete’ as a value of action attribute of tag.

Enjoy :-)

How to create Virtual Portal on IBM WebSphere Portal Server?

2011-10-19T06:30:00.001-07:00

In my earlier post ‘WebSphere Portal Server: Virtual Portals Concept’ we have discussed about the Content of a virtual portal. Here we can configure our virtual portal using XML configuration interface script that will be an xml file and using it we will create a Virtual Portal. For example here I have configured and XML file InitVirtualPortal_ITCD.xml using the XML configuration interface script and I have added desired content in it.

Following are the steps to create a Virtual Portal:

Step1. Place the InitVirtualPortal_ITCD.xml file to the following WPS installed location:

C:\IBM\WebSphere \wp_profile\installedApps\\wps.ear\wps.war\virtualportal

Step2. Open the Portal administration console for the Portal server by going to https://localhost:10040/wps/portal/ and logging in as administrator user "wpsadmin" password "wpsadmin".

Step3. Click on Virtual Portals->Manage Virtual Portals

Step4. Click on the little arrow in the upper-right corner of the Virtual Portal Manager portlet and select Edit Shared Settings

Step5. Change the value for the Xml script to create virtual portal content tree field to "InitVirtualPortal_ITCD.xml" and click OK.

Step6. Click on New Virtual Portal tab

Step7. Enter the following information:

Virtual portal title: iTech Cognition Domain

URL Context: ITCD

Virtual portal hostname: You can leave blank

User realm: You can leave blank

Initial admin user group: Wpsadmins (Administrator)

Then Click Ok.

Virtual Portal ‘ITCD’ has created successfully:

Step8. Now click on virtual portal link ITCD or type the url: http://localhost:10040/wps/myportal/ITCD to open virtual portal.

Enjoy :)

How to deploy an EAR file on WebSphere Portal Server?

2011-10-19T02:40:00.000-07:00

The IBM WebSphere portal server does not allow deploying the EAR file directly in Portal Server. If you are planning to put all your web modules (war files) in an EAR file then you need to deploy the EAR file in WAS server and then later need to register your web modules/portlets to Portal server.

Following are the steps for doing the same using XMLaccess:

Step1. Deploy your EAR on WAS server: Using Integrated Solutions Console you can deploy your ear.

For example here we have deployed a SamplePortalEAR.ear file in below screen:

Step2. Create XMLAccess script for portlet registration on Portal server:

Below is the sample XMLAccess script to register the web modules/portlets on Portal server: This XMLAccess script is created for SamplePortalEAR.ear file, which have two web modules (war files) that we need to register on portal server.

xml version="1.0" encoding="UTF-8"?>

<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="PortalConfig_6.1.0.xsd"

type="update" create-oids="true">

<web-app action="update" uid="com.ibm.faces.portlet.FacesPortlet.9c5fe31133.webmod" active="true" predeployed="true">

<url>file://C:\IBM\WebSphere\wp_profile\installedApps\hecha\SamplePortalEAR.ear\testPortlet1.warurl>

<context-root>.testPortletcontext-root>

<display-name>testPortletdisplay-name>

<portlet-app action="update" active="true" uid="com.ibm.faces.portlet.FacesPortlet.9c5fe31133">

<access-control externalized="false" owner="all authenticated portal users" private="false">

role>

access-control>

portlet>

portlet-app>

web-app>

<web-app action="update" uid="com.ibm.faces.portlet.FacesPortlet.dc81041133.webmod" active="true" predeployed="true">

<url>file://C:\ibm\WebSphere\wp_profile\installedApps\hecha\SamplePortalEAR.ear\testPortlet2.warurl>

<context-root>.testPortlet2context-root>

<display-name>testPortlet2display-name>

<portlet-app action="update" active="true" uid="com.ibm.faces.portlet.FacesPortlet.dc81041133">

<access-control externalized="false" owner="all authenticated portal users" private="false">

role>

access-control>

portlet>

portlet-app>

web-app>

portal>

request>

Mandatory tags and their values:

The tag is about to web module (WAR file) in your EAR file. If we have more then one web module in our EAR file then for each module It will be a separate tag.

Note: The uid attribute of must be the correct web module id with.webmod
suffix.

The tag holds the installed location of your web module.
The tag should be the correct context path of your web module other wise script will not run successfully.
The tag has an uid attribute it holds the web module id.

Step3. Import XMLAccess: Once we are ready with our XMLAccess, now open Portal administration then goto left hand navigation and choose Import XML option under the Portal Settings.

Import XML file: Provide the location of XML file by clicking the browse button then click Import button: Once it will import successfully it will show an success message just above the same screen. (Below is the screen shot)

Registered: Now following web modules of SamplePortalEAR.ear file has been registered on portal server:

testPortlet1.war
testPortlet2.war

Registered Portlets: Now the following portlets of registered web modules are available on portal:

testPortlet2
testPortlet

Enjoy WPS :)

2011-09-26T05:28:00.000-07:00

WebSphere Portal Server: Virtual Portals Concept

Introduction

Virtual Portals are logical portals that share the same WebSphere Portal Server hardware and software installation.
All the Virtual Portals, including the default portal, run on and share the same JVM (Java Virtual Machine).
Each Virtual Portals will have its own unique URI.

Sample Portal Architecture using an Virtual Portal

Advantages of VP feature

Using the VP feature we can not only save costs by using the shared resources for multiple portals, but we also can enable a new portal application much faster as you don’t have to spend time installing and configuring new hardware and software for the new portal.

Portal resources that are scoped for virtual portals

WebSphere Portal has the following portal resources scoped internally for virtual portals:

Portal pages
Portlet instances
Portal Search Engine search services and search collections. This includes the search content sources.

Scoping of these resources is managed by internal portal mechanisms.
Scoped resources are only available for the virtual portal for which they are defined. They are well isolated from other virtual portals.
Scoped resources cannot be shared with other virtual portals. They are not visible or accessible outside of the virtual portal for which they have been created. This behavior cannot be changed by any portal access control settings.

The rules applied on Virtual Portal

Within each virtual portal you or a subadministrator can use Portal Access Control to grant individual users of that virtual portal specific access rights to the scoped portal resources. This works just like under a single portal installation.
An administrator can give access rights to users who are members of the user population of a virtual portal only on the scoped resources of that same virtual portal. This implies that, vice versa, you can give access rights on the resources of a virtual portal only to those users who are members of the user population of that virtual portal.
Users can only use these access rights when they access the specific virtual portal under which they have the access rights on the scoped resources. The same users cannot access the resources when logging in to a different virtual portal.

Portal resources that you can separate for virtual portals by using Portal Access Control

There are some portal resources that are not scoped internally for a particular virtual portal. These resources are shared among all virtual portals of the entire installation. However, as a master administrator you can yourself separate such portal resources for the virtual portals. To do this, use Portal Access Control and the access rights portlets to set up the appropriate access rights for users on the resources of each virtual portal as required.

You can separate the following portal resources by using Portal Access Control to give users of an individual virtual portal access right to the resources:

Portlets
Portlet applications
Web modules
URL mapping contexts
Users and groups.

You can separate these resources for individual virtual portals by using Portal Access Control. When you do this, apply special care. It can be of benefit to document the relationships between the users and the virtual portals.

Portal resources that cannot be separated for virtual portals

There are some types of portal resources that are not scoped to a particular virtual portal, and you cannot separate them yourself by using Portal Access Control. The following list shows portal resources that you cannot separate for virtual portals:

Themes and skins. If you do not want subadministrators to be able to manage themes and skins, restrict their access rights on them.
Vault segments and vault slots. To avoid security problems, use private credentials only. They can be used by only one specific user.
Supported clients and markups. The settings for these are configured in the corresponding portlets; therefore they apply to the entire portal installation.
Composite applications and templates. There is one common application and template catalog per installation. Users see the applications and templates to which they have access, regardless of virtual portal assignments. For more information about applications and templates refer to Composite applications.
Policies. Policy resources are not scoped to virtual portals. Users see the policy resources to which they have access, regardless of the virtual portal assignments.

Examples:

Themes and skins can be accessed by all subadministrators who have the access right to apply themes and skins to the pages that they can administer, regardless of which virtual portal the subadministrators are responsible for.
If a subadministrator imports a new template into one virtual portal, this template will appear in the application template library of all virtual portals.

Content of a virtual portal

When we create the virtual portal by using the Virtual Portal Manager portlet, the portlet invokes an XML configuration interface script that creates the initial content of the new virtual portal.

Content (wps.content.root). This includes the following pages and portlets:

Home (ibm.portal.Home). This includes the Welcome page.

Welcome (ibm.portal.WebSphere Portal.Welcome). This includes the following portlet:

Page Customizer (ibm.portal.Page Customizer)
Page Properties (ibm.portal.Page Properties)

Welcome (wps.p.Welcome)

Organize Favorites (wps.p.Favorites)

Search (wps.p.Search Center)
Profile Management (wps.p.Selfcare)
Documents (wps.Documents). This contains the following portlet:

Document Manager (wps.p.Documents) and Document Picker (wps.p.DocPicker)

Administration (ibm.portal.Administration). This includes the following portlets:

Manage Pages (wps.p.Manage Pages)
Users and Groups (wps.p.Manage Users and Groups)
Resource Permissions (wps.p.Resource View)
User and Group Permissions (wps.p.User Group Permissions)
URL Mapping (wps.p.Url Mapping)
Custom Unique names (wps.p.Unique Names)
Manage Search (wps.p.Manage Search Admin)
Manage Document Libraries (wps.p.MDL)
Enable tracing (wps.p.Enable Tracing)
Portlet Palette (wps.p.Content Palette)
Personalization Picker (ibm.portal.Personalization.Picker.portlet)
Applications (wps.p.App Catalog)
Edit Layout (wps.p.Content Layout)
Members (wps.p.App Membership)
Roles (wps.p.App Roles)
Properties (wps.p.App Properties)
Parameters (wps.p.Template Parameters)
Application Layout (wps.p.Application Layout)
Application Template Library (wps.p.Template Library)
Portlet Wiring Tool (wps.p.Wiring)
Appearance portlet (wps.p.Appearance)
Page Locks (wps.p.Permissions)
Page Properties (wps.p.Properties)
Information Portlet (wps.p.Information)
Anonymous Information (wps.p.Information.Anonymous). Note: This portlet is hidden.
Policy Editor (wps.p.PolicyEditor)
Resource Policies (wps.p.PolicyExplorer)

By default the administration portlet Virtual Portal Manager is installed as part of the initial portal installation only. It is not part of the default content of virtual portals that you create. You can only use it in the initial portal installation.

Enjoy :-)

Performance guidelines for themes and skins

2011-09-07T02:48:00.000-07:00

Use the following guidelines when making decisions that affect the development of your custom themes and skins. These guidelines describe the relative path length involved with the inclusion of various components of themes and skins. A number of the following changes are already implemented in the Portal theme. However, the functionality described is still supported and may have an impact on your design choices for your theme. To further aid in your design decisions, the Portal theme's approach to each guideline is listed in the following table:

Guidelines for a lightweight theme
Guideline	Effect on functionality	Effect on performance	Portal theme approach
Remove Show tools icon from the toolbar	Prevents users from displaying icons on pages and portlets used to arrange or remove content on the page.	High impact on pathlength required to generate the page	Show tools options are included through asynchronous context menus.
Remove enrollment icon from the toolbar	Prevents new visitors to the site from creating a new account for themselves.	High impact on pathlength required to generate the page	Enrollment included through asynchronous context menu.
Remove self care icon from the toolbar	Prevents users from updating account information.	High impact on pathlength required to generate the page	Edit Profile included through asynchronous context menu.
Remove AdminLinkBarInclude.jsp	Removes context-sensitive links that allow authorized users to create a new page, edit the current page, or assign permissions to the current page.	High impact on pathlength required to generate the page	These options are included through asynchronous context menu.
Remove and supporting code	Removes the ability for users to bookmark pages in the portal for quick retrievability	High impact on pathlength required to generate the page	Not included in the theme.
Shrink lines of text to remove white space	With some editors, white space might be used to aid in readability during theme development	Low impact on bandwidth required to transmit the page.	JSPs are left uncompacted for readability.
Change all HTML comments to JSP comments	None	Low impact on bandwidth required to transmit the page.	Mostly JSP comments used.

As noted earlier, not all of the above guidelines for the Portal theme may apply to all the available themes for WebSphere Portal. For example, the following guidelines do not apply to the Tab Menu - Page Builder theme:

Remove Show tools icon from the toolbar
Remove AdminLinkBarInclude.jsp
Remove and supporting code

Guides for a lightweight skin
Guideline	Effect on functionality	Effect on performance	IBM Skin approach
Remove minimize, restore, and maximize buttons	Prevents users from manipulating the size and state of the portlets on the page	High impact on pathlength required to generate the page	These options are included through asynchronous context menu.
Place the JSP tags for the Back, Edit, and Configure icons inside the tag.	No impact to users. Prevents unauthenticated (anonymous) users from attempting to access resources that are protected. For users that are logged in, this adds an extra JSP tag for processing. Processing of the tag has much less impact on performance than the access control checks to determine if a user has access to Edit and Configure portlet modes.	Medium impact on pathlength required to generate the page	None.
Shrink lines of text to remove white space	With some editors, white space might be used to aid in readability during skin development	Low impact on bandwidth required to transmit the page.	JSPs are left uncompacted for readability.
Remove drag and drop tags.	Users will be unable to drag and drop portlets on a page or from the Portlet Palette onto a page.	Medium impact on bandwidth required to transmit the page.	None.
Change all HTML comments to JSP comments	None	Low impact on bandwidth required to transmit the page.	Mostly JSP comments are already used.

As noted earlier, not all of the above guidelines for the IBM skin may apply to all the available skins for WebSphere Portal. For example, the Tab Menu - Page Builder theme does not use drag and drop tags. It uses the Dojo drag and drop framework. Hence, the Remove drag and drop tags guideline does not apply to the Tab Menu - Page Builder and the corresponding skins.

Note: If your starting point is the IBM skin, remember that portlet context menus are loaded asynchronously and the changes to the options available mentioned below (removing window state choices, surrounding in tag) will not affect the initial page size. The changes will affect the size of the page required to generate the contents of the portlet context menu.

Static resources

If possible, any CSS or Javascript that is included either in a theme, skin, portlet application, widget, or by any other extension should be built together either at buildtime or runtime, and then minimized and compressed to remove comments and unnecessary whitespace. This decreases the overall size of these files, reduces the number of HTTP requests the browser must make to aggregate the page, and reduces the load on the Web servers and Portal server. Using CSS sprites in themes, skins, and portlets can improve performance as well for the same reasons.

Theme Style and Theme Policy

2011-08-17T23:26:00.000-07:00

The theme policy concept has introduced in WebSphere portal server v6.x and above version. Theme Style and Theme Policy are different.

The theme style is used to modify the colors, fonts, and graphics displayed by the theme.

And theme policy is used to turn portions of the page on or off and adjust settings of those areas that are rendered, such as control the menu bread crumbs. These elements are controlled by modifying policy attributes and applying the policy to one or more pages.

The differences between 'Theme Style' and 'Theme Policy' are as following:

Theme Style

· We can create a new Theme Style using the Portal Administration, under Portal User Interface > Theme Customizer.

· We can edit a Theme Style using the Theme Customizer.

· We can remove a Theme Style using the Theme Customizer.

· You can apply a Theme Style to a page using the Theme Customizer or the Manage Pages portlet. The Manage Pages portlet treats a Theme Style as a Theme Policy.

Theme Policy

· We can create a new Theme Policy using the XML Configuration Interface.

· We can not edit a Theme Policy using the Theme Customizer.

· We can update a Theme Policy using the XML Configuration Interface (xmlaccess).

· We can not delete a Theme Policy using the Theme Customizer.

· We can remove a Theme Policy using the XML Configuration Interface (xmlaccess).

· We can apply a Theme Policy to a page using the Manage Pages portlet or the XML Configuration Interface.

The caching features in jsr 286 portlets.

2009-11-24T03:18:00.000-08:00

The JSR 286 specification added the following two new caching features:
1. Public cache scope: the cache entries are shared across users
2. Validation based caching: expired cache entries can be validated using ETag
But there in JSR 168, only "Expiration" cache was supported. And also the cache is per user client and not shared across users.
Public Cache Scope You can tell the Portlet Container that the cache entry can be shared across users. This can be done by setting the value of element to public.The default value is "private" which behaves like the JSR 168 caching where the cache is per user. The cache scope can also be changed programmatically using a response property(i.e MimeResponse.PUBLIC_SCOPE, MimeResponse.PRIVATE_SCOPE) or the new CacheControl interface(i.e response.getCacheControl().setPublicScope(true).)

Validation based Caching Validation" caching is supported along with "Expiration" caching. After the cache has expired the portlet has the option to check if the cache is still valid and indicate that the cache can be reused. To enable this, ETag has been introduced, which is similar to how the browsers, which conform to HTTP 1.1, perform caching. Once the cache has expired the Portlet Container calls the render/serveResource method with the ETag set in the RenderRequest/ResourceRequest, which the portlet can access and check if the cache is still valid. If the cache is still valid, then the portlet can set CacheControl.setUseCachedContent(true) in the response, and the new expiration time.

protected void doView (RenderRequest request, RenderResponse response)    throws PortletException, IOException {
   …
   if ( request.getETag() != null ) { // validation request
      if ( markupIsStillValid(request.getETag()) ) {
          // markup is still valid
          response.getCacheControl().setExpirationTime(30);
          response.getCacheControl().setUseCachedContent(true);
         return;
       }
   }
   // create new content with new validation tag
   response.getCacheControl().setETag(someID);
   response.getCacheControl().setExpirationTime(60);
   PortletRequestDispatcher rd = getPortletContext().getPortletRequestDispatcher(“view.jsp”);      rd.include(request, response);
}

The introduction of ETag ensures that the browser can be leveraged to cache resources and markup. With the new features of public sharing of caches, resource caching, validation caching and leveraging browser caching, the performance of aggregation of portlets by a portal can be seen to increase significantly.

How to write the portlet filter ?

2009-11-18T02:07:00.000-08:00

You can write a portlet filter in geven two steps:

Step 1 - Write a filter class: A filter class should implement one or more of the above mentioned four interfaces and should provide a no argument public constructor. The filter class should also override the init() and destroy() methods of the javax.portlet.filter.PortletFilter interface.

Step 2 - Filter and filter mapping: Define the filter and filter mapping in the portlet.xml . This is done using the element, where you also need to specify the lifecycle call to which the filter should be applied. In the element you describe to which portlets the filter should be applied. If you want the filter to be applied to all portlets in the application, you need to used an asterisk as a wildcard.

What are the Portlet Filters ?

2009-11-17T23:27:00.000-08:00

A portlet filter is same as a servlet filter. The only difference is that a servlet has only one request handling method, service() and therefore there is only one type of the servlet filter. A portlet on the other hand has four types of request handling methods and therefore there are four different types of portlet filters.

The portlet API defines the following interfaces for creating portlet filters:
javax.portlet.filter.ActionFilter - For processAction method
javax.portlet.filter.EventFilter - For processEvent method
javax.portlet.filter.RenderFilter - For render method
javax.portlet.filter.ResourceFilter - For serveResource method

Each of the above filter interface contains a single doFilter(Request, Response, FilterChain chain) method which differs in the type of request and response object. For example, the doFilter() method of ActionFilter takes instances of ActionRequest and ActionResponse objects while the doFilter() method of RenderFilter takes instances of the RenderRequest and RenderResponse.

Each filter interface extends a common base interface called javax.portlet.filter.PortletFilter. This common base interface contains two methods:
init(javax.portlet.filter.FilterConfig filterConfig) and destroy(). The init() method makes sure that every filter has access to a FilterConfig object from which it can obtain its initialization parameters, a reference to the PortletContext which it can use, for example, to load resources needed for filtering tasks. The destroy() method signifies the end of service of the filter. The init() and destroy() methods of a portlet filter are called only once during their lifetime.

A single filter class can provide filter functionality for more than one life cycle method. Also, a single filter can provide filter functionality for more than one portlet. Multiple filters can be associated with one life cycle method of a portlet. The doFilter() method of a portlet filter might create customized request and response objects by using the RequestWrapper and ResponseWrapper classes and by passing these wrappers to the doFilter() method of the FilterChain object.

Note: A portlet filter is a Java technology-based component that can be used to modify the content of the portlet request and portlet response before or after any life cycle method of the portlet.

Click here to know How we can write a portlet filter?

Set cookies for portlet.

2009-11-12T22:50:00.000-08:00

There you can set cookies for your portlet on the response of each lifecycle method (processAction, processEvent, render, and serveResource) with the following code:
response.addProperty(javax.servlet.http.Cookie cookie);

The cookie can then be accessed in all lifecycle methods using: request.getCookies(); method.

How a Portlet is different from a Servlet ?

2009-05-23T14:44:00.000-07:00

Here I would like to publish a small discussion on portlet and servlet, hope that will help you to make a better understanding on portal technology.

The differences between the portlet and servlet are:
1. Servlets can provide the content to complete web pages, whereas portlets only provide fragments. And these fragments are then aggregated to form a complete web page by the portal.
2. The user cannot access a portlet directly using a URL in the way that a servlet is accessed. Instead, the URL points to the page containing all of the portlets on single page.
3. Portlets aren’t allowed to generated HTML code that contains tags such as base, body, frame, frameset, head, title or html . Note: Here the iframe tag can be used with caution.
4. The communication between the web client and the portlets is performed through the portal.
5. Portlet allows to manipulate the portlets’ window states or portlet modes by providing the buttons or controls.

The similarities between the servlet and portlet:
1. Servlets and portlets are web based components that utilize Java for their implementation.
2. Portlets are managed by a portlet container similar to a servlet container.
3. Both of these components generate content, which can be static or dynamic.
4. Both portlets and servlets have a lifecycle that is controlled by the container.
5. The client/server model is used for both servlets and portlets.
6. The packaging and deployment are essentially the same.
7. The manner in which the classes are loaded and the class loaders that perform the work are also the same.
8. Lifecycle management is similar.
9. The Request and Response semantics are also similar.

There are several things that servlets are allowed to do, but portlets are not allowed. These are:
1. Portlet aren’t allowed to set the character set encoding of the response.
2. Portlet also aren’t allowed to set the HTTP headers on the response.
3. Portlet cannot manipulate the URL of the client request to the portal.

Enjoy :)

Download JSR 286 portlet specification 2.0

New features in JSR 286 portlets

2009-05-21T08:04:00.000-07:00

The main features are added in the jsr 286 specification are:
1. Events – enabling a portlet to send and receive events and perform state changesor send further events as a result of processing an event.
2. Public render parameters – allowing portlets to share parameters with other portlets.
3. Resource serving – provides the ability for a portlet to serve a resource.
4. Portlet filter – allowing on-the-fly transformations of information in both the request to and the response from a portlet.

Click here to download the complete jsr 286 specification.