Portal service configuration

 

+
Search Tips   |   Advanced Search

 

Overview

The services framework consists of a manager and an abstract class that represents all services that are to be managed. A service that is supposed to participate in the framework needs to derive from class...

com.ibm.wps.services.Service

When the service manager is initialized, each service defined in...

WP_ROOT/shared/app/config/services.properties

... is also initialized. The order of initialization is equivalent to the order of services in this file. This initialization is performed once only.

Each service can (but does not need to) have its own configuration file. All of these files are conveniently stored in the directory...

WP_ROOT/shared/app/config/services

...of your WebSphere Application Server installation. The following sections describe the services and their configuration files that may be of interest to the portal administrator. Those files which are not described in the following are for purely internal usage.

Please make sure that the order of initialization of system services is not corrupted by adding or removing other services.

 

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.

Some of the parameters in the file DeploymentService.properties of WebSphere Portal Version 5.0.2 have been moved there from the file ConfigService.properties of WebSphere Portal Version 4.x.

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>

This is the absolute path to the install directory of WebSphere Application Server. This parameter has no default.

wps.home = <none>

This is the 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.

execute.portal.jaas.login = false

Allows the possibility to disable the execution of the portal JAAS login. Disable only if no JAAS Login Modules are defined for the portal application login configuration.

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.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.enable.filtering = (true)

Flag that determines whether the portal should use Portlet 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)

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

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

wps.mappingurl.enabled = (true)

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

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.

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.defaultstate = (true)

Determines whether the nodes in the navigation tree are expanded or collapsed by default. The default is true, which means that nodes are expanded. Changing this setting to false, however, causes the navigation in portal Administration to not function properly. See Cannot navigate portal Administration to fix navigation for the Administration pages.

 

Portlet Object Filtering

portletcontainer.filter.request = <none>
portletcontainer.filter.response = <none>
portletcontainer.filter.session = <none>
portletcontainer.filter.config = <none>
portletcontainer.filter.context = <none>

The filter mechanism of the portlet container allows to change and adapt the behavior of methods that are only defined in the servlet API and not available in the portlet objects. These filters must be derived from the existing filters in the package com.ibm.wps.pe.pc.legacy.objectfilter .
For each filter the fully qualified class name must be assigned.

 

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 that are by default not allowed.

The following header fields of the HTTP 1.1 (RFC 2616) are not allowed to be set:

6.2 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 (Section 14.5)
  • Location (Section 14.30)
  • Proxy-Authenticate (Section 14.33)
  • Server (Section 14.38)
  • Vary (Section 14.44)
  • WWW-Authenticate (Section 14.47)

 

7.1 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 (Section 14.7)
  • Content-Encoding (Section 14.11)
  • Content-Language (Section 14.12)
  • Content-Length (Section 14.13)
  • Content-Location (Section 14.14)
  • Content-MD5 (Section 14.15)
  • Content-Range (Section 14.16)
  • Content-Type (Section 14.17)
  • Expires (Section 14.21)
  • Last-Modified (Section 14.29)

 

4.2 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 true, then high-performance control elements are enabled. If false, high performance controls are not used. See Performance - Using high performance skins for more details.

skins.highperf.containers = (false)

If true, then high-performance unlayered containers are enabled. If false, high performance unlayered containers are not used. See Performance - Using high performance skins for more information.

skins.highperf.layeredcontainers = (false)

If true, then high-performance layered containers are enabled. If false, high performance layered containers are not used. See Performance - Using high performance skins for more information.

skins.highperf.showself = (false)

If 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. You must manually add this parameter to the file. See Performance - Using high performance skins for more details.

 

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 WebSphere Application Server. It uses the WebSphere Application Server management services for the physical deployment and management of war files in the WebSphere Application Server. 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 WebSphere Application Server. 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 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.

Some of the parameters in the file DeploymentService.properties have been moved here from the file ConfigService.properties of WebSphere Portal for Version 5.0.2.

In the following list of parameters the values given in parentheses are the default values.

wps.appserver.name = (WebSphere_Portal)

The application server 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.

was.admin.port = (8881)

WAS administrative port. This parameter is used to adapt to the WAS SOAP bootstrap port number, if the default is not applicable.

was.admin.user = (wpsadmin)

Sets the Administrator user ID.

was.admin.pwd = (wpsadmin)

Sets the Administrator password.

was.ssl.truststore = (/etc/DummyClientTrustFile.jks)

Determines location of trust file.

was.ssl.keystore = (/etc/DummyClientKeyFile.jks)

Determines location of key file.

was.ssl.truststore.pwd = (WebAS)

Sets password for trust files.

was.ssl.keystore.pwd = (WebSA)

Sets password for key files.

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

Controls the update of portlet configuration settings. This parameter controls whether the portlet configuration parameters from portlet.xml should replace the existing ones, or whether the existing parameters should be preserved, and only new ones being added.

use.redeploy = (true)

This parameter controls whether WebSphere Application Server 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)

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

portletapp.starting.weight = (100)

This is the 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

This is the 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.

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

This is the 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> )

This is the root directory where job files are stored for deployment.

jobs.dir.name = (jobs)

This is the subdirectory name where job files are stored for deployment.

delete.temp.files = (false)

This parameter determines whether temporary files are deleted or kept.

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 database is configured as described under Configure for DB2.

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

This is the type of database management that manages the datasource. Valid values are DB2, DB2_ZOS, ORACLE, SQLSERVER, INFORMIX, and CLOUDSCAPE.

For further information on datasources and their configuration, refer to the WebSphere Application Server 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, and 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.

 

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]

This parameter 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]

This parameter 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.

component

The component bucket is used to cache the database representation of all components stored in the portal database. An example is the columncontainer client.

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

This section lists and describes the PortletContainer related settings in the file PortletContainerService.properties.

legacy.checkListeners =

Possible values: true | false.
This flag should always be set to true. Its main usage and purpose is for development. If this flag is set to true, the PortletContainer will always check whether the portlet implements the concerned listener. If the flag is set to false it is assumed that all possible listeners are available.
Reason: performance.

Example: legacy.checkListeners = true

legacy.useStoredResponse=

Possible values: true | false.
This flag should always be set to true. It controls caching of portlet responses. It could be set to false when a possible future implementation in WebSphere Application Server is available.

Example: legacy.useStoredResponse = true

 

Parallel portlet rendering

Use the properties for parallel portlet rendering to optimize the portal response time, depending on your configuration. Enabling 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 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 can be rendered in parallel. However, the default setting for individual portlets is not to be rendered in parallel, unless the portlet has been enabled for parallel rendering, for example, by the portlet developer or the administrator. Therefore, 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, then Portlets, and then Manage portlets. Select the desired portlet and click on Modify parameters. Change the value of the parallel parameter to true. If the property does not exist yet, you can add it to the portlet. To do this, enter parallel under Parameter and true under Value. This way you can configure a portlet for parallel rendering, even if the original portlet was not set up for it.

You can change the portal settings for parallel portlet rendering in the file PortletContainerService.properties. The settings for configuring parallel portlet rendering are listed and explained in the following:

legacy.useParallelRendering=true

Activates the portlet container functionality for parallel portlet rendering [true = default, false]

true

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

false

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

Queues are used to pass the content of the portlet between the threads. You can further tune parallel rendering by specifying different values for the queue parameters used:

Size of queues:

legacy.parallelRenderingQueueSize

Size of chunks read out of queue:

legacy.parallelRenderingChunkSize

Timeout:

legacy.parallelRenderingTimeOut

However, it is recommended to keep the default values.

Asynchronous beans are used for the parallel rendering process. A WorkManager wm/wpsWorkManager is configured to manage the asynchronous beans. Note that the WorkManager is only available in IBM WebSphere Application Server Version 5.0 Fix Pack 2. It is recommended not to change this name as the name is set in both the WebSphere Application Server and the WebSphere Portal configurations. You must set the option isGrowable in the WorkManager panel of the WebSphere Application Server to false. Otherwise parallel portlet rendering may not work to the full extent.

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. For more information see Use logs.

 

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.max.follow.redirects =

Specifies the maximum number of redirections which the ContentAccessService can handle to bind to other servlets or external resources. After it reaches its maximum it returns the contents from the last URL it reaches. The default maximum is 10.

Example: com.ibm.wps.pe.pc.legacy.service...max.follow.redirects = 10

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

 

The following section allows you to specify proxy protocol and port settings for different protocols. For each protocol the name and port number of the proxy servers used must be specified.

General Format:

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.*).
 

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

 

The following settings are used to control various secure protocol setups:

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.trust.store.url =

The file or URL of the trust store to be used by the ContentAccessServiceImpl

Example: com.ibm.wps.pe.pc.legacy.service...trust.store.url = c:\\websphere\\appserver\\java\\jre\\lib\\security\\cacerts

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.trust.store.pswd =

The password (optional) of the trust store to be used by the ContentAccessServiceImpl.

Example: com.ibm.wps.pe.pc.legacy.service...ContentAccessServiceImpl.trust.store.pswd = changeit

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.key.store.url =

the file or url of the key store to be used by the ContentAccessServiceImpl

Example: com.ibm.wps.pe.pc.legacy.service...ContentAccessServiceImpl.key.store.url = c:\\jsse\\classes\\key.jks

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.key.store.pswd =

the password (mandatory) of the key store to be used by the ContentAccessServiceImpl

Example: com.ibm.wps.pe.pc.legacy.service...ContentAccessServiceImpl.key.store.pswd = key

 

Cache Manager Service

The Cache Manager Service is responsible for managing the different caches used in WebSphere Portal Version 5.0.2. Starting with Version 5.0.2 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 parameters

They specify the default setting which is to be used for all caches unless explicitly overridden by the corresponding cache instance parameter.

cacheinstance.cacheidentifier parameters

They are used to 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 WebSphere Application Server 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]

This setting controls wether 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 wether a cluster-aware cache is to be used or not.

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

cacheglobal.replacement= [agressive | moderate | conservative]

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

Controls the eviction algorithm behaviour.

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.

 

AdminUniqueNamesMapping 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

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

 

 

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