Simplest SSO implementation

OA needs to be done with the project and the Portal of the SSO, two applications were on different servers, but top-level domain name is identical to the simple formula, and I said, it used domain cookie bar, they still will not talk for a long time doing,囧~~~~,

Suppose portal's domain name is portal.xxxx.com in the Portal log is complete, set a cookie:
<% @ Page language = "java" pageEncoding = "UTF-8"%>
<% @ Page import = "javax.servlet .*"%>
"%
/ / Login successful Domain Cookie Settings
Cookie cookie = new Cookie ( "ssoUserId", "zhangs ");// create a file called ssoUserId, the cookie value zhangs
/ / cookie.setDomain ( "xxxx.com ");// set cookie scope for xxxx.com so that all of the two domain names (such as www.xxxx.com, portal.xxxx.com, oa.xxxx.com) This cookie can obtain a
response.addCookie (cookie); / / write the cookie to the client
out.println ( "Login successful!");
% "

OA can read this cookie, to the user as the currently logged-on user
<% @ Page language = "java" pageEncoding = "UTF-8"%>
<% @ Page import = "javax.servlet .*"%>
"%
/ / Get single sign-on of the Cookie
Cookie [] cookies = request.getCookies ();
String ssoUserId = null;
for (int i = 0; i if ( "ssoUserId". equals (cookies [i]. getName ())){
ssoUserId = cookies [i]. getValue ();
)
)
out.println ( "SSO User Account:" + ssoUserId);
% "

If we consider the security issues, the userId encryption.

Can a URL mapping and friendly URL contain the same name?

Question In IBM WebSphere Portal, can a URL mapping and a friendly URL have the same name? For example, can you specify both a friendly URL via the Page Properties administrative portlet for your home page named "Home", and also create a URL mapping named "Home" for your home page via the URL Mapping administrative portlet?

Answer

The usage of identical names for friendly URLs and URL mappings in WebSphere Portal is not supported for usage with the same target page. Doing so can cause a redirection loop when attempting to access WebSphere Portal. Such a redirection loop can only be eliminated by avoiding the name duplication by either removing the URL mapping or the friendly URL.

Getting Page Title

Using Model SPI to get Page title

IBM WebSphere Portal uses a concept of Models for content aggregation, to track user's pages etc. The Model SPI provides access to these models. The attached code provides an example to illustrate on how to get a title of a page using model SPI in JSR 286 portlet. Here is the code snippet to get title of page

public String getTitle(PortletRequest request, PortletResponse response)
{
Context context=null;
PortletServiceHome homeObject =null;
NavigationSelectionModelProvider provider=null;
NavigationSelectionModel navSelectionModel = null;

try
{
context = new InitialContext();
homeObject = (PortletServiceHome) context.lookup("portletservice/com.ibm.portal.portlet.service.model.NavigationSelectionModelProvider");
provider = (NavigationSelectionModelProvider) homeObject.getPortletService (NavigationSelectionModelProvider.class);
navSelectionModel = provider.getNavigationSelectionModel(request, response);
}
catch (Exception exception)
{
exception.printStackTrace();
}
NavigationNode selectedNode = (NavigationNode) navSelectionModel.getSelectedNode();
//Following is commented since there is no title for page if user's locale is US English
//String pageTitle = selectedNode.getTitle(request.getLocale());
String pageTitle = selectedNode.getTitle(Locale.ENGLISH);

How to get the seedlist for the WebSphere Portal search engine in version 6.1.x Portal for either the portal collection or the WCM collection

How do I generate the output for the search seedlist in portal version 6.1.x for either the portal collection or the WCM collection?

Cause

The reason for this is to examine if there is a problem with the search engine crawler or the seedlist servlet that provides a list of documents to be crawled and indexed in the portal. This is used in debugging if it is suspected that the proper amount of documents are not indexed, or not all the correct attributes are indexed.

Answer

Follow these steps to generate the seedlist output. 1. Log in to the portal with an administrative ID 2. Navigate to the administrative pages and select this portlet: Search Administration > Manage Search 3. Within the portlet go to Search Collections > (portal/wcm collection) 4. Select this collection: 5. Edit the Portal content source: 6. Copy the URL that was automatically generated when creating the content source, and past this in a new browser window: 7. You may be asked for a log in via a pop-up. Be sure to allow this, and log in with the userid that you configured search to use. This is what you should see: 8. Save this as a web page, and submit this to support via this information.

Just JSR 168

The Java Standardization Request 168 (JSR 168) defines a portlet specification, including a contract between the portlet container and the portlet. JSR 168 is defined by the Java Community Process (JCP). The JSR 168 was co-led by IBM and Sun and had a large Expert Group that helped to create the final version which is now available. This Expert Group consisted of Apache Software Foundation, Art Technology Group Inc.(ATG), BEA, Boeing, Borland, Citrix Systems, Fujitsu, Hitachi, IBM, Novell, Oracle, SAP, SAS Institute, Sun, Sybase, Tibco, Vignette. More details about this JSR can be found at http://jcp.org/en/jsr/detail?id=168.

Important: The information provided in this analysis is provided without warranty of any kind. The analysis is intended to be an informational tool only for the reader.

JSR 168 definitions

This section provides basic JSR 168 definitions so that you can understand how JSR 168 fits into the overall portal architecture.

Portal and portlet container

A portal is a Web application which typically provides personalization, single sign-on, content aggregation from different sources, and hosts the presentation layer of different backend systems.

The main task of a portal is to aggregate different applications into one page with a common look and feel for the portal user. A portal may also have sophisticated personalization features which provide customized content to users. Portal pages may have different sets of portlets to create content for different users.

depicts the basic architecture of portals, such as a portal that is served by WebSphere Portal. A client request is processed by the portal Web application, which retrieves the portlets on the current page for the current user. The portal Web application then calls the portlet container for each portlet to retrieve its content through the Container Invoker API. The portlet container calls the portlets through the Portlet API. The Container Provider Service Provider Interface (SPI) enables the portlet container to retrieve information from the portal.

The portlet container runs the portlets, provides them with the required runtime environment, and manages their lifecycle. It provides persistent storage for portlet preferences which enables the portlet to produce customized output for different users.

Portal page and portlets

depicts the basic portal page components. The portal page represents a complete markup document and aggregates several portlet windows; that is, it combines different application user interfaces into one unified presentation. The portal page lets the user authenticate to the portal through the login dialog to access a personalized portal view. Most portal pages include some navigation mechanism to enable the user to navigate to other portal pages.

A portlet window consists of:

• Title bar, with the title of the portlet
• Decorations, including buttons to change the window state of the portlet (such as maximize or minimize the portlet) and buttons to change the mode of a portlet (such as show help or edit the predefined portlet settings)
• Content produced by the portlet (also called a markup fragment).

Figure 3 shows such a portlet window on different browsers. As you can see, the markup fragment produced by the portlet is not restricted to HTML, but can be any markup.

Portlet lifecycle

The basic portlet lifecycle is to:

1. Initialize, using the init class to initialize the portlet and put it into service.
2. Handle requests, processing different kinds of actions and rendering content.
3. Complete, using the destroy class to take the portlet out of

The portlet receives requests based on the user interaction with the portlet or portal page. The request processing is divided into two phases:

1. Action processing

If a user clicks on a link on the portlet, an action is triggered. The action processing must be finished before any rendering of the portlets on the page is started. In the action phase the portlet can change the state of the portlet.

2. Rendering content

In the render phase, the portlet produces its markup to be sent back to the client. Rendering should not change any state. It allows a page re-fresh without modifying the portlet state. Rendering of all portlets on a page can be performed in parallel.

Figure 4 depicts the request flow from the client to the portlets, and shows the action and render phases in more detail. In this example, portlet A has received an action. After the action is processed, the render methods of all portlets on the page (A, B, C) are called.

Portlet modes

Portlets perform different tasks and create content according to their current function. A portlet mode indicates the function a portlet is performing, at a point in time. A portlet mode specifies the kind of task the portlet should perform and what content it should generate. When invoking a portlet, the portlet container provides the mode for the current request to the portlet. Portlets can programmatically change their portlet mode while processing an action request.

JSR 168 defines three categories of portlet modes.

1. Modes which are required to support (same semantic as above)

Edit

Display one or more views that let the user personalize portlet settings.Help

Help

Display help views.

View

Display the portlet output.

2. Optional custom modes

About

Display the portlets purpose, origin, version, and other information.

Config

Display one or more configuration views that let administrators configure portlet settings which are valid for all users.

Edit_defaults

Set the default values for the modifiable preferences that are typically changed in the EDIT screen.

Preview

Render output without the need to have back-end connections or user specific data available.

Print

Display a view which is suitable for printing.

3. Portal vendor specific modes

These modes are only available in a specific vendor portal.

Window states

A window state is an indicator of the amount of portal page space assigned to the content generated by a portlet. The portlet container provides the current window state to the portlet, and the portlet uses the window state to decide how much information it should render. However, portlets can also programmatically change their window state while processing an action request.

JSR 168 defines the following window states:

Normal

The portlet shares the space with other portlets and should take this into account when producing its output.

Maximized

A window has more real estate to render its output than in normal window state.

Minimized

The portlet should only render minimal or no output.

In addition to these window states, JSR 168 allows the portal to define custom window states.

Data model

JSR 168 defines different mechanisms for the portlet to access transient and persistent data.

The portlet can set and get transient data in the following scopes:

Request	The request has attached data, such as request parameters and attributes, similar to the servlet request. The request can contain properties to allow extension, and client header fields being transported from the portal to the portlet and vice versa.
Session	The portlet can store data in the session with either global scope, to let other components of this Web application access the data, or portlet scope, which is private to the portlet.
Context	The portlet can store data in the Web application context, similar to servlets

The portlet can access persistent data with these scopes:

Per portlet	The portlet can store configuration and personalization data in the portlet preferences to enable the portlet to create personalized output. The portlet can define which data the user is allowed to change in the edit mode (for example, stock quotes), and which data are configuration settings can only be changed by an administrator in config mode (for example, the stock quote server).
Per user	User profile information can be read by the portlet to tailor its output towards the user (for example, show the weather of the city where the user lives).

Portlet application

All resources, portlets, and deployment descriptors are packaged together into one Web application archive (WAR) file. There are two deployment descriptors:

• All Web application resources that are not portlets must be specified in the web.xml deployment descriptor.
• All portlets and portlet related settings must be specified in the portlet.xml deployment descriptor.

Comparing JSR 168 and the IBM Portlet API

Comparing JSR 168 and the IBM Portlet API

This section gives a high level comparison between the new JSR 168 Portlet API and the IBM Portlet API. First, it covers the concepts that are similar; then, it explains some of the differences between the two.

Similarities

The following concepts are very similar in JSR 168 and the IBM Portlet API.

Feature	Similarities	Differences
Portlet modes	Both support the basic portlet modes: Edit, Help, and View.	The config mode is optional in the JSR 168. The other optional JSR 168 modes (About, Edit_defaults, Preview, Print) are not supported by the IBM Portlet API.
Window states	These window states are supported: Maximized, Normal, and Minimized.	The Solo window state is only supported by the IBM Portlet API.
Portlet lifecycle	The lifecycle life cycle is the same: init, process requests, destroy.	none
Request processing	Request processing is divided into an action phase for processing user actions and a render phase for producing the markup.	none
URL encoding	Both support creating URLs pointing to the portlet or to a resource.	none
Include servlets/JSPs	Servlets and JSPs can be included in the portlet.	none
Portlet session	Portlets can store transient information that should span requests in a session.	none
Portlet application packaging	Both package portlet applications as WAR files with an additional deployment descriptor called portlet.xml.	The portlet.xml format differs.
Expiration-based caching	The portlet can support expiration based caching.	The APIs use different mechanisms to implement this functionality. The IBM Portlet API uses a polling mechanism where the portal queries the portlet for how long the markup will be valid, whereas in the JSR 168 the portlet can attach an expiration time to each created markup. Sharing the cache entry across users is only possible in the IBM Portlet API.

Differences

The JSR 168 and the IBM Portlet API differ in the following ways.

Feature	IBM Portlet API	JSR 168
Portlet application entities	Lets you define an abstract portlet application and different instance of this portlet application as concrete portlet applications via the deployment descriptor. This allows reusing settings of the abstract portlet application and only overwriting the parts that are unique for each concrete portlet application.	The deployment descriptor follows the web.xml deployment descriptor and defines one portlet application and the portlet definitions for this application.
Portlet entity	There is one portlet object instance per portlet configuration in the Web deployment descriptor. There may be many PortletSettings objects parameterizing the same portlet object according to the Flyweight pattern, provided on a per-request basis. Changes in the PortletSettings apply to all portlet instances of this concrete portlet. The user can also have personal views of concrete portlets that are rendered using the PortletData for customization of the output.	PortletSettings and PortletData are merged into one object called PortletPreferences.
Request/Response objects	The request/response object that the portlet receives in the render call is the same as the one received in the action call.	In the JSR 168 these are two different objects.

Cross Site Request Forgery. What it is and how to work around it.

If there's a way to solve the Cross Site Request Forgery (CSRF) issue that has been highlighted by every web Security Team. Previously, normal a common filter application (J2EE Filter) that filters out Cross Site Scripting Characters from a request and response. This helped tremendously in passing the security assessment as all they have to do is define the filter on their applications and filter will do the rest.

Is there's a way to create a common standards for applications so that each applications need not to worry about Cross Site Request Forgery. Basically, their Internal Security Team requested them to put hidden keys that will be validated once the forms are submitted (for got post and get) and if the hidden keys are missing or wrong, then the form submission will fail.

Anyway, this was the first time anyone heard of Cross Site Request Forgery, so did some research.

Apparently, Cross Site Request Forgery is a form of hijacking your application session in order to fool the users into submitting invalid contents to the application and the application will process it. How does it hijack your application ? And why only now ?

Basically it works this way. Imagine you are browsing your Online Banking and you need to transmit money to your GF/WIfe/Mother or whoever. You forgot the amount to transfer and the information is actullay on your Email. So you decided to check your online email account (by going to New -> Open Window on I.E., which will share the same session with the exisitng browser). While checking your email, you saw an email from someone asking you to check a good holiday getaway. You checked the email and you find that place impressive, so you decided to click on the image on that email. And that email redirected you to a genuine looking promotion site. After your read, you closed the email and decided to transfer the money. Seems nothing happened right ? Wrong, you noticed that you have missing thousand of dollars on your account.

How did this happened ? Remember two things in these scenario :

1. You are still logged in to your online banking. Technically, your session is still alive.
   
   
2. You saw a genuine email inviting you to check out the new holiday getaway. However, when you clicked the image, apparently, the image link actually executes a javascript which will contact your bank by executing a get command with parameters such as : http://bank.example/withdraw?account=bob&amount=1000000&for=mallory Which actually withdraws from your account and transfers it to another account. And since your session is alive, this actually gets executed on your behalf. However, it looks harmless to you as you were just redirected to a vacation site, without knowing that you have just transferred thousands of dollars to another bank account.

Why only now ? It became prevalent because of the Tabs behavior of the browser. Normally, what people doe before was just to launch a new IE browser (nobody goes to New->Window.. only a few), which thereby actually separates your banking session to your email. However, with the prevalence of the tab technology, people just open up a tab, which will actually share session with your existing banking application.

There are ounces of preventions on this thing. Two of the most popular ones are :

1. Checking the HTTP Referrer.
2. Having a hidden validation key for every form submission

The problem with checking HTTP Referrer is that this can be suppressed. Some HTTPS also omits HTTP Referrer.

Hidden Validation Key is one of the solution for this. How does this work ? Basically, for every form request, the application will issue a unique key that will be validated upon the submission of the request. Since the attacker does not know the correct key, if the form is submitted with an invalid key or missing key, the application can assume that this is an attack and fail the submission of the form.

The problem with implementing this solution is that you need to modify your application to conform to this. If you are using an MVC Framework, this might not be an issue as you can have your controller issue the key and check the key before the view generates the page. However, I don't think most of the applications out there actually uses MVC framework (take .NET for example). If you are my client and you have a lot of applications available, then you need to re-write this applications to include Hidden Validation Keys.

However, there's another solution to this issue (for both .NET and Java/J2EE). The solution is to have a J2EE Filter or IHttpModule do the job for your. How does this work ?

If you are familiar with .NET and/or Java, before the request or response reaches the application, any implemented filters via J2EE Filter or IHttpModule gets executed first. On this level, Filters can check the contents of the Request or Response. They can even modify the contents of this two. If I have a Filter that will actually help me :

1. Generate a random key and store the key into the session.
2. Add this Random key as a hidden value field on the Response part of the application as part of the Form Submission.
3. When Form is submitted, I validate this key.
4. If Key is valid, pass it to the applicaiton.
5. If key is invalid, fail the submission.

This will solve the issue. And since its a J2EE Filter or IHttpModule, this can be re-used and is shareable to all applications. This mean... Taa-daaaa.. I DON'T even need to change any line in my existing applications to defeat CSRF.

However, sometimes, storing a session variable may not be a good idea, especially if you are working on an environment with Load Balancing. Sometimes, session variables get lost so there's a tendency of Form Failure not because of CSRF but because of infrastructure failure. How do you do solve this ? Well, why don't we generate a Checksum key instead.

How does this work ? It works by doing the below :

1. Read the contents of the Form Data. Based on the field names, generate a checksum with an algorithm known only to you.
2. Add this key to the form data.
3. When form is submitted, check the field names and calculate the checksum.
4. If Key is valid, pass it to the applicaiton.
5. If key is invalid, fail the submission.

Voila!!!. I don't need a session variable after all. So I told my client that this can be done.

Well, I emailed him that we can prevent CSRF without even changing your application. At most, only the configuration (web.xml or web.config) needs to be changed to include the Filter on the application.

So the filter will do this :

1. User Request for Page
2. Browser goes to the server and request for the page
3. Application sends the page to the browser.
4. However, Response Filter intercepts the response.
5. Response Filter generates an authentication key. If you used a checksum based solution, this key is a calculated checksum.
6. Response Filter saves the key to the J2EE Session, if you follow the session-based solution, otherwise this key is actually a checksum key.
7. Response Filter appends the key to the HTML Form.
8. Response Filter sends the request to the Browser.
9. Browser renders page (with the key embedded).
10. User interacts and submits the page
11. Information is send to the application
12. However, Request filter intercepts the request.
13. Request Filter checks for the authentication key
14. Request Filter Authenticates Key by comparing with the J2EE Session, if you're using a Session-based solution, otherwise Filter will validate the checksum..
15. If key is invalid, Request Filter generates a response and shows error page. Request ends.
16. If valid, Request Filter sends the information to the Application.
17. If Key is in the hidden field, hidden field is removed. This is optional and can be done in-cases where Application checks for any extra fields and invalidates the request if any extra-field is found.
18. Application processes the information.

Next would be coding part. When I have time, I will probably code on both .NET and Java and share the codes to you. It will be a simple Filter that uses Session-based solution.

Portlet Context,Portlet Config and Portal Context

PortletContext

is similar to servletConext and is used to get values declared in web.xml.
Inside doView method of your custom portlet ( implementing GenericPortlet.), you can get context param as below

getPortletContext().getInitParameter("ContextParam")

PortletContext scope is application wide.
If you set any attribute to portletContext, that would be available to all the portlets in that portlet application.

PortletConfig

PortletConfig is similar to ServletConfig and is used to get init parameters declared in portlet.xml. In servlet, we use web.xml for declaring init params and get those using servletConfig.

portletConfig data is attached to a portlet and has a scope to the portlet only.

Code sample to get portlet init parameters....

public void init(PortletConfig portletConfig) throws PortletException{

super.init(portletConfig);

portletConfig.getInitParameter("");

}

PortalContext

this gives information about portal server and other properties...

if you write renderRequest.getPortalContext().getPortalInfo()

this will give you portal name and version as per your env

for me it returned:- IBM WebSphere Portal/6.1

PortalContext has more methods to get properties... you can play with them all as and when needed

WebSphere Portal DataBases

Understanding the Portal Server Configuration
So far, you have seen and hopefully understood how to install and verify the WebSphere
Portal server. Now you will see how the Portal server’s configuration data is stored in the
default Cloudscape database and in files in the file system. If you want to configure and
maintain your portal server in a production environment then you need to have a
complete understanding of this configuration so pay close attention to this information.
As shown in the illustration above, the WebSphere Portal server will store most of the
configuration data in the Cloudscape database. The name of the database is wpsdb by
default. Different parts of the configuration are stored in different schemas in the wpsdb
database. The remaining part of the configuration (DB connections and Deployment
Descriptors for example) will be stored as property files in the file system.

What follows is a brief description of the important schema names and the type of
information that is stored in the wpsdb database schemas:
• Release, Likeminds, Feedback: These schemas store data of Pages, Portlets, Portlet
instances, Themes, Templates, Personalization rules and Policies. This data is not
modified during the portal runtime.
• Customization: This schema stores information specific to users (for example
PortletData).
• Community, Jcr: These schemas store data of shared documents and resources. This
data will be modified during runtime.
• wmm: This schema stores user registry data used to authenticate users.
Having the portal configuration in the Cloudscape database is fine for education and
demonstration purposes. However, this configuration data does not scale as user volume
increases and does not support portal cluster configuration data or multiple realms. You
need to move this configuration to a robust RDBMS (like DB2, Oracle, Sybase, MS SQL
Server or Informix for example) in production environments. You also need to move user
registry data from the Cloudscape database (stored in the wmm schema) to an LDAP
server (like IBM Tivoli Directory Server for example) in production environments.

How to take a heapdump and a javacore on a WebSphere Portal server

Sometimes taking a heapdump or a javacore on a Portal system can help to diagnose hung threads or a stalled system. A heapdump is a dump of the memory of the Java heap. A javacore provides insights into the various processing running inside of the heap at a given time.

Javacores should be taken two minutes apart in order determine if processes are hanging across intervals.

Depending on the version of Portal/WAS installed, the heapdumps and javacores are placed in different locations on the filesystem.

For Portal 5.1, the files are placed in /usr/WebSphere/AppServer
For Portal 6.0, the files are placed in /usr/IBM/WebSphere/AppServer/profiles/wp_profile

The files will be called something like heapdump434360.1198699170.phd and
javacore434360.1198699180.txt

Use these instructions to get started:

1. Find out the PID (process ID) of the Portal server by typing 'ps -ef|grep java'.
2. Type 'kill -3 '
3. Wait.
4. Verify that the heapdump and javacore were finished by checking in the appropriate directory.
5. Wait two minutes, and then run 'kill -3 '
6. Wait
7. Verify that they were created.

Accessing parameter from QueryString in IBM WebSphere Portal V6.1

This is very simple in IBM WebSphere Portal V 6.1
Consider we have url : https://localhost:60035/wps/portal/test?PhoneId=35102

Import com.ibm.ws.portletcontainer.core.impl.RenderRequestImpl


Write down code in Portlet.

public void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException {


RenderRequestImpl renderRequestImpl = (RenderRequestImpl)request;
String phoneId = renderRequestImpl.getRequest().getParameter("PhoneId");
super.doView(request, response);
}

How to get path(/wps/portal or /wps/myportal) in IBM WebSphere Portal V6.1 theme

Import following object in jsp or class

import com.ibm.portal.state.accessors.url.ServerContext;
import com.ibm.wps.services.ServiceManager;
import com.ibm.wps.services.config.ConfigService;
import com.ibm.wps.state.accessors.url.ServerContextOnConfigFactory;
import com.ibm.wps.state.phases.ServerContextFactory;


ConfigService configService = (ConfigService)ServiceManager.getService(com.ibm.wps.services.config.ConfigService.class);
ServerContextFactory ctxFactory = new ServerContextOnConfigFactory(configService);
ServerContext serverContext = ctxFactory.newServerContext((HttpServletRequest)(request));

System.out.println(serverContext.getContextPath());
System.out.println(serverContext.getHomeProtected());
System.out.println(serverContext.getHomePublic());

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

Problem(Abstract) 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. Symptom 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.

Cause

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: Log in to the target Web server administrative console. Add Write and Delete access control roles to the anyone users and groups. Save and submit your changes. Restart the Web server. The problem should now be resolved.

Monitoring IBM WebSphere Portal caches using IBM Tivoli Performance Viewer

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

Answer

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: ClientRequestCount The number of requests for cacheable objects that are generated by applications running on this application server. DistributedRequestCount The number of requests for cacheable objects that are generated by cooperating caches in this replication domain. ClientRequestCount The number of requests for cacheable objects that are generated by applications running on this application server. DistributedRequestCount The number of requests for cacheable objects that are generated by cooperating caches in this replication domain. ExplicitDiskInvalidationCount The number of explicit invalidations resulting in the removal of an entry from disk. ExplicitInvalidationCount The number of explicit invalidations. ExplicitMemoryInvalidationCount The number of explicit invalidations resulting in the removal of an entry from memory. HitsInMemoryCount The number of requests for cacheable objects that are served from memory. HitsOnDiskCount The number of requests for cacheable objects that are served from disk. InMemoryAndDiskCacheEntryCount The current number of used cache entries in memory and disk. LocalExplicitInvalidationCount The number of explicit invalidations generated locally, either programmatically or by a cache policy. LruInvalidationCount The number of cache entries that are removed from memory by a Least Recently Used (LRU) algorithm. MissCount The number of requests for cacheable objects that were not found in the cache. RemoteCreationCount The number of cache entries that are received from cooperating dynamic caches. RemoteExplicitInvalidationCount The number of explicit invalidations received from a cooperating Java virtual machine in this replication domain. RemoteHitCount The number of requests for cacheable objects that are served from other Java virtual machines within the replication domain. TimeoutInvalidationCount The 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: Enable Performance Monitoring Infrastructure on the IBM WebSphere Portal Server: 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. Go to "Monitoring and Tuning > Performance Monitoring Infrastructure (PMI)". Select the IBM WebSphere Portal server for which the Performance Monitoring Infrastructure should be enabled, e.g. "WebSphere_Portal" for standalone installations. Check the "Enable Performance Monitoring Infrastructure (PMI)" checkbox. Save the changes to the master configuration. Restart the IBM WebSphere Portal Server if it was last started with the Performance Monitoring Infrastructure disabled. Configure the caches for monitoring: Go to "Monitoring and Tuning > Performance Monitoring Infrastructure (PMI)" Select the IBM WebSphere Portal server for which the Performance Monitoring Infrastructure has been enabled, e.g. "WebSphere_Portal" for standalone installations. Under "Currently monitored statistic set" click "Custom". Switch to the "Runtime" tab. Settings defined under the "Runtime" tab in the IBM Integrated Solutions Console will not be persisted. Expand the "Dynamic Caching" section. Expand the IBM WebSphere Portal cache of interest. For example: "Object: ws/com.ibm.wps.ac.AccessControlUserContextCache". Expand the "Object Cache" section and click the "Counters" link. Enable the counters to monitor by adding checkmarks in front of the counter name. Repeat 2. for all exposed IBM WebSphere Portal caches of interest. Monitor the configured caches in Performance Viewer of the Integrated Solutions Console: Go to "Monitoring and Tuning > Performance Monitoring Infrastructure (PMI) > Performance Viewer > Current Activity". Click the server name the Performance Monitoring Infrastructure was configured for. The Performance Viewer dashboard is displayed. 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. Expand the section of an monitored cache entry. For example: "Object: ws/com.ibm.wps.ac.ExplicitEntitlementsCache.CONTENT_NODE > Object Cache > Counters" and checkmark the "Counters" entries and click the "View Module(s)" button at the top. 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.

JSR286 : Action scope request attribute

Introduction

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.io.IOException;

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

       res.getWriter().println("
");

       PortletURL u = res.createActionURL();

       res.getWriter().println("Trigger an action.");

       res.getWriter().close();

   }



   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.

javax.portlet.actionScopedRequestAttributes

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

 



 DateTimePortlet

 Date Time Portlet

 samples.actionscope.DateTimePortlet

 �

 

     javax.portlet.actionScopedRequestAttributes

     true

     numberOfCachedScopes

     10

 



 

Application Level (All the portlets in the application):

 



 DateTimePortlet

 Date Time Portlet

 samples.actionscope.DateTimePortlet

 �

 

 � 



     javax.portlet.actionScopedRequestAttributes

     true

     numberOfCachedScopes

     10

 

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.

   

   javax.portlet.servletDefaultSessionScope

   PORTLET_SCOPE

   

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

Conclusion

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.

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

here http://logging.apache.org/log4j/1.2/download.html.

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. log4j.properties. By creating this file under this directory. JavaResources / JavaSource.

5. Then change the file. log4j.properties 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. http://logging.apache.org/log4j/1.2/manual.html.

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 log4j.properties.

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 wpconfig.properties 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: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rxml_removenode.html WAS 6.1: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rxml_removenode.html 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

Additional steps needed after updating wps.ear

Problem

After an effort to update the wps.ear to include new configuration for IBM® WebSphere® Portal, the deployment completes successfully, but browsing to the Portal to verify the update results in errors on the page.

Symptom

You will see content errors on the Portal page in the browser.

Errors logged for this issue:

[date/time] 0000002e Helpers W NMSV0605W: A Reference object looked up from the context "java:" with the name "comp/env/jdbc/customizationDS" was sent to the JNDI Naming Manager and an exception resulted. Reference data follows:
Reference Factory Class Name: com.ibm.ws.util.ResRefJndiLookupObjectFactory
Reference Factory Class Location URLs:
Reference Class Name: java.lang.Object
Type: ResRefJndiLookupInfo
Content: com.ibm.ws.util.ResRefJndiLookupInfo@19d6388 ResRefJndiLookupInfo: Look up Name="jdbc/customizationDS";JndiLookupInfo: jndiName="jdbc/wpdbDS"; providerURL=""; initialContextFactory=""

Exception data follows:
javax.naming.NameNotFoundException: Context: /clusters/PortalCluster, name: jdbc/wpdbDS: First component in name wpdbDS not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
at com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4392)
..........
Caused by: javax.naming.NameNotFoundException: Context: /clusters/PortalCluster, name: jdbc/wpdbDS: First component in name wpdbDS not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
at com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4392)
..........
Caused by: org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0
at com.ibm.ws.naming.ipcos.WsnOptimizedNamingImpl.do_resolve_complete_info(WsnOptimizedNamingImpl.java:543)
.........
[date/time] 0000002e NamingService E com.ibm.wps.services.naming.NamingServiceImpl lookup EJPFD0006E: Cannot find object java:comp/env/jdbc/customizationDS in JNDI context java:comp/env/jdbc/customizationDS.
com.ibm.websphere.naming.CannotInstantiateObjectException: Exception occurred while the JNDI NamingManager was processing a javax.naming.Reference object. [Root exception is javax.naming.NameNotFoundException: Context: /clusters/PortalCluster, name: jdbc/wpdbDS: First component in name wpdbDS not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]]
at com.ibm.ws.naming.util.Helpers.processSerializedObjectForLookupExt(Helpers.java:952)
at com.ibm.ws.naming.urlbase.UrlContextHelper.processBoundObjectForLookup(UrlContextHelper.java:191)
.........

Cause

There are missing steps in the following section of the InfoCenter:

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

Resolving the problem

Following the InfoCenter link above, after completing Step 6 of 'Deploying themes and skins in a production environment', please substitute these steps for Step 7:

Complete the following tasks:

Note: When using a cluster environment use the primary node to invoke the commands.
1. Locate the directory portal_server_root/config/
2. Type the following configuration task appropriate for your operating system on a command line:
o Windows: WPSconfig.bat action-modify-attributes-ear-wps
o UNIX: WPSconfig.sh action-modify-attributes-ear-wps
3. Synchronize all the nodes
4. Restart WebSphere Portal on the stand-alone server or on each cluster member if using a cluster environment

How to restore WebSphere Portal back to the out-of-the-box security configuration

Question Sometimes you may encounter a problem when you configure IBM WebSphere Portal security (standalone or federated). This problem can cause the system configuration files to be in an inconsistent state. Can you revert back to the original file registry configuration if the security task fails? Answer It is now possible to revert back to the out-of-the-box security configuration for WebSphere Portal 6.1.0.1 You must populate the wkplc.properties file with the parameters stated below and then run the wp-restore-default-repository-configuration task. NOTE: If you are on WebSphere Portal 6.1.0 you need to install PK73815 and update the Portal configuration per the APAR details for this task to work properly. This APAR is included in WebSphere Portal 6.1.0.1 or later, but if you originally installed WebSphere Portal 6.1.0 and then upgraded to 6.1.0.1 or later, you still need to reference the APAR details for the instructions necessary to use the task successfully. The wp-restore-default-repository-configuration task allows you to return to the default VMM setup with a federated file repository. The task will create a new realm, delete all existing repositories, and configure a file repository in VMM. The file repository itself must exist (fileRepository.xml) before calling this task. A new user and a new user group will be created and set to the WebSphere Portal and WAS administrators. If you want the admin user to be added to the admin group, this must be done manually after restarting the portal by calling the wp-restore-default-repository-add-group-member task. This task will use the admin user and group set for wp-restore-default-repository-configuration in the wkplc.properties file. Parameters in wkplc.properties: ######################################################### ## ## ## Restore VMM security ## ## wp-restore-default-repository-configuration ## ######################################################### ######################################################### # The realm name to be used. A realm with this name will be created. restore.file.realm=federatedRealm restore.file.delimiter=/ # Portal and WAS admin UID (short name) and password restore.file.primaryAdminId=adminUID restore.file.primaryAdminPassword=adminPWD # CN of portal admin group (short name) restore.file.primaryPortalAdminGroup=adminGroupCN ######################################################### ## ## ## Restore VMM security ## ## ######################################################### #########################################################