Wednesday, October 28, 2009

WebSphere Portal site management - publishing pages using a SUN Web server

Even if you successfully configured your portal with a SUN Web server as the target server for site management, the browser might prompt you for the Web server administrator user ID and password when you publish a page to this target server several times.
When you use portal site management to publish a page to the SUN target Web server, the browser prompts you for the Web server administrator user ID and password. Even if you enter the correct user ID and password, the prompt will be displayed over and over again.

The exception occurs because by default the SUN Web server does not have the write and delete access control rules. Publishing a page to the target server requires write and delete access rights, but the default SUN Web server installation does not grant these two access rights to anyone.

Resolving the problem
To resolve the problem, proceed as follows:
  1. Log in to the target Web server administrative console.
  2. Add Write and Delete access control roles to the anyone users and groups.
  3. Save and submit your changes.
  4. Restart the Web server.

The problem should now be resolved.

Monitoring IBM WebSphere Portal caches using IBM Tivoli Performance Viewer

The correct sizing of internal caches used by IBM WebSphere Portal is critical to the product performance. In order to configure and tune the caches of IBM WebSphere Portal, monitoring of the caches is required under load conditions. How can the internal caches be monitored without installing extra analysis tooling?

A selection of the internal caches of IBM WebSphere Portal can be monitored leveraging the Performance Monitoring Infrastructure (PMI) of IBM WebSphere Application Server. For each cache the Performance Management Infrastructure can report the following metrics:

ClientRequestCountThe number of requests for cacheable objects that are generated by applications running on this application server.
DistributedRequestCountThe number of requests for cacheable objects that are generated by cooperating caches in this replication domain.
ClientRequestCountThe number of requests for cacheable objects that are generated by applications running on this application server.
DistributedRequestCountThe number of requests for cacheable objects that are generated by cooperating caches in this replication domain.
ExplicitDiskInvalidationCountThe number of explicit invalidations resulting in the removal of an entry from disk.
ExplicitInvalidationCountThe number of explicit invalidations.
ExplicitMemoryInvalidationCountThe number of explicit invalidations resulting in the removal of an entry from memory.
HitsInMemoryCountThe number of requests for cacheable objects that are served from memory.
HitsOnDiskCountThe number of requests for cacheable objects that are served from disk.
InMemoryAndDiskCacheEntryCountThe current number of used cache entries in memory and disk.
LocalExplicitInvalidationCountThe number of explicit invalidations generated locally, either programmatically or by a cache policy.
LruInvalidationCountThe number of cache entries that are removed from memory by a Least Recently Used (LRU) algorithm.
MissCountThe number of requests for cacheable objects that were not found in the cache.
RemoteCreationCountThe number of cache entries that are received from cooperating dynamic caches.
RemoteExplicitInvalidationCountThe number of explicit invalidations received from a cooperating Java virtual machine in this replication domain.
RemoteHitCountThe number of requests for cacheable objects that are served from other Java virtual machines within the replication domain.
TimeoutInvalidationCountThe number of cache entries that are removed from memory and disk because their timeout has expired.

In order to enable monitoring for the caches exposed to Performance Viewer available in the Integrated Solutions Console of IBM WebSphere Application Server follow the following steps:

  1. Enable Performance Monitoring Infrastructure on the IBM WebSphere Portal Server:
    1. Open the Integrated Solution Console on your portal node for standalone installations or access the Integrated Solution Console on the deployment manager for clustered portal installations.
    2. Go to "Monitoring and Tuning > Performance Monitoring Infrastructure (PMI)".
    3. Select the IBM WebSphere Portal server for which the Performance Monitoring Infrastructure should be enabled, e.g. "WebSphere_Portal" for standalone installations.
    4. Check the "Enable Performance Monitoring Infrastructure (PMI)" checkbox.
    5. Save the changes to the master configuration.
    6. Restart the IBM WebSphere Portal Server if it was last started with the Performance Monitoring Infrastructure disabled.
  2. Configure the caches for monitoring:
    1. Go to "Monitoring and Tuning > Performance Monitoring Infrastructure (PMI)"
    2. Select the IBM WebSphere Portal server for which the Performance Monitoring Infrastructure has been enabled, e.g. "WebSphere_Portal" for standalone installations.
    3. Under "Currently monitored statistic set" click "Custom".
    4. Switch to the "Runtime" tab. Settings defined under the "Runtime" tab in the IBM Integrated Solutions Console will not be persisted.
    5. Expand the "Dynamic Caching" section.
    6. Expand the IBM WebSphere Portal cache of interest. For example: "Object: ws/".
    7. Expand the "Object Cache" section and click the "Counters" link.
    8. Enable the counters to monitor by adding checkmarks in front of the counter name.
    9. Repeat 2. for all exposed IBM WebSphere Portal caches of interest.
  3. Monitor the configured caches in Performance Viewer of the Integrated Solutions Console:
    1. Go to "Monitoring and Tuning > Performance Monitoring Infrastructure (PMI) > Performance Viewer > Current Activity".
    2. Click the server name the Performance Monitoring Infrastructure was configured for. The Performance Viewer dashboard is displayed.
    3. Expand the "Performance Modules > Dynamic Caching" section. The entries for caches you configured for monitoring before will be shown in back color. Caches that were not configured yet for monitoring are shown as grey inactive links.
    4. Expand the section of an monitored cache entry. For example: "Object: ws/ > Object Cache > Counters" and checkmark the "Counters" entries and click the "View Module(s)" button at the top.
    5. The configured counters will be displayed by Performance Viewer of the Integrated Solutions Console and can be visualized in graphs.

Note: Enabling the Performance Monitoring Infrastructure can cause overhead on the IBM WebSphere Portal Server and can cause performance degradation. Enable only necessary statistic stets and test the influence of settings on a test system under load conditions before applying it to production systems.

Monday, October 26, 2009

JSR286 : Action scope request attribute


The core features of any Internet portal are content aggregation from different information sources, web-page personalization and single sign-on. Java portlets act as the building blocks of any J2EE based portal implementation. Java portlets are very similar to Java servlets in many ways. They too are web components, managed by a container, that generate dynamic content. Java Portlet Specification v1.0 (JSR 168) defines the portlet API, container-portlet contract and packaging requirements for Java portlets. The recent Java Portlet Specification 2.0 final draft (JSR 286) facilitates implementing portlets with more advanced capabilities. This article illustrates the use of action scoped request attributes runtime option, which facilitates Java objects created during action phase being accessible during render phase in the form of request attributes.

Portlet Spec v1.0 (JSR 168): Action phase and Request attributes

As defined in the portlet specification v1.0, the portlet lifecycle is split into two distinct phases: Render and Action. When the portlet is rendered in a web page for the first time, it is said to be in render phase in which it returns the initial HTML fragment to be displayed. The portal aggregates this HTML fragment with the fragments of other portlets to form a complete web page. When the user takes an action (form submission for example), it enters action phase in which it processes the request and update its internal state (data).

To reflect the state changes in the user interface, the portlet enters render phase again. This means every action phase is followed by at least one render phase invocation. The portlet might receive additional render requests under various circumstances like when the user refreshes the browser or when he/she makes a request on some other portlet on the same page. This refined request-handling model is required with portlets since they generate only segments of the web page and are hosted along with other portlets in the same page (alternatively, in the servlet model the implementation of service() method takes care of both request processing and response rendering; also it renders the entire web page).

The interface javax.portlet.Portlet abstracts the portlet API and has render() and processAction() methods to represent render and action phases respectively. The portlet container is responsible for invoking these methods as appropriate. During action(), you can call ActionResponse.setRenderParameter() method to set any String values and retrieve the same using RenderRequest.getParameter() in the following render calls. However there is no similar mechanism in case of request attributes. For example, the following portlet will not print the request attribute that is set in processAction().

package samples.actionscope;

import javax.portlet.*;
import java.util.Date;

public class DateTimePortlet extends GenericPortlet {

public void doView(RenderRequest req, RenderResponse res) throws IOException, PortletException {
Object actionAttribute = req.getAttribute("datetime");
res.getWriter().println("Date Time:" + (actionAttribute != null ? actionAttribute :"Unavailable"));
PortletURL u = res.createActionURL();
res.getWriter().println("Trigger an action.");

public void processAction(ActionRequest req, ActionResponse res) throws PortletException {
req.setAttribute("datetime",new Date());

Below is a screenshot of the resultant portlet window after clicking Trigger an action action URL.

With MVC-based web applications, you are very likely to create view objects after request processing, set them as request attributes and use the same for display purposes. Due to the separated action and rendering model, the action request attributes will not be available in any of the view components that are included in the render phase (JSP, Servlet etc).

The only workaround is to use HTTP session (javax.portlet.PortletSession interface) to store and retrieve the attribute explicitly during action and render phases respectively. The problem with this approach is that you, not the container, are responsible for managing session attributes. The attributes are scoped only to the current action request and following render requests and, must be cleaned up when the portlet receives next action request. If you don’t code it properly, you might end up retaining lot of unused objects in the session, thus causing performance issues (IBM Struts Portlet Framework and Apache Struts Portal Bridge also use session as the underlying mechanism). Won’t it be good if the container itself takes care of managing the attributes thus relieving portlet/frameworks from doing the same?

JSR 286 Container Runtime Options

With JSR 286 compliant portlet containers, you can specify additional runtime behavior. The specification defines the following options:

  1. javax.portlet.escapeXml
  2. javax.portlet.renderHeaders
  3. javax.portlet.servletDefaultSessionScope
  4. javax.portlet.actionScopedRequestAttributes

Support for the first three are optional whereas the last one is required, which is the one we are interested in.


As the name implies, the purpose of this runtime option is to provide the portlets with the action scoped request attributes during render phase. You specify this option in the portlet deployment descriptor (portlet.xml) at either portlet level or application level.

Portlet level (only this portlet):

Date Time Portlet


Application Level (All the portlets in the application):

Date Time Portlet


This specification instructs the portlet container to retain the action request attributes across requests and make them available in all the following render requests. The attributes are valid until a new action occurs or session timeout. Internally, portlet containers use an action scope id to keep track of the action scope, thus associating the attributes with it.

Below is a screenshot of the portlet running the same code with javax.portlet.actionScopedRequestAttributes specified after clicking Trigger an action action URL.

This feature makes the request attributes lifecycle model same as it is in Servlets. It can now be taken advantage to pass form beans back to JSPs in case of errors, resultant objects after processing a request or any object that is used for display. There is no need to manage the session attributes within portlet/framework. Note that the internal implementation mechanism will most likely use an HTTP session only. Hence , best practices related to keeping the session size to the minimum should be followed. For example, you have to design specific view data beans containing only information that is absolutely required (instead of using existing complex objects) to render the web page.

Along the same lines, javax.portlet.servletDefaultSessionScope runtime option can override the visibility of session attributes in the JSP/Servlets. By default, included JSP/Servlets have access to session attributes stored within application scope. Unless the portlet stores session objects at the application scope, they are not visible within JSP/Servlets. This option can be used to change this behavior to portlet scope.


Portlet containers may choose not to support this runtime option, as this is not required according to the v2.0 specification.


As we saw, the Java Portlet Specification 2.0 has added the new container runtime option to support action scoped request attributes. In addition, it includes many features including events, public render parameters, serving resources, and new servlet features like cookies, lifecycle listeners, filters etc thus facilitating porting of existing servlet based applications into portal environment easily. Currently Sun Java System Application Server 9.1 (GlassFish v2) provides a Java Portlet Specification 2.0-compliant container that can be used to develop portlets leveraging new features.

Friday, October 23, 2009

Adding Log4j Logging to a Portlet

System.out is used to put one feel that it give any Performance performance. Now change to try and see Log4j may helpSet out how to write well.

1. First, they need to download log4j before


2. When we have already loaded the file will be much different to many files for extension. Jar.

It is outmostEg. Zip to extract the directory name apache-log4j-1.2.15. c: / apache-log4j-1.2.15/log4j-1.2.15.jar.

3. File log4j-1.2.15.jar. That has to be placed in the path / WEB-INF/lib of Portlet.

4. And then create the file. By creating this file under this directory. JavaResources / JavaSource.

5. Then change the file. example.

# An example log4j configuration file.

log4j.rootLogger = DEBUG, FILE.

log4j.appender.FILE = org.apache.log4j.FileAppender.

log4j.appender.FILE.File = C: / log / SSOApplicationPortlet.log.

log4j.appender.FILE.Append = true.

log4j.appender.FILE.layout = org.apache.log4j.PatternLayout. log4j.appender.FILE.layout.ConversionPattern = [%-d (yyyy-MM-dd HH: mm: ss)] [% 37c]% 3x -% m% n. Details would be used more.

To write here.

6. To see our Portlet When we use Log4j finished we will come running to see.

7. In Class we want to keep or Debug Log Import this into us.

import org.apache.log4j.Logger;

Global variables and then announced to run the following log.

private static Logger logger = Logger.getLogger (name ClassPortlet.class);

And it comes out out outttttt log of each visit Log want to keep this where to use. System.out.println ( "Start doView ()"); / / not used bylogger.debug ( "Start doView ()"); / / Use this to remove.

8.'re Done use Log4j to see if the output is to see the path that we write Set in

Sunday, October 4, 2009

Steps to remove a damaged Primary Node and assign a new Primary Node to a Portal Cluster

What are the steps that can be used to remove a damaged Primary Node from an IBM® WebSphere® Portal cluster and assign another node to the role of Primary Node ?

If there is an event that causes issues with the Primary Node in the cluster, such as a failed upgrade, hardware failure, etc, there is a requirement that a Primary Node be identified in the Portal Cluster for maintenance and other tasks. To assign the Primary Node role to another cluster member and remove the damaged member, follow these instructions.
1. Remove Primary node from traffic:
  • Stop IP traffic to the node you are upgrading:
  • If you are using the IP sprayers for load balancing, reconfigure the IP sprayers to stop routing new requests to the node.
  • If you are using the Web server plug-in for load balancing, perform the following steps to stop traffic to the node:
i. In the Deployment Manager administrative console, click Servers>Clusters>cluster_name>Cluster members to obtain a view of the collection of cluster members.
ii. Locate the cluster member you are removing and change the value in the Configured weight column to zero. NOTE: Record the previous value to restore the setting when the upgrade is complete.
iii. Click Apply to apply the change.
iv. If automatic plug-in generation and propagation is disabled, manually generate and/or propagate the plugin-cfg.xml file to the Web servers.
  • If you have a local Web Server on the node you are removing, stop the local Web server.
  • Shut down the Portal Server on the node you are removing.

2. Assign Primary Node classification to a secondary node: Since the Portal Server uses the flag PrimaryNode= for running its configuration tasks, you need to maintain one Primary node in each cluster for that purpose. To Designate a new Primary Node:
  • Select an existing secondary node.
  • Navigate to /PortalServer/config/
  • Open file in a text editor.
  • Change the following value: PrimaryNode from false to true.
  • example: PrimaryNode=true.
  • Save the changes.

3. Remove damaged node from cluster configuration: Given that you may not want to troubleshoot this node, and instead build a new node to add to the cluster, please follow these instructions:

WAS 6.0:

WAS 6.1:

and remove the affected node from the cluster.

4. (optional) Uninstall/reinstall node and add back to Cluster: Once you have the working cluster with the new Primary Node, you can choose to rebuild this node and add it back to the cluster at a later time as a secondary node.

These steps should provide you with a working cluster with a new WebSphere Portal Primary Node.

To install/configure the personalization sample in WPS 6.1

To install/configure the personalization sample by following these task in WPS 6.1

Step 1: ConfigEngine.bat create-pzndemo-users -DPortalAdminPwd=password

Step 2: ConfigEngine.bat install-pzndemo -DPortalAdminPwd=password -DWasPassword=password