Create or update a topology-centric, or global, web server plug-in configuration file
If all of the application servers in a cell use the same web server to route requests for dynamic content, such as servlets, from web applications to application servers, we can create a global web server plug-in configuration file for that cell. The resulting plugin-cfg.xml file is located in the profile_root/config/cells directory.
Deprecated feature: Topology-centric, also called global, configuration is deprecated. Instead, use application-centric configuration, which is more flexible and provides support for dynamic functions such as Intelligent Management.
Topoloy-centric plug-ins are generated from...
-
Environment > Update global web server plug-in configuration
Application-centric plug-ins are generated from...
-
Servers > Server Types > Web Servers > web_server > plug-in properties > Automatically generate plug-in configuration file
For any existing topology-centric configuration, we can update the global plugin-cfg. file using the administrative console or running the GenPluginCfg command for all of the clusters in a cell. However, we must delete config/cells/plugin-cfg.xml before updating the global plugin-cfg.xml file. If we do not delete the config/cells/plugin-cfg.xml file, only the new properties and their values are added to the global plugin-cfg.xml file. Any updates to existing plug-in property values are not added to the global plugin-cfg.xml file.
We must update the global web server plug-in configuration file whenever we perform one of the following actions:
- Change the configuration settings for an application server, cluster, virtual host, or web container transport that is part of that cell.
- Add a new application server, cluster, virtual host, or web container transport to that cell.
To update the configuration settings for a global web server plug-in, we can either use the Update global web server plug-in configuration page in the administrative console, or issue the following command:
- %was_profile_home%/config/cells/GenPluginCfg.sh|bat
Both methods for regenerating the global web server plug-in configuration create a plugin-cfg.xml file in ASCII format.
To use the Update global web server plug-in configuration page in the administrative console:
Tasks
- Click...
-
Environment > Update global web server plug-in configuration
- Click OK to update the plugin-cfg.xml file.
- Optional: Click View or download the current web server plug-in configuration file
to view or download the current version of this file.
We can select this option to:
- View the current version of the file before updating it.
- View the file after it is updated.
- Download a copy of this file to a remote machine.
Regenerating the configuration might take a while to complete. After it finishes, all objects in the administrative cell use their newest settings, which the web server can access. Whether triggered manually or occurring automatically, plug-in regeneration requires about 30 to 60 seconds to complete when the application server is on the same physical machine (node) as the web server. In other cases, it takes more time.
The delay is important because it determines how soon the new plug-in configuration takes effect. Suppose we add a new served path for a servlet, then regenerate the plug-in configurations. The regeneration requires 40 seconds, after which a user should be able to access the servlet by the new served path.
For an HTTP plug-in, the length of the delay is determined by the Refresh Interval attribute of the Config element in the plugin-cfg.xml file. The plug-in polls the disk, or file system, at this interval to see whether the configuration has changed. The default interval is 60 seconds. To regenerate the plug-in configuration requires twice the refresh interval.
In a development environment in which we are frequently changing settings in the administrative console, it is recommended that we set the refresh interval to 3 to 5 seconds.
In a production environment, set a longer refresh interval, perhaps as long as 30 minutes, depending on the frequency of changes.
What to do next
We might need to stop the application servers in the cell and then start the application servers again before the changes to the plug-in configuration go into effect.
If the web server is running on a remote machine, click View or download the current web server plug-in configuration file to download a copy of the plugin-cfg.xml file to a that machine.
When the deployment manager is installed on a machine that is remote from where the product is installed, one of the following solutions must be implemented in order for the plugin-cfg.xml file to retain the application server directory structures, and not assume those of the deployment manager after the plug-in is regenerated and a full synchronization occurs.
- Command line:
At a command prompt, enter to change the DeploymentManager/bin directory and type on the machine where the deployment manager is installed. This command creates or updates the plugin-cfg.xml file, and changes all of the directories in plugin-cfg.xml to app_server_root directories.
- GenPluginCfg -destination.root <app_server_root>
(ZOS) At a command prompt, enter to change to the DeploymentManager/bin directory and type on the machine where the deployment manager is installed. This command creates or updates the plugin-cfg.xml file, and changes all of the directories in the plugin-cfg.xml file to WAS_HOME/AppServer directories.
- GenPluginCfg.sh -destination.root WAS_HOME/AppServer
For example, issue the following command from the DeploymentManager/bin directory.
- GenPluginCfg -destination.root "E:\WebSphere\AppServer"
(ZOS)
- GenPluginCfg -destination.root "/WebSphere/V5R0M0/AppServer"
- plugin-cfg.xml file:
Edit plugin-cfg.xml to point to the correct directory structure for the log file, keyring, and stashfile.
Perform a full synchronization so the plugin-cfg.xml file is replicated in all the nodes. Use scripting or the administrative console to synchronize the nodes in the cell.
The deployment manager plugin-cfg.xml file can point to the application server directories without any conflict.
Subtopics