PLUGINS_ROOT/binPlug-ins configuration
The Plug-ins installation wizard...
- Installs a binary plug-in module and a plug-in configuration file for the Web server
- Creates a Web server definition in the configuration of the appserver.
Configuration flows for WAS ND
The Plug-ins installation wizard resolves all configurations of Web server and WAS to three scenarios:
- remote appserver
- local distributed appserver
- local standalone appserver
The logic implemented in determining which scenario applies to a configuration is shown in the following diagram.
 
Scenario 1. Remote plug-in configuration
The Plug-ins installation wizard does not automatically create a Web server definition within the default distributed profile on a remote machine. The wizard creates the configurewebserver script instead.
The Plug-ins installation wizard configures the Web server to use plugin-cfg.xml that will be maintained on the Web server machine in...
PLUGINS_ROOT/config/webserverThis file requires periodic propagation. Propagation is copying the current plugin-cfg.xml file from the appserver machine to replace...
PLUGINS_ROOT/config/webserver/plugin-cfg.xmlAfter installing the binary plug-in for the local Web server, you do not have to run the script before we can start the appserver and the Web server. However, you do not have the benefits of a Web server definition in the appserver node until you run the script.
Profile type Federation status Creation of Web server definition? Web server already defined in Application Server configuration? Any profile anywhere if we select a remote installation type in the Plug-ins installation wizard N/A By script N/A No default profile detected N/A By script N/A Default unfederated standalone appserver profile with an existing Web server definition Not federated By script Yes Default dmgr profile with no managed nodes N/A By script N/A  
Testing the appserver without a Web server definition:
The following overview shows the procedure for verifying the temporary file...
PLUGINS_ROOT/config/webserver/plugin-cfg.xmlThe Web server communicates with the remote Application Server using the temporary plugin-cfg.xml file.
If the appserver has an HTTP Transport port assignment other than 9082, the test is not successful. Continue to the next section to create the Web server definition on the appserver and complete your test of the configuration.
- Start the Web server with the proper procedure for the Web server. For example, start the IBM HTTP Server from a command line:
./IHS_root/bin/apachectl start
- Start the appserver on the remote machine. Change directories to...
$WP_PROFILE/bin
...and run the startServer command:
./$WP_PROFILE/bin/startServer.sh server1
- Point the browser to...
http://localhost:9082/snoop...to test the internal HTTP transport provided by the appserver.
Point the browser to...
http://Host_name_of_Web_server_machine/snoop...to test the Web server plug-in.
- Verify that both Web addresses display the Snoop Servlet - Request/Client Information page.
 
Completing the installation by configuring a Web server definition:
The configuration is not complete until the Web server definition exists in the configuration of the appserver node. The Web server definition is a central element in the regeneration of a valid plug-in configuration file, plugin-cfg.xml.
- Start the dmgr if we are configuring the deployment manager or a managed node.
- Federate a remote appserver node or custom node now if we are planning to federate the node at some point. If a Web server definition already exists when you federate a node, the definition is lost.
- Create the Web server definition in the appserver. we have two options for a managed node. Use the script option for a deployment manager node without managed nodes.
- Use the admin console of the dmgr to create a Web server definition for a managed node. Go to...
Servers | Web servers | New
...and use the Create new Web server entry wizard to create the Web server definition.
- Run the script to manually create the Web server definition within the configuration of the appserver node:
- Copy the script from...
PLUGINS_ROOT/bin
...to...
remote APP_ROOT/bin
- Open a command window and run the script:
./configurewebserver.sh
The webserverNodeName value in the script is a concatenation of the nick name we have chosen for the web server and the suffix -node. It is automatically created during plug-in installation and cannot be changed. For example, if we named the web server myserver during plug-in installation, the value for the associated Web server definition created after you ran the script would be myserver-node.
If we have enabled security or changed the default JMX connector type, edit the script and include the appropriate parameters.
- Open the admin console of the dmgr if the node is federated. Wait for node synchronization to occur on the managed node and save the changed configuration that includes the new Web server definition. If the remote node is not federated, open the admin console of the appserver and save the changed configuration.
- Copy the current plug-in configuration file, plugin-cfg.xml, in...
$WP_PROFILE/config/cells/cell/nodes/node/servers/webserver
Paste the file on the Web server machine to replace the temporary file...
PLUGINS_ROOT/config/webserver/plugin-cfg.xmlThe IBM HTTP Server supports automatic propagation. Other Web servers require manual propagation.
- Start the Web server with the proper procedure for the Web server.
- Point the browser to...
http://localhost:9082/snoop...to test the internal HTTP transport provided by the appserver. Point the browser to...
http://Host_name_of_Web_server_machine/snoop...to test the Web server plug-in.
- Verify that both Web addresses display the Snoop Servlet - Request/Client Information page.
 
Scenario 2. Local distributed plug-in configuration
The Plug-ins installation wizard does not automatically create a Web server definition within a federated appserver profile. The wizard creates the configurewebserver script instead in...
PLUGINS_ROOT/bin
The Plug-ins installation wizard configures the Web server to use plugin-cfg.xml that will be created within the appserver profile when you run the script. The dmgr regenerates plugin-cfg.xml in...
$WP_PROFILE/config/cells/cell/nodes/node_name/servers/webserver
Regeneration occurs whenever a change occurs in the appserver configuration that affects deployed applications on the managed node.
After installing the binary plug-in for the local Web server, run the script before we can start the Web server. The Web server has already been configured to use plugin-cfg.xml in the appserver configuration. That file does not exist until you run the configurewebserver script.
Profile type Federation status Creation of Web server definition? Web server already defined in Application Server configuration? Default appserver profile Federated By script N/A Default Custom profile Not federated By script N/A Default Custom profile Federated By script N/A Default dmgr profile with a managed node (non-default distributed profile) N/A By script N/A The following overview shows the procedure for completing the configuration and verifying the Web server configuration:
- Start the dmgr.
- If planning to add an appserver node into a deployment manager cell but have not done so yet, federate the node before installing the plug-ins. If the Web server definition exists when you federate the node, the Web server definition is lost when you federate.
- Create the Web server definition in the appserver. we have two options:
- Use the admin console of the dmgr to create a Web server definition for a managed node....
Servers | Web servers | New
Use the Create new Web server entry wizard to create the Web server definition.
- Run the script to manually create the Web server definition within the configuration of the dmgr. Run the script from...
The script can address the dmgr on the same machine. Open a command window to run the appropriate script:
The webserverNodeName value in the script is a concatenation of the nick name we have chosen for the web server and the suffix -node. It is automatically created during plug-in installation and cannot be changed. For example, if we named the web server myserver during plug-in installation, the value for the associated Web server definition created after you ran the script would be myserver-node.
If we have enabled security or changed the default JMX connector type, edit the script and include the appropriate parameters.
...and run the startServer command:
http://localhost:9082/snoop
...to test the internal HTTP transport provided by the appserver. Point the browser to...
http://Host_name_of_Web_server_machine/snoop
...to test the Web server plug-in.
 
The Plug-ins installation wizard creates a Web server definition within the appserver profile.
The Plug-ins installation wizard configures the Web server to use plugin-cfg.xml that is within the appserver profile. The standalone appserver regenerates...
$WP_PROFILE/config/cells/cell/nodes/node/servers/webserver/plugin-cfg.xml
...whenever a change occurs in the appserver configuration that affects deployed applications.
After installing the binary plug-in for the local Web server, we can start the appserver and the Web server.
Suppose created a Web server definition on a standalone appserver and then federate the node. The Web server definition is not federated into the cell because the Web server definition is defined as a separate node in a standalone Application Server. You must recreate the Web server definition on the managed node. See Scenario 2.
Profile type | Federation status | Automatic creation of Web server definition? | Web server already defined in Application Server configuration? |
---|---|---|---|
Application Server | Not federated | Yes | No |
 
An unfederated default standalone appserver that has an existing Web server definition is processed as a remote plug-in configuration.
An existing Web server definition on a standalone appserver causes the Plug-ins installation wizard to follow the remote installation path. A standalone appserver can have just one Web server definition. Specify the same nick name for the Web server to configure a new Web server.
Use plugin-cfg.xml that is within the Web server definition in the configuration of the appserver. Simply click Browse on the appropriate panel in the Plug-ins installation wizard to select the file. This file must exist. Otherwise, the Plug-ins installation wizard displays a warning and prevents you from proceeding until you select an existing file. The Web server is configured to use this existing plugin-cfg.xml file.
See Scenario 1 for a description of this type of node.
 
A federated default standalone Application Server is processed as a local distributed plug-in configuration. See Scenario 2 for a description of this type of node.
 
The following overview shows the procedure for verifying the Web server configuration after installing the binary plug-in module:
...and run the startServer command:
Open the admin console and save the changed configuration.
http://localhost:9082/snoop
...to test the internal HTTP transport provided by the appserver.
Point the browser to...
http://Host_name_of_Web_server_machine/snoop
...to test the Web server plug-in.
 
Three scenarios exist for Web server plug-ins for WAS. Each scenario revolves around a unique location for the plug-in configuration file, plugin-cfg.xml.
The appserver generates the plug-in configuration file. The purpose of the file is to publish the location of all of the appserver elements that are relevant to a Web server. Such elements include applications, virtual hosts for serving applications, clusters, and cluster members, for example.
If the Web server cannot get to the file on the appserver machine, take the file to the Web server. That process is called propagation. Propagation is reserved for the remote plug-in configuration scenario, which is Scenario 1 in this topic.
In each of the local scenarios, the Web server can get to plugin-cfg.xml because it is on the same machine as the file. Two local scenarios exist because of two distinct locations for a local plugin-cfg.xml file.
The configuration scheme for V6 of WAS puts the plug-in configuration file in a Web server definition that is either within a Web server node or a managed node. The type of node is the difference between Scenario 2 and Scenario 3 in this topic. All Scenario 2 configurations require the Web server definition to exist within a managed appserver node. All Scenario 3 configurations have the Web server definition within its own Web server node.
Limited management options do not let you create or delete the one Web server definition in the admin console of a standalone appserver. The inability of a standalone appserver to create a Web server definition is the basis for the configuration scripts created by the Web server plug-ins for WAS. Without the scripts you could not create a Web server definition on a standalone appserver node.
The location of plugin-cfg.xml for each configuration described in this topic is shown in the following table:
Scenario | Profile type | Location of plugin-cfg.xml | ||
---|---|---|---|---|
Plugins_ install_ root | profiles_ root: within the managed node | profiles_ root: within the Web server node | ||
1 | Any profile anywhere if we select a remote installation type in the Plug-ins installation wizard | X | ||
No default profile detected | X | |||
Default unfederated (stand-alone) Application Server profile with an existing Web server definition | X | |||
Default dmgr profile with no managed nodes | X | |||
2 | Default appserver profile | X | ||
Default custom profile | X | |||
Default dmgr profile with a managed node (non-default distributed profile) | X | |||
3 | Default appserver profile | X |