The Web Server Plug-ins Configuration Tool configures an
application server for a web server type and creates a web server
definition in the configuration of the application server. This overview
shows the different processing paths that the Web Server Plug-ins
Configuration Tool can use.
This topic describes the three ways that the Web
Server Plug-ins Configuration Tool can configure a web server and
create the plugin-cfg.xml file, which is the
plug-in configuration file.
Configuration flows for the Network
Deployment product
The Web Server Plug-ins Configuration
Tool resolves all configurations of a web server and WebSphere® Application
Server to three scenarios: a remote application server, local distributed
application server, and local standalone application server. The logic
implemented in determining which scenario applies to a configuration
is shown in the following diagram.

Legend:
- Installation type?
- The installation type is either remote or local.
When the Web
server and application server are not on the same computer, choose
the remote scenario. When both the web server and application server
are on the same computer, choose the local scenario.
- Profile?
- If the product is installed but the Profile Management Tool has not yet created
a profile, the scenario is considered to be a remote installation.
- Standalone application server with web server definition?
- If the profile is an application server with an existing web server
definition, the installation is considered a remote installation.
- Profile_type?
- The Web Server Plug-ins Configuration Tool can configure only
one profile at a time. These three paths show how processing varies
for different types of profiles.
- Federated?
- If the application server node is federated, the Web Server Plug-ins
Configuration Tool configures the web server definition on the managed
node. This has advantages. Suppose the web server and the managed
node are on a separate machine. The plugin-cfg.xml file
is automatically propagated to the remote node during node synchronization
because the web server definition is part of the node configuration.
- Distributed profile?
- If the deployment manager has a federated custom node (custom
profile), the Web Server Plug-ins Configuration Tool configures the
web server definition on the managed node. This has advantages. Suppose
the web server and the managed node are on a separate machine. The plugin-cfg.xml file
is automatically propagated to the remote node during node synchronization
because the web server definition is part of the node configuration.
Scenario 1. Local standalone plug-in configuration
The
Web Server Plug-ins Configuration Tool creates a web server definition
within the application server profile.
The Web Server Plug-ins
Configuration Tool configures the web server to use the plugin-cfg.xml file
that is within the application server profile. The standalone application
server regenerates the profile_root/config/cells/cell_name/nodes/web_server_name_node/servers/web_server_name/plugin-cfg.xml file
whenever a change occurs in the application server configuration that
affects deployed applications.
After installing the binary
plug-in for the local web server, you can start the application server
and the web server immediately upon completion of the installation.
Suppose
that you create a web server definition on a standalone application
server 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.
Table 1. Configuration that qualifies
for the local standalone application server scenario.
Profile type |
Federation status |
Automatic creation of web server definition? |
Web server already defined in application server
configuration? |
Application server |
Not federated |
Yes |
No |
Redirection to Scenario 3
An unfederated
standalone application server that has an existing web server definition
should be processed as a remote plug-in configuration.
An existing
web server definition on a standalone application server requires
that the Web Server Plug-ins Configuration Tool follow the remote
installation path. A standalone application server can have just one
web server definition.
See Scenario 3 for a description
of this type of node.
Redirection to Scenario 2
A
federated standalone application server should be processed as a local
distributed plug-in configuration. See Scenario 2 for a description
of this type of node.
Overview of the verification procedure
The
following overview shows the procedure for verifying the web server
configuration:
- Start the web server with the proper procedure for your web server.
For
example, start the IBM HTTP Server from a command line:
- ./IHS_root/bin/apachectl
start
- IHS_root\bin\apache
- Start the application server.
Change directories to the
profile_root/bin directory
and run the
startServer command:
- ./profile_root/bin/startServer.sh
server1
- profile_root\bin\startServer
server1
Open the administrative console and save the changed configuration.
- Point your browser to http://localhost:9080/snoop to
test the internal HTTP transport provided by the application server.
Point your 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
Web Server Plug-ins Configuration Tool does not automatically create
a web server definition within a federated application server profile.
The tool creates the configureweb_server_name script
instead in the plugins_root/bin directory.
The
Web Server Plug-ins Configuration Tool configures the web server to
use the plugin-cfg.xml file that will be created
within the application server profile when you run the script. The
deployment manager regenerates the plugin-cfg.xml file
in the profile_root/config/cells/cell_name/nodes/node_name/servers/web_server_name directory.
Regeneration occurs whenever a change occurs in the application server
configuration that affects deployed applications on the managed node.
After
installing the binary plug-in for the local web server, you must run
the script before you can start the web server. The web server has
already been configured to use the
plugin-cfg.xml file
in the application server configuration. That file does not exist
until you run the
configureweb_server_name script.
Table 2. Configurations that qualify
for the local distributed application server scenario.
Profile type |
Federation status |
Creation of web server definition? |
Web server already defined in application server
configuration? |
Application server profile |
Federated |
By script |
N/A |
Custom profile |
Not federated |
By script |
N/A |
Custom profile |
Federated |
By script |
N/A |
Deployment manager profile with a managed node
(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 deployment manager.
- If you are planning to add an application server 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 application server. You
have two options:
- Use the administrative console of the deployment manager to create
a web server definition for a managed node. Click 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 deployment manager. Run the script from the plugins_root/bin directory.
The script can address the deployment manager on the same machine.
Open
a command window to run the appropriate script:
- ./configureweb_server_name.sh
- configureweb_server_name.bat
Note: The webserverNodeName value in the
script is a concatenation of the nick name you 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 you named your 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
you have enabled security or changed the default JMX connector type,
edit the script and include the appropriate parameters.
- Start the web server with the proper procedure for your web server.
For
example, start the IBM HTTP Server from a command line:
- ./IHS_root/bin/apachectl
start
- IHS_root\bin\apache
- Start the application server.
Change directories to the
profile_root/bin directory
and run the
startServer command:
- ./profile_root/bin/startServer.sh
server1
- profile_root\bin\startServer
server1
- Open the administrative console of the deployment manager. Wait
for node synchronization to occur and save the changed configuration
that includes the new web server definition.
- Point your browser to http://localhost:9080/snoop to
test the internal HTTP transport provided by the application server.
Point your 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 3. Remote plug-in configuration
The
Web Server Plug-ins Configuration Tool does not automatically create
a web server definition within the distributed profile on a remote
machine. The tool creates the configureweb_server_name script
instead.
The Web Server Plug-ins Configuration Tool configures
the web server to use the plugin-cfg.xml file
that will be maintained on the web server machine in the plugins_root/config/web_server_name directory.
This file requires periodic propagation. Propagation is copying the
current plugin-cfg.xml file from the application
server machine to replace the plugins_root/config/web_server_name/plugin-cfg.xml file.
After
installing the binary plug-in for the local web server, you do not
have to run the script before you can start the application server
and the web server. However, you do not have the benefits of a Web
server definition in the application server node until you run the
script.
Table 3. Configurations
that qualify for the remote application server scenario.
Profile type |
Federation status |
Creation of web server definition? |
Web server already defined in application server
configuration? |
Any profile anywhere if you select a remote
installation type in the Web Server Plug-ins Configuration Tool |
N/A |
By script |
N/A |
No profile |
N/A |
By script |
N/A |
Unfederated standalone application server profile
with an existing web server definition |
Not federated |
By script |
Yes |
Deployment manager profile with no managed nodes |
N/A |
By script |
N/A |
Testing the application server without a web server
definition: The following overview shows the procedure for verifying
the temporary plugins_root/config/web_server_name/plugin-cfg.xml file.
The
web server communicates with the remote application server using the
temporary plugin-cfg.xml file.
If the
application server has an HTTP Transport port assignment other than
9080, the test is not successful. Continue to the next section to
create the web server definition on the application server and complete
your test of the configuration.
- Start the web server with the proper procedure for your web server.
For
example, start the IBM HTTP Server from a command line:
- ./IHS_root/bin/apachectl
start
- IHS_root\bin\apache
- Start the application server on the remote machine.
Change
directories to the
profile_root/bin directory
and run the
startServer command:
- ./profile_root/bin/startServer.sh
server1
- profile_root\bin\startServer
server1
- Point your browser to http://localhost:9080/snoop to
test the internal HTTP transport provided by the application server.
Point your 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 following overview shows the procedure for completing
the configuration. The configuration is not complete until the Web
server definition exists in the configuration of the application server
node. The web server definition is a central element in the regeneration
of a valid plug-in configuration file,
plugin-cfg.xml.
- Start the deployment manager if you are configuring the deployment
manager or a managed node.
- Federate a remote application server node or custom node now if
you 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 application server. You
have two options for a managed node. Use the script option for a deployment
manager node without managed nodes.
- Use the administrative console of the deployment manager to create
a web server definition for a managed node. Click 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 application server node:
- Copy the script from the plugins_root/bin directory
to the remote app_server_root/bin directory.
- Open a command window and run the script:
- ./configureweb_server_name.sh
- configureweb_server_name.bat
Note: The webserverNodeName value in the script
is a concatenation of the nick name you 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
you named your 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
you have enabled security or changed the default Java Management
Extensions (JMX) connector type, edit the script and include the appropriate
parameters.
- Open the administrative console of the deployment manager 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 administrative
console of the application server and save the changed configuration.
- Copy the current plug-in configuration file, plugin-cfg.xml,
in the profile_root/config/cells/cell_name/nodes/web_server_name_node/servers/web_server_name directory.
Paste the file on the web server machine to replace the temporary plugins_root/config/web_server_name/plugin-cfg.xml
file. The IBM HTTP Server supports automatic propagation.
Other web servers require manual propagation.
- Start the web server with the proper procedure for your web server.
- Point your browser to http://localhost:9080/snoop to
test the internal HTTP transport provided by the application server.
Point your 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.
Summary
Three scenarios exist for Web Server
Plug-ins. Each scenario revolves around a unique location for the
plug-in configuration file, plugin-cfg.xml. The
application server generates the plug-in configuration file. The purpose
of the file is to publish the location of all of the application server
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 application server machine, you must 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
3 in this topic.
In each of the local scenarios, the Web
server can get to the plugin-cfg.xml file 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 WebSphere Application Server
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 1 in
this topic. All Scenario 2 configurations require the web server
definition to exist within a managed application server node. All Scenario
1 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 administrative console
of a standalone application server. The inability of a standalone
application server to create a web server definition is the basis
for the configuration scripts created by the Web Server Plug-ins Configuration
Tool. Without the scripts you could not easily create a web server
definition on a standalone application server node.
The location
of the
plugin-cfg.xml file for each configuration
described in this topic is shown in the following table:
Table 4. Plug-in configuration file
locations.
Scenario |
Profile type |
Location of
the plugin-cfg.xml file |
plugins_root |
profile_root:
within the managed node |
profile_root:
within the web server node |
1 |
Application server profile |
|
|
X |
2 |
Application server profile |
|
X |
|
Custom profile |
|
X |
|
Deployment manager profile with a managed node
(distributed profile) |
|
X |
|
3 |
Any profile anywhere if you select a remote
installation type in the Web Server Plug-ins Configuration Tool |
X |
|
|
No profile |
X |
|
|
Unfederated (standalone) application server
profile with an existing web server definition |
X |
|
|
Deployment manager profile with no managed nodes |
X |
|
|
Legend:
- plugins_root
- plugins_root
/config/web_server_name/plugin-cfg.xml
- profile_root: within the managed node
profile_root/config/cells/cell_name/nodes/node_name_of_AppServer/servers/web_server_name/plugin-cfg.xml
- profile_root: within the web server node
profile_root/config/cells/cell_name/nodes/web_server_name_node/servers/web_server_name/plugin-cfg.xml