Regenerating Web server plug-in configurationsAt times, you might need to instruct the WebSphere Web server plug-in to regenerate its configuration. You should regenerate the plug-in configuration after, for example, installing or removing an enterprise application, adding or removing servlets and mappings from a particular application, or changing the configuration for the plug-in, a virtual host or a transport. Failure to regenerate the plug-in after introducing a new application likely results in a 404 File Not Found error when a user tries to access the new web application (.war).
CAUTION: Regenerating the plug-in configuration can overwrite manual configuration changes that you might want to preserve. Before performing this task, understand its implications as described in Configuring Web server plug-ins.
To regenerate the plug-in configuration, you can either use the Update Web Server Plug-in Configuration page in the administrative console, or issue the following command$WAS_HOME/bin/GenPluginCfg.sh|bat
Both methods for regenerating the plug-in configuration create a plugin-cfg.xml file in ASCII format, which is the proper format for execution in a distributed environment.
To use the Update Web Server Plug-in Configuration page in the administrative console:
- Go to the Update Web Server Plug-in page. Click Environment > Update Web Server Plug-in in the console navigation tree.
- Click OK.
- You might need to stop the appserver and then start the appserver again before the changes to the plug-in configuration go into effect.
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 you 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 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 you are frequently changing settings in the administrative console, it is recommended that you 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.
- Command line...
At a command prompt, change to the DeploymentManager/bin directory and type on the machine where the Deployment Manager is installed. This creates or updates the plugin-cfg.xml file, and changes all of the directories in the plugin-cfg.xml file to directories.
For example, issue the following command from the DeploymentManager/bin directoryGenPluginCfg -destination.root "E:\WebSphere\AppServer"GenPluginCfg -destination.root "/WebSphere/V5R0M0/AppServer"
- plugin-cfg.xml file...
Edit the plugin-cfg.xml file, located in the $WAS_HOME/DeploymentManager/config/cells directory, 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 WAS nodes. You can use scripting to perform a node synchronization or use the Network Deployment administrative console to synchronize the nodes.
The Deployment Manager plugin-cfg.xml file can point to the application server directories without any conflict.
See AlsoConfiguring Web server plug-ins
Change the WAS configuration using wsadmin
GenPluginCfg command reference