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 two 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
The
Web Server Plug-ins Configuration Tool resolves all configurations
of the web server and WebSphere® Application Server
to two scenarios: remote plug-in configuration and local plug-in configuration.
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 is accidentally deleted
or otherwise missing, the scenario is considered to be a remote installation.
Create a profile before running the script.
- Standalone application server with web server definition?
- If the profile has an existing web server definition, the installation
is considered a remote plug-in configuration. You cannot have more
than one web server definition in a standalone application server.
Scenario A. Local standalone plug-in configuration
In
this scenario, the Web Server Plug-ins Configuration Tool creates
a web server definition within the application server profile directly,
without the use of a script.
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 application server
regenerates the plugin-cfg.xml file in the profile_root/config/cells/ cell_name/nodes/ web_server_name_node/servers/ web_server_name directory.
Regeneration occurs whenever a change occurs in the application server
configuration that affects deployed applications.
After configuring
the application server for the local web server, you can start the
application server and the web server immediately.
Table 1. Configuration that qualifies for the
local application server scenario.
Profile type |
Automatic creation of web server definition? |
Web server already defined in application server
configuration? |
Application server |
Yes |
No |
Redirection to Scenario B
A application
server profile that has an existing web server definition should be
processed as a remote plug-in configuration. An application server
can have just one web server definition.
See Scenario B 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.
- 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 B. 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 is 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 2. Configurations
that qualify for the remote application server scenario.
Profile type |
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 |
By script |
N/A |
No profile |
By script |
N/A |
Standalone application server profile with an
existing web server definition |
By script |
Yes |
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 to
complete your test of the configuration.
- Start the web server with the proper procedure for your web server.
- Start the application server on the remote machine.
- 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.
- Create the web server definition in the application server.
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
The
configureweb_server_name script
can take three parameters:
profile_name,
Admin_Console_Username and
Admin_Console_Password.
- profile_name indicates the name of the profile
used to create the web server definition.
- Admin_Console_Username indicates the username
of the administrative console. The profile with the administrative
console deployed must have administrative-console security turned
on. This parameter can not be used if profile_name is
blank.
- Admin_Console_Password indicates the password
corresponding to the username. This parameter cannot be used if both profile_name and Admin_Console_Username are
blank.
Note: The webserverNodeName value in the script
is a concatenation of the nickname that you have chosen for the Web
server and the suffix -node. It is automatically
created during plug-in configuration and cannot be changed. For example,
if you named your web server myserver during plug-in
configuration, 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.
- 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.
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.
Summary
Two 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
objects that are relevant to a web server and to control binary plug-in
configuration options. The file identifies objects such as applications
and virtual hosts for serving applications.
If the web server
cannot access the file on the application server machine, you must
copy the file to the web server. That process is called "propagation."
Propagation is reserved for the remote plug-in configuration scenario,
which is Scenario B in this topic.
In the local scenario,
the web server can access the plugin-cfg.xml file
because the web server is on the same machine as the file.
All Scenario
A 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 3. Plug-in configuration file
locations.
Scenario |
Profile type |
Location of
the plugin-cfg.xml file |
plugins_root |
profile_root:
within the web server node |
A |
Application server profile |
|
X |
B |
Any profile anywhere if you select a remote
installation type in the Web Server Plug-ins Configuration Tool |
X |
|
No profile |
X |
|
Application server profile with an existing
web server definition |
X |
|
Legend:
- plugins_root
plugins_root/config/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