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

6.6.45: Administering WebSphere plug-ins for Web servers

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 "Modifications to Web server configurations 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.

Administering WebSphere plug-ins for Web servers

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

Automatically triggering a regeneration of the plug-in configuration

Most of the time, you will perform administrative tasks without even thinking about dynamic plug-in configuration. The configuration is regenerated automatically every time you stop an application server process and start it again, as explained below.

The following general steps cause plug-ins to be regenerated automatically:

  1. Make one or more configuration changes that are considered "start up" changes, in contrast to changes to that take effect immediately.
  2. In the Topology tree on the Topology tab, locate the application servers containing the objects to which you made the configuration changes.

  3. Stop the application servers and start them again to cause the dynamic regeneration of the Web server plug-ins.

Now the objects for which you made the configuration changes are operating with the new values you specified. The Web servers are aware of the changes, too.

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 OSE plug-in, the length of the delay is determined by the ose.refresh.interval setting in the IBM WebSphere Application Server bootstrap.properties file. The plug-ins poll the disk at this interval to see whether their configurations have changed.

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, stop the affected application servers and start them again to trigger an automatic regeneration of the plug-in configuration files.

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

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

  2. The servlet engine 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 of the plug-in configuration files.

For the OSE plug-in configuration files, you should always use the WebSphere administrative console to modify the files, rather than modifying them directly. If you directly edit the files, the results cannot be guaranteed. It is likely your changes will be overwritten because the product periodically performs automatic updates of these files.

Sometimes you might find it useful to view the OSE plug-in configuration files. For example, the files can reveal which requests are being handled by the servlet redirector (using RMI-IIOP), and which are being handled on the machine local to the Web server (using an OSE transport).

Go to previous article: Using the JDK conversion assistant to switch Java 1.2.2 vendor implementations Go to next article: Properties of WebSphere plug-ins for Web servers

 

 
Go to previous article: Using the JDK conversion assistant to switch Java 1.2.2 vendor implementations Go to next article: Properties of WebSphere plug-ins for Web servers