Java Portals

HttpServletRequest and HttpServletResponse from portlet request

2012-02-03T14:34:00.000-08:00

Howto get HttpServletRequest and HttpServletResponse from portletrequest

We can only have portletRequest in the portlet. If weare setting anything in the HttpServletRequest it is not accessile inthe portlet. IBM provides an utility class which gives which convertsthe “portletRequest” to HttpServletRequest.

Thereare some scenario when you want to get httpServletRequest orhttpServletReponse from portletRequest.

PortletUtilclass available in the com.ibm.ws.portletcontainer.portletpackage in “com.ibm.ws.portletcontainer_6.1.0.jar” at“WebSphere/AppServer/plugins/”on server, through which you can directly get httpServletRequest,httpServletResponse, ServletContext and many more.

Code to getHttpServletRequest fromportletRequest/renderRequest/actionRequest.

HttpServletRequesthttpServletRequest=PortletUtils.getHttpServletRequest(renderRequest);

There arecouple of utility methods available in PortletUtil which gives youServletContext, ServletConfig, PortletWindow,PortletApplicationDefinition etc.

2012-02-03T14:32:00.000-08:00

WebSphereApplication Server Ships com.ibm.ws.webcontainer.httpsession.SessionInspectServletservlet that you can use to investigate what content is stored inHttpSession of your application. The SessionInspectServlet will tellyou

Names of the session attributes
Size of the data in session attribute
If the attribute is serializable or not

Youmight want to use this when you start gettingNotSerializableException or you run into performance issue due tosize of data stored in session.

Steps toadd SessionInspectorServlet to your web application

Add Session Inspector servlet to web.xml file of your web application.

Check the ibm-web-ext.xmi in the portlet WebContext.

Install and start your web application on server.

This is the output that i get for the webapplication. I am not storing anything in the session.

Access the SessionInspectorServlet by going to //SessionInspectServlet url

Delete/Overwrite cookie from client/UI

2012-01-11T12:25:00.000-08:00

function loaded()
{
    document.cookie = "v0=1;";
    document.cookie = "v1=2;";

    alert(document.cookie);
}

function deletecookie()
{
    var d = new Date();
    document.cookie = "v0=1;expires=" + d.toGMTString() + ";" + ";";

    alert(document.cookie);
}

>>First call method loaded -- To see the loaded cookies.
>> Then call deletecookie method to delete/overwrite the cookies.

testdelete cookie

Enabling traces in WebSphere Application Server

2011-12-12T09:45:00.000-08:00

Steps to enable traces

Open the WebSphere Application Service Integrated Solutions Console.

Expand Troubleshooting and select Logs and trace.

Select the server on which you want to enable traces, and then select Diagnostic Trace.

Click the Runtime tab.

Click Change Log Detail Levels.

Set the required trace level, select Save runtime changes to configuration as well, and click Apply.
The resulting traces of Member Manager will be written to portal_server_root/log/trace.log.
Restart is needed if the trace level is set as configuration level.

Web Services

com.ibm.ws.webservices.trace.MessageTrace=all

JSF

com.ibm.ws.wim.registry=all:

com.ibm.ws.jsf=all:

com.ibm.ws.webcontainer.*=all:

com.ibm.ws.jsp=all

PUMA

com.ibm.wps.puma.*=all:

com.ibm.wps.services.puma.*=all:

com.ibm.wps.command.puma.*=all:

com.ibm.wps.um.*=all:

com.ibm.ws.wim.*=all:

com.ibm.websphere.wim.*=all:

com.ibm.wsspi.wim.*=all

Personalization

For issues with personalization in WebSphere Portal ( rules, campaigns, application objects ):
com.ibm.websphere.personalization.*=all:com.ibm.websphere.query.*=all

For issues with personalization and security:
com.ibm.websphere.personalization.*=all

For issues with personalization and Web Content Management (WCM):
com.ibm.websphere.personalization.*=all:com.ibm.websphere.query.*=all:
com.ibm.workplace.wcm.pzn.*=all:com.ibm.workplace.wcm.services.pzn.*=all

For issues with personalization and JCR:
com.ibm.websphere.personalization.*=all:com.ibm.websphere.query.*=all:
com.ibm.icm.jcr.*=all

For issues with personalization authoring performance:
com.ibm.websphere.personalization.*=all:com.ibm.wps.caf.*=all

For issues with personalization runtime performance:
com.ibm.websphere.personalization.*=all

For issues with personalization publishing:
com.ibm.websphere.personalization.*=all

For configuration issues with personalization authoring environment
(Navigator Portlet, Editor Portlet, and List Portlet):
com.ibm.websphere.personalization.*=all:com.ibm.wps.caf.*=all

Portlet Container

com.ibm.wps.pe.pc.*=all:

org.apache.jetspeed.portlet.Portlet=all

javax.portlet.Portlet=all

Portlet Environment

com.ibm.wps.pe.ext.*=all:

com.ibm.wps.pe.factory.*=all:

com.ibm.wps.pe.om.*=all:

com.ibm.wps.pe.util.*=all

Portlets

Use to diagnose problems with portlets.

com.ibm.wps.portlets.*=all:

org.apache.jetspeed.portlet.PortletLog=all

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.ent.doc/wpf/run_logs.html

MongoDB

2011-12-08T12:05:00.000-08:00

MongoDB, noSQL open source database, written in C++, with many great features like map-reduce , auto sharding, replication, high availability and etc.

Why MongoDB?

Document-oriented
- Documents (objects) map nicely to programming language data types
- Embedded documents and arrays reduce need for joins
- Dynamically-typed (schemaless) for easy schema evolution
- No joins and no multi-document transactions for high performance and easy scalability
High performance
- No joins and embedding makes reads and writes fast
- Indexes including indexing of keys from embedded documents and arrays
- Optional streaming writes (no acknowledgements)
High availability
- Replicated servers with automatic master failover
Easy scalability
- Automatic sharding (auto-partitioning of data across servers)
  - Reads and writes are distributed over shards
  - No joins or multi-document transactions make distributed queries easy and fast
- Eventually-consistent reads can be distributed over replicated servers
Rich query language

MongoDB : CRUD operation Java Code

2011-12-08T12:02:00.000-08:00

Prerequisite:

1. Start the MongoDB before running the code.

package mongoDB;

import java.net.UnknownHostException;
import com.mongodb.BasicDBObject;
import com.mongodb.DB;
import com.mongodb.DBCollection;
import com.mongodb.DBCursor;
import com.mongodb.Mongo;
import com.mongodb.MongoException;

public class MongoDBTest {

    public void testMongoDB(){
        try {
            // DB Connection
            Mongo mongo = new Mongo("localhost", 27017);

            // Connect to existing db or if not exist create new one
            DB db= mongo.getDB("testmongodb");

            // Create a new collection or if not exist create a new one
            DBCollection dbCollection = db.getCollection("item");

            // Set data in the DBObject
            BasicDBObject item = new BasicDBObject();
            item.put("name", "Item1");
            item.put("quantity", "1.0");

            // insert the data : if item already exist it will be ignore other wise added
            dbCollection.insert(item);

            BasicDBObject find = new BasicDBObject();
            find.put("name", "Item1");

            // find the record on the basis of search criteria
            DBCursor dbCursor = dbCollection.find();

            while (dbCursor.hasNext()) {
                System.out.println(dbCursor.next());
            }

            //Update the record
            item = new BasicDBObject();
            item.put("name", "Item1 updated");
            item.put("quantity", "2.0");

            // save the data : if item already exist it will be update otherwise added
            dbCollection.save(item);
            find = new BasicDBObject();
            find.put("name", "Item1 updated");
            find.put("name", "Item1");

            // find the record on the basis of search criteria
            dbCursor = dbCollection.find();
            while (dbCursor.hasNext()) {
                System.out.println(dbCursor.next());
            }
        } catch (UnknownHostException e) {
            e.printStackTrace();
        } catch (MongoException e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args){
        MongoDBTest db = new MongoDBTest();
        db.testMongoDB();
    }
}

{ "_id" : { "$oid" : "4eb1886a6858c8ac05afca8d"} , "name" : "Item1" , "quantity" : "1.2"}

{ "_id" : { "$oid" : "4eb18ded6858419dd21690cd"} , "name" : "Item1" , "quantity" : "1.0"}

{ "_id" : { "$oid" : "4eb1886a6858c8ac05afca8d"} , "name" : "Item1" , "quantity" : "1.2"}

{ "_id" : { "$oid" : "4eb18ded6858419dd21690cd"} , "name" : "Item1" , "quantity" : "1.0"}

{ "_id" : { "$oid" : "4eb18ded6858419dd21690ce"} , "name" : "Item1 updated" , "quantity" : "2.0"}

MongoDB: Insert a Document

2011-12-08T11:56:00.001-08:00

There are 4 ways to insert a document in the MongoDB

BasicDBObject

BasicDBObjectBuilder

Map

Json

MongoDB: BasicDBObjectBuilder

2011-12-08T11:56:00.000-08:00

public void testMongoDBObjecyBuilder() {

        try {

            // DB Connection

            Mongo mongo = new Mongo("localhost", 27017);
            DB db = mongo.getDB("testmongodb");
            DBCollection collection = db.getCollection("consumer");

            BasicDBObjectBuilder dbObj = BasicDBObjectBuilder.start()
            .add("database", "testmongodb")
            .add("table", "consumer");

            // Set data in the DBObject
            BasicDBObjectBuilder consumer = BasicDBObjectBuilder.start()
            .add("name", "BasicDBObjectBuilder")
            .add("age", "20");

            dbObj.add("details", consumer);
            collection.insert(dbObj.get());
        } catch (UnknownHostException e) {
            e.printStackTrace();
        } catch (MongoException e) {
            e.printStackTrace();
        }
    }

MongoDB: BasicDBObject

2011-12-08T11:55:00.000-08:00

public void testMongoDBObject() {

        try {

            // DB Connection

            Mongo mongo = new Mongo("localhost", 27017);
            DB db = mongo.getDB("testmongodb");
            DBCollection collection = db.getCollection("consumer");

            BasicDBObject dbObj = new BasicDBObject();
            dbObj.put("database", "testmongodb");
            dbObj.put("table", "consumer");

            // Set data in the DBObject

            BasicDBObject consumer = new BasicDBObject();
            consumer.put("name", "BasicDBObject");
            consumer.put("age", "20");

            dbObj.put("details", consumer);
            collection.insert(dbObj);

        } catch (UnknownHostException e) {
            e.printStackTrace();
        } catch (MongoException e) {
            e.printStackTrace();
        }
    }

MongoDB: Code Change If running in Secure Mode

2011-12-08T11:51:00.001-08:00

Mongo mongo = new Mongo("localhost", 27017);

   // Connect to existing db or if not exist create new one
     DB db= mongo.getDB("testmongodb");

   // Authenticate the user
     boolean isAuth = db.authenticate("admin", "admin".toCharArray());

MongoDB: Secure Mode

2011-12-08T11:51:00.000-08:00

Start the server in normal mode

/etc/init.d/mongod start

> use adduser

switched to db adduser

> db.addUser("admin","admn")

{ "n" : 0, "connectionId" : 1, "err" : null, "ok" : 1 }

{ "user" : "admin", "readOnly" : false, "pwd" : "8ac----pwd---", "_id" : ObjectId("4eb-----") }

Stop the server

/etc/init.d/mongod stop

Start the server in the auth mode

/etc/init.d/mongod start –-auth

MongoDB: Map

2011-12-08T11:48:00.000-08:00

public void testMongoDBInsertMap(){

try {

// DB Connection

Mongo mongo = new Mongo("localhost", 27017);

DB db = mongo.getDB("testmongodb");

DBCollection collection = db.getCollection("consumer");

Map map = new HashMap();

map.put("database", "testmongodb");

map.put("table", "consumer");

// Set data in the DBObject

Map mapData = new HashMap();

mapData.put("name", "Map");

mapData.put("age", "20");

map.put("details", mapData);

collection.insert(new BasicDBObject(map));

} catch (UnknownHostException e) {

e.printStackTrace();

} catch (MongoException e) {

e.printStackTrace();

}

MongoDB: Json

2011-12-08T11:46:00.000-08:00

public void testMongoDBObjecyJSON(){

try {

// DB Connection

Mongo mongo = new Mongo("localhost", 27017);

DB db = mongo.getDB("testmongodb");

DBCollection collection = db.getCollection("consumer");

String json = "{'database' : 'localhost','table' : 'consumer'," +

"'detail' : {'name' : 'json', 'age' : '40'}}";

DBObject obj = (DBObject) JSON.parse(json);

collection.insert(obj);

} catch (UnknownHostException e) {

e.printStackTrace();

} catch (MongoException e) {

e.printStackTrace();

}

MongoDB: Complete Java Example

2011-12-08T11:44:00.000-08:00

package mongoDB;

import java.net.UnknownHostException;

import java.util.HashMap;

import java.util.Map;

import com.mongodb.BasicDBObject;

import com.mongodb.BasicDBObjectBuilder;

import com.mongodb.DB;

import com.mongodb.DBCollection;

import com.mongodb.DBCursor;

import com.mongodb.DBObject;

import com.mongodb.Mongo;

import com.mongodb.MongoException;

import com.mongodb.util.JSON;

public class MongoDBInsertDB {

public void testMongoDBfindRecord(){

try {

// DB Connection

Mongo mongo = new Mongo("localhost", 27017);

DB db = mongo.getDB("testmongodb");

DBCollection collection = db.getCollection("consumer");

BasicDBObject find = new BasicDBObject();

find.put("database", "testmongodb");

// find the record on the basis of search criteria

DBCursor dbCursor = collection.find(find);

System.out.println("Search results : ");

while (dbCursor.hasNext()) {

System.out.println(dbCursor.next());

}

} catch (UnknownHostException e) {

e.printStackTrace();

} catch (MongoException e) {

e.printStackTrace();

}

public static void main(String[] args){

MongoDBInsertDB db = new MongoDBInsertDB();

System.out.println("------ DBObject ------");

db.testMongoDBObject();

System.out.println("------ DBObjectMap ------");

db.testMongoDBInsertMap();

System.out.println("------ DBObjectBuilder ------");

db.testMongoDBObjecyBuilder();

System.out.println("------ JSON ------");

db.testMongoDBObjecyJSON();

System.out.println("------ Find Record ------");

db.testMongoDBfindRecord();

}

JSF-Ajax Portlet

2011-12-08T11:39:00.000-08:00

Web applications are now commonly referred to as Web 1.0. They have two distinct weak points from the user experience point of view:

The interaction between the browser and the server is initiated by a limited number of controls on the page -- usually only by links and buttons.
The interaction between the browser and the server results in updating the entire browser window.

Web 2.0, works around these weak points by using Ajax technology. In Ajax, interactions between the browser and the server occur in the background. They are also more targeted than the usual browser-server interactions, in that only a subset of the page can be sent to the server, and the server can return only a subset of the page to be updated. As a result of this approach, communication between the browser and server can be initiated by almost any event. This results in significant benefits:

Communication is faster, because less data is transmitted.
The user stays on the same page, because less navigation from page to page is required.
Complete browser is not refreshed. because only small regions of the page get updated with each Ajax request.

How to use Ajax with JSF components

There are 4 steps to integrate Ajax with JSF:

Identify the area of the page that will be updated by the Ajax request.
(If using Rational Application Developer v7x, you can use Ajax with the content of almost any panel component. The panels range from simple containers, such as and , to feature-rich panels, such as menus () and dialogs ().
Select the type of Ajax request to use. There are three different kinds of Ajax requests supported in the RAD V7 JSF library:

GET request for the same page ()
POST request for the same page ()
GET request for another page ()

Configure parameters to pass to the server with the Ajax request.

For GET requests, you can pass values of various input fields on the page.
For POST request, the entire form is submitted.

Identify the event that initiates the Ajax request. This can be any client-side JavaScript event, such as onclick for a button, onblur for an input field, or onchange for a check box.

Steps to create the Project:

Create a Portlet Project.
Select PortletType: Faces Portlet
Add jsp in the WebContent.
Go to the design Mode
Add the following components on the page using Enhanced Faces Components drawer
1. Drag the input component.
2. Drag a Panel Group box component from the palette onto the page below the Input component. When you are prompted for the group box type, select Group.
3. Drag an Output component from the palette onto the Panel Group box.
Add Ajax support to the panel
1. Select the outputText component and switch to the Properties view.
2. In the Properties view, select the h:panelGroup tag, which is directly above the h:outputText tag in the left-side tag navigator.
3. Select the Ajax page for the h:panelGroup tag.
4. Click the Allow Ajax updates check box.
5. Select Refresh as the Ajax request type.
Configure parameters for the Ajax request
1. Select Click to edit Ajax request properties on the Ajax properties page.
2. On the Properties page for the hx:ajaxRefreshRequest tag:
  - Click Add Parameter for the parameters to send from the browser.
  - Select the name of the Input component (in this case, text1) from the combo box.
3. On the Properties page , Select the outputText component.
4. Enter Hello, #{param.text1} into the Value field.

Initiate the Ajax request.
1. Select the inputText component.
2. Switch to Quick Edit view.
3. In the Quick Edit view:
  - Select the onblur event in the list of events on the left side.
  - Click the Use predefined behavior check box.
  - Select the Invoke Ajax behavior on the specified tag action.
  - Select the name of the panelGroup (in this case, group1) as the target.

JSP source will look like this:

Go to the jsp source and add the targetAction to the behavior tag : targetAction="group1"

The value of targetAction is same as the target value in the tag.

MongoDB : Maven dependency

2011-12-08T11:32:00.001-08:00

Add the following entry in the pom.xml

<groupId>org.mongodbgroupId>

<artifactId>mongo-java-driverartifactId>

<version>2.5.2version>

dependency>

MongoDB: Installation

2011-12-08T11:32:00.000-08:00

Install Mongo DB on Linux

1. Install MongoDB on Fedora 16/15/14/13/12/11, CentOS 6/5.6 and Red Hat (RHEL) 6/5.6

Change to root User

sudo -i

Add and enable 10gen MongoDB repository

open /etc/yum.repos.d/10gen-mongodb.repo

[10gen]

name=10gen Repository

baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/x86_64

gpgcheck=0

Install mongo server and mongo client packages

yum install mongo-10gen mongo-10gen-server

2. Configure MongoDB Database Server

Edit /etc/mongod.conf
nano -w /etc/mongod.conf
Check and set basic settings, before starting MongoDB (default settings are good)

logpath=/var/log/mongo/mongod.log

port=27017

dbpath=/var/lib/mongo

3. Start MongoDB Server

/etc/init.d/mongod start

4. Test MongoDB Server

Open MongoDB Command Line Client

mongo

Open Browser

http://localhost:28017/

WMM & VMM

2011-12-07T15:37:00.000-08:00

WMM
security.xml : (wps_profile/config/cells/cell01)
wimconfig.xml: (wps_profile/config/cells/cell01/wim/config)

wimconfig.xml is a WebSphere Application Server (WSAS) configuration file, however it is an important file in a WebSphere Portal environment.It is the main file that controls the behavior of the Virtual Member Manager component (VMM). WebSphere Portal (WP or Portal) depends on VMM services during login, user and group search and access control assignments, among other tasks. Wimconfig.xml is critical to the functioning of WebSphere Portal.

VMM

In Portal 6.1 and later VMM has replaced the WebSphere Member Manager (WMM). There is no WMM code in Portal or WSAS 6.1. Most of the terms used in WMM (realm, searchBase) translate directly to VMM and the configuration "pattern" of properties and their values represented as XML applies to VMM as well. VMM is simpler to manage in that there is only a single major configuration file while in WMM care often had to be taken to ensure consistency across multiple files.

The core Portal code does not communicate with a configured repository directly. Calls are made by VMM at the direction of Portal components; principal among these is PUMA, the Portal User Management Architecture. For example, a search for a user by CN in the Users and Groups portlet makes calls to PUMA which in turn calls VMM to fetch data from the repository. Similarly, PUMA API calls also result in method calls by VMM.

Websphere portal - Autologin

2011-12-07T15:33:00.000-08:00

http://server:port/wps/portal/ cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?
userid=user ID&password=password

Java - Capturing SOAP request/response for Apache Axis client

2010-08-01T09:34:00.000-07:00

Save this file as client-config.wsdd in the working directory of your Axis client. Axis will load it automatically.

The configuration here tells Axis to save all incoming and outgoing XML into a file named axis.log.

//Save this file as "client-config.wsdd" in the working directory of your Axis client. Axis will load it automatically. The configuration here tells Axis to save all incoming and outgoing XML into a file named "axis.log"

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<handler name="log" type="java:org.apache.axis.handlers.LogHandler"/>
<globalConfiguration>
<requestFlow><handler type="log"/></requestFlow> <responseFlow><handler type="log"/></responseFlow>
</globalConfiguration>
<transport name="http" pivot="java:org.apache.axis.transport.http.HTTPSender"/>
</deployment>

Adding Custom Attributes to WebSphere Portal

2010-02-27T00:08:00.000-08:00

Before adding any new attribute, the current attribute configuration should be validated and corrected with proper mappings and removing unwanted attributes.

Validate/Verify the Attribute Mapping

Run ConfigEngine.bat wp-validate-standalone-ldap-attribute-config -DWasPassword=password

There are 2 ways to add the attribute

In wkplc.properties

Modify the wkplc.properties with the following:
standalone.ldap.attributes.mapping.ldapName=mail
standalone.ldap.attributes.mapping.portalName=ibm-primaryEmail
standalone.ldap.attributes.mapping.entityTypes=PersonAccount,Group

The above configuration also maps the ibm-primaryEmail to mail in LDAP.

Run

ConfigEngine.bat wp-update-standalone-ldap-attribute-config -DWasPassword=password

Command line

Check if wimejb.jar is installed for not. If not then install it using

1. ConfigEngine.bat wp-la-install-ear -DwasPassword=password
(Execute ./ConfigEngine.sh wp-la-install-ear task, this task will install WIMSYSTEM.ear which contains wimejb.jar on your portal server. The wimejb.jar is used for actual attribute addition)

2. Restart all the servers.

Add Attribute

./ConfigEngine.sh wp-add-property -DWasPassword=password -Dla.propertyName="portal property name"
-Dla.entityTypes=PersonAccount
-Dla.dataType=String
-Dla.multiValued=false
-Dla.providerURL=corbaloc:iiop:host-name:bootstrap-port

Restart the server

Change LDAP Host Name in Websphere Portal

2010-02-27T00:03:00.000-08:00

Change the host name for LDAP in the following files:

security.xml (wps_profile/config/cells/cell01)
wimconfig.xml (wps_profile/config/cells/cell01/wim/config)
wkplc.properties (wps_profile/ConfiEngine/properties)

Restart the server.

Update Portal from 6.1.2 to 6.1.5

2010-02-27T00:00:00.000-08:00

Perform the following steps to download the fix and the WebSphere Portal Update Installer:

1. Download the latest cumulative fix file and WebSphere Portal Update Installer from ibm site
.

2. Create the portal_server_root/update directory and extract the WebSphere Portal Update Installer file into this directory. NOTE on Windows: The pkunzip utility might not correctly decompress the download image so use another utility such as Winzip to unzip the image.

3.Create the portal_server_root/update/fixpacks directory and extract the WP_PTF_6103.zip file into this directory.

If using the Universal PUI, (which does not include the bundled Java environment), run the following command, setupCmdLine.bat for Windows or . ./setupCmdLine.sh for Unix/Linux from the was_profile_root/bin directory to set up the Java environment for the graphical user interface installation program.

* Enter the following command to launch the graphical user interface installation program:
Windows: portal_server_root\update> updatePortalWizard.bat
Unix/Linux: portal_server_root/update> ./updatePortalWizard.sh

Once the fix pack is successfully installed then install the fixpack of 6.1.5

4. Change to the wp_profile_root/PortalServer/bin directory.

5. Run the appropriate command for your operating system:
Unix/Linux: ./install615.sh

Web App Integrator

2010-02-26T23:26:00.000-08:00

To integrate an external web application with Portal, there are 3 approaches:

1. Write a set of portlets that expose the web application's UI/functionality.
2. Use Portal's web clipper portlet (an iFrame based portlet).
3. WebAppIntegrator offers a third approach allows external web applications to be integrated with WebSphere Portal (Portal)

WebAppIntegrator solution work?

WebAppIntegrator integration is achieved by "injecting" Portal navigation markup into the external web application when the web application is rendered. The solution implementation leverages the existing Portal URL page feature and makes use of a new Portal entry point, the WebAppIntegrator theme template, which returns JavaScript that generates Portal page navigation markup (e.g. page tabs, the banner and bread crumbs). This markup is "injected" into an external web application by adding an HTML.

Advantages of using the WebAppIntegrator

1. No portlet development is required to implement this integration since it does not use portlets at runtime. Portal administrators, in concert with the internal web application owner, can do this integration.

2.It does not use an iFrame. Consequently, the viewing area of the web application is not constrained in any way (i.e. no iFrame scroll bars). Also, all JavaScript and links within the integrated web application continue to function as expected.

Integration?

There are exactly three steps required to integrate an external web application with Portal:

1.Create the URL which is pointing to the external web application on Portal.

2.Download the WebAppIntegrator from the developer site.

3.Follow the steps to install the WebAppIntegrator described in the downloaded zip.

4.Once the the WeIntegrator is configured.

5.Installed the war file and add the portlet on the page.

6.Use the new Web Application Integrator portlet to generate an HTML "script" tag using Unique name.

7.Add the script tag to the web application.

Design goals

There were several design goals that guided this solution as its implementation evolved. They should provide a technical audience with a better understanding of this solution's design.

They are listed below in order of perceived importance:

1. Ease of Integration - The integration is achieved in three simple steps, the most complex of which is simply adding an HTML "script" tag to the external web application.

2. External web application can be implemented using non-J2EE technologies - Portal navigation markup is returned as JavaScript when the browser executes the HTML "script" tag. Because the tag's execution occurs on the client machine (in the browser), the integrated web application can be built using any technology (e.g. .NET, Ruby on Rails, PHP, PEARL, Domino, J2EE, etc.)

3. Cross-Domain Capability - web applications need not be installed in the same domain as Portal.

4. Bookmarkability - Web applications can be bookmarked (not possible when web application is integrated with Portal using iFrame approach). When SSO in configured between the web application and Portal, bookmarked pages of the web application will properly display Portal navigation markup.

WebSphere Portal Server : Standalone LDAP Registry

2010-02-26T23:05:00.000-08:00

Steps to configure Stand-alone LDAP registry for the WebSphere Portal Server.

1. Go to /ConfigEngine/properties
2. Edit wkplc.properties

standalone.ldap.id=unique_name
standalone.ldap.host=host_name
standalone.ldap.port=389
standalone.ldap.bindDN=uid=wpsbind,cn=users,dc=abc,dc=com>
standalone.ldap.bindPassword=
standalone.ldap.ldapServerType=SUNONE
standalone.ldap.userIdMap=inetOrgPerson:uid
standalone.ldap.groupIdMap=*:cn
standalone.ldap.groupMemberIdMap=
standalone.ldap.userFilter=((objectclass=inetOrgPerson))
standalone.ldap.groupFilter=((objectclass=groupOfUniqueNames))
standalone.ldap.serverId=
standalone.ldap.serverPassword=

# The security context of this server. A realm with this name will be created.
standalone.ldap.realm=

# The ID of the WAS admin user. The ID must exist in the LDAP server.

standalone.ldap.primaryAdminId=uid=wasadmin,cn=users,dc=abc,dc=com
standalone.ldap.primaryAdminPassword=wasadmin

# The ID of the portal admin user. The ID must exist in the LDAP server.

standalone.ldap.primaryPortalAdminId=uid=wasadmin,cn=users,dc=abc,dc=com
standalone.ldap.primaryPortalAdminPassword=wasadmin

# The user group with admin permission in portal. The group must exist in the LDAP server.

standalone.ldap.primaryPortalAdminGroup=cn=wpsadmins,cn=groups,dc=abc,dc=com

# The LDAP base entry.
# This is the startpoint for all LDAP searches of Websphere Application Server Security

standalone.ldap.baseDN=dc=abc,dc=com

# Entity type Group

standalone.ldap.et.group.objectClasses=groupOfUniqueNames
standalone.ldap.et.group.objectClassesForCreate=

# The search base or bases to use while searching the entity type.
standalone.ldap.et.group.searchBases=

# Entity type PersonAccount

standalone.ldap.et.personaccount.searchFilter=
standalone.ldap.et.personaccount.objectClasses=inetOrgPerson
standalone.ldap.et.personaccount.objectClassesForCreate=

# The search base or bases to use while searching the entity type.
standalone.ldap.et.personaccount.searchBases=
## Group member attributes
standalone.ldap.gm.groupMemberName=uniqueMember
standalone.ldap.gm.objectClass=groupOfUniqueNames
standalone.ldap.gm.scope=direct
standalone.ldap.gm.dummyMember=uid=dummy

# Default parent, RDN attribute

standalone.ldap.personAccountParent=cn=users,dc=abc,dc=com
standalone.ldap.groupParent=cn=groups,dc=abc,dc=com
standalone.ldap.personAccountRdnProperties=uid
standalone.ldap.groupRdnProperties=cn

# Defines if VMM will enable the ConnectionPool
standalone.ldap.connectionPool=false

3. save the wkplc.propeties
4. websphereProfile/ConfigEngine and run

./ConfigEngine.sh validate-standalone-ldap -DWasPassword=wasadmin

./ConfigEngine.sh wp-modify-ldap-security -DWasPassword=wasadmin

Restart both the server1 and WebSphere_Portal server

ITAM - Webseal - Developing External Authentication Interface (EAI)

2010-02-25T14:53:00.000-08:00

WebSEAL is a high-performance, multi-threaded Web server that applies fine-grained security policy to the Tivoli Access Manager protected Web object space. WebSEAL can provide single sign-on solutions and incorporate back-end Web application server resources into its security policy. WebSEAL normally acts as a reverse Web proxy by receiving HTTP/HTTPS requests from a Web browser and delivering content from its own Web server or from junctioned back-end Web application servers. Requests passing through WebSEAL are evaluated by the Tivoli Access Manager authorization service to determine whether the user is authorized to access the requested resource.
[Source: IBM Tivoli Access Manager & WebSEAL]

Webseal provides a authentication interface out-of-box which does the authentication and authorization after user enters the username and password and submits the form.

There can be scenarios/requirements where it is required to enhance the login page.

For example:
Branding of login page for an organization. Provide i18N.
Perform different actions before login to system.

Branding can be handled out-of-box if the login page is common to all SSO enabled applications. If the branding is required specific to each application, then it is difficult to address it OOB.

Similarly, for i18N it is not possible to maintain the resource bundles for the plain html form.

The above requirements can be fulfilled by designing an EAI and perform the desired operations and submit the control back to Webseal.

* Considering Struts framework for the module, following steps may be peformed to build the EAI module:

1. Create an Action class which would be called by webseal to redirect the user to EAI.

2. Map the action to login.jsp and display the desired page.

3. To meet the branding divide the page into different sections where the username/password box location need to be static while other content area can be adjusted dynamically.

4. In the action class load the resourcebundle and read all the key/values that are needed on the Login page.

5. For branding, keep the URL,appname as key value in properties file and read it in the action class. Now based on the application name, display the login page.

6. To get the URL from webseal, we need to enable the macros (URL) in webseald-default.conf. We will discuss the webseald-default.conf in later sections.

7. For i18N, load the properties based on the locale (either get it from browser) OR show a default language page and display the option to change the locale from that page.

8. The user can enter the username and password on the page and we can write our custom validations before performing any other operation.

9. Once the validations are complete, the user and password can be validated against LDAP/DB either through direct LDAP query or using TAM APIs.

10. Considering that webseal is used for authorization, now the time is to submit the user to webseal.

11. The step for final submission involves setting the response to OK (200) and flush it.

* Handling the Configuration at Webseal and relate with EAI module:

1. The desired URL needs to map to the Webseal IP in DNS.

2. Create a standard junction for the EAI hosted on the app server. Now, make the following changes in webseald-default.conf:

3. Set the enable-local-response-redirect to "yes".

4. The entry for local-response-redirect-uri should contain complete URL mapping to the action class.

5. The MACROS should be enabled for URL, USERNAME, PROTOCOL, HOSTNAME etc as per the requirement.

6. Define a trigger, which would map to URL which is last called when submitting the response.

7. Lastly, you should configure the common headers to record the username and URL for sending the user back to webseal.

# Sample EAI COMMON header names
eai-redir-url-header =

eai-user-id-header =

For the detailed knowledge, please refer to documentation on ITAM and sample code provided by IBM.

What's New in IBM WebSphere Portal 6.1

2009-07-03T15:27:00.000-07:00

Site management

Site management to manage the individual pages and groups of page, artifacts, and properties that make up those pages by providing an easy way to move them around between Portal environments.

The new Resource Manager Portlet lets administrators create a page on a source server, then publish it to a target server where only a selected group of users can see and test the new page. After testing is complete, you can promote the new page so all users on the target server with the appropriate access rights can view the new page.

Portal Administrators can use the Site Management capability by accessing the Resource Manager Portlet on the Site Management page in the Portal Administration area.

Theme Customizer

The Theme Customizer portlet features a tabbed design and live preview you can use to customize key site elements including the banner, navigation, fonts, and colors, turn areas of the page on and off, and adjust the settings for areas of the page such as the navigation (figure 5). This portlet includes a wizard-driven branding and in-place customization, designed to simplify new theme style creation or updates.

Search Enhancements

Portal Search is enhanced with features designed to enrich the search experience for users and improve Portal Search consumption. In version 6.1, searching Portal content is remotely accessible through REST Services, letting clients (e.g., Lotus Sametime) integrate search functionality.

The new AJAX Search Center is based on a set of customizable components which may be Portlets or Dojo Widgets. The components are designed to be "mashed-up" to create a search experience to match the needs of each organization.

You can also add a new External Search Results portlet to the Search Center. This portlet displays search results from third-party search engines such as Yahoo!, Google, or Flickr and you can configure it to display different number of results.

With the new External Search Results portlet, you can extend your search by searching against external search engines and viewing their search results in the Search Center, in addition to the main search against WebSphere Portal.

Other new features
New Feed reader portlet based on AJAX
Support for portlet open standards such as JSR286 and WSRP 2.0
New portal Site Wizard lets users create independent virtual portals
Updated out-of-the-box Internet and intranet site jumpstart templates

Web 2.0 Portal theme

2009-07-03T15:25:00.000-07:00

WebSphere Portal 6.1 comes with a new Web 2.0 Theme. The new theme uses AJAX, XSLT, and a new aggregation model called Client-Side Aggregation (CSA).

The Portal Web 2.0 Theme is a specialized theme which only renders the parts of the page that are changed from a user interaction. So, if there are four different portlets on a page and a user interacts with a single portlet on the page, only the portlet the user interacts with is updated. If a user selects a new page on the Portal navigation links, only the affected navigation elements are updated, and the new page contents are rendered. Rather than updating and refreshing the entire page on every user interaction, the CSA aggregator only updates the parts of the page that changed.

Client-Side Aggregation (CSA) reduces server-side processing and improves performance by offloading the page and portlet rendering from the server to the client, providing a richer and more responsive user experience. Previous versions of WebSphere Portal supported Server-Side Aggregation model only where JSPs were executed on the Server.

Live Text (Semantic Tags)

This new feature provides a simple way of adding semantic tags (keywords) to the HTML markup to simplify information discovery, retrieval, and navigation. For instance, in figure 2, a Live Text "pop-up" presents access to relevant information, such as e-mail address, job

Web Application Integrator

With Web Application Integrator, you can integrate external Web applications with WebSphere Portal providing a way of easily embedding existing Web applications into WebSphere Portal with no portlet development required.
You perform this integration by "injecting" Portal navigation markup into the external Web application. As the Portal navigation is displayed in the Web application, the user experience suggests the user is still in the Portal environment even though he is, in reality, natively browsing the external Web application. Because the Portal navigation is displayed on the Web application, the user can navigate back to Portal by clicking on any Portal page link

Steps to create New Web2.0 Skin in WebSphere portal

2009-07-03T15:13:00.000-07:00

1. Duplicate the IBM.xsl file and rename newSkin.xsl within the xsl folder inside your
theme
/wps.ear/wps.war/themes/html/newTheme/xls

2. In the skins/html folder, duplicate the "IBM" skin folder and rename to newSkin.

3. In the head_extras_jspf file, add your new skin. Add the following line in the bootstrap function

portalAggregator.page.addSkin(new
com.ibm.portal.aggregation.Skin("newSkin",skinResourceRoot2Id["newSkin"],""),false);

note: newTheme is the custom theme
newSkin is the custom skin

Accessing portlet services

2009-07-03T15:11:00.000-07:00

This article explains how the JSR 168 portlet can retrieve and use a sample portlet service.

1.JNDI lookup for a PortletServiceHome. (best pratice is to do that in the init() method of the portlet and store the returned object in an instance variable.)

import javax.portlet.*;
import com.ibm.portal.portlet.service.*;

private PortletServiceHome helloServiceHome = null;
.

public void init(PortletConfig config)
{
javax.naming.Context ctx = new javax.naming.InitialContext();
try {
Object home = ctx.lookup("portletservice/sample.portletservice.HelloService");
if (home != null)
helloServiceHome = (PortletServiceHome) home;
} catch(javax.naming.NameNotFoundException ex) {
config.getPortletContext().log("No hello service available");
}
}

Creating your own portlet service for JSR Portlets

2009-07-03T15:05:00.000-07:00

Defining the interface

A portlet service interface must extend the PortletService interface defined in the com.ibm.portal.portlet.service package. The following is an example interface for the HelloWorldService .

package test.portletservice;

import java.io.IOException;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import com.ibm.portal.portlet.service.PortletService;

public interface HelloService extends PortletService
{
/** print a nice greeting */
public void sayHello(RenderRequest request, RenderResponse response) throws IOException;
}

Writing the service implementation

The service implementation must implement the PortletServiceProvider interface of the com.ibm.portal.portlet.service.spi package to be able to make use of the portlet service life cycle methods in addition to your service interface.

The PortletServiceConfig parameter of the init() method allows you, for example, to access the configuration of the service.

package test.portletservice;

import java.io.IOException;
import java.io.PrintWriter;
import java.util.prefs.Preferences;

import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;

import com.ibm.portal.portlet.service.spi.PortletServiceProvider;

public class HelloServiceImpl
implements HelloService, PortletServiceProvider {

private String message;

// called by the portal when the service is initialized
public void init(Preferences servicePreferences) {

// read the message from the configuration, default is "Hello"
message = servicePreferences.get("message", "Hello");
}

public void sayHello(RenderRequest request, RenderResponse response) throws IOException {
String user = request.getRemoteUser();
if (user == null)
// no user logged in
user = "Guest";

PrintWriter out = response.getWriter();
out.print(message);
out.print(", ");
out.print(user);
}

}

Registering the service

1. Put all service interface and implementation classes into a JAR file.
2. Place the JAR file in the wp_root/shared/app directory.
3. Update the PortletServiceRegistryService.properties file in the
wp_root/shared/app/config/services directory
to register the new service:

1. Register the implementation in the JNDI directory. The syntax of this line is
jndi:service_interface = service_implementation. The fully qualified service interface name can then be used to lookup the service.

2. Provide configuration parameters for the implementation. The syntax for configuration parameters is service_implementation.parameter=value.

3. Restart the portal server.

HelloService is the name of the portlet service and the message configuration parameter is set with the value Greetings.

jndi:sample.portletservice.HelloService = sample.portletservice.HelloServiceImpl
sample.portletservice.HelloServiceImpl.message = Greetings

To check whether your service has been registered successfully, use the application server dumpNamespace tool. The following command, executed from the was_profile_root/bin directory, will list all portlet service entries in JNDI:

dumpNamespace -port bootstrap_port -root server -startAt portletservice

Using the application server's administrative console, you can find the bootstrap port of your portal server in the "End Points" section of the settings for the server "WebSphere_Portal"

JSF Portlet - Shale View Framework

2009-04-02T15:35:00.001-07:00

Summary
A POC was done to create a sample widget portlet that is able to clear the portlet state. The sample portlet created is able to clear the portlet state. The feature to clear the portlet state can be integrated to any page of the portlet.

Shale View Framework
The approach uses the Shale View Framework. Shale supports a mechanism that provides a relationship between a presentation layer and corresponding backing bean including event handling logic, values used in the dynamic rendering of the response.

Shale view framework supports:
Portlet view can be modified before rendering.
Multiple pages portlet can be handled using this approach.

For example:
There are 2 pages in portal, Welcome & Benefits

On Benefits: We have 1 portlet which has 3 jsps.

Steps:
User click on Benefits Page and go to page2 (jsp2)
Then go to Welcome page from the navigation and click on the Benefits page again

In usual case, as per as portal behavior it should go to page 2, since portal caches the portlet state but with the help of Shale view framework, we can check the jsp from which the user is coming from and modify the Navigation State and forward it to page1 (jsp1)

Steps to Integrate the Shale view in the existing portlets

1. Portlet should have the pageCode.java
2. Add the dependency for Shale-view in pom.xml
3. Add the Phase Listener Classs, which extends extends ViewPhaseListener and implements PhaseListener
4. In the backing bean extend PageCodeBase.java and implement ViewController.

Code Level changes

Backing Bean: jsp1
Set a parameter in the session when the user is going from jsp1 to jsp2

FacesContext facesContext = FacesContext.getCurrentInstance();
PortletSession session =
((PortletRequest)facesContext.getExternalContext().getRequest()).getPortletSession(false);
session.setAttribute("pageCache", "true");

Backing Bean: jsp2
Override the prerender.

Remove the parameter from the session in the prerender of jsp2
FacesContext facesContext = FacesContext.getCurrentInstance();
PortletSession session = ((PortletRequest)facesContext.getExternalContext().getRequest()).getPortletSession(false);
session.setAttribute("pageCache", "false");

PhaseListener.java

if(session.getAttribute("pageCache")!=null && session.getAttribute("pageCache").equals("false") ){
NavigationHandler navigator = facesContext.getApplication().getNavigationHandler();
navigator.handleNavigation(facesContext, null, "POCProjectView");
}

Facesconfig

Public Render Parameters

2009-01-12T23:39:00.000-08:00

In JSR 168, the render parameters set in processAction is only available in the render of the same portlet.
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. Using public render parameters instead of events avoids the additional process event call.

In order to allow coordination of render parameters with other portlets, within the same portlet application or across portlet applications, the portlet can declare public render parameters in its deployment descriptor using the public-render-parameter element in the portlet application section. Public render parameters can be viewed and changed by other portlets or components.

In the portlet section each portlet can specify the public render parameters it would like to share via the supported-public-render-parameter element. The supported-public-render-parameter element must reference the identifier of a public render parameter defined in the portlet application section in a public-render-parameter element.
In the code, the portlets should use the defined public render parameter identifier to access the public render parameter

Steps to create a portlet with the Render parameters

Declare the render parameters to be shared in the portlet.xml

Specify the render parameter that the portlet would like to share in the portlet section

Set the render parameter in the processAction() method

JSR286 : Eventing Feature

2009-01-12T23:13:00.000-08:00

Eventing can be described as a loosely coupled, brokered means of communication between portlets. It is intended to allow portlets to react on actions or state changes not directly related to an interaction of the user with the portlet.
Events are a lifecycle operation that occurs before the rendering phase.

Steps to have eventing feature in Portlet

1. Declare the events in the portlet.xml
Set the event definition at the portlet application level. This specifies the event name and the object type.
Note: The object must be serializable and must be instrumented with valid JAXB annotation

2. In the portlet section, specify the event name defined above for those portlets that want to publish this event.

3. In the portlet section, specify the event name defined above for those portlets that want to process this event.

4. Issue an event in the portlet that was specified as supported-publishing-event in the portlet.

5. Process the event in the portlet that has specified as supported-processing-event in the portlet

JSR 168 and 286 Specification

2009-01-12T23:11:00.000-08:00

Portlets are Web-based components managed by portlet containers that supply dynamic content. Portals employ portlets as pluggable user-interface components—a presentation layer—for information systems. The Java Portlet Specification achieves interoperability among portlets and portals by defining the APIs for portlets and by standardizing the rules for preferences, user data, portlet requests and responses, deployment, packaging, and security. Java Portlet Specification 1.0, Java Specification Request (JSR) 168, was released in October 2003.
In February 2006, the JSR 286 Expert Group was formed to start work on Java Portlet Specification 2.0. When that is finalized, backward compatibility will be in place: JSR 168 portlets will be able to run seamlessly in JSR 286 portlet containers. No recompilation will be necessary.

What new in JSR 286?

Eventing
Public Render Parameters
Resource Serving
Portlet Filters
Validation based caching
Request Dispatcher Include from all lifecycle
Request Dispatcher Forward from all lifecycle
Container Runtime Options that includes escapeXml and actionScopedRequestAttributes
Taglibrary enhancements

Themes & Skins : WebSphere Portal

2008-12-08T14:58:00.001-08:00

The portal page is composed of JSPs for screens, themes, and skins that are typically created by the Web designer of the portal.

Themes :It provide the navigation, appearance, and layout of the portal, including colors, fonts, and images outside of the portlet content area.
Screens:The area of the portal that typically displays portlets, but can also display other content in its place, for example, a login form or error message. Screens are selected from navigation icons in the theme.
Skins:It represent the border rendering around components, such as row containers, column containers, or portlets. Skins are installed independently from themes. However, the administrator can set a default skin for a theme.

Themes:
It is best practice to copy the IBM directory, give it your own name, and then use that for your sample. Also, it is best to assign it to a page only, and not the whole portal, while developing it. The portal page is rendered starting with Default.jsp in the /themes directory.

The starting place for building the portal page is Default.jsp in the /themes directory. The screen and skin are called by the corresponding and tags from the engine tag library.

JSP in theme:

Head.jspf: Head.jsp provides the necessary header information to correctly render the portal page. This file is used to link the style sheets and set the page title and the text direction.

Banner.jspf. This fragment is the first visible JSP fragment to be included in the portal. It represents the top layer of the page and it holds the launch button, the breadcrumb trail, the search control, and the toolbar JSPF files.

TopNav.jspf. This fragment controls the look and feel of the top navigational bar. This bar can be one or two layers, depending on the theme policy selected. Edit this JSP file if you want to create a drop-down navigational structure. The file also holds logic to render the context menus for the page. Appendixes A and B show additional variations on the navigation of the WebSphere Portal site.

SideNav.jspf. This fragment controls the side navigation and only has visible content if needed. This page also has logic to expand and contract the child pages and build the context menus for the pages.

Footer.jspf. The final fragment is the footer, which holds the normal footer information for page navigation and quick links to other pages for the users.

Skins:
Skins represent the border rendering around components, such as row containers, column containers, or portlets. The skin is loaded in the portal page by the tag. Skins are installed independently from themes. However, a skin can be associated with a theme.
Skins define more than the look and feel of portlets; they define the look and feel of components. These components include the navigation, containers, and controls. This hierarchical structure is depicted in the following diagram.

The components of the skin are called in the following order.

The tag in the default.jsp, displays the components for the selected node. The components are implemented as row containers, column containers, and controls depending upon the portal layout that is defined in portal page customization. Controls are displayed using Control.jsp. The figure in Underlying layout of the home screen depicts one row container that has two column containers, each containing two portlets.
The row and column containers display their nested components using either Java code or the and elements.
Each portlet is rendered by the tag within the Control.jsp. file. The control also builds the border and title bar around the portlet output.

JSPs of Skin

Control.jsp. This file controls the look and feel of the portlet itself. It renders the menu items, the title bar, and the table that holds the portlet content. It also provides drag-and-drop handles for moving the portlet around on the portlet page.
UnlayeredContainer-V.jsp. This file controls the vertical columns for the portlets and how they are arranged within that column. The tags in the JSP file help control the drag-and-drop feature.
UnlayeredContainer-H.jsp. This file controls the horizontal appearance of the portlets and can contain the UnlayeredContainer-V.jsp.

Deploying the Theme and skin
Copy the above created theme and skin in the below mentioned path

Themes : /software/WebSphere60/AppServer/profiles/wp_profile/installedApps/Cell /wps.ear/wps.war/themes/html
Skins:/software/WebSphere60/AppServer/profiles/wp_profile/installedApps/Cell/wps.ear/wps.war/skins/html

Themes and skins can be deployed using the Administration console or using XMLaccess scripts

Through Admin Console:

Login the portal
Got to the Portal admin Console To add the theme, use the Themes and Skins portlet under Administration > Portal User Interface > Themes and Skins
Click on add new theme. Enter the following field (s) :
· Theme name and default locale title
· Theme directory name
Click on Ok Button.
Theme is deployed.
Same steps need to be follow to deploy the skin.

Through XML Access : See the XMLAccess script article

JSR 286 vs JSR 168

2008-12-08T14:20:00.000-08:00

Features	JSR 168 Specification	JSR 286 Specification
Inter Portlet Communication	Only supported within the same portlet application using session attributes Target portlets will only "see" messages during next render request.	Add additional coordination capabilities Limited only to String Values. Sharing of session data beyond the current Portlet application. Sharing of render parameters across portlets.
Life cycle	Portlets cannot update their state during a render request: "event" handling not really possible	New 3rd life cycle phase before rendering
Portlet Filters	Doesn't Support	Supports Allow on the fly transformations of information in both the request to and the response from the portlet Defined in portlet.xml
Caching		Extended Cache support. Allow public cached content for multiple users
Common Web Frameworks	Servlet dispatching not supported from process Action. Needs Portals Bridges or similar solutions. JSTL support very limited	Extended Cache support. Allow public cached content for multiple users. Improved support for web frameworks (Struts, JSF, Spring) Allow servlet dispatching during all lifecycle calls: processAction, processEvent, render, serverResource. Extended JSP tag library <defineObjects/>, support for JSF
Non HTML Resources(pdf, doc, images etc.)	A portlet can only render html fragments. Have to fallback/delegate to the servlet container. Requires coordination between portlet and servlet.

JSF vs Struts

2008-12-07T15:42:00.000-08:00

Features	Struts	JSF
	Struts isn't client device independence	Faces is client device independence
	Struts tags aren't as well suited to complex widgets such as trees and tab panels.	Faces supports
	Struts do not support 'code behind files' concept.	Faces supports 'code behind files' concept.
	Struts form Beans can span pages.	Faces use a cleaner approach in complex applications.
	Struts DynaActionForm instances can be authored automatically.	No support in the JSF framework to author backing beans automatically.
Request Processing and Navigation	Struts uses the returned ActionForward instance.	JSF uses logical outcomes from a java method to feed into the navigation rule base.
Model Tier access	Not Supported	JSF uses the ValueBinding API.
	Struts creates form beans. DynaActionForms enables to pre-configure the initial properties of the form.	JSF has a much richer bean creation story.
	Struts uses commons-beanutils for bean hierarchy navigation
Component Event	Struts has no notion of components but the struts-faces integration library allows you to use the JSF component model, and keep your Struts based back end logic.
	It has no notion of component state.	Faces have an excellent state management strategy in saving the state on the client or the server.
	Struts has no event model on web.	Faces brings a JavaBeans like event model to the web.
Conversion and Validation	Both support type Conversion	Faces is more powerful
	Struts Action class is tightly coupled to ActionServlet, can call its methods.	JSF invoke FacesServlet

Portal and its Components

2008-12-07T15:19:00.000-08:00

Portlets provide a componentized user interface (UI) for services. In a Service Oriented Architecture (SOA) one does not write monolithic applications, but separate services that can be orchestrated together into applications.

This service orchestration benefits from componentized UIs for the services -- monolithic web UIs based on servlets are no longer sufficient. This is where Porlets play a central role.

The following diagram is useful to understand Portal and Portlet concepts.

What is a Portlet

Portlets are pluggable user interface components that are managed and displayed in a web portal. Portlets produce fragments of markup code that are aggregated into a portal page.

Typically, following the desktop metaphor, a portal page is displayed as a collection of non-overlapping portlet windows, where each portlet window displays a portlet. Hence a portlet (or collection of portlets) resembles a web-based application that is hosted in a portal.

Portlet Modes

Portlets have several modes and states including:

MODES: VIEW, EDIT, HELP
STATES: NORMAL, MAXIMIZED, MINIMIZED

A portlet mode indicates the function a portlet is performing in the render method. Normally, portlets perform different tasks and create different content depending on the function they are currently performing. A portlet mode advises the portlet what task it should perform and what content it should generate. When invoking a portlet, the portlet container provides the current portlet mode to the portlet. Portlets can programmatically change their portlet mode when processing an action request.

The Portlet Specification defines three portlet modes, VIEW, EDIT, and HELP. The availability of the portlet modes, for a portlet, may be restricted to specific user roles by the portal. For example, anonymous users could be allowed to use the VIEW and HELP portlet modes but only authenticated users could use the EDIT portlet mode.

VIEW MODE (required)
The expected functionality for a portlet in VIEW portlet mode is to generate markup reflecting the current state of the portlet.

EDIT MODE (optional)
Within the EDIT portlet mode, a portlet should provide content and logic that lets a user customize the behavior of the portlet. The EDIT portlet mode may include one or more screens among which users can navigate to enter their customization data.

HELP MODE (optional)
When in HELP portlet mode, a portlet should provide help information about the portlet. This help information could be a simple help screen explaining the entire portlet in coherent text or it could be context-sensitive help.

Examples of View & Edit mode:

Portlet - View Mode:
Portlet – Edit Mode:

Portlet Window States

The Portlet Specification defines three window states, NORMAL, MAXIMIZED and MINIMIZED.

The NORMAL window state indicates that a portlet may be sharing the page with other portlets. It may also indicate that the target device has limited display capabilities. Therefore, a portlet should restrict the size of its rendered output in this window state.

The MAXIMIZED window state is an indication that a portlet may be the only portlet being rendered in the portal page, or that the portlet has more space compared to other portlets in the portal page. A portlet may generate richer content when its window state is MAXIMIZED.

When a portlet is in MINIMIZED window state, the portlet should only render minimal output or no output at all.

Web Clipping - WebSphere Portal

2008-12-07T14:49:00.000-08:00

Web clipping allows user to build portlets that consume external content and filter it to present a view of only the relevant portions of that content.

The first step in creating a new Web clipper is to specify the basic settings that tell the Web clipping portlet what to name the new Web clipper and the base URL of the external content to serve as the content of the new Web clipper.

Steps to ceate a Web Clip.

Go to Administration sceen of WebSphere Portal

Click on Portlet Management

Select Web Clipping

Select “Add new portlet”.

Specific the values for title and “url to clip”.

Click on next

The next step in creating a new Web clipper is to clip the contents of the URL specified on the Basic Settings page. Clipping a Web page is the process of selecting elements of the page to be retained in the output of a Web clipper. Only those selected (clipped) elements will be displayed within the output of the Web clipper. All other elements will be discarded, that is, not displayed in the output. There are three methods for clipping the contents of the page within the Web clipping portlet.

Now we have to add the portlet on the page.

XML Access Script - WebSphere Portal

2008-12-07T11:53:00.000-08:00

XMLAccess is a command-line batch-processing utility that is incredibly useful for exporting and importing various portal configurations. It can be used for backing up the configuration of certain environments, for loading new configurations (for new portlets or pages, for example), or for updating existing portlets when a new WAR file is provided by development. Perhaps most important, this tool greatly eases the duplication of a portal environment from server "A" to server "B."

XMLAccess connects to the portal configuration URL over HTTP (usually something like: http://myhost:10038/wps/config

The syntax for the command is as follows:
1. Command for Base portalxmlaccess -user wpsadmin -pwd itso -in file.xml -out result.xml -url myhost:10038/wps/config

2. Command for Virtual portal
xmlaccess -user wpsadmin -pwd itso -in input.xml -out output.xml -url myhost:10038/wps/config/<virtualportalname>

In the command line, use the following file names:
• input.xml: The name of a file containing the XML request (configuration export or update) that should be processed.
• output.xml: The name of the result file containing the XML output/error (configuration export).
• url: The URL to access the Portal configuration servlet. This URL consists of the Portal host name, the base Uniform Resource Identifier for the Portal, as specified during installation (for example /wps), the servlet extension /config and the virtual portal name.

You can use the XMLAccess tool to transfer a complete configuration, including:
• Portlets
• Access Control List
• Portal Web application configurations (portlet applications)
• Portal skin definitions
• Portal theme definitions
• Portal portlet configurations
• Portal site map (pages, labels, and links)
• Portal URL mappings
• Creation of clones/instances
• Deployment of war files
• Create the virtual portal

Basic Examples:

1. Deployment of war file:

<web-app action="update" active="true" uid="worldclock_app_id.webmod">
<url>file:///$server_root$/installableApps/StdWorldClock.war</url>
<portlet-app action="update" active="true" uid="worldclock_app_id">
<portlet action="update" active="true" objectid="id.com.portlet.worldclock"
name="StdWorldClock" >

<access-control owner="undefined" private="false">
<role actionset="Privileged User" update="set">
<mapping subjectid="cn=admin,ou=groups,o=org.com" subjecttype="usergroup"
update="set"/>
</role>
<role actionset="User" update="set"></role>
</access-control>
</portlet>
</portlet-app>
</web-app>

2. Adding portlet on page

<content-node action="update" objectid="id.com.clock.page.new" uniquename="id.com.clock.page.new" themeref="TestoPortal" skinref="undefined">
<component action="update" ordinal="100" type="container" orientation="H">
<component action="update" ordinal="100" type="container" orientation="V" >
<component action="update" ordinal="100" type="control" uniquename="un.com.win.clock.portlet">
<portletinstance action="update" objectid="un.com.win.clock.portlet.id"
portletref=" id.com.portlet.worldclock"/>
</component>
</component>
</component>
</content-node>

3. Create page/Label/URL, Access control and URL mapping
> For label: type=”label”
> For Page : type=”page”

<content-node action="locate" objectid="6_9AO19TE0004HE029EDJVR90026" uniquename="ibm.portal.Home"/>
<content-node content-parentref="6_9AO19TE0004HE029EDJVR90026" action="update" active="true" objectid="id.com.welcome.page.new" uniquename="id.hr.benefits.page.new" type="page" themeref="<themename>" skinref="undefined">
<supported-markup markup="html" update="set"/>
<localedata locale="en">
<title>Welcome</title>
</localedata>
</content-node>

> URL: there are 2 types of URLS
External URL
Internal URL
<content-node content-parentref="6_9AO19TE0004HE029EDJVR90026" action="update" active="true" objectid="id.com.yahoo.page.new" uniquename=" id.com.yahoo.page.new " type="external-url" themeref="<themename>" skinref="undefined">
<supported-markup markup="html" update="set">http:yahoo.com</supported-markup>
<localedata locale="en">
<title>External Link to Yahoo</title>
</localedata>
</content-node>
Internal URL:

4. URL mapping : Create theURL mapping in the specified virtual portal.

<url-mapping-context action="update" label="<vportalname>" objectid="vportalId">
<portal-url resourceref="root"/>
<url-mapping-context action="update" label="um id.com.welcome.page.new ">
<portal-url resourceref=" id.com.welcome.page.new "/>
</url-mapping-context>
5. Install theme and skin
<request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.3.xsd"
type="update"
create-oids="true">
<portal action="locate">
<skin action="update" active="true" objectid="TestPortal"
uniquename="ibm.portal.skin.TestPortal" resourceroot="TestPortal">
<localedata locale="en">
<title>TestPortal</title>
<description>TestPortal Skin</description>
</localedata>
</skin>
<skin action="update" active="true" objectid="NoSkin"
uniquename="ibm.portal.skin.NoSkin" resourceroot="NoSkin">
<localedata locale="en">
<title>No Skin</title>
<description>NoSkin</description>
</localedata>
</skin>
<theme action="update" active="true" defaultskinref="TestPortal"
uniquename="ibm.portal.theme.TestPortal" resourceroot="TestPortal">
<localedata locale="en">
<title>TestPortal</title>
<description>TestPortal Theme</description>
</localedata>
</theme>
</portal>
</request>