InfoCenter Home >
6: Administer applications >
6.6: Tools and resources quick reference >
6.6.45: Administering WebSphere plug-ins for Web servers (overview)

6.6.45: Administering WebSphere plug-ins for Web servers (overview)

The WebSphere Application Server works with a Web server to handle requests for Web applications. The Web server and application server communicate using the WebSphere plug-in for the Web server.

When you install WebSphere Application Server, it modifies the Web server configuration file automatically to establish the plug-in. The exception is for installations using Domino Server, in which you need to perform manual steps to update the Web server configuration file after installing WebSphere Application Server. For more information, see "6.6.45.0.1: Modifications to Web server configuration files during product installation."

Administering Web servers

Refer to your Web server documentation as the ultimate source of information about administering your Web server. See also the subtopics of this article.

Ensure that Web servers are 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 httpd.conf for IBM HTTP Server). Refer to the Web server documentation for instructions. If an operation is not enabled when a servlet or JSP page requiring the operation is accessed, an error message is displayed, such as this one from IBM HTTP Server:

HTTP method POST is not supported by this URL.

The internal HTTP transport and the Web server plug-in

A Web server and WebSphere plug-in for the Web server are required for use in a production environment, for performance reasons. But strictly speaking, they are not required in order to start the application server or the administrative console. In a test or development environment, you might want to use the internal HTTP transport described in the transport administration overview, instead of the Web server plug-in and Web server.

The remainder of this article and its sub-topics (6.6.45.*) discuss the Web server plug-in.

Administering WebSphere plug-ins for Web servers

Version 4.x introduces the HTTP transport plug-ins as the preferred method of communication between the Web server and the application server. The HTTP plug-in introduces the following advantages:

  • XML-based configuration file
  • Standard protocol recognized by firewall products
  • Security using HTTPS, replacing proprietary OSE over SSL

The remainder of this article discusses the main plug-in tasks and when to perform them:

Manually triggering a regeneration of the plug-in configuration

The WebSphere administrative console supplies a manual way to force plug-in configurations to update (regenerate) themselves. For a summary of the occassions on which to update the plug-in configuration, see the instructions for regenerating the plug-in.

Time required for plug-in regeneration

Regenerating the configuration might take a while to complete. After it is finished, all objects in the administrative domain will use their newest settings, of which the Web server is now aware.

Whether triggered manually or occurring automatically, plug-in regeneration requires about 30 - 60 seconds to complete, when the application server product 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 will take 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. You can see how dynamic plug-in configuration enables you to make newly configured resources available to users right away.

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 configurations requires twice the refresh interval.

In a development environment in which you are frequently changing settings in the administrative console, it is recommended 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.

Example of regenerating the plug-in configuration

After using the administrative console to make configuration changes that involve the served paths of Web applications, manually trigger the regeneration of the plug-in configuration (or manually edit the file if that is what you have been doing).

When you trigger the regeneration of the plug-in configuration:

  1. The Web container containing the Web application registers the configuration changes to those objects.

  2. The Web container unloads the Web application, then loads it again, causing the Web application to adopt the new settings.

    Note that the state and data of any servlets running in the Web application will be lost, unless the Web application usually persists data (for example, it saves servlet-generated session and user profile data in a database).

  3. The plug-in configuration is regenerated. The Web server is aware of the new Web application configuration. If a user requests the servlet using the path specified by the new Web resource, the request should be successful.

Manually editing the plug-in configuration

The Web server plug-in property reference describes the location and contents of the plug-in configuration files.

Use care when you manually edit the HTTP plug-in configuration, because your changes will be overwritten if the plug-in configuration is regenerated. However, regenerating the plug-in configuration cannot guarantee a correct configuration file for advanced configuration scenarios. If you seeing strange behavior after triggering a regeneration of the plug-in configuration, consider manually editing the configuration.

Go to previous article: 6.6.43.0.3: Assembly properties for security role references Go to next article: Properties of WebSphere plug-ins for Web servers

 

 
Go to previous article: 6.6.43.0.3: Assembly properties for security role references Go to next article: Properties of WebSphere plug-ins for Web servers