To plug into the managed settings framework, the back-end management system that populates the Eclipse preference store with the settings for the application must have a corresponding managed settings provider.
A managed settings provider is a plug-in that knows how to pull settings from an associated back-end management system and format them appropriately for the framework to read them. Lotus® Expeditor provides providers for settings specified by the Portal Policy Manager and for settings that are specified in XML files. If your application gets its preference settings from a back-end system other than WebSphere® Portal or an XML file, you can create a custom provider for it. See Adding a managed settings provider
You must configure the file provider associated with settings specified in XML files. For details, see Configuring the XML file provider .
You do not need to configure the provider for the Portal Policy Manager, which is the back-end administrative system used by the WebSphere Portal-administered client. Instead, you must create an account that identifies the WebSphere Portal server and stores authentication information for connecting to it. See Managing accounts
for more information.
Configuring the XML file provider
The XML file provider is responsible for getting the preference settings from an XML file. The file provider needs to have an XML file containing the managed setting data and must know the location of that XML file.
To configure the file provider:
- Format the XML file as follows:
Set the initial location of the XML file in the plugin_customization.ini file using a key of com.ibm.rcp.managedsettings.provider.file/URL.
- It must contain a <ManagedSettings> element that contains one or more <settingGroup> elements. Each <settingGroup> element must contain one or more <setting> elements.
- Each <settingGroup> tag must have the following attributes:
- name – Use the same name as the qualifier (typically plug-in name but can be anything) that its settings are associated with.
- lastModDate – Specify the date using the java.text.SimpleDateFormat format. The syntax is YYYYMMDDThhmmssZ, where YYYY=year, MM=month, DD=day, hh=hours, mm=minutes, ss=seconds. The values to the right of the T are optional.
- Every change to a setting group must be accompanied by a change to the lastModDate attribute or the new values will not be updated. If no lastModDate is specified, the values are always updated, even if they are not new.
- Each <setting> tag must have the following attributes:
- name – Use a name that identifies what the setting does.
- value – Provide a default value for the setting.
- Each <setting> tag may also have the following attributes:
- isLocked – Boolean. The default value is true. If true, the setting is read-only and any changes that a user or application make to the value set by you, the administrator, are prevented or later overwritten. If this attribute is set to false, the administrator's setting is treated as a default value that can be changed.
- overwriteUnlocked - Boolean. The default value is false. By default, a setting that is specified as being unlocked will be treated as a default and will not overwrite any existing value on the client. This is to avoid undoing changes that the user might have legitimately made. However, if this setting is set to true, the unlocked value will be overwritten with this new value even if it means clearing the user's existing value.
- For example:
<settingGroup name="com.ibm.workplace.mail.policy" lastModDate="20060131">
<setting name="alwaysEncryptEmail" value="true" isLocked="true"/>
<setting name="saveCopyinSentFolder" value="false" isLocked="false"/>
<settingGroup name="desktop_settings" lastModDate="20060131">
<setting name="logOffAfter" value="30" isLocked="true"/>
<setting name="autoSaveAfterNMinutes" value="5" isLocked="true"/>
- See the com.ibm.rcp.managedsetttings.provider.file plugin to see the schema.
If you would like to subsequently change the URL for the file provider, you may update the existing XML file to add a new setting group of com.ibm.rcp.managedsettings.provider.file and a setting of URL. The next update will run on the existing URL, but the update after that will run with the new URL. If the new URL is unreachable at the time of the update that is setting it, it will not be saved and the original URL will continue to be used. The URL will not be changed until it is updated at a time that the URL is reachable.
You can update the plugin_customization.ini file in the install/deploy/ directory on a CD-structure or the one provided with the download applet/portlet using the instructions provided with it.
If the XML file is being hosted by an HTTP server on which authentication has been enabled and there is no associated account set up for the server, the user will be prompted for a name and password the first time the provider runs. Since the provider runs in the background, the user is likely to be confused by this. You can prevent the authentication prompt from displaying by including code in the application that creates an account for this URL during its setup. See Managing accounts
for more information.
During communication with the portal, the default policy provider assumes that the portal is configured with the default custom directory. When retrieving updates for the specified user, the default provider uses the default dn
(Distinguished Name) suffix for the default directory.
However, if the portal is configured with a different user directory, the default dn may not work. To provide a directory specific dn
suffix, you can update the plugin_customization.ini file using a key of com.ibm.rcp.managedsettings.provider.portal/dnSuffix
Managed settings allows for the simultaneous use of more than one provider.
For instance, you could specify the setting values for one plug-in in the Portal Policy Manager and for another in the XML file provider. However, the potential exists that the same setting group or qualifier could be defined on both the Portal Policy Managed and in the XML File. This is highly discouraged both because of the ambiguity and for efficiency reasons. If you determine that this is happening, you should fix it as soon as possible. To handle this situation, framework forces the results to be deterministic by using the weight of the provider to determine which setting value is applied. The lowest weight "wins". You can determine the default weight of the providers by looking in the ManagedSettingProvider extension point in their plugin.xml files. The default weight of the file provider is set to 300. The default weight of the Portal provider is 200. If necessary, you can change the weight by creating a managed setting for it, using a qualifier of com.ibm.rcp.managedsettings and a setting name of <provider_id (usually plug-in ID)>-weight
Parent topic: Configuring managed settings: XPD621