Resource serving

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

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

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()

• 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.

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">

<portal action="locate">

<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?

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?

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">

<portal action="locate">

<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">

<portlet action="update" active="true" name="testPortlet" uniquename="">

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

<role actionset="User" update="set">

<mapping subjectid="all authenticated portal users" subjecttype="user_group" update="set" />

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">

<portlet action="update" active="true" name="testPortlet2" uniquename="">

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

<role actionset="User" update="set">

<mapping subjectid="all authenticated portal users" subjecttype="user_group" update="set" />

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 :)