Plug-ins configuration

 

+

Search Tips   |   Advanced Search

 

The Plug-ins installation wizard installs a binary plug-in module and a plug-in configuration file for the Web server. The wizard then configures the supported Web server for the Application Server and creates a Web server definition in the configuration of the application server. This overview shows the different processing paths that the wizard uses.

This topic describes the three ways that the Plug-ins installation wizard configures a Web server to locate the plugin-cfg.xml file, which is the plug-in configuration file.

 

Configuration flows for the Network Deployment product

The Plug-ins installation wizard resolves all configurations of Web server and WAS to three scenarios:

  1. Remote application server
  2. Local distributed application server
  3. Local stand-alone application server

The logic implemented in determining which scenario applies to a configuration is shown in the following diagram.

 

Legend:

Default application server with Web server definition

If the default profile is an application server with an existing Web server definition, then the installation is considered a remote installation. You cannot have more than one Web server definition in a stand-alone application server.

Use the same name for the Web server to configure a new Web server to use the existing Web server definition.

Use a different Web server name to create a script that creates a new Web server definition in a federated application server profile.

Default profile

If the product is installed but the Profile Creation wizard has not yet created a profile, the scenario is considered to be a remote installation. When multiple profiles exist, the plug-ins installer configures only the default profile.

Default profile_type

The Plug-ins installation wizard can configure only one profile at a time. The wizard always works with the default profile. These three paths show how processing varies for different types of profiles.

Federated

If the application server node is federated, the Plug-ins installation wizard 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.

Installation type

The installation type is either remote or local.

Non-default distributed profile

If the deployment manager has a federated custom node (custom profile), the Plug-ins installation wizard 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.

If a federated custom profile is not found, the Plug-ins installation wizard looks for and configures the first federated application server node (application server profile) that it finds. So, the logic is:

  1. Look for a federated managed (custom) profile and configure the first one found.

  2. If no federated managed profile is found, look for a federated application server profile and configure the first one found.

 

Scenario 1. Remote plug-in configuration

The Plug-ins installation wizard does not automatically create a Web server definition within the default distributed profile on a remote machine. The wizard creates the configureweb_server_name script instead.

The Plug-ins installation wizard 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...

plugins_root/config/web_server_name/plugin-cfg.xml

After installing the binary plug-in for the local Web server, you do not have to run the script before we 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.

Four configurations 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 Plug-ins installation wizard N/A By script N/A
No default profile detected N/A By script N/A
Default unfederated stand-alone application server profile with an existing Web server definition Not federated By script Yes
Default 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.

  1. 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

  2. Start the application server on the remote machine.

    Change directories to the...

    profile_root/bin

    ...directory and run the startServer command:

  3. 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.

  4. 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.

  1. Start the deployment manager if you are configuring the deployment manager or a managed node.

  2. 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.

  3. 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 manger 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:

      1. Copy the script from the plugins_root/bin directory to the remote app_server_root/bin directory.

      2. Open a command window and run the script:

        • ./configureweb_server_name.sh

        • configureweb_server_name.bat

      If you have enabled security or changed the default Java Management Extensions (JMX) connector type, edit the script and include the appropriate parameters.

  4. 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.

  5. 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.

  6. Start the Web server with the proper procedure for your Web server.

  7. 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.

  8. Verify that both Web addresses display the Snoop Servlet - Request/Client Information page.

 

Scenario 2. Local distributed plug-in configuration

The Plug-ins installation wizard does not automatically create a Web server definition within a federated application server profile. The wizard creates the configureweb_server_name script instead in the plugins_root/bin directory.

The Plug-ins installation wizard 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, run the script before we 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.

Four configurations 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?
Default application server profile Federated By script N/A
Default Custom profile Not federated By script N/A
Default Custom profile Federated By script N/A
Default deployment manager profile with a managed node (non-default distributed profile) N/A By script N/A

The following overview shows the procedure for completing the configuration and verifying the Web server configuration:

  1. Start the deployment manager.

  2. 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.

  3. Create the Web server definition in the application server. You have two options:

    • Use the administrative console of the deployment manger 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

      If you have enabled security or changed the default JMX connector type, edit the script and include the appropriate parameters.

  4. 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

  5. Start the application server.

    Change directories to the...

    profile_root/bin

    ...directory and run the startServer command:

  6. 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.

  7. 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.

  8. Verify that both Web addresses display the Snoop Servlet - Request/Client Information page.

 

Scenario 3. Local stand-alone plug-in configuration

The Plug-ins installation wizard creates a Web server definition within the application server profile.

The Plug-ins installation wizard configures the Web server to use the plugin-cfg.xml file that is within the application server profile. The stand-alone 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, we 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 stand-alone 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 stand-alone Application Server. You must recreate the Web server definition on the managed node. See Scenario 2.

Only one configuration qualifies for the local stand-alone 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 1

An unfederated default standalone application server that has an existing Web server definition is processed as a remote plug-in configuration.

An existing Web server definition on a stand-alone application server causes the Plug-ins installation wizard to follow the remote installation path. A stand-alone application server can have just one Web server definition. Specify the same nick name for the Web server if you want to configure a new Web server.

We can use the plugin-cfg.xml file that is within the Web server definition in the configuration of the Application Server. Simply click Browse on the appropriate panel in the Plug-ins installation wizard to select the file. This file must exist. Otherwise, the Plug-ins installation wizard displays a warning and prevents you from proceeding until you select an existing file. The Web server is configured to use this existing plugin-cfg.xml file.

See Scenario 1 for a description of this type of node.

 

Redirection to Scenario 2

A federated default standalone Application Server is 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 after installing the binary plug-in module:

  1. 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

  2. Start the application server.

    Change directories to the...

    profile_root/bin

    ...directory and run the startServer command:

    Open the administrative console and save the changed configuration.

  3. 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.

  4. Verify that both Web addresses display the Snoop Servlet - Request/Client Information page.

 

Summary

Three scenarios exist for Web server plug-ins for WebSphere Application Server. 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 1 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 Version 6 of WAS 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 3 in this topic. All Scenario 2 configurations require the Web server definition to exist within a managed application server node. All Scenario 3 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 stand-alone application server. The inability of a stand-alone application server to create a Web server definition is the basis for the configuration scripts created by the Web server plug-ins for WebSphere Application Server. Without the scripts you could not easily create a Web server definition on a stand-alone application server node.

The location of the plugin-cfg.xml file for each configuration described in this topic is shown in the following table:

 

Plug-in configuration file locations

Scenario Profile type Location of the plugin-cfg.xml file
Plugins_ install_ root profiles_ root: within the managed node profiles_ root: within the Web server node
1 Any profile anywhere if you select a remote installation type in the Plug-ins installation wizard X    
No default profile detected X    
Default unfederated (stand-alone) Application Server profile with an existing Web server definition X    
Default deployment manager profile with no managed nodes X    
2 Default application server profile   X  
Default custom profile   X  
Default deployment manager profile with a managed node (non-default distributed profile)   X  
3 Default application server profile     X

 

Legend:

plugins_root

plugins_root
/config/web_server_name/plugin-cfg.xml

profiles_ root: within the managed node

profile_root/config/cells/cell_name/nodes/node_name_of_AppServer/servers/web_server_name/plugin-cfg.xml

profiles_ root: within the Web server node

profile_root/config/cells/cell_name/nodes/web_server_name_node/servers/web_server_name/plugin-cfg.xml


 

Related concepts


Web server configuration

 

Related tasks


Installing Web server plug-ins