Troubleshooting
Problem
Manually merging plugin-cfg.xml files from multiple nodes for releases of IBM® WebSphere® Application Server releases prior to 7.0, or refining the output of the merge tools in later releases.
Resolving The Problem
Merging two plugin-cfg.xml files
NOTE: The instruction in this technote is for versions 6.1 or earlier or where automatic plugin-cfg.xml merging does not produce the desired result.
Version 7.0 Fix Pack 7.0.0.17 ships a merge tool PluginCfgMerge. If your WebSphere Application Server is version 7.0 or later, please apply the latest Fix Pack and use the merge tool to merge two plug-in configuration files.
Note: Anytime you merge two plugin-cfg.xml files, you should take time to review all properties that would be considered global to the merged xml (i.e.. refreshInterval or esiEnable). If you see disparaging settings between the two, you will need to evaluate which setting best suites the environment under the new xml.
Warning: As you make changes to the WAS environment that require a new plug-in generation, you will need to remerge the files.
NOTE: The instruction in this technote is for versions 6.1 or earlier or where automatic plugin-cfg.xml merging does not produce the desired result.
Version 7.0 Fix Pack 7.0.0.17 ships a merge tool PluginCfgMerge. If your WebSphere Application Server is version 7.0 or later, please apply the latest Fix Pack and use the merge tool to merge two plug-in configuration files.
- The
<Config>tag is the root element in the plugin-cfg.xml file. There should be only one<Config>element in the merged file.
- Copy the
<Log>element from any of the two merging files, and modify the Path/Name, if required.
- Copy properties like esiEnable and esiMaxCacheSize from any of the two merging files.
- Copy all the
<VirtualHostGroup>elements from both the files.
The VirtualHostGroup name must be unique; if the names are not unique and the VirtualHosts differ, prepend the node name to the VirtualHostGroup name to make it unique.
The contents of each VirtualHostGroup, the individual VirtualHost tags, do NOT need be unique across all VirtualHostGroups. The Plug-in will iterate across as many matching VirtualHostGroup entries as needed to find one that is reachable from a <Route> with a matching <URIGroup>.
If there are identical VirtualHostGroup sections in the merged plugin-cfg.xml, consolidate them into one updating later references within the <Route> tag.
When serving a request, the plug-in searches for the VirtualHost and URI, so the combination of these must be unique. If it is not, you receive unexpected results. - Copy all
<ServerCluster>elements from both the files. Normally they are unique because the host name is included in the name; however, make the names unique if necessary. - Server Name must be unique across all clusters. From WebSphere Application Server version 5.0.1 or higher, host or node name is included in server name. If you are at version 5.0, then you might have to prepend the host name to the server name to make it unique.
- In the
<Transport>element, the properties keyring and stashfile should use the same location for all the Application Servers in the merged file. Caution: If your application server's require client authentication, you may need to merge the personal certificates into one keyring.
- Copy all the
<URIGroup>elements from both nodes. Normally these are unique because a server cluster name is included; however, make the names unique if necessary.
- Copy all the
<Route>elements and apply any changes that you have made to the names of VirtualHostGroup, ServerCluster or URIGroup.
- Make sure that resources are unambiguously specified. Especially when merging two servers containing applications with similar context-root. You may want to consider utilizing virtual host aliases in Administrative Console to unambiguously route the requests to specific application server.
- Copy the
<RequestMetrics>element from any of the two merging files.
- Make sure that the Web server points to the new plugin-cfg.xml file.
Note: Anytime you merge two plugin-cfg.xml files, you should take time to review all properties that would be considered global to the merged xml (i.e.. refreshInterval or esiEnable). If you see disparaging settings between the two, you will need to evaluate which setting best suites the environment under the new xml.
Warning: As you make changes to the WAS environment that require a new plug-in generation, you will need to remerge the files.
[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Plug-in","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"6.1;6.0;5.1","Edition":"Base;Network Deployment","Line of Business":{"code":"LOB45","label":"Automation"}},{"Product":{"code":"SSNVBF","label":"Runtimes for Java Technology"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Java SDK","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]
Was this topic helpful?
Document Information
Modified date:
08 September 2020
UID
swg21139573