The WebSphere Application Server works with a Web server to route
requests for dynamic content, such as servlets, from Web applications. The
Web servers are necessary for directing traffic from browsers to the applications
that run in WebSphere Application Server. The Web server plug-in uses the
XML configuration file to determine whether a request is for the WebSphere
Application Server.
Before you begin
- Install your Web server if it is not already installed.
If you want to use an IBM HTTP Server for WebSphere
Application Server, see Installing IBM HTTP Server
.
Otherwise, see the installation information provided with your Web server.
- Ensure that your Web server is configured to perform operations required
by Web applications, such as GET and POST. Typically, this involves setting
a directive in the Web server configuration file (such as the httpd.conf file
for an IBM HTTP Server). Refer to the Web server documentation for instructions.
If an operation is not enabled when a servlet or JSP file
requiring the operation is accessed, an error message displays, such as this
one from the IBM HTTP Server:
HTTP method POST is not supported by this URL.
- Make sure the appropriate plug-in file has been installed
on your Web server and the configureWeb_server_name script has been run to
create and configure the Web server definition for this Web server.
If
you are using a distributed platform Web server, use the Plug-in Installation wizard to install the appropriate
plug-in file to your Web server. Then run the configureWeb_server_name script
created by the wizard to create and configure the Web server definition in
the WebSphere configuration repository.
About this task
The following steps are performed during the plug-in
installation process. See the Plug-in Installation Roadmap for additional
information.
- A node is created.
An unmanaged node is created when the Web server is on a
different computer from the Application Server. An unmanaged node is a node
that does not have a WebSphere node agent running on it. Using unmanaged nodes,
WebSphere Application Server can represent servers that are not application
servers within its configuration topology. This representation enables connection
information between those servers and application servers to be maintained. Managing nodes
describes
how to create a node.
- A Web server definition is created.
You can also use either the administrative
console or use the ConfigureWebServerDefintion.jacl script to create a Web
server definition. If you use the administrative console:
- Select the node that was created in the preceding step, and in the Server
name field, enter the local name of the Web server for which you are creating
a Web server definition.
- Use the wizard to complete the Web server definition.
- An application or modules are mapped to a Web server. If an application
that you want to use with this Web server is already installed, the application
is automatically mapped to the Web server. If the application is not installed,
select this Web server during the Map modules to servers step of the application
installation process.
- The master repository is updated and saved.
When you install a plug-in, the configuration
file for that plug-in is automatically created. You can change or fine tune
the default settings for the properties in this configuration file. If change
any of the settings, you must regenerate the file before your changes take
affect.
Generating or regenerating the configuration
file 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.
If the Application Server is on the same physical machine as the Web server,
the regeneration usually takes about 30 to 60 seconds to complete. The regeneration
takes longer if they are not both on the same machine.
The following
procedure describes the steps for updating the plug-in configuration file,
including configuring for SSL and Web server tuning
Procedure
- Use the administrative console to change the settings in the plug-in
configuration file.
When setting up your Web server plug-in,
you must decide whether or not to have the configuration automatically generated
in response to a configuration change. When the Web server plug-in configuration
service is enabled and any of the following conditions occur, the plug-in
configuration file is automatically generated:
- When the Web server is created or saved.
- When an application is installed.
- When an application is uninstalled.
- When the virtual host definition is updated
You can either use the administrative console, or issue
the GenPluginCfg command to regenerate your plugin-cfg.xml file.
To use the administrative console:
- Select Servers > Web Servers > webserver >
plug-in properties.
- Select Automatically generate plug-in configuration file or
click one or more of the following topics to manually configure the plugin-cfg.xml file:
- Caching
- Request and response
- Request routing
- Custom Properties
Web server
plug-in configuration properties maps each property to one of these
topics. Note: It is recommended that you do not manually update the plugin-cfg.xml file.
Any manual updates you make for a given Web server are overridden whenever
the plugin-cfg.xml file for that Web server is regenerated.
- Click OK.
- You might need to stop
the application server and then start
the application server again to enable the Web server to locate the plugin-cfg.xml file.
Optional: Edit
the plug-in configuration file. You should not have to edit the
configuration file. If you do edit this file remember that:
- The file is in ASCII format (ISO-98859-1).
- Any manual changes you make to the file are overwritten the next time
the file is regenerated.
- If you want to use Secure-socket layer (SSL) with
this configuration, use the plug-in's installation wizard to install the appropriate GSKIT installation image file on
your workstation.
See Configuring the Web server plug-in for Secure Sockets Layer
for information on how
to configure GSKIT.
- If you want to enable the Application Server to use the private
headers that the Web server plug-in sends, make sure the transport you are
using is configured for SSL and is trusted.
If
your transport is a transport chain you must define an SSL repertoire for that chain that includes a trust
file definition.
If a trust file definition is not included,
the private headers will be ignored, and the application server might not
locate the requested application. If
you are using an HTTP transport, make sure the transport is configured
for SSL and the Trusted custom property for
the transport is set to false.
After you enable the use of private headers,
this transport trusts all inbound private headers it receives. Therefore,
you must ensure that all inbound paths to this transport are trusted.
- Tune your Web server. See
Tuning Web servers
for more information.
- Propagate the plug-in configuration.
The plug-in configuration file (plugin-cfg.xml) is automatically propagated
to the Web server if the Web server plug-in configuration service is enabled,
and one of the following is true:
- The Web server is a local Web server. (It are located on the same machine
as an application server.)
- The Web server is a remote IBM HTTP Server Version 6.0 that has a running
IBM HTTP Server administration server.
If neither of these conditions is true, the plugin-cfg.xml file must
be manually copied to the remote Web server's installation location.
Important: If you use the FTP function to perform the copy, and the
configuration reload fails, check the file permissions on the plugin-cfg.xml
file and make sure they are set to rw-r--r--. If the file permissions are
not correct, the Web server is not able to access the new version of the file,
which causes the configuration reload to fail.
If the file permissions are
incorrect, issue the following command to change the file permissions to the
appropriate settings:
chmod 644 plugin-cfg.xml
The
AIX FTP function does not preserve file attributes. Therefore, if you need
to manually copy the plugin-cfg.xml from an AIX operating system, you might
want to use the AIX RCP function instead of the FTP function to copy the file.
The remote Web server installation location
is the location you specified when you created the node for this Web server.
Results
The configuration is complete. To activate the configuration, stop
and restart the Web server. If you encounter problems restarting your Web
server, check the http_plugin.log file for information on what portion of
the plugin-cfg.xml file contains an error. The log file states the line number
on which the error occurred along with other details that might help you diagnose
why the Web server did not start. You can then use the administrative console
to update the plugin-cfg.xml file.
If applications are infrequently installed
or uninstalled, which is usually the situation in a production environment,
or if you can tolerate the performance impact of generating and distributing
the plug-in configuration file each time any of the previously listed actions
occur, you should consider enabling this service.
If you are making
a series of simultaneous changes, like installing numerous applications, you
might want the configuration service disabled until after you make the last
change. The Web server plug-in configuration service is enabled by default.
To disable this service, in the administrative console click elect Servers
> Application Servers > server_name > Administration Services
>Web server plug-in configuration service and then unselect the Enable
automated Web server configuration processing option.
Tip: If
your installation uses a firewall, make sure you configure the Web server
plug-in to use a port that has been opened. (See your security administrator
for information on how to obtain an open port.)