Previous Page |
Next Page This section describes the tasks you can perform to configure the Lotus® Expeditor Client on the user's machine.
Applications might require specific system properties to be set at startup when running the Lotus Expeditor Client platform.
To minimize the number of parameters that you must specify on the command line, you can add configuration lines to the rcpinstall.properties file.
See Updating the rcpinstall.properties file for detailed information.
You can also specify properties on the command line when you launch the platform. See Configuring the platform launcher for more information.
Applications might require the addition of specific arguments for a Virtual Machine (VM) that implements the Java™ specifications when the platform starts.
To minimize the number of parameters that must be specified on the command line, you can add vmarg.* configuration lines to the rcpinstall.properties file, which resides in the .config directory of the workspace. (See Overriding the workspace directory location for more information.).
See Updating the rcpinstall.properties file for detailed information.
You can also specify VM arguments on the command line when you launch the platform. See Configuring the platform launcher for more information.
When using the Lotus Expeditor on the desktop, the recommended approach is that all native
library objects be included in operating system/processor specific fragments.
In general, this is sufficient to allow the application code and the operating system to locate the desired library. However, there might be cases where it is not possible to organize the libraries within a fragment, or the library loading requirements inhibit this approach. Therefore, library search path must be updated.
You will need to update the library.path.append or library.path.prepend lines in the rcpinstall.properties file to specify the directory locations containing the libraries.
See Updating the rcpinstall.properties file for detailed information.
When using the Lotus Expeditor Client on
the desktop, the recommended approach is that all class libraries that are needed by applications reside within plug-ins or fragments.
If there are cases in which the libraries must be placed on the Java bootclasspath, then you will need to update the -Xbootclasspath.append or Xbootclasspath.prepend line or lines in the rcpinstall.properties file.
Refer to Updating the rcpinstall.properties file for detailed information.
You can configure additional arguments to use when the user launches the Lotus Expeditor Client. For example, you can specify that a console is displayed when launching the client.
Options that you might want to configure are as follows:
- -application
- Temporarily overrides the application property in the rcpinstall.properties file.
- -config
- Allows you to specify command options in the rcplauncher.properties file to avoid operating system restrictions in the length of commands. See Updating the rcplauncher.properties file for more information.
The launcher output is written to a file named rcplauncher.log in the logs directory. For a normal launch, it does not contain any output. It contains information if you are using the -debug option or if the launcher has a fatal error while launching the platform. In the event of a fatal error prior to the creation of the log, the output is written to /tmp/rcplauncher.log on Linux® and to %TEMP%/rcplauncher.log on Windows®.
Arguments
based on VM, Eclipse, or OSGi are passed through, except for the following:
- If either the -console or -consoleLog option is specified, then javaw.exe/expeditorw.exe specified in the rcpinstall.properties file is converted to java.exe/expeditor.exe by the launcher.exe.
- -configuration: This option is stripped. The configuration location is always calculated as workspace_location/.config.
For a complete list of runtime options defined by Eclipse, see the Platform Plug-in Developer's Guide, which is installed with the Rational® Software
Development Platform, and to http://help.eclipse.org/help32/index.jsp" target="_blank">http://help.eclipse.org/help32/index.jsp.
To configure the platform launcher to use additional options, you must add the option to the path of the executable. To add options to the executable, modify the shortcut from the desktop icon. Additionally, you can add options as properties in rcplauncher.properties. See Updating the rcplauncher.properties file for more information.
- -console
- Enables you to display the OSGi console. You can have the maximum information logged by adding logredirector.level=INFO to the rcpinstall.properties file. These two options work well together when you need to debug problems.
Note:
On Linux you must also change the application type to "Application Terminal" in the shortcut properties.
- -data
- Temporarily overrides the workspace location (osgi.instance.area property). The default calculation of the workspace is specified by the rcp.data property in rcplancher.properties. The configuration area is calculated based on this value. A -configuration option is ignored.
Note:
If the default workspace is not available or inaccessible, specify the workspace during
IBM® Lotus Expeditor startup
using the following command:
rcplauncher.exe -data workspace
where
workspace is the path to the desired workspace location.
- -debug
- Causes additional debugging information to be logged automatically for the core launcher components. Normally the --launcher.supressErrors argument is added by the launcher. This has the effect of suppressing the dialog displayed by the Eclipse executable when the Java machine returns unexpectedly. If you want to see this dialog during a debug session it can be enabled by adding -debug to the launch arguments.
- -dir
- Overrides the bidi direction. Correct values are rtl and ltr.
Note:
Overriding the settings to specify rtl is not supported on Linux.
- -nl
- Overrides the locale being used. The appropriate locale features must have been installed to provide for localized content. For more information, see Installing additional languages content.
Note:
Overriding the settings to specify Hebrew or Arabic as a locale is not supported on Linux.
- -personality
- Customizes the look and feel depending on the desired applications. This can be used to override the value specified in the rcpinstall.properties.
- -product
- Overrides the product feature that is specified by other means.
- -version
- Prints the version of the rcplauncher to the
temporary log and exits. For example: rcplauncher.exe -version - -vm
- Overrides an external Virtual Machine (VM). You must also pass in any vmargs that are required for this VM. The VM pointed to by this option can cause problems when switched after the fact. IBM supports the VMs packaged with the product as well as IBM Java 6 and Sun Java 6.
- -vmargs
- Allows additional vmargs to be passed to the VM that implements the Java specifications. No checks are performed on the values. This is not an override, but strictly an addition to the vmargs specified in the rcpinstall.properties file.
Dcommands
See the com.ibm.rcp.core.daemon package for information about how to use the daemon.
The com.ibm.rcp.core.daemon class defines an interface that must be implemented by an application developer who uses the com.ibm.rcp.core.daemon.command extension. See the com.ibm.rcp.core.daemon extension point for more information.
You can use this extension point when you need to forward a command to a plug-in from a desktop command. To do so, follow these steps:
- Add the command as an option to the launch command.
- Run the launch command. Instead of launching the platform, the daemon forwards the complete launch command to the platform.
- The plug-in that registered the extension has its RcpDCommand.execute() method called.
- Call the execute method to decode the command line arguments and act on them in some way.
A plug-in that is to receive commands must:
- Contain the com.ibm.rcp.core.daemon.command extension point in its plugin.xml. A complete example can be found in the com.ibm.rcp.core.daemon extension point
- Implement the com.ibm.rcp.core.daemon.RcpDCommand interface, which is defined in the com.ibm.rcp.core.daemon extension point.
To activate the command, launch the platform with rcplauncher.exe -my.plugin#extId.my_command. If the platform is running, the command is forwarded to the plug-in.
If the platform is not running, the command is ignored and the platform is started. If you need to encrypt the command stream sent to the platform, the following property
should be added to the rcpinstall.properties file:
-Ddaemonconnect.provider=
com.ibm.rcp.core.internal.connect.encrypt.EncryptedDaemonConnect
The daemon thread listens for commands while the platform is running. It examines each parameter for command ID patterns registered using the extension point. See the com.ibm.rcp.core.daemon package for more information.
The daemon thread recognizes the following
pattern for command IDs:
-plugin-id#extension-id.]command-id
where the need for the optional [extension-id] element depends on whether the extension ID was specified in the plug-in manifest when the command was registered.
Example: Register the extension point
in plugin.xml:
<extension [id="foo"] point="com.ibm.rcp.core.daemon.command"
<command id="mycmd" class="org.example.MyCommandClass"/
</extension
where the extension ID is optional. If the extension ID ("foo") is specified, the RcpD examines the received
parameters for matches of the form:
-my.plugin#foo.mycmd
If the extension ID was not specified in the manifest, the RcpD would
be looking for:
-my.plugin#mycmd
Since the entire parameter list is sent to each command, it is possible for each command
to have any number of arguments:
-my.plugin#mycmd arg1 arg2 arg3...
Example: It is also possible to register for all command-line notifications,
regardless of content, as follows:
<extension [id="foo"] point="com.ibm.rcp.core.daemon.command"
<command id="mycmd" class="org.example.MyCommandClass" matchAll="true"/
</extension
If you register a handler to receive all commands, you should not register it to receive individual commands also.
Example: Application's plugin.xml:
<plugin
<extension
point="com.ibm.rcp.core.daemon.command"
<command
class="com.jdmiles.command.MyCommandClass"
id="my_command"
matchAll="true"/
</extension
</plugin
The provisioning system of the client platform provides the feature install and life cycle management. The provisioning system extends the capabilities provided by the underlying Eclipse Update Manager.
The Eclipse Update Manager and the provisioning system provide a number of preferences to control how these functions operate.
This section describes the deployment preferences you can change.
The following set of preferences are available and managed using Eclipse Preferences. IBM Lotus Expeditor allows many of them to be set by the user using the Install/Update Preferences page. You can set other preferences through manual
file updates of the plugin_customization.ini file or through remote management of the org.eclipse.update.core node, the org.eclipse.update.scheduler node, and the com.ibm.rcp.provisioning node. See Managing Eclipse preferences for more information on remote management of Eclipse preferences.
Preferences for org.eclipse.update.core:
- updatePolicyURL
- Location of the update policy file. This may be a local file or one accessible through an HTTP (or similar) URL. This preference is available to the user using the Install/Update Preference page.
Default: Not specified
- org.eclipse.update.core.historySize
- Number of history update files to maintain for the platform.
Default: 100
- org.eclipse.update.core.checkSignature
- Whether to check for signed feature objects during installation.
Default: true
- org.eclipse.update.core.automaticallyChooseMirror
- Automatically check Mirrors during feature installation.
Default: false
- org.eclipse.update.core.updateVersions
- Select the features that the scan for updates will select prior to display. Available values are compatible, equivalent, or major. This preference is available to the user using the Install/Update Preference page.
Default: equivalent
Preferences for org.eclipse.update.scheduler:
- download
- Search for updates and notify when they are available (false) or download new updates automatically and notify when ready to install them (true). Ignored unless enabled preference set to true. This preference is available to the user using the Install/Update Preferences page.
Default: false
- enabled
- Whether to automatically search for updates.
Default: false
- schedule
- Determines when to search for new updates. Choices are to search on platform start (on-startup) or on a schedule (on-schedule). Ignored unless enabled preference set to true.
This preference is available to the user using the Install/Update Preferences page.
Default: on-startup
- hour
- Time of day to search for new updates (time
specified in HH:00 AM|PM). Note that this value is locale dependent, so a setting for US English is not recognized correctly on another locale. Administrators managing platforms in multiple locales will need to set a locale specific setting. This preference is available to the user using the Install/Update Preferences page.
Default: 1:00 AM
- day
- Day of the week to search for new updates. Values are Every day, or Every <dayname
. Note that this value is locale dependent, so a setting for US English is not recognized correctly on another locale. Administrators managing platforms in multiple locales will need to set a locale specific setting. This preference is available to the user using the Install/Update Preferences page.
Default: Every day
Preferences for com.ibm.rcp.provisioning. (These preferences are not available through the preferences user interface. See Managing Eclipse preferences for
more information on how to change these values.):
- feature.history.size
- Specifies the number of old versions of a feature to retain on the file system. The default values will depend on the platform configuration. If the platform configuration (install.configuration) is set to user, the default is 0. If the platform configuration is set to multiuser, the default value is -1, indicating that all feature versions are retained. The default value used on device configurations is 0.
As an example, if the value is set to 0, then installing an updated version of a feature will cause the previous version of the feature to be removed. If the value is set to 1, then when an updated version of a feature is installed, a single previous version will be maintained. If there was more than one version already installed on the platform, then the oldest versions will be removed. Only older versions of the currently enabled feature are removed. Versions greater than the currently enabled feature will not be removed.
- runDeferredActionsOnStartup
- Specifies when deferred actions should run, such as the uninstall of old versions of features. When set to true, the deferred actions will run immediately when the platform starts, and no progress indicator will be displayed. When set to false, the deferred actions will run after the workbench has completed its
startup processing, and a progress indicator will be displayed. The default value is false.
- updateSiteList
- A list of Strings representing update sites separated by the vertical
bar (|) character. For example:
- file:/E:/updatesite|http://www.mycompany.com/myupdatesite|jar:file:/z:/someupdatesite.zip!/
- file:updatesite|http:www.mycompany.com/myupdatesite|jar:file:/z:/someupdatesite.zip!/
The sites in this list are in priority order. The first site in the list will be searched first, then the second site, and so on.
A feature found on the first site will be used, even if the same feature with a higher version may be available on the second or third site. The default value for updateSiteList is an empty list.
- whiteList
- A Boolean specifying how the updateSiteList will be used.
If this property is set to true, then the Policy URL searching will be turned off and the useList preference, feature.xml update site, and the bookmarks.xml update site will be ignored.
- useFeatureURL
- A Boolean specifying whether to include update site URLs provided using feature.xml, provisioning manifest, or provisioning API request in the search list.
This preference determines if the feature.xml provided update site should be searched. The manifest and provisioning API requests are always used if specified. If the whiteList preference is set to true, then this value will be ignored.
- useList
- A Boolean specifying whether the list of update site URLs defined in updateSiteList are used.
If set to true, and if the whiteList preference is set to false, then the updateSiteList is used. If the whiteList preference is set to true, then this value will be ignored.
This section describes how the Expeditor platform provides for automatic searching for updates.
There are several ways that the Expeditor platform provides for
automatic searching for updates:
- From the File -
Application -
Install dialog - From the File -
Application -
Application management dialog (when the Lotus Expeditor product is selected) - From an individual feature in the Application Management dialog, if an update site has been configured for that particular feature
- By enabling Automatic Updates using the Install/Update Preference Page or by programmatically updating the applicable Eclipse preference
The search hierarchy for Automatic Updates or Scan for Updates
is as follows:
- Update Policy URL
- Update sites specified in individual features
To prevent any updates from occurring based on update sites in individual features, the update policy should always contain a pattern specified as "*". Otherwise, if a feature is installed that does not match any patterns in the update policy, the individual update site specified by that feature will be used.
Automatic updates will search for feature updates of equivalent, compatible, or major, based on the preference setting org.eclipse.update.core/org.eclipse.update.core.updateVersions.
Specifying discovery sites and bookmarks for features
Bookmarks are update sites defined in the bookmarks.xml file residing in the configuration directory. Contributions to the bookmarks file can be provided through discovery sites defined in individual features.
Bookmarks are not used during the automatic search.
The Expeditor product provides access to the update manager user interface for deployment of new features and managing of the current configuration.
In addition, preference pages are provided to enable configuration of the behavior of the provisioning system, such as the platform update policy or scheduling of automatic updates. If desired, you can hide the menu actions and preference pages by using the activity support of the workbench.
Define the following extension to the org.eclipse.ui.activities extension point to define an activity that includes the menu actions and preference pages. This extension definition can be included in any plugin.xml (or fragment.xml) of any plug-in (or fragment) deployed to the client platform.
<plugin
<extension
point="org.eclipse.ui.activities"
<activity
id="UIEnabler.installupdatemenu"
name="Install Update Menu"/
<activityPatternBinding
activityId="UIEnabler.installupdatemenu"
pattern="com\.ibm\.rcp\.provisioning\.ui/management"/
<activityPatternBinding
activityId="UIEnabler.installupdatemenu"
pattern="com\.ibm\.rcp\.provisioning\.ui/install"/
<activityPatternBinding
activityId="UIEnabler.installupdatemenu"
pattern="org\.eclipse\.update\.ui/org\.eclipse\.update\.internal\.ui\.preferences\.MainPreferencePage"/
<activityPatternBinding
activityId="UIEnabler.installupdatemenu"
pattern="org\.eclipse\.update\.scheduler/org\.eclipse\.update\.scheduler\.AutomaticUpdatesPreferencePage"/
</extension
</plugin
After the activity is defined, you can enable or disable the activity to display or hide the actions and preference pages. This example includes both menu actions and preference pages in the same activity, but the activity can be defined to include only the capabilities that are desired to be controlled, such as only the menu actions. After the activity is defined, you can enable or disable the activity as needed.
Lotus Expeditor provides an enhanced set of capabilities for managing and controlling the search order when locating new or updated features to install.
Deployers face the following three challenges in managing the set
of features installed on any particular system:
- To restrict the places a user can go to obtain new or updated features. If a user is allowed to go to any arbitrary update site to download new or updated features, there is a security risk - the integrity of the client platform could be compromised by malicious features.
- To maintain the currency of the installed set of features. Issues such as network topology changes, renamed servers, third party references, and sites that are inaccessible from user's desktops make this especially challenging. Maintenance through updating of CA XML files can be difficult and time consuming.
- To ensure that features are updated from the correct location.
Users may find they have access to a variety of versions of the same features from different sites and may be confused by which site is the correct one to use. Deployers need the ability to specify the order that Expeditor uses to search for updates for installed features.
The client platform provides an enhanced set of capabilities for managing and controlling the search order when locating new or updated features to install. In addition, the platform now provides the concept of a White List - a restricted set of sites from which to obtain new or updated features. The following preferences are used together to provide flexible control over the update sites from which new features are obtained. See Changing deployment preferences for descriptions of these preferences.
- com.ibm.rcp.provisioning/updateSiteList
- com.ibm.rcp.provisioning/useList
- com.ibm.rcp.provisioning/useFeatureURL
- com.ibm.rcp.provisioning/whiteList
- org.eclipse.update.core/updatePolicyURL
The combination of these 5 preferences determines the search order and location for installing feature updates. The following table describes how the settings influence the search order.
Table 1. White list managed settings and their desired outcomes | useFeatureURL | useList | UpdateSiteList | whiteList | Policy URL | Desired outcome |
| True/False |
True/False | If empty, this causes no features to be found. | True | Set/Not set | Search the manifest feature URL first if it is in the updateSiteList. Next search the sites in updateSiteList.
If search request contains a policy URL, whiteList will erase this value to ensure compliance. Log a message that the policy URL was removed. The sites in feature URL and bookmarks.xml will be ignored. If updateSiteList is empty, no features will be found. |
| True | True | Can be empty because feature URL and bookmarks.xml are also used to find features. | False | Not set | Search the manifest feature URL first. Search the sites in updateSiteList next. If updateSiteList is exhausted or empty, then search the feature URL site. If request is from Update UI "Search for new features to install" action, search the sites in bookmarks.xml. |
| True | False | Irrelevant | False | Not set | Search the manifest feature URL first. Next
use the feature URL to search. If request is from Update UI, search sites in bookmarks.xml. |
| True | False | Can be empty because feature URL and bookmarks.xml are also used to find features. | False | Set | Search for features using the policy URL if specified in the search request. Search the manifest feature URL next. If not found, search the updateSiteList. Search the feature URL site next. If request is from Update UI "Search for new features to install" action, search sites in bookmarks.xml. |
| True | False | Irrelevant | False | Set | Search for features using the policy URL if specified in the search request. Search the manifest feature URL next. If not found search the feature URL site. If request is from Update UI "Search for new features to install" action, search sites
in bookmarks.xml. |
| False | True | Could be empty because bookmarks.xml is used to find features also. | False | Not set | Search the manifest feature URL first. Use the updateSiteList to search for features. If request is from Update UI, search sites in bookmarks.xml. |
| False | False | Irrelevant | False | Not set | Search the manifest feature URL first. If request is from Update UI "Search for new features to install" action, use bookmarks.xml only to search for features. |
| False | True | Could be empty because policy URL and bookmarks.xml are used to find features also. | False | Set | Search for features using the policy URL if
specified in the search request. Search the manifest feature URL next. Search the updateSiteList next. If request is from Update UI "Search for new features to install" action, search sites in bookmarks.xml. |
| False | False | Irrelevant | False | Set | Search for features using the policy URL if specified in the search request. Search the manifest feature URL first. If request is from Update UI "Search for new features to install" action, search sites in bookmarks.xml. |
The default configuration of the platform allows updates to be installed from any update site specified in the provisioning request
or using the provisioning API: [useFeatureURL = true, whiteList = false, useList = false, updateSiteList = <empty list
. While this configuration provides the most flexibility, it also provides the least control over from where new features are obtained. In addition, this configuration relies on the users of the platform and the content of the distributed features to locate new and updated features.
To help control the number of sites from where features can be obtained, the updateSiteList can be defined with a set of update sites. In this configuration useFeatureURL = true, whiteList = false, useList = true, updateSiteList = <nonemptylist
, in addition to the sites defined by the features, updates and new features can also be found on the set of update sites specified by updateSiteList.
The update sites specified by the features will take precedence over the update sites specified by the updateSiteList.
A third setting of the configuration is very similar to using the update policy specified by the org.eclipse.update.core/updatePolicyURL preference. In this configuration [useFeatureURL = false, whiteList = false, useList = true, updateSiteList = <nonemptylist
], features will only be searched for on the update sites specified in the update site list. Whereas the update policy directs specific feature identifiers to specific update sites, this allows the update sites to be specified in a list, without requiring features to be obtained from any one of them. Note that in this configuration, if the updateSiteList is empty, no features will be able to be located, and the feature install requests will fail.
To provide the most control over where new and updated features can be installed from, the configuration whiteList = true,
updateSiteList =<nonemptylist
, useList = true or false, useFeatureURL = true or false ] will restrict updates to come from only the set of update sites specified on the updateSiteList. Note that in this configuration, if the updateSiteList is empty, no features will be able to be located, and the feature install requests will fail.
Note that since there are three Boolean variables, combinations other than those highlighted above are possible, but will result in a configuration in which provisioning requests can never succeed.
In all of the configurations except whiteList=true, the update policy (specified by org.eclipse.update.core/updatePolicyURL) can also be used. If the update policy is specified, then any feature update site remapping will occur prior to applying the preferences as defined above. For example, if a feature com.ibm.sample.feature contains
a URL that refers to site http://www.ibm.com, and the update policy
contains a mapping of "com.ibm.sample" to http://w3.mycompany.com,
the feature search will be directed to http://w3.mycompany.com.
Update manager behavior when useList or whiteList preference
is "true":
When the useList or whiteList preference is "true," the Update Manager will automatically add sites specified in the updateSiteList preference to the list of sites to be searched. These sites can be identified in the Update Manager by the "minus sign" that precedes the update site entry. These sites can not be modified or removed but they can be disabled from search by deselecting the site. When the whiteList preference is "true," the updateSiteList sites are the only sites that are available to the user and no bookmark sites will be displayed
When searching the update sites, the searches will occur in a specific order. If the feature is found on a site, and it satisfies the match rules contained in the request, then this feature will be used, regardless of any features that may be contained on any other sites.
The order of precedence for searching is:
- Policy URL mapped sites (only if the search request has this set and whiteList preference is "false")
- Feature URL from manifest request (only if manifest has a URL set)
- updateSiteList sites in order (only if useList or whiteList preference is "true")
- Feature URL site from feature.xml (only if useFeatureURL preference is "true" and whiteList preference is "false")
- Bookmark sites in no order (only from Update UI "Search for new features to install" action and if whiteList preference is "false")
For performance reasons, it is therefore recommended that the updateSiteList, if used, be carefully managed to make sure that the update sites contain the features required, and are organized in the best performing order.
Unresponsive sites may significantly increase the time required to complete a provisioning request.
To eliminate confusion as to which feature will be found during searches, it is recommended that the update sites either contain different sets of features or that the same versions of all features are maintained across all sites.
This section describes the signed plug-in policy settings used by the Lotus Expeditor Client provisioning system for controlling access to local or remote Eclipse update sites. Your end users access the update sites to upgrade their base offerings and custom plug-in applications.
Because the provisioning system can access code from a local or remote eclipse update site, signing the jar files posted on the update site and verifying them on the client at download time allows the end user to get reliable information about the code they are about
to download. This component allows them to identify who published the code and verify that software has not been tampered with or altered since the time it was uploaded to the update site.
The decisions made by the provisioning subsystem when installing jars from an update site are made by a policy engine which uses policy settings defined as Eclipse preferences to make trust decisions. The policy engine that makes the trust decisions is controlled by a set of Eclipse preferences.
By default, support for verifying signed plug-ins is turned on.
To configure signed plug-in verification, modify the following Eclipse preferences. See Managing Eclipse preferences for setting preference information.
Table 2. Signed plug-ins preferences | Eclipse preference |
Possible Values |
| com.ibm.rcp.security.update/VERIFICATION_LISTENER | Class implementing the IVerificationListener interface |
| com.ibm.rcp.security.update/EXPIRED_SIGNATURE_POLICY | PROMPT/ALLOW/DENY |
| com.ibm.rcp.security.update/UNSIGNED_PLUGIN_POLICY | PROMPT/ALLOW/DENY |
| com.ibm.rcp.security.update/UNTRUSTED_SIGNATURE_POLICY | PROMPT/ALLOW/DENY |
- VERIFICATION_LISTENER
- This preference setting indicates which Eclipse IVerificationListener
implementation will be used by the provisioning system while verifying jar files being provisioned from an Eclipse update site. This subcomponent
provides the below two implementations of IVerificationListener interface:
- com.ibm.rcp.security.update.DefaultVerificationListener
- Set this value for enabling this subcomponent when provisioning is done by launching the platform in headless mode. This can be enabled at install time by adding this preference to the plugin_customization.ini file in the deploy directory of the media kit.
- com.ibm.rcp.security.update.ui.PromptVerificationListener
- Set this class to implement the user interface to be shown to the end user. Offerings should set this value to when the platform is launched in non-headless mode and it is expected that the end user will make the trust decisions for untrusted code being downloaded by the provisioning system.
- EXPIRED_SIGNATURE_POLICY
- This preference setting value defines the default behavior for a given IVerificationListener implementation when it encounters a jar file, which is signed, but the certificate used to sign the jar file has expired.
- UNSIGNED_PLUGIN_POLICY
- This preference setting value defines the default behavior for a given IVerificationListener implementation when it encounters a jar file that is unsigned.
- UNTRUSTED_SIGNATURE_POLICY
- This setting value defines the default behavior for a given IVerificationListener implementation when it encounters a jar file that is untrusted.
Setting the above policy values to ALLOW or DENY will be interpreted by the IVerification Listener implementation to allow or deny provisioning of features. However, the policy setting of PROMPT will be interpreted by an IVerificationListener implementation based on whether the platform is running in headless mode. For example, the PromptVerificationListener will prompt the users to make the necessary trust decisions while the DefaultVerificationListener treats PROMPT as DENY so that untrusted code never gets provisioned.
For additional information regarding IVerificationListeners and
other public APIs related to signed plug-ins, see the Eclipse Javadoc for the package org.eclipse.update.core.
Plug-ins can be signed using either Eclipse tools or the Java keytool.
When a signed plugin is installed, it is verified using certificates in the media kit keystore and the IBM keystore. The IBM keystore contains public IBM certificates, which are used to verify IBM signed plug-ins. The media kit keystore contains public certificates used to verify third party plug-ins.
If a third party wishes to provide public certificates (including self-signed certificates) to be used to verify plug-ins at install
time, use the following procedure:
- Create the following keystore file with no password (using
keytool or ikeyman if available). Note: Use the keytool (or ikeyman if available) that is included with the target install JVM. This can also be done programmatically with the target install VM.
Use the following filename for the given target install VM:
Desktop EE VM (default):
.keystore.jks.J9.install
J2SE VM:
.keystore.JCEKS.IBM_J9_VM.install
Macintosh JVM:
.keystore.JCEKS.Java_HotSpot(TM)_Client_VM.install
- Use keytool (or ikeyman if available) to add certificates to the newly created keystore.
- Place the keystore file in the desktop\install\deploy directory of the Expeditor install.
Note:
If supporting more than one target install VM, repeat steps 1-3 using a different VM's keytool (or ikeyman) and a different keystore file name. The deploy directory can support multiple keystores.
The Web Container provides a runtime environment for Web applications in which Web applications can be run both disconnected and connected.
The default configuration for the web container listens only for HTTP requests received on localhost on a port dynamically selected during platform startup. If you need to make changes to this configuration, refer to the contents of this
section.
The following properties are available for configuration of the web container.
Table 3. Java system properties | Option | Default | Description | Java System Property |
| HTTP Port | 0 | Defines the port or list of ports used by the HTTP port listener to listen for requests. A value of 0 indicates that a port will be selected at random when the platform starts. A value of -1 indicates that no listener will be started to listen for HTTP requests. | com.ibm.pvc.webcontainer.port |
| HTTPS Port | -1 |
Defines the port or list of ports used by the HTTPS port listener to listen for requests. A value of 0 indicates that a port will be selected at random when the platform starts. A value of -1 indicates that no listener will be started to listen for HTTP requests. | com.ibm.pvc.webcontainer.port.secure |
| HTTP Timeout | 60 sec | Defines the value used for socket time-outs | com.ibm.pvc.webcontainer.http.timeout |
| HTTP Address | localhost | Defines the host address(es) that the Web Container listens on. If this property is defined then the Web Container will only listen for requests that come through this IP address(es). The special value ALL indicates all available IP addresses on the device will be used. The value of this property may be a resolved name or IP address (for example, www.ibm.com, 192.168.0.101,
localhost). | com.ibm.pvc.webcontainer.http.address
Note: Deprecated in Expeditor 6.2. Use the virtualhost configuration file to define Web application access rules |
| Min HTTP Threads | 4 | Defines the minimum number of threads to be started to listen for requests. Valid values are in the range of 0 to 63. | com.ibm.pvc.webcontainer.http.minThreads |
| Max HTTP Threads | 20 | Defines the maximum number of threads to be started to listen for requests. Valid values are in the range of 2 to 63. | com.ibm.pvc.webcontainer.http.maxThreads |
| Max Keep Alive Connections | 20 | Use this property to specify the maximum number of concurrent keep alive (persistent) connections across all HTTP transports. | com.ibm.pvc.webcontainer.http.maxKeepAliveConnections |
| Max Keep Alive Requests | 50 | Use this property to specify the maximum number of requests that can be processed on a single keep alive connection. | com.ibm.pvc.webcontainer.http.maxKeepAliveRequests |
| Keep Alive Timeout | 20 sec | Use this property to specify the maximum number of seconds to wait for the next request on a keep alive connection. | com.ibm.pvc.webcontainer.http.keepAliveTimout |
| MIME Mapping configuration file | mimemap.properties | Specifies the MIME mapping file to be used by the Web Container.
By default, the Web Container will use the mimemap.properties file that is located in the Web Container plug-in directory. | com.ibm.pvc.webcontainer.mimemap.configfile |
| Encoding configuration file | encoding.properties | Specifies the character set encoding file to be used by the Web Container.
By default the Web Container will use the encoding.properties file located in the Web Container plug-in directory. Users can use this property to supply their own character set encoding file.
Users can specify an absolute path or a path relative to the working directory. | com.ibm.pvc.webcontainer.encoding.configfile |
| Converter configuration file | converter.properties | Specifies the character converters to be used by the Web Container.
By default the Web Container will use the converter.properties file located in the Web Container plug-in directoryUsers can use this property to supply their own character converter file.
Users can specify an absolute path or a path relative to the working directory. | com.ibm.pvc.webcontainer.converters.configfile |
| Virtual host configuration file | N/A | Specifies the location of the virtual host configuration file. This configuration file can be used to control access to web applications registered with the Web Container by port or hostname | com.ibm.pvc.webcontainer.vhost.configfile |
| Global Session Timeout | N/A | Specifies the global session timeout value. This value will override the session timeout setting specified at the application level. Value is an integer and is in minutes. | com.ibm.pvc.webcontainer.http.sessionGlobalTimeout |
| Static File Directory | N/A | Specifies the location of the static files.
The files in this directory can be accessed via a URL using a path relative to the root context "/" | com.ibm.pvc.webcontainer.staticFileDirectory |
If your machine is disconnected from the network (Linux only), then you need to manually add
the following entry to the /etc/hosts file:
127.0.0.1 <your_machine_hostname
This will allow the Web Container to function correctly when you are disconnected from the network.
The Web Container provides administrators with the capability to restrict access to Web applications to a specific port or list of ports. Refer to this section if you need to restrict access to certain Web applications.
Use the com.ibm.pvc.webcontainer.vhost.configfile system property to specify a configuration file that assigns a port(s) to Web applications. For example, if Web application A is mapped to port 80, then it can only be accessed from port 80; accessing Web application A from any other port will result in a 404 error.
The configuration file contains a series of application-port mappings. An application can be mapped to a port or a list of ports. An example
configuration file would look like this:
/foo=localhost:80
/foo2=*:80
/foo3=*:*
/foo4=localhost:[80,8777,9999] /foo5=[80,8777,8999] /foo6=80
/foo7=xyz.com:*
/foo8=xyz.com:8777
/foo9=xyz.com:[80,8777]
- foo is accessible only from localhost on port 80
- foo2 is accessible from any external machine but only on port 80
- foo3 is accessible from any external machine on any port
- foo4 is accessible only from localhost on ports 80, 8777 and 9999
- foo5 is accessible only from localhost on ports 80,8777 and 8999
- foo6 is accessible only from localhost on port 80
- foo7 is accessible from any external machine on any port IF the hostname of the machine the web application is hosted on is xyz.com
- foo8 is accessible from any external machine on port 8777 IF the hostname of the machine the web application is hosted on xyz.com
- foo9 is accessible from any external machine on ports 80 and 8777 IF the hostname of the machine the web application is hosted on is xyz.com
The following set of rules apply for the Virtual Host configuration
file:
- To protect a servlet, non-J2EE Web application (like WebServices dispatcher servlet), you will need to specify the servlet name similar to what you would do for a J2EE Web application that has a context root (for example, to secure the Web services servlet ws specify /ws=[9000, 9050] if you want to restrict Web services access to ports 9000 and 9050).
Channel Framework Configuration File - This file should be used to configure channels, channel chains and channel factories. Refer to Using the Channel Framework configuration file for more information on the steps involved in configuring the channel framework using system properties and also an example configuration file.
If the value of the com.ibm.pvc.webcontainer.port Java system property is equal to 0, then the Web Container selects a random port when the Web Container plug-in is started. This allows for multiple instances of the Web Container to be running at the same time on the same machine.
Lotus Expeditor Client uses a dynamic port by default.
Note:
This port will be broadcast to all plug-ins that register a com.ibm.pvc.webcontainer.listener.HttpSettingListener service. When using a dynamic port, the range of the port value is 1-65535. When specifying the value of a Web Container port, administrators must make sure that there is no conflict with any other server on the system. For example, administrators should be careful when setting the Web Container port to 80 since port 80 is frequently used by HTTP servers.
When using the Lotus Expeditor on the desktop, the secure hypertext transfer protocol (HTTPS)
is a communications protocol used to encrypt data between computers over the Web.
HTTPS uses a Secure Socket Layer (SSL) to transfer encrypted HTTP data. Refer to Configuring SSL for the Web Container for the required steps.
Third-party bundles can use the com.ibm.pvc.webcontainer.service.SocketConfigService service to dynamically configure the Web Container ports at run time. Review this section if you need to dynamically configure the Web Container ports at run time.
Bundles should use a ServiceTracker to track the com.ibm.pvc.webcontainer.service.SocketConfigService object.
The following example shows how to invoke the com.ibm.pvc.webcontainer.service.SocketConfigService
startTransport and stopTransport methods from a bundle's ServiceTracker.
import com.ibm.pvc.webcontainer.service.SocketConfigService; import com.ibm.pvc.webcontainer.service.SocketConfigException; ...
private BundleContext context = null; private ServerSocket socket = null;
public MyServiceTracker(BundleContext bc) {
context = bc; }
public Object addingService(ServiceReference reference) {
SocketConfigService service = (SocketConfigService) context.getService(reference);
if(service != null) {
try {
create a ServerSocket
socket = new ServerSocket(9999);
configure Web Container to listen on port 9999
service.startTransport(socket);
...
} catch (SocketConfigException e) {
handle exception
}
...
}
... }
public void removedService(ServiceReference reference, Object service) {
if(service != null) {
shutdown transport
service.stopTransport(socket);
} } The Channel Framework Architecture (CFA) is a highly flexible and scalable solution for client and server transports and provides common networking services, protocols, and I/O operations for the Expeditor Web Container.
Taking a protocol stack abstraction to building a transport, individual channels within this architecture may be thought of as protocol layers in a network stack. This architecture provides extended plugability along the entire chain of events involved in handling communication with the server and processing of the content of the communication at various steps in the server.
The CFA defines a set of interfaces that can be used to implement two main types of objects, channels and channel chains. Channels are used to transport data between the network and the Web Container server component. Channels are an encapsulation of the logic for processing some part of a data stream or for interfacing with a component. The data stream may be part of an inbound request to an application server or an outbound request from an application server. Channel chains consist of a set of channels that are linked together and used to transport data from the network to a component or from a component to the network. By defining a standard mechanism for combining channels, it becomes possible to plug in custom channels that support requirements unique to a particular customer or environment.
In the CFA, a component that is at the beginning or the end of a channel chain is known as the channel framework user (CFU). In an inbound channel chain, the request originates at the network and ends at the CFU. In an outbound channel chain, the request originates at the CFU and ends at the network. The Expeditor Web Container is a CFU. CFUs may have many inbound channel chains leading to them and many outbound channel chains leading from them.
Types of channels
Channels are classified into the following types:
- Connector channels are those channels closest to the network interface. A connector channel is the lowest channel in the channel protocol stack. An example of a connector channel is a TCP (Transmission Control Protocol) channel.
- Protocol channels are responsible for abstracting information that is transferred through them. When reading information, a protocol channel will generally parse the information into high-level structures that map to constructs which are specific to the protocol. When writing information, a protocol channel will take information provided in protocol-specific structures and map it to the structures needed by the channel below it in the stack. There may be zero or more protocol channels in the link between the connector channel and the application channel. An example of a protocol channel would be an HTTP (HyperText Transfer Protocol) channel.
- Application / Acceptor channels are the top-level channels. These channels are generally built on top of specific protocols in order to draw the correct data out of them. An example of an application channels is the one included for the Expeditor Web Container.
- Filter channels can only appear in the interior of a chain. Filter channels do not perform protocol conversions, and thus should accept and emit the same data type. Filter channels may be used for such applications as logging, SLA enforcement, etc.
The Channel Framework service is responsible for managing the channel framework lifecycle. It is responsible for the correct behavior of channels and channel chains at server startup and shutdown.
The following steps describe how to enable the Web Container's Channel Framework using Eclipse extensions.
Create an Eclipse plug-in and specify the Eclipse extensions in the plug-in's plugin.xml descriptor. A sample plugin.xml descriptor file looks like this
<?xml version="1.0" encoding="UTF-8"?
<?eclipse version="3.0"?
<plugin
<!-- Register the TCP connector channels --
<extension point="com.ibm.rcp.channelframework.service.channel"
<channel name="TCP_OUT" factory="com.ibm.ws.tcp.channel.impl.TCPChannelFactory"
</channel
</extension
<extension point="com.ibm.rcp.channelframework.service.channel"
<channel name="TCP_IN" factory="com.ibm.ws.tcp.channel.impl.TCPChannelFactory"
<property name="hostname"
value="localhost"/
<property name="port"
value="11111"/
</channel
</extension
<extension point="com.ibm.rcp.channelframework.service.channel"
<channel name="TCP_IN_2"
factory="com.ibm.ws.tcp.channel.impl.TCPChannelFactory"
<property name="hostname"
value="*"/
<property name="port"
value="9898"/
</channel
</extension
<extension point="com.ibm.rcp.channelframework.service.channel"
<channel name="TCP_IN_3"
factory="com.ibm.ws.tcp.channel.impl.TCPChannelFactory"
<property name="hostname"
value="localhost"/
<property name="port"
value="15000"/
</channel
</extension
<extension point="com.ibm.rcp.channelframework.service.channel"
<channel name="TCP_IN_4"
factory="com.ibm.ws.tcp.channel.impl.TCPChannelFactory"
<property name="hostname"
value="*"/
<property name="port"
value="5061"/
</channel
</extension
<!-- Register the HTTP protocol channels --
<extension point="com.ibm.rcp.channelframework.service.channel"
<channel name="HTTP_IN"
factory="com.ibm.ws.http.channel.inbound.impl.HttpInboundChannelFactory"
<property name="persistTimeout" value="5000" /
<property name="readTimeout" value="5000" /
<property name="writeTimeout" value="5000" /
<property name="maxKeepAliveRequests" value="30" /
<property name="keepAliveEnabled" value="true" /
</channel
</extension
<extension point="com.ibm.rcp.channelframework.service.channel"
<channel name="HTTP_OUT"
factory="com.ibm.ws.http.channel.outbound.impl.HttpOutboundChannelFactory"/
</extension
<!-- Register the SSL channels --
<extension point="com.ibm.rcp.channelframework.service.channel"
<channel name="SSL_2"
factory="com.ibm.ws.ssl.channel.impl.WSSSLChannelFactory"
</channel
</extension
<!-- Register the UDP connector channels --
<extension point="com.ibm.rcp.channelframework.service.channel"
<channel name="UDP"
factory="com.ibm.ws.udp.channel.impl.UDPChannelFactory"/
</extension
<!-- Register the Web Container application channel --
<extension point="com.ibm.rcp.channelframework.service.channel"
<channel name="WC_APP"
factory="com.ibm.ws.webcontainer.channel.WCChannelFactory"/
</extension
<!-- Register the test channel chains --
<extension point="com.ibm.rcp.channelframework.service.chain"
<chain name="TEST INBOUND CHAIN"
type="INBOUND"
group="com.ibm.pvc.webcontainer"
<channel name="TCP_IN" order="0" type="CONNECTOR"/
<channel name="HTTP_IN" order="1" type="PROTOCOL"/
<channel name="WC_APP" order="2" type="ACCEPTOR"/
</chain
</extension
<extension point="com.ibm.rcp.channelframework.service.chain"
<chain name="TEST INBOUND CHAIN 2"
type="INBOUND"
group="com.ibm.pvc.webcontainer"
<channel name="TCP_IN_2" order="0" type="CONNECTOR"/
<channel name="HTTP_IN" order="1" type="PROTOCOL"/
<channel name="WC_APP" order="2" type="ACCEPTOR"/
</chain
</extension
<extension point="com.ibm.rcp.channelframework.service.chain"
<chain name="TEST INBOUND CHAIN 3"
type="INBOUND"
group="com.ibm.pvc.webcontainer"
<channel name="TCP_IN_3" order="0" type="CONNECTOR"/
<channel name="SSL_2" order="1" type="PROTOCOL"/
<channel name="HTTP_IN" order="2" type="PROTOCOL"/
<channel name="WC_APP" order="3" type="ACCEPTOR"/
</chain
</extension
</plugin
- All the SSL properties should continue to be specified in the SSL configuration file of the Web Container. The location of this file is specified using the com.ibm.pvc.webcontainer.ssl.configfile system property. (refer to Configuring SSL for the Web Container).
Note:
The SSL channel is ONLY supported on J2SE. It does not work on DesktopEE.
Channels, channel factories and channel chains can be configured using the system properties in this section. All system properties must be specified in the Channel Framework configuration file. Refer to Using the Channel Framework configuration file - the location of this file is specified using the com.ibm.rcp.channelframework.configfile system property
Table 4. TCP Channel properties | Option |
Default | Description | Java System Property |
| Factory | TCP_FACTORY (both Inbound and Outbound) | Responsible for creating or finding a channel. | com.ibm.rcp.channelframework.channel.factory.<TCP_channel_name |
| Hostname | N/A | Host name on which the inbound channel will listen. | com.ibm.rcp.channelframework.channel.hostname.<TCP_channel_name |
| Port | N/A | Port on which the inbound channel will listen | com.ibm.rcp.channelframework.channel.port.<TCP_channel_name |
| Max Open Connections |
Min - 1
Max - 20000 | The maximum number of connections allowed for an inbound channel | com.ibm.rcp.channelframework.channel.port.<TCP_channel_name |
Table 5. HTTP Channel properties | Option | Default | Description | Java System Property |
| Factory |
Inbound: HTTP_IN_FACTORY
Outbound: HTTP_OUT_FACTORY | Responsible for creating or finding a channel. | com.ibm.rcp.channelframework.channel.factory.<HTTP_channel_name |
| Persist timeout | 30000 | Time to wait for additional requests on a socket (ms) | com.ibm.rcp.channelframework.channel.persistTimeout.
<HTTP_channel_name |
| Read timeout | 60000 | Time to wait for a read to complete (ms) | com.ibm.rcp.channelframework.channel.readTimeout.
<HTTP_channel_name |
| Write timeout | 60000 | Time to wait for a write to complete (ms) | com.ibm.rcp.channelframework.channel.writeTimeout.
<HTTP_channel_name |
| Maximum requests per connection | 100 | Maximum requests allowed on a single HTTP connection | com.ibm.rcp.channelframework.channel.maxKeepAliveRequests.
<HTTP_channel_name |
| Keep-alive connection | True | Controls whether or not to default to a persistent connection as opposed to a connection that will close after one request/response exchange. | com.ibm.rcp.channelframework.channel.keepAliveEnabled.
<HTTP_channel_ name |
Table 6. SSL Channel properties | Option | Default | Description |
Java System Property |
| Factory | SSL_FACTORY (both Inbound and Outbound) | Responsible for creating or finding a channel. | com.ibm.rcp.channelframework.channel.factory.<SSL_channel_name |
| Protocol | SSL | Optional. Specifies the protocol to use. | com.ibm.ssl.protocol. <SSL_channel_name |
| Keystore type | JKS | Optional. Specifies the type of keyStore to use. | com.ibm.ssl.keyStoreType.<SSL_channel_name |
| Keystore location | N/A | Mandatory. Specifies the location of keyStore on the file system. | com.ibm.ssl.keyStore.<SSL_channel_name |
| Keystore password | N/A | Mandatory. Specifies the password to open the keyStore. | com.ibm.ssl.keyStorePassword.<SSL_channel_name |
| Truststore type | Fully-qualified path to file on the filesystem. | Mandatory. Specifies the type of trustStore | com.ibm.ssl.trustStoreType.<SSL_channel_name |
| Truststore location | Plain-text password for keyStore | Mandatory. Specifies the location of trustStore on the file system. | com.ibm.ssl.trustStore.<SSL_channel_name |
| Truststore password | Plain-text password for trustStore | Mandatory. Specifies the password to open the trustStore. | com.ibm.ssl.trustStorePassword.<SSL_channel_name |
| Client authentication required | false | Mandatory. Specifies whether or not the client application requires authentication. | com.ibm.ssl.clientAuthentication.<SSL_channel_name |
| Enabled cipher suite list | N/A | Mandatory. Enabled cipher suites. | com.ibm.ssl.enabledCipherSuites.<SSL_channel_name |
Table 7. Webcontainer Application Channel properties | Option | Default | Description | Java System Property |
| Factory | WC_APP_FACTORY (both Inbound and Outbound) | Responsible for creating or finding a channel. | com.ibm.rcp.channelframework.channel.factory.
<WC_APP_channel_name |
Table 8. Channel chain properties | Option | Default | Description | Java System Property |
| Chain name | N/A | The name of the chain. | com.ibm.rcp.channelframework.chain.name.<chain_id |
| Chain group |
com.ibm.pvc.webcontainer. | The name of the group the chain belongs to. Should be set to the CFU identifier (for example, com.ibm.pvc.webcontainer). | com.ibm.rcp.channelframework.chain.group.<chain_id |
| Channel list | N/A | List of channels in the chain (separated
by ':' and specified in order starting with connector channel. | com.ibm.rcp.channelframework.chain.channelList.<chain_id |
| Chain type | N/A | The type of chain (inbound or outbound) | com.ibm.rcp.channelframework.chain.type.<chain_id |
Table 9. Channel Factory properties | Option | Default | Description | Java System Property |
| Factory class | N/A | The factory class. Must be a valid classname, class package must be on the bundle classpath |
com.ibm.rcp.channelframework.factory.class.<factory_name |
The following steps describe how to configure the Web Container's Channel Framework support.
Create the Channel Framework configuration file. Refer to Enabling and configuring the Channel Framework using system properties for more information on properties that can be specified or configured. The location of the Channel Framework configuration file is specified using the com.ibm.rcp.channelframework.configfile property.
The sample Channel Framework configuration file below shows
how to configure two separate HTTP / HTTP channel stacks:
# factory properties com.ibm.rcp.channelframework.factory.class.HTTP_TEST_FACTORY=
com.ibm.ws.http.channel.inbound.impl.HttpInboundChannelFactory com.ibm.rcp.channelframework.factory.class.TCP_TEST_FACTORY=
com.ibm.ws.tcp.channel.impl.TCPChannelFactory com.ibm.rcp.channelframework.factory.class.WC_TEST_FACTORY=
com.ibm.ws.webcontainer.channel.WCChannelFactory com.ibm.rcp.channelframework.factory.class.SSL_TEST_FACTORY=
com.ibm.ws.ssl.channel.impl.WSSSLChannelFactory
- channel properties for TCP channel(s) com.ibm.rcp.channelframework.channel.factory.TCP_TEST=TCP_TEST_FACTORY com.ibm.rcp.channelframework.channel.port.TCP_TEST=9999 com.ibm.rcp.channelframework.channel.hostname.TCP_TEST=localhost com.ibm.rcp.channelframework.channel.factory.TCP_TEST_2=TCP_TEST_FACTORY com.ibm.rcp.channelframework.channel.port.TCP_TEST_2=12222 com.ibm.rcp.channelframework.channel.hostname.TCP_TEST_2=localhost
- channel properties for HTTP channel(s) com.ibm.rcp.channelframework.channel.factory.HTTP_TEST=HTTP_TEST_FACTORY com.ibm.rcp.channelframework.channel.persistTimeout.HTTP_TEST=7500 com.ibm.rcp.channelframework.channel.readTimeout.HTTP_TEST=7500 com.ibm.rcp.channelframework.channel.writeTimeout.HTTP_TEST=7500 com.ibm.rcp.channelframework.channel.maxKeepAliveRequests.HTTP_TEST=7500 com.ibm.rcp.channelframework.channel.keepAliveEnabled.HTTP_TEST=true com.ibm.rcp.channelframework.channel.factory.HTTP_TEST_2=HTTP_TEST_FACTORY com.ibm.rcp.channelframework.channel.persistTimeout.HTTP_TEST_2=7500 com.ibm.rcp.channelframework.channel.readTimeout.HTTP_TEST_2=7500 com.ibm.rcp.channelframework.channel.writeTimeout.HTTP_TEST_2=7500 com.ibm.rcp.channelframework.channel.maxKeepAliveRequests.HTTP_TEST_2=7500 com.ibm.rcp.channelframework.channel.keepAliveEnabled.HTTP_TEST_2=true
- channel properties for SSL channel(s) (remaining SSL properties including # keystore, truststore locations are defined in the SSL config file) com.ibm.rcp.channelframework.channel.factory.SSL_TEST=SSL_TEST_FACTORY
- channel properties for Webcontainer application channel(s) com.ibm.rcp.channelframework.channel.factory.WC_TEST=WC_TEST_FACTORY com.ibm.rcp.channelframework.channel.factory.WC_TEST_2=WC_TEST_FACTORY
- chain properties com.ibm.rcp.channelframework.chain.name.1=TEST HTTP CHAIN com.ibm.rcp.channelframework.chain.group.1=com.ibm.pvc.webcontainer
com.ibm.rcp.channelframework.chain.channelList.1=TCP_TEST:HTTP_TEST:WC_TEST com.ibm.rcp.channelframework.chain.type.1=INBOUND
com.ibm.rcp.channelframework.chain.name.2=TEST HTTPS CHAIN com.ibm.rcp.channelframework.chain.group.2=com.ibm.pvc.webcontainer com.ibm.rcp.channelframework.chain.channelList.2=
TCP_TEST_2:SSL_TEST:HTTP_TEST_2:WC_TEST_2 com.ibm.rcp.channelframework.chain.type.2=INBOUND
- All the SSL properties should continue to be specified in the SSL configuration file of the Web Container. The location of this file is specified using the com.ibm.pvc.webcontainer.ssl.configfile system property. (refer to Configuring SSL for the Web Container).
- Launch the Lotus Expeditor Runtime. The Web Container will then proceed to initialize the Channel Framework provider and use the provider to configure each channel specified in the configuration file and subsequently enable the channel chains also specified in the configuration file. All SSL properties will also be provided to the Channel Framework provider.
- Access any registered and active web application on the specified ports.
The Portlet Container provides a runtime environment for JSR 168 portlet applications in which JSR 168 portlets can be instantiated, used and finally destroyed.
The Portlet Container allows users and developers alike to access and run portlet applications either disconnected (offline) or connected (online).
No configuration of the Portlet Container is necessary.
The Portlet Container is an additional extension processor which leverages Web Container functionality and reuses the Web Container settings (server address and server port, for example). See Configuring the Web Container for more information.
You can change the images and style sheet used by the portlet container when rendering portlets. See Configuring the Portlet Container branding for more information.
Previous Page |
Next Page
ile system property. (refer to
Configuring SSL for the Web Container).
Launch the Lotus Expeditor Runtime. The Web Container will then proceed to initialize the Channel Framework provider and use the provider to configure each channel specified in the configuration file and subsequently enable the channel chains also specified in the configuration file. All SSL properties will also be provided to the Channel Framework provider. Access any registered and active web application on the specified ports.
The Portlet Container provides a runtime environment for JSR 168 portlet applications in which JSR 168 portlets can be instantiated, used and finally destroyed.
The Portlet Container allows users and developers alike to access and run portlet applications either disconnected (offline) or connected (online).
No configuration of the Portlet Container is necessary.
The Portlet Container is an additional extension processor which leverages Web Container functionality and reuses the Web Container settings (server address and server port, for example). See Configuring the Web Container for more information.
You can change the images and style sheet used by the portlet container when rendering portlets. See Configuring the Portlet Container branding for more information.
Previous Page |
Next Page
/a>).
Launch the Lotus Expeditor Runtime. The Web Container will then proceed to initialize the Channel Framework provider and use the provider to configure each channel specified in the configuration file and subsequently enable the channel chains also specified in the configuration file. All SSL properties will also be provided to the Channel Framework provider. Access any registered and active web application on the specified ports.
The Portlet Container provides a runtime environment for JSR 168 portlet applications in which JSR 168 portlets can be instantiated, used and finally destroyed.
The Portlet Container allows users and developers alike to access and run portlet applications either disconnected (offline) or connected (online).
No configuration of the Portlet Container is necessary.
The Portlet Container is an additional extension processor which leverages Web Container functionality and reuses the Web Container settings (server address and server port, for example). See Configuring the Web Container for more information.
You can change the images and style sheet used by the portlet container when rendering portlets. See Configuring the Portlet Container branding for more information.
Previous Page |
Next Page