Configurable Portal Services - WebSphere Portal v5.1

Configurable Portal Services

Overview

WebSphere Portal comprises a framework of services, a subset of which are configurable. Files and services which are not described in the following are purely for portal internal usage. Do not modify them in any way.
The configurable service files can be found in...
wp_root/shared/app/config/services

After changing property settings in property files, restart the portal to make the changes become effective.

Configurable Services

Configuration
Deployment
DataStore
Finder
Loader
Localizer
Navigator
Registry
PortletContainer
Content Access
Cache Manager
State Manager
Administrator Unique Names Mapping
Site Analyzer Log
Portal Security

Access Control Data Management
Authentication

Configuration Service

The Configuration Service is responsible for collecting the most essential configuration data of the portal engine. These are the parameters set by the install procedure.
The following configuration parameters can be modified in the file...
/config/services/ConfigService.properties

However, plan well ahead and apply special care when modifying these parameters.
In the following list of parameters the values given in parentheses are the default values. Parameters marked with <none> have no default values.

was.home = <none>

Absolute path to the install directory of WAS. This parameter has no default.

wps.home = <none>

Home (or install) directory of the WebSphere Portal.

command.sessionvalidator = (SessionValidatorAuth)

The name of the command that serves as the session validator command.

command.login = (LoginUserAuth)

The name of the command that serves as the login command.

command.logout = (LogoutUserAuth)

The name of the command that serves as the logout command.

redirect.login = (true)

Turns on user-defined redirection after successful login.

redirect.login.ssl = (false)

Turns on SSL in system-defined redirection after successful login.

redirect.login.url [optional] = <none>

Specifies the URL for redirection after successful login.

redirect.logout = (false)

Turns on user-defined redirection after successful logout.

redirect.logout.ssl = (false)

Turns on SSL in system-defined redirection after successful logout.

redirect.logout.url [optional] = <none>

Specifies the URL for redirection after successful logout.

multiple.realms.enabled = false

Multiple Realms Support parameters to allow login with uid@realm.

multiple.realms.login.default.realm = <none>

Multiple Realms Support parameters to allow login with uid@realm.

multiple.realms.user.dn.template = <none>

Multiple Realms Support parameters to allow login with uid@realm.

host.name = <none>

The default is that no value exists for host.name. In this case, portal URLs start with the hostname of the incoming request. If you want the host.name in URLs be static, you enter a hostname here. For example, in case of a cluster installation you can enter the name of the network traffic dispatcher here. If a hostname is entered, this entry is used to create the portal URLs.

host.port.http [optional] = <none>

The HTTP port (normally 80).

host.port.https [optional] = <none>

The HTTP-SSL port (normally 443).

security.css.protection = (true)

This parameter determines whether Cross-Site-Scripting security protection is turned on. The default is true for enabling the protection.

redirect.commands = (false)

Specifies that a portal command is followed with an HTTP redirect. This way URLs can be bookmarked. Using this feature results in a certain performance overhead. Therefore it should only be used if needed.

uri.context.path = <none>

The context path under which the portal is running.

uri.context.path.facade = <wsrp>

The context path for the additional WAR file that is used as a facade Web application for your WSRP implementation. This enables you to use Secure Socket Layer (SSL) with Client Authentication for WSRP and simultaneously use other means of authentication for the portal, for example form based authentication. This separation is required as J2EE allows only for one authentication mechanism per WAR file.

uri.home.public = (portal)

The servlet context of the portal engine for public (or anonymous) pages, i. e. pages that users can view without entering a user ID or password.

uri.home.protected = (myportal)

The servlet context portal engine for protected (or personal) pages. i. e. pages that users can only view by entering a user ID and password.

uri.home.doc = <none>

The servlet context of the portal engine for the documentation area.

uri.home.substitution = (false)

Determines whether a public URL should be translated to a protected URL if a user session exists.

uri.requestid = (false)

Flag that determines whether the portal should use a Request ID. If you want to use URL addressability, set this key to false. This indicates that no Request ID is used.

persistent.session.level = (0)

Determines the level on which the persistent session should operate.

persistent.session.option = (0)

Determines whether the user gets the option to resume the session.

portal.enable.filtering = (true)

Flag that determines whether the portal should use Portal Filtering or not.

portlet.url.find = <none>

URL that is used for find and set in global settings portlet.

portlets.unauthorized.visible = (false)

Determines what a user sees if they are not authorized to view a portlet.

allow.derived.titles = (true)

Determines if the title and description of derived pages can be redefined by users. If the value is set to false, titles and description of pages can only be changed on non-derived pages.

wps.mappingurl.portal_url_identifier = (/!ut/p)

Defines an identifier for Portal URLs. See URL Mapping for the specification of the format of this property.

wps.mappingurl.enabled = (true)

Defines whether URL Mapping is enabled or not. Possible values are true to enable URL Mapping, or false to disable URL Mapping.

navigation.portletmenu.mode = ( 1 )

The navigation.portletmenu.mode parameter defines in which way portlet menus are integrated in the overall portal navigation menu structure. Portlet menus are navigation parts that are provided by the portlet itself. They can be added as a subtree to the navigation menu item that references the page in which the portlet resides. This parameter has the following three options:
0 Disabled: Portlet Menus are not displayed in the navigation menu at all.
1 Current selection: Only the portlet menus of the portlets that reside on the currently selected page are added below the navigation menu item for that page. This is the default value.
2 Everything: The portlet menus of all portlets on all pages are added below the appropriate navigation menu items in the navigation tree.

navigation.expansion.defaultstatetrue)

Determines whether the nodes in the navigation tree are expanded or collapsed by default. The default is true, which means that nodes are expanded.

page.reload.interval = (0)

This defines the page reload interval for authenticated users. Use it to specify the interval in minutes after which pages should be reloaded for an authenticated user. The reload respects the most current access control settings for that user. If this value is set to zero, no automatic reload occurs during the session.

PortletResponse headers

portletcontainer.response.headers.additionallyNotAllowed = <none>

There is a predefined set of response header fields which are not allowed to be used in portlet response fields. In addition to these predefined header fields it is possible to define additional fields, which are then also prohibited to be included into a portlet response header.
Values must be separated by commas, if more than one field is specified.
The following list shows the header fields of the HTTP 1.1 (RFC 2616) specification that are by default not allowed to be set:

Response Header Fields

The response-header fields allow the server to pass additional information about the response that cannot be placed in the Status-Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.

Accept-Ranges
Location
Proxy-Authenticate
Server
Vary
WWW-Authenticate

Entity Header Fields

Entity-header fields define meta information about the entity-body or, if no body is present, about the resource identified by the request. Some of this meta information is optional; some might be required by portions of this specification.

Allow
Content-Encoding
Content-Language
Content-Length
Content-Location
Content-MD5
Content-Range
Content-Type
Expires
Last-Modified

Message Headers

HTTP header fields, which include general-header (section 4.5), request-header (section 5.3), response-header (section 6.2), and entity-header (section 7.1) fields, follow the same generic format as that given in Section 3.1 of RFC 822 [9]. Each header field consists of a name followed by a colon ( : ) and the field value. Field names are case-insensitive.

portletcontainer.response.headers.forceAllowed = <none>

This parameter enables you to re-enable the usage of the fields listed above which are by default prohibited header fields.
Values must be separated by commas, if more than one field is specified.

portletcontainer.restrict.dataaccess = (true)

Restricts the access of PortletData, PortletSettings and PortletApplicationSettings to the respective Portlet.Mode. This parameter should always be set to true.

xmlaccess.allowshortnames = (false)

Distinguishes DNs from short names in the subjectID. All subjectID attributes are treated as IDs and never as short names.

application.repository.dir = (deployed)

Path to portlet application root or repository.

portlet.enable.transcoding = (true)

Determines whether transcoding is enabled.

was.security.enabled = (false)

Determines if the portal monitors WAS security.

skins.highperf.controls = (false)

If you set this to true, then high-performance control elements are enabled. If you set this to false, high performance controls are not used.
skins.highperf.containers = (false)

If you set this to true, then high-performance unlayered containers are enabled. If you set this to false, high performance unlayered containers are not used.
skins.highperf.layeredcontainers = (false)

If you set this to true, then high-performance layered containers are enabled. If you set this to false, high performance layered containers are not used.
skins.highperf.showself = (false)

If you set this to true, then an HTML comment appears at the beginning of the code for components that are rendered with high performance skins. This parameter does not appear by default. manually add this parameter to the file.

Deployment Service

The Deployment Service provides services for accessing the configuration parameters required for the portlet deployment.
The portlet deployment component is responsible for the integration of portlets into the portal. It handles the correct deployment of portlet applications and their WAR files into WebSphere Portal and WAS. It uses the WAS management services for the physical deployment and management of war files in the WAS. Management of war files includes installing, removing, redeploying, starting, and stopping portlet applications.
Portlet applications appear in the Enterprise Application list on the administrative console of WAS. However, never manage them from outside the portal. Instead, manage them by using the WebSphere Portal administration portlets or the XML configuration interface of the portal.
You can recognize Web applications which comprise a portlet application by their administrative name, also called the display name. It is shown in the WAS administrative console. You can identify the name of such a portlet application by a portal specific identifier suffix _PA_<id> . This identifier is appended to the name.
An example for such a name is Welcome_PA_1_04_uX2 . The name in turn is derived from the name of the WAR file when the portlet application was first installed. This administrative name never changes, even if a different filename is used to update the portlet application.
The following configuration parameters can be modified in the file...
/config/services/DeploymentService.properties

However, plan well ahead and apply special care when modifying these parameters.
In the following list of parameters the values given in parentheses are the default values.

wps.appserver.name = (WebSphere_Portal)

The appserver name of the portal on a single server, or, in the case of a cluster, the name of the cluster. If the WAS assignment was manually altered after the portal installation, this parameter must be updated to match it.

was.admin.host = (localhost)

The WAS administrative host.name. This parameter is used to adapt to the WAS bootstrap host.name, if the default is not applicable.

use.admin.user = (true)

Use this key to select between two user authentication mechanisms for the portal Portlet Deployment Manager to authenticate with the WAS administrative services when portal security is enabled. Specify one of the following two possible values:

true

Use a single preset shared user ID for all portal administrative users who issue WAR deployment requests. This is the default. This is a separate user ID that is common for all users who are allowed to perform install or manage applications tasks. register this user ID with WAS Console User Administrator rights.

false

Use the actual user ID by which the administrator issues the WAR deployment request. Every portal user with portlet deployment rights must be added to the WAS Console User list with administrator rights. Alternatively, you can add the complete group of portal administrators to the WAS Console Group administrator rights.

update.portlet.preserves.config.settings = (true)

This controls the update of portlet configuration settings during updates of portlet application WAR files. This parameter determines whether the portlet configuration parameters from the file portlet.xml should replace the existing ones, or whether the existing parameters should be preserved, and only new ones be added.
If you set this property to true, this prevents modifications made by an administrative user from being overwritten with default values that the portlet developer put into the portlet.xml in the new WAR file. The following fields are preserved from modification by an updated portlet.xml file:

Portal resource JSR 168 portlet application IBM Version 4.x API portlet application
Portlet Application Default locale N/A
Title Title
User attributes Context parameter
Portlet Name Name
Title Title
Short title Short title
Keywords Keywords
Description Description
Default locale and description Default locale
Initialization parameter Initialization parameter
Preferences N/A
Remote cache settings Cache settings
Expiration date settings N/A
Servlet N/A Mappings

use.redeploy = (true)

Controls whether WAS supports redeploy to update an existing war file. If redeploy is not supported, then the portal emulates it by using remove and install. This value should not be altered.

was.notification.timeout = (60)

Timeout value (in seconds). It specifies how many seconds the deployment tasks waits for an appserver event during the management of war files. This value may have to be increased on large portal installations.

portletapp.starting.weight = (100)

Value for the starting weight of the portlet applications (war files). To ensure the correct initialization sequence, this value must be higher than the starting weight of the portal itself.

portletapp.classloader.mode = (PARENT_LAST)

Value for the classloader mode for the deployed WAR file. Valid settings are: PARENT_LAST and PARENT_FIRST . The default setting is: (PARENT_LAST) . Under normal circumstances this is the most appropriate setting. Therefore do not modify this setting.
portletapp.classloader.policy = MULTIPLE

Value for the classloader policy for the deployed WAR file. Do not modify this value. Valid settings are MULTIPLE or SINGLE . The default is MULTIPLE .
portletapp.shared.library.list

List of library references which are added to each deployed WAR file during deployment. You can specify multiple references separated by a comma ( , ). The library references must have already been defined in the appserver, and the JAR files must have already been deployed at the location assigned in the reference definition.

portletapp.reload.enabled = preserve

Use this key to define the value for the reload property of the deployed WAR file. This property can have the following values:

true

This enables reloading mode for all war files. Use this value only for portlet development and portlet debugging purposes, but not for production environments.

false

This disables reloading mode for all war files. This is the default.

preserve

When you specify this value, the setting from the file ibm-web-ext.xmi is applied, if available.

The default setting is false.
Note: Do not enable reloading in a production environment. Enable reloading only for portlet development and portlet debugging purposes.

The following values define file locations. All these settings have default values and should only be enabled and modified if the defaults are not appropriate.

application.repository.root.dir = ( <wp_root> )

Root directory where war files are stored for deployment.

application.repository.dir.name = (deployed)

the name of the subdirectory where .war and .ear files are stored.

jobs.root.dir = ( <wp_root> )

Root directory where job files are stored for deployment.

jobs.dir.name = (jobs)

Subdirectory name where job files are stored for deployment.

delete.temp.files = (true)

This parameter determines whether temporary files that were created during deployment in the directory application.repository.dir.name/temp are deleted or kept. The default is true , which means that the files are deleted. Change the value to false only for debugging purposes so that you can view the content of the temporarily expanded WAR files. When you have completed debugging, change the value back to true and delete the directories manually. If you change the value to false, be aware that the hard drive space required by the temporary directory grows with each WAR file that you add or update.

The following setting is for debug purposes only. Enable it only when instructed to do so by support personnel.

deployment.debug.log.times = (false)

DataStore Service

WebSphere Portal uses a database to store configuration data for pages, clients, markup, and all other resources.
The DataStore Service is responsible for managing the data source of the portal as configured while installing WebSphere Portal.
Normally there should not be a need to modify any of the configuration parameters in the service configuration file. However, in the rare case that the configuration has to be changed manually, the configuration parameters can be modified in the file...
wp_root/shared/app/config/services/DataStoreService.properties
The database access parameter is shown in the following:

datasource.dbms

Type of database management that manages the data source. Valid values are DB2, DB2_ZOS, ORACLE, SQLSERVER, and CLOUDSCAPE.

scheduler.cleanup.enabled = (true)

Determines whether deletion of portal pages is performed later by the scheduled cleanup service, or immediately after the user completes the deletion task. This affects the deletion of portal pages and all their dependent resources, such as components and portlet instances. The default is true, which means that deletion of portal pages is delayed and performed by the cleanup service.
For details about this parameter and how to schedule the cleanup service, refer to Delayed cleanup of deleted portal pages.
Note: The scheduled cleanup service works only when your portal installation is based on a version of WAS that includes the Scheduler service. This service is part of the IBM WebSphere Business Integration Server Foundation.

For further information on data sources and their configuration, refer to the WAS Handbook.
Client configuration and markup configuration are managed using administration portlets; the configuration data is stored in the database.

Finder Service

The Finder Service evaluates and verifies file names based on the settings of each request, for example, the specified browser type or the language. In case a file cannot be found, a fall-back mechanism tries to locate the file in alternative places by reducing the settings of the request step by step.
For normal operations, the configuration of this service is complete and does not need to be modified. However, if additional or alternative mappings are required, the following configuration properties can be modified in the file...
/config/services/FinderService.properties

screen.mapping.screen

Use this mapping to assign a different name to a template. The new name can be used as an alias. To configure a default screen template, specify screen = * .

skin.mapping.skin

Use this mapping to assign a different name to a template. The new name can be used as an alias. To configure a default skin template, specify skin = * .

theme.mapping.theme

Use this mapping to assign a different name to a template. The new name can be used as an alias. To configure a default theme template, specify theme = * .

Loader Service

The Loader Service is responsible for dynamically loading class files in four categories: commands, supporting classes for screen templates, skin templates, and theme templates. The service does so by looking up a given (class) name in different packages. Upon loading the respective class file, an instance of that class is returned. To optimize the efficiency, the implementation of the service is free to cache loaded class files or instances and return a cached instance. That means, that the implementation of any such classes must be thread-safe.
In cases where additional or alternative commands or support classes are required, the following configuration properties can be modified in the file...
/config/services/LoaderService.properties

...to accommodate these classes:

command.path

The package prefix(es) in which commands are searched.

command.mapping Command

Use this mapping to assign an alternative name to be used for a command name. For example, you can map an abbreviated name to a long command name.

screen.path

The package prefix(es) in which screen templates are searched.

screen.mapping.Screen

Use this mapping to assign a different support class to a JSP name. Per default, all screen templates map to the same class (Screen = *).

skin.path

The package prefix(es) in which skin templates are searched.

skin.mapping.Skin

Use this mapping to assign a different support class to a JSP name. Per default, all skin templates map to the same class (Skin = *).

theme.path

The package prefix(es) in which theme templates are searched.

theme.mapping.Theme

Use this mapping to assign a different support class to a JSP name. Per default, all theme templates map to the same class (Theme = *).

Localizer Service

The Localizer Service provides access to the configured default locale and the system default locale. It also provides a list of supported bidirectional languages.
Giving the system default locale is necessary because Locale.getDefault() is set to the portal default.
Although the locale is set during installation time, it is possible to change the locale at a later time by modifying the following configuration properties in the file...
/config/services/LocalizerService.properties

locale.default.language

The language of the locale, for example, EN or PT.

locale.default.country

The country or region code of the locale, for example, US or BR.

locale.default.variant

The variant code of the locale.

The default language must be supported by the portal. If you leave all three parameters without a specified value, the system locale is used as the default locale.
Use the following parameter to specify which bidirectional languages you want your portal to render from right to left (RTL):

locales.bidi

The individual languages listed are separated by commas. Only languages that are listed in the file...
/wp_root/shared/app/config/language.properties

...can be specified here.
If the language determined by the portal for a user is one of the languages listed here, all pages are shown from right to left for that user, regardless of whether the page content is in fact in a bidirectional language or not. If you want to disable right-to-left rendering for a particular bidirectional language, remove that language from the list of values for this parameter.
For details on how the portal determines the language for a user, see Selecting and changing the language.

All parameters are case-insensitive. The ISO standard ISO-639 is used for the language codes of most languages. For Hebrew the old language code iw is used. The ISO standard ISO-3166 is used for the country/region codes.

Navigator Service

The Navigator Service, (NavigatorService.properties), allows you to specify a number of settings. Among these are settings for cache scope and cache expiration. Depending on your portal configuration, you might be able improve the performance of your portal by modifying these settings. For more detailed information about page caching for improved performance, refer to Caching.

Sets that influence local caching
Key Meaning Default value
public.reload Specifies the cache expiration time (in seconds) for the portal internal cache for anonymous portal pages. These are unpersonalized and unauthenticated portal pages which users can access without having to log in to the portal. Values smaller than 0 are replaced by the default. 60
Sets that influence remote caching
Key Meaning Default value
public.session Specifies whether an anonymous user always has a public session. This may be useful when a portlet requires a session for anonymous users. To enable public sessions for pages that anonymous users can view without logging in, set this parameter to true.
The setting of public.session influences the remote cache scope for public pages. If public.session is set to true, then the cache scope is set to non-shared (private). If public.session is set to false, then the cache scope is set to shared (public).
Setting public.session to true reduces portal performance.
false
public.expires Specifies the cache expiration time (in seconds) for caches outside of the portal and for unauthenticated pages only. These caches must adhere to the HTTP 1.1 specification (RFC 2616). The public.expires key specifies the time after which HTTP caches should drop the response. This can be further restricted by the remote.cache.expiration key (see below).
This value is used as a maximum value for the cache expiration time and as a global default value for unauthenticated pages. If the setting remote.cache.expiration is also set to a value greater than or equal to 0, the smaller one of the two values is used.
The portal calculates and aggregates the remote cache information, that is the scope and expiration time, by a number of parameters contributed by themes, pages, and portlets besides the settings described here. Therefore the portal can do any of the following internally while processing a request:

Reduce the cache lifetime
Reduce the cache scope, for example, from public (shared) to private (non-shared)
Switch off the overall cachability of pages.

Therefore this value might not be static for all responses resulting from requests to unauthenticated pages.
The response of the portal sets the following header fields:

The Expires header with the expiration time added to the system date and time of the portal
The Cache-Control : max-age = header with the expiration time as its parameter.
The default setting specified in this file is 60 seconds. If no value is specified, the portal defaults the value to 60 seconds. 60
remote.cache.expiration Maximum cache lifetime (in seconds) of a page, both public and private.
Used to specify a global value for the expiration of pages in remote caches.
Set to 0 switches caching off in remote caches.
If the legacy setting is not available, this setting is used for authenticated and unauthenticated pages. If the legacy setting is available, then the smaller of the two values is used for unauthenticated pages only. In this case the remote.cache.expiration setting is used for authenticated pages in general. If theme, composition, and portlets contribute remote cache information, then the global settings also contribute to the information. In this case the lowest of the values of all contributors is used, including the global settings.
The default setting specified in this file is 60 seconds. If no value is specified, the portal defaults the value to zero (0 seconds).
0
remoteCacheInfo.response.header.vary Specifies the HTTP headers that force a proxy to cache different variants of the same URL. Use this setting to specify a comma separated list of HTTP header fields to which the portal should refer in its vary field of the generated HTTP response. This is required to ensure that proxy caches can invalidate entries in their cache if the specified header fields do not match from request to request. User-Agent

Registry Service

The RegistryService loads and caches a small number of objects which are regularly accessed in the portal engine. This improves performance, however the tradeoff is that the cached objects are possibly stale compared to their database counterparts. This applies particularly in a cluster environment. If the age of those objects causes a problem in your portal, try reducing the refresh rate for the respective entities. Do this by adjusting the settings in the configuration file...
/config/services/RegistryService.properties

default.interval = (1800)

The default.interval for refreshing a bucket. The amount is specified in seconds, for example default.interval = 1800.

bucket.names

A comma-separated enumeration of names of the buckets defined by this service.

bucket.<bucket-name>.class

The type of class that the bucket with the given name is caching.

bucket.<bucket-name>.reload [optional = true]

Controls whether or not the bucket with the given name is reloaded in frequent intervals.

bucket.<bucket-name>.interval = (default.interval)

The length of the reload interval for the bucket with the given name. If no value is set, the default.interval setting is used.

bucket.<bucket-name>.sorted [optional = false]

Controls whether or not the bucket with the given name needs to keep the cached objects in a sorted order. The sorting order is determined by the objects themselves.

The bucket.names are described in the following:

portlet

The portlet bucket is used to cache the database representation of all portlets stored in the database of this portal.

application

The application bucket is used to cache the database representation of all portlet applications stored in the portal database.

theme

The theme bucket is used to cache the database representation of all themes stored in the portal database.

skin

The skin bucket is used to cache the database representation of all skins stored in the portal database.

client

The client bucket is used to cache the database representation of all clients stored in the portal database.

markup

The markup bucket is used to cache the database representation of all markups stored in the portal database.

servlet

The servlet bucket is used to cache servlet configuration information stored in the portal database.

webmodule

The webmodule bucket is used to cache the database representation of all Web modules stored in the portal database.

PortletContainer Service

List and describe the PortletContainer related settings in the file PortletContainerService.properties.

legacy.portlet.enable.filtering = (true)

Flag that determines whether the portal should use Portlet Filtering or not.

Parallel portlet rendering

Use the properties for parallel portlet rendering to optimize the portal response time, depending on your configuration. When portlets on a page are rendered sequentially, some portlets can delay output from other portlets to the portal server. This delay can be caused, for example, by portlets that are waiting for a response from a remote service. Parallel portlet rendering can prevent this delay.
Enable parallel portlet rendering provides a benefit if a high proportion of the portlets in your portal access remote locations to fetch the content they render. For more detail about integrating Web services as remote portlets in your portal refer to Using WSRP services with WebSphere Portal.
For portlets to be rendered parallel, the settings for both the portal and the individual portlets need to be set to enable parallel portlet rendering.
The default setting for the portal is that portlets cannot be rendered in parallel. In addition, the default setting for individual portlets is not to be rendered in parallel. A portlet can only be rendered in parallel, if it has been enabled for parallel rendering, for example, by the portlet developer or the administrator. Therefore, if you enable the portal wide property for parallel portlet rendering, the portal can render only those portlets concurrently which have been configured accordingly. All properties listed below apply only to such portlets. Portlets which are not configured for parallel rendering are always rendered sequentially.
For details about the sequence of calls and action handling see Portlet events under Portlet API.
To change the setting for a portlet to parallel rendering, select...
Portal Administration | Portlets | Manage portlets

Select the desired portlet and click on the Configure (wrench) icon. The portal displays the panel for configuring the portlet. Mark the Enable parallel rendering checkbox to enable parallel rendering for the portlet.
Note: Usually only some of the portlets that are configured for parallel rendering are actually rendered in parallel. Portlets for which the portal cannot provide a thread immediately are rendered sequentially. Therefore, in order to get the best performance, select carefully which portlet you configure for parallel rendering.
You can configure portal wide parallel portlet rendering globally for all markups, or individually for the markups of the client devices that display the portal pages. This way, you can have multiple entries of the main parameters for parallel portlet rendering in the file PortletContainerService.properties. For example, you can have separate entries for different markups. Or you can enable parallel rendering for the portal, but disable it for one specific markup.
Note: To enable parallel rendering makes sense only for markups that can display all portlets on a page, such as HTML. Therefore, do not enable parallel rendering for markups that can only display a single portlet of a page at a time, such as WML. Doing so would trigger additional rendering processes for those portlets which are not displayed and thereby decrease portal performance.
You can change the portal wide settings for parallel portlet rendering in the file...
PortletContainerService.properties

You use two different parameters for configuring parallel portlet rendering, depending on the type of portlets you want to have rendered parallel:

For parallel rendering of local IBM portlets, enable the following parameter...
legacy.useParallelRendering[.markup] = (false)

...which activates the portlet container functionality for parallel portlet rendering for the specified markup [false = default, true]. If you omit the markup, the setting applies to all markups for which no specific setting has been defined.
For parallel rendering of local JSR 168 compliant portlets, or for remote portlets that you integrated in a WSRP Consumer portal, enable the following parameter...
std.useParallelRendering[.markup] = (false)

...which activates the portlet container functionality for parallel portlet rendering for the specified markup [false = default, true]. If you omit the markup, the setting applies to all markups for which no specific setting has been defined.

The settings for configuring the parallel portlet rendering parameters are listed and explained in the following:

false

Parallel rendering is disabled. This is the default. All portlets are rendered sequentially, even if they have parallel rendering enabled.

true

Parallel rendering is enabled. All portlets which have parallel rendering enabled are rendered in parallel. Portlets which do not have parallel rendering enabled are rendered sequentially.

You can further tune parallel rendering by specifying different values for the following parameters. These parameters apply to both main parallel portlet rendering parameters given above.
You can specify the time limits for the parallel rendering process of portlets by the following parameters:

parallelRenderingTimeOut = (2000)

Specifies the timeout in milliseconds after which the render process of a portlet is aborted.

parallelRenderingWaitTimeOut = (1)

Specifies the waiting time in milliseconds for parallel threads to finish the render process of portlets. A low value can result in exceptions caused by portlets that could not finish their parallel rendering process. A high value can cause an increase of the portal response time. The value 0 (zero) specifies that no timeout occurs and the main thread waits for all portlets to finish.

Queues are used to pass the content of the portlet between the threads. The queue parameters are listed here:

parallelRenderingQueueSize = (30720)

Specifies the size of the queues in bytes.

parallelRenderingChunkSize = (1024)

Specifies the size of the chunks in bytes that are read from the queue.

To improve performance, all queues are held in a pool for reuse. Variations in the usage of the queues result in increase or decrease of the pool size. You can configure the pool size to be more stable by increasing the strength of the hysteresis function. This smoothens how directly the pool size follows the number of accesses. A second property defines the compacting rate, that is how often the pool size is actually reduced as determined by the hysteresis function.

parallelRenderingPoolHysteresis = (10)

Specifies the number of accesses to the pool that determines the strength of the hysteresis function. The default is 10.

parallelRenderingPoolCompactRate = (300)

Specifies after how many seconds the pool size is actually reduced. The default is 300 seconds (= 5 minutes).

Asynchronous beans are used for the parallel rendering process. A WorkManager wm/wpsWorkManager is configured to manage the asynchronous beans. Do not change this name as the name is set in both the WAS and the WebSphere Portal configurations. Note that the WorkManager is only available with IBM WebSphere Business Integration Server Foundation in WAS Version 5.1.1 Cumulative Fix 1. Set the option isGrowable in the WorkManager panel of the WAS to false. Otherwise parallel portlet rendering might not work to the full extent.
You can further tune parallel rendering by specifying different values for the minimum and maximum number of threads in the WorkManager panel, but the minimum value is 1 (one).
When general tracing is enabled and parallel portlet rendering is turned on, portlets that are configured to be rendered in parallel display the render time as part of the portlet content. If you want to use general tracing but do not want the render times to be displayed for such portlets, selectively disable tracing.

Content Access Service

Portlets can access content from remote systems that are located on the other side of a firewall by invoking the Content Access Service. The following settings are used to configure the Content Access Service, but only for those portlets that call this service. These settings are located in the file PortletServiceRegistryService.properties under the items beginning with com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.no.proxy.for =

Specifies host names for which ContentAccessServices does not use a proxy, even if a proxy is configured. Values must be separated by semicolon ( ; ). Wildcards are not supported.
Example: com.ibm.wps.pe.pc.legacy.service...no.proxy.for =localhost;127.0.0.1

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.protocol.handlers =

Assigns additional URL protocol handlers that Java uses to handle connections to various URL protocols. Values must be separated by a vertical bar ( | ). The default is usually sufficient, as it supplies a handler for https URLs.
Example: com.ibm.wps.pe.pc.legacy.service...ServiceImpl.protocol.handlers = com.ibm.net.ssl.internal.www.protocol

Proxy protocol and port settings

Specify proxy protocol and port settings for different protocols. specify for each protocol the name and port number of the proxy servers that you use.
The general format is as follows:

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.http.host = hostname

Specifies an HTTP proxy host for http URLs.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.http.port = port number

Specifies the port for the HTTP proxy. If this is not specified, 80 is used as the default value.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.https.host

Specifies an HTTP proxy host for https URLs. The proxy must support CONNECT requests, otherwise known as 'tunneling' requests.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.https.port

Specifies the port for the HTTP proxy. If this is not specified, 80 is used as the default value.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.socks4.host

Specifies a SOCKS V4 proxy host for any URL.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.socks4.port

Specifies the port. If this is not specified, 1080 is used as the default value.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.socks5.host

Specifies a SOCKS V5 proxy host for any URL.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.socks5.port

Specifies the port. If this is not specified, 1080 is used as the default value.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.auth.enabled

Specifies if authentication should be tried for proxied connections. - This applies to the proxy server, not to the origin server from which the ContentAccessService is fetching. Also, this only applies to HTTP proxy (with settings from proxy.http.* and proxy.https.*) and SOCKS proxy (with settings from proxy.socks4.* and proxy.socks5.*).

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.auth.credentialslot

Specifies if proxy authentication should be used for connections that use a proxy server. provide the user ID and password in a credential slot of the portal credential vault. also specify the name of this slot in the content access service configuration. The credential must have the type UserPasswordPassive.
For details about the credential vault refer to Credential Vault and Credential Service. Proxy authentication applies to the proxy server, not to the origin server from which the ContentAccessService is fetching. Also, this only applies to HTTP proxy (with settings from proxy.http.* and proxy.https.*) and SOCKS proxy (with settings from proxy.socks4.* and proxy.socks5.*).

If no proxy host is set, WebSphere Portal tries to load all URLs directly. If no port is set, the default port for HTTP (80) is used. Alternatively, you can socksify the TCP/IP stack of your system.
Examples:

The name of the http proxy host:

com.ibm.wps.pe.pc.legacy.service...ContentAccessServiceImpl.proxy.http.host = host.somewhere.ibm.com

The name of the http proxy port:

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.http.port = 80

The name of the tunneling https proxy host:

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.https.host = securehost.somewhere.ibm.com

The name of the https proxy port:

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.https.port = 443

Cache Manager Service

The Cache Manager Service is responsible for managing the different caches used in WebSphere Portal Version 5.1. Starting with Version 5.1 the portal provides two different types of caches: shared and non-shared.

Shared caches
The shared caches are cluster aware. This means that deleting an element from the cache on one cluster node results in deleting that element from the corresponding cache instances on all other nodes. This ensures that frequently changing data are kept consistent over the whole cluster installation.
Non-shared caches
The non-shared caches are used for data where cluster awareness is of no concern. This avoids unnecessary network communication overhead.

You can modify the configuration parameters for the Cache Manager Service in the file...
/config/services/CacheManagerService.properties

However, plan well ahead and apply special care when modifying these parameters.
There are two levels of parameters:

cacheglobal
Default setting which is to be used for all caches unless explicitly overridden by the corresponding cache instance parameter.
cacheinstance.cacheidentifier
Override a global setting, for example the size of the cache, for a specific instance of a cache.

Changing some or all of these settings can dramatically improve or impair portal performance. Therefore it is recommended not to change the shared setting for any cache unless the consequences are absolutely understood and agreed. If you want to determine the optimal values for the size, lifetime, admit-threshold and replacement parameters, monitor the cache parameters during the staging phase of your portal installation. Use the Tivoli Performance viewer, that is the WAS PMI client (PMI = Performance Monitoring Interface) to find the optimal settings for your environment.
The parameters for the Cache Manager Service for both shared and non-shared caches are listed in the following:

cacheglobal.enabled = [true|false]

cacheinstance.cacheidentifier.enabled = [true|false]

Controls whether caching is enabled or not. Use this parameter with care !

cacheglobal.size = number

cacheinstance.cacheidentifier.size = number

This defines the number of elements that can be put into the cache before eviction takes place. The eviction uses a "near LRU" algorithm.

cacheglobal.shared = [true|false]

cacheinstance.cacheidentifier.shared = [true|false]

Defines whether a cluster-aware cache is to be used or not.

You can set the following additional parameters for non-shared caches. (Setting them for shared caches does no harm, they will be ignored.)

cacheglobal.replacement= [aggressive | moderate | conservative]

cacheinstance.cacheidentifier.replacement= [aggressive | moderate | conservative]

Controls the eviction algorithm behavior.

cacheglobal.admint-threshold = number

cacheinstance.cacheidentifier.admint-threshold = number

Admittance threshold. Use this parameter to keep unwanted entries from the cache. An entry is cached only if it is put into the cache as often as specified by the value for this parameter. If you want each entry to be cached, set this parameter to zero ( 0 ).

cacheglobal.lifetime = number

cacheinstance.cacheidentifier.lifetime = number

Use this parameter to specify the lifetime of elements in the cache in seconds. When the specified lifetime is up, elements are not discarded from the cache immediately. They are evicted when the next element is inserted. Specifying -1 means that no timeout is applied.

State Manager Service

The State Manager Service is the access point for managing the navigational state of the portal. Navigational state represents the current view of portal resources as displayed to a user.

preprocessors = ( com.ibm.wps.state.preprocessors.selection.StandardPortalSelectionImpl )

Use this parameter to specify a list of one or more preprocessors that are used. Note that for requests the preprocessors are processed in the sequence in which you arrange them here. The required syntax is (<classname> (, <classname>) * ) 1 .
The list below shows the selection preprocessors provided with WebSphere Portal Version 5.1. Selection preprocessors process the page selected by the user.
Note: Both of these preprocessors are exclusive. This means they cannot be used in combination with each other.

com.ibm.wps.state.preprocessors.selection.StandardPortalSelectionImpl

This value implements the standard portal selection behavior which prefers displaying pages over displaying labels. This means that if a user selects a label, the portal displays a page under that label, rather than the label itself with the message saying that there is no content available. (In this case the page displayed is the last page that the user selected under this label, or if that page is not available, the first available page below the label.)

com.ibm.wps.state.preprocessors.selection.SimpleSelectionImpl

This value implements a simple selection strategy; it always displays the element selected by the user, regardless of whether the user selects a label or a page. If the user selects a label, the portal displays that label with the message that there is no content available.

com.ibm.portal.state.keymanager.lru.size = ( integer )

Use this parameter to specify the history expiration limit of portal pages visited by users. Determines how far backwards users can at least navigate in the recent history of portal pages that they visited. The number that you specify defines the minimum number of different pages selected by the user after which the portal can discard the render parameters of a page. (The decision whether the render parameters of the page are actually discarded depends on the expiration policy of the internal cache that stores the render parameters of those pages.) If the user returns to a page after visiting the specified number of other pages and if the render parameters of that page have expired, the portal displays that page in its default state.
For details about the portal navigational behavior refer to Portal navigation and Back button behavior.
You can specify by which circumstances the render parameters of a page are stored or discarded:

1

Each time that the user selects a different page, the render parameters of the portlets on the previously selected page can be discarded.

A positive integer

Specify the required number of pages. The render parameters of a given page can be discarded after the user has visited that number of other pages.

0

Render parameters are always stored in the portal session memory and never discarded.

Do not specify a value below zero ( 0 ). Negative values are considered to be not valid.

Administrator Unique Names Mapping Service

Administration portlets and themes create URL links to other administration portlets and pages. If these links were hard-coded, they would no longer be usable if you changed the unique names of these pages. Therefore a service for obtaining those unique names is provided in the properties file AdminUniqueNamesMappingService. This file contains key-value pairs mapping internal keys to the actual unique names which are assigned to the referenced pages.
If you change the unique name of a portal administration page using the Manage Unique Names portlet, you also need to update that name in the properties file. This is required so that the theme and administration portlets still function. Restart the portal to make the changes in the properties file become effective.
The location of the properties file is...
wp_root/shared/app/config/services/AdminUniqueNamesMappingService.properties
The contents of the file are as follows:
CONTENT_LAYOUT = wps.Content APPEARANCES = wps.Appearance MANAGE_PAGES = wps.Manage Pages UNIQUE_NAMES = wps.Custom Unique Names ASSIGN_ROLES = wps.Resource Permissions PROPERTIES_PORTLET = wps.Page Properties MY_FAVORITES = wps.My Favorites ORGANIZE_FAVORITES = wps.Organize Favorites SET_PERMISSIONS = wps.Locks MANAGE_LOG = wps.Enable Tracing MY_PORTAL = wps.My Portal ADMINISTRATION = wps.Administration PAGE_CUSTOMIZER = wps.Page Customizer PORTLET_MANAGER = wps.Portlet Manager MANAGE_MY_PORTLETS = wps.Manage My Portlets MANAGE_MY_PORTLET_APPS = wps.Manage My Portlet Apps MANAGE_WEBSERVICES = wps.Manage Web Services IMPORTXML = wps.Import XML SEARCH_CENTER = wps.Search Center VIRTUAL_PORTAL = wps.Virtual Portal LOGIN = wps.Login SELFCARE = wps.Selfcare

Examples of where these unique names are used are: Theme links for 'New Page', 'Edit Page', and 'Assign Permissions'.

Portal Security Services

The following sections describe the different configuration services provided for Portal Access Control and authentication.

Access Control Data Management Service

Configuration settings for Portal Access Control.

accessControlDataManagement.enableNestedGroups = (true)

Determine whether the group membership of groups is exploited at all by the Portal Access Control component. Supported values are: true and false. The default is true.

accessControlDataManagement.enableTargetResourceGroupInheritance = (false)

Determine whether the group membership of groups is exploited by the Portal Access Control component for permission enforcement on users or groups. If you specify false, you can only get permissions on user groups via roles on the groups and on users via roles on the direct groups of which the user is a member. Supported values are: true and false. The default is false.

accessControlDataManagement.cacheTimeout = (0)

Determine the wait time in seconds between two periodic access control cache flushes. If you do not want periodic cash flushes to occur, set this property to zero ( 0 ). You need to enable this feature when you use an external authorization provider, such as IBM Tivoli Access Manager for e-business. The default is zero ( 0 ).

accessControlDataManagement.reorderRoleNames = (false)

Determine whether the role name contains the unique name or the title of the resource on which the role was created. Specify true when you use an external authorization provider, such as IBM Tivoli Access Manager for e-business, as this makes it easier to find the role names. Supported values are: true and false. The default is false.

Authentication Service

The authentication service contains the configuration settings for portal authentication. Authentication means that users identify themselves in order to gain access to the system. Usually they do this by a user ID and password.

authentication.execute.portal.jaas.login = (false)

Enable or disable the execution of the portal JAAS login:

false

Disables the execution of the portal JAAS login. This is the default. Disable this property only if you have no JAAS Login Modules defined for the portal application login configuration.

true

Enable the execution of the portal JAAS login. You can enable this property if you have JAAS Login Modules defined for the portal application login configuration.

This is related to performance.

authentication.screen.login = (false)

Determine whether an error during authentication results in a redirect to an error screen or if an exception is thrown that can be caught by the Login portlet.

false

Means an error condition during authentication results in an exception that is caught by the Login portlet. This is the default.

true

Means an error condition during authentication results is redirected to an error screen.

The XML configuration interface

For hints on how to export a configuration from an existing portal and import it to another portal, see XML configuration interface.

See also

Persistent session state
Configure dynamic fragment cache
Portlet filters
URL Mapping
Portal configuration
XML configuration interface
Portal configuration
Install databases
Configure databases
Administering your portal
Writing portlets
Customizing the portal
Portlet development
Performance
Credential Vault and Credential Service

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.

Portal resource	JSR 168 portlet application	IBM Version 4.x API portlet application
Portlet Application	Default locale	N/A
	Title	Title
	User attributes	Context parameter
Portlet	Name	Name
	Title	Title
	Short title	Short title
	Keywords	Keywords
	Description	Description
	Default locale and description	Default locale
	Initialization parameter	Initialization parameter
	Preferences	N/A
	Remote cache settings	Cache settings
	Expiration date settings	N/A
Servlet	N/A	Mappings

Sets that influence local caching
Key	Meaning	Default value
public.reload	Specifies the cache expiration time (in seconds) for the portal internal cache for anonymous portal pages. These are unpersonalized and unauthenticated portal pages which users can access without having to log in to the portal. Values smaller than 0 are replaced by the default.	60
Sets that influence remote caching
Key	Meaning	Default value
public.session	Specifies whether an anonymous user always has a public session. This may be useful when a portlet requires a session for anonymous users. To enable public sessions for pages that anonymous users can view without logging in, set this parameter to true. The setting of public.session influences the remote cache scope for public pages. If public.session is set to true, then the cache scope is set to non-shared (private). If public.session is set to false, then the cache scope is set to shared (public). Setting public.session to true reduces portal performance.	false
public.expires	Specifies the cache expiration time (in seconds) for caches outside of the portal and for unauthenticated pages only. These caches must adhere to the HTTP 1.1 specification (RFC 2616). The public.expires key specifies the time after which HTTP caches should drop the response. This can be further restricted by the remote.cache.expiration key (see below). This value is used as a maximum value for the cache expiration time and as a global default value for unauthenticated pages. If the setting remote.cache.expiration is also set to a value greater than or equal to 0, the smaller one of the two values is used. The portal calculates and aggregates the remote cache information, that is the scope and expiration time, by a number of parameters contributed by themes, pages, and portlets besides the settings described here. Therefore the portal can do any of the following internally while processing a request: Reduce the cache lifetime Reduce the cache scope, for example, from public (shared) to private (non-shared) Switch off the overall cachability of pages. Therefore this value might not be static for all responses resulting from requests to unauthenticated pages. The response of the portal sets the following header fields: The Expires header with the expiration time added to the system date and time of the portal The Cache-Control : max-age = header with the expiration time as its parameter. The default setting specified in this file is 60 seconds. If no value is specified, the portal defaults the value to 60 seconds.	60
remote.cache.expiration	Maximum cache lifetime (in seconds) of a page, both public and private. Used to specify a global value for the expiration of pages in remote caches. Set to 0 switches caching off in remote caches. If the legacy setting is not available, this setting is used for authenticated and unauthenticated pages. If the legacy setting is available, then the smaller of the two values is used for unauthenticated pages only. In this case the remote.cache.expiration setting is used for authenticated pages in general. If theme, composition, and portlets contribute remote cache information, then the global settings also contribute to the information. In this case the lowest of the values of all contributors is used, including the global settings. The default setting specified in this file is 60 seconds. If no value is specified, the portal defaults the value to zero (0 seconds).	0
remoteCacheInfo.response.header.vary	Specifies the HTTP headers that force a proxy to cache different variants of the same URL. Use this setting to specify a comma separated list of HTTP header fields to which the portal should refer in its vary field of the generated HTTP response. This is required to ensure that proxy caches can invalidate entries in their cache if the specified header fields do not match from request to request.	User-Agent