Deployment Service
The portal Deployment Service provides services for accessing the configuration properties 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 HCL WebSphere Portal and WebSphere Application Server. 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.
In the WAS console, the portal Deployment Service is listed as WP DeploymentService.
- HCL WebSphere Portal has the configuration separated into two types:
- Deployed configuration. This is read-only. The deployed configuration is always read from the file portlet.xml.
- Administrative configuration. This is read/write.
The deployed configuration can be modified by administrative changes, for example, using administrative portlets or the XML configuration interface. The administrative configuration is never overwritten by changes to the deployed configuration.
- Portlet applications appear in the Enterprise Application list on the WAS console. However, we should never manage them from outside the portal. Instead, manage them using the 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 console. We can identify the name of such a portlet application by a portal specific identifier prefix PA_<name> . This identifier is appended to the name. An example for such a name is PA_WPS_Welcome . The name in turn is derived from the name of the WAR file when the portlet application is installed. We can change this administrative name with an update of the portlet application.
In the following list of properties, the values given in parentheses are the default values.
- was.admin.host = (localhost)
- The WebSphere Application Server administrative host name. This property 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 dmgr 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. Default. This is a separate user ID that is common for all users who are allowed to perform install or manage applications tasks. We must 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, we can add the complete group of portal administrators to the WAS console Group administrator rights.
- was.notification.timeout = (300)
- 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)
- 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.shared.library.list
- This property defines a list of library references which are added to each deployed WAR file during deployment. We can specify multiple references separated by a comma ( , ). The library references must have already been defined in the application server, 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. Default.
- preserve
- When we specify this value, the setting from the file ibm-web-ext.xmi is applied, if available.
The default setting is false.
Do not enable reloading in a production environment. Enable reloading only for portlet development and portlet debugging purposes.
- discard.config.interval = (60)
- This property defines the minimum time interval for which the configuration service workspace used during WAR file deployment is kept. After this time expires, the workspace is discarded when the portal runs the next deployment task. The unit of measure is minutes. Valid values are listed in the following, together with their meaning:
- -1
- Never discard the workspace.
- 0
- Always discard the workspace immediately after the action that required the workspace has been completed.
- > 0 (numerical value greater than 0)
- Time interval (in minutes) for which a workspace is retained before it is discarded. It is then rebuilt for the next deployment task.
- Use good judgement when setting this property. The proper use of this setting must be a compromise between performance and workspace consumption for the following reasons:
- Discarding the workspace frequently has a negative impact on deployment performance. The larger the portal installation is, the longer it takes to discard and rebuild the workspace to save the configuration changes during WAR file deployment.
- However, retaining a workspace keeps the wp_xxx temporary directories in the WAS wstemp directory. Consequently, the temporary space they occupy in the file system grows every time a WAR file is deployed and every time the portal is restarted.
- The configuration service workspace is not discarded immediately after expiry of the time interval set. The cleanup is done the next time that a deployment operation is called. It checks for expired changes and discards the workspace they occupy. If further deployment operations occurred after the last time the timer interval expired and the workspace was released, the changes in the last allocated workspace remain in the file system even on portal shutdown. Nevertheless, the previous cleanup reduces the volume of occupied disk space to only those temporary files that were processed after the last cleanup interval.
File location definitions: 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.
- delete.temp.files = (true)
- Whether temporary files created during deployment in the directory application.repository.dir.name/temp are deleted or kept. The default is true , which means the files are deleted. Set the value to false only for debugging purposes so we can view the content of the temporarily expanded WAR files. When we have completed debugging, change the value back to true and delete the directories manually. If we change the value to false, be aware the hard drive space required by the temporary directory grows with each WAR file that you add or update.
- shorten.deployment.names = (true)
- Use this key to enforce shorter file names during deployment. Some platforms, such as Windows impose a limit to the length of a file path. This can cause deployment to fail if the resulting path is too long.
- deployment.names.limit = (21)
- The threshold value for portlet application file and display names. Longer names will be shortened if required.
The following setting is for debug purposes only. Enable it only when instructed to do so by support personnel.
- deployment.debug.log.times = (false)
- This setting is for debug purposes only. Enable it only when instructed to do so by support personnel.
Parent Portal service configuration