InfoCenter Home >
3: Migration overview >
3.4: Running coexisting installations of WebSphere Application Server on a single machine

3.4: Running coexisting installations of WebSphere Application Server on a single machine

This article describes various coexistence scenarios that WebSphere Application Server supports and the steps required to achieve coexistence.

What is meant by "coexistence of WebSphere"?

Coexistence of WebSphere encompasses any of the following:

  • Running different releases of WebSphere Application Server on a single machine at the same time
  • Running multiple instances of a single version of WebSphere Application Server on a single machine at the same time
  • Running multiple instances of WebSphere Application Server from multiple installations at the same time

As part of coexistence, you can configure a single Web server for multiple instances or releases of WebSphere Application Server or configure a separate instance of a Web server for each instance or release of WebSphere Application Server.

Planning for coexistence

Before you install WebSphere Application Server, consider the following issues:

  1. Do you need to upgrade WebSphere supporting software to have coexisting installations of WebSphere Application Server? For coexistence of WebSphere Application Server Version 3.5 and WebSphere Application Server Version 4.0, you must upgrade software so it supports WebSphere Application Server Version 4.0; that is, you must use software that is common among the releases. For example, levels of Web servers common among WebSphere Application Server Versions 3.5 and 4.0 include: IBM HTTP Server 1.3.19, Apache HTTP Server 1.3.20, iPlanet Web Server 4.1 SP7, Lotus Domino 5.0.6, and Microsoft IIS 4.0 on Windows NT and 5.0 on Windows 2000. Examine the WebSphere supporting software Web page at http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html to see if you can use common levels of supporting software for your desired installations.

  2. Do you need to resolve conflicts in the desired configurations? Supported configurations include:
    • WebSphere Application Server Versions 3.5 and later releases and 4.0 and later releases
    • Multiple server instances of WebSphere Application Server Advanced Single Server Edition from a single installation
    • Multiple server instances of WebSphere Application Server Advanced Single Server Edition from multiple installations
    • WebSphere Application Advanced Single Server Edition and WebSphere Application Server Advanced Edition

    Determine whether you need a single instance of a Web server with mutiple instances of WebSphere Application Server or a separate instance of a Web server with each instance of WebSphere Application Server. See "Configuring Web servers" for details on selecting a single Web server instance or multiple Web server instances.

  3. Does the machine have enough system resources to handle coexistence? Based on system requirements for each instance, determine if your system has enough resources to support coexistence.

  4. Will you need to install WebSphere Application Server FixPaks (PTFs)?

    If you do need to install PTFs, you must address issues such as the following for Windows: when installing Version 3.5 PTFs earlier than 3.5.5, the PTF installer uses WAS_HOME to determine the location of where to install the PTF. If installing 3.5.4 or earlier PTFs when Version 4.0 or later releases is already installed, the PTF installer will install into the Version 4.0 WebSphere directory. Before installing a PTF earlier than Version 3.5.5, update the WAS_HOME entry to point to WebSphere Application Server Version 3.5 and, after the installation completes, switch it back to the Version 4.0 location.

Installing various supported configurations

This section describes how to install the supported configurations. References to Version 3.5 includes 3.5 and all later releases and FixPaks. References to Version 4.0 includes 4.0 and all later releases and FixPaks.

Enabling coexistence of WebSphere Application Server Version 3.5 and later releases and WebSphere Application Server Advanced Single Server Edition Version 4.0 and later releases, where both use a common Web server

Assuming Version 3.5 is already installed on your system, complete steps such as those described in this section to enable installations of WebSphere Application Server to co-exist. For these steps, the assumed Version 3.5 installation root is \WebSphere35\AppServer.

  1. Use XMLConfig in WebSphere Application Server Version 3.5 to back up the configuration so that you can repair inadvertent mistakes in configurations.
  2. Stop WebSphere Application Server Version 3.5.
  3. Upgrade your Web server to the version commonly supported by different versions of WebSphere Application Server. For example, if your system is using IBM HTTP Server Version 1.3.12 but needs Version 1.3.19 to support coexisting installations of WebSphere Application Server, upgrade IBM HTTP Server to 1.3.19.
  4. Back up the HTTP configuration file of your Web server (for example, httpd.conf for IBM HTTP Server and obj.conf for Sun ONE [iPlanet] Web Server V4.1 or both obj.conf and magnus.conf for Sun ONE V6.0) so that you can repair inadvertent mistakes in configurations.
  5. Install WebSphere Application Server Advanced Single Server Edition Version 4.0. For coexistence of Versions 3.5 and 4.0 specify a different location (for example, \WebSphere40\AppServer) for the installation directory from that of Version 3.5. When installing Version 4.0, do not select any Web server plug-in.
  6. Fix the Web server HTTP configuration to support both releases of WebSphere Application Server.
  7. Fix conflicting ports in the WebSphere Application Server instances. Choose port numbers not being used by other applications. For the Version 4.0 Advanced Single Server Edition, open an editor on the \WebSphere40\AppServer\config\server-cfg.xml file and find the element
    <locationServiceDaemon
    xmi:id="LocationServiceDaemon_1" hostname="localhost"
    port="9000" mode="NONE"/>

    Change the port to 9001. Next, find the element

    <orbSettings xmi:id="ORBConfig_1" enable="true"
    bootstrapHost="localhost" bootstrapPort="900">

    Change the bootstrapPort to 901.

  8. Configure a virtual host, if needed. For information on virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
  9. Start both releases of WebSphere Application Server.
  10. Run tools as needed to support coexistence.

    For example, installing WebSphere Application Server Version 4.0 updates the system variable PATH, potentially affecting tools with the same name across installations. To run tools with conflicting names, alter the PATH environment variable in a command window and place the directory for the former WebSphere installation before the directory for the latter WebSphere installation (for example, PATH=E:\WebSphere\AppServer\35\bin;%PATH%). Then, invoke the tools from the bin directory.

    Further, specify the bootstrap port. In coexistence environments, you must configure different WebSphere instances with different bootstrap ports. While invoking the tools, specify the bootstrap port of the server you are trying to access. For information, see "Using WebSphere Application Server tools."

Enabling coexistence of WebSphere Application Server Version 3.5 and WebSphere Application Server Advanced Single Server Edition Version 4.0 using separate instances of a Web server

Assuming Version 3.5 is already installed on your system, complete steps such as those described in this section to enable installations of WebSphere Application Server to co-exist. For these steps, the assumed Version 3.5 installation root is \WebSphere35\AppServer.

  1. Use XMLConfig in WebSphere Application Server Version 3.5 to back up the configuration so that you can repair inadvertent mistakes in configurations.
  2. Stop WebSphere Application Server Version 3.5.
  3. Upgrade your Web server to the version commonly supported by different versions of WebSphere Application Server. For example, if your system is using IBM HTTP Server Version 1.3.12 but needs Version 1.3.19 to support coexisting installations of WebSphere Application Server, upgrade IBM HTTP Server to 1.3.19.
  4. Create a second instance of the Web server. For IBM HTTP Server, see "Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 3.5."
  5. Back up the HTTP configuration file of your Web server (for example, httpd.conf for IBM HTTP Server and obj.conf for Sun ONE [iPlanet] Web Server V4.1 or both obj.conf and magnus.conf for Sun ONE V6.0) so that you can repair inadvertent mistakes in configurations.
  6. Install WebSphere Application Server Advanced Single Server Edition Version 4.0. For coexistence of Versions 3.5 and 4.0, specify a different location (for example, \WebSphere40\AppServer) for the installation directory from that of Version 3.5. When installing Version 4.0, select your Web server plug-in to create a second instance of the Web server.
  7. Fix conflicting ports in the WebSphere Application Server instances. Choose port numbers not being used by other applications. For the Version 4.0 Advanced Single Server Edition, open an editor on the \WebSphere40\AppServer\config\server-cfg.xml file and find the element
    <locationServiceDaemon
    xmi:id="LocationServiceDaemon_1" hostname="localhost"
    port="9000" mode="NONE"/>

    Change the port to 9001. Next, find the element

    <orbSettings xmi:id="ORBConfig_1" enable="true"
    bootstrapHost="localhost" bootstrapPort="900">

    Change the bootstrapPort to 901.

  8. Configure a virtual host to support a second Web server instance, if needed. For information on virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
  9. Start both releases of WebSphere Application Server.
  10. Run tools as needed to support coexistence.

    For example, installing WebSphere Application Server Version 4.0 updates the system variable PATH, potentially affecting tools with the same name across installations. To run tools with conflicting names, alter the PATH environment variable in a command window and place the directory for the former WebSphere installation before the directory for the latter WebSphere installation (for example, PATH=E:\WebSphere\AppServer\35\bin;%PATH%). Then, invoke the tools from the bin directory.

    Further, specify the bootstrap port. In coexistence environments, you must configure different WebSphere instances with different bootstrap ports. While invoking the tools, specify the bootstrap port of the server you are trying to access. For information, see "Using WebSphere Application Server tools."

Enabling coexistence of multiple instances of WebSphere Application Server Advanced Single Server Edition Version 4.0 from a single installation using a single instance of a Web server

This section describes how to configure multiple instances of one installation of WebSphere Application Server Advanced Single Server Edition. Having multiple instances allows, for example, different developers to have their own environment (instance) of the Advanced Single Server Edition running their application on a single machine.

To begin, install Version 4.0 FixPak 2 (4.0.2) of the Advanced Single Server Edition once on a single machine. Then, for each instance of the Advanced Single Server Edition, complete the steps below.

Configuring two instances
  1. Make two copies of the server-cfg.xml file and name the copies server-cfg1.xml and server-cfg2.xml.
  2. Define unique ports within the configuration XML files. The unique ports that need to be different are listed below, along with the port numbers used for this example. Specify the ports in the server configuration files. You can use different port numbers. The port numbers listed for Instance 1 are the default supplied with server-cfg.xml. Choose ports that no other applications use.
    Port used for... Instance 1 Instance 2 XML element in .xml file
    HTTP transport port 9080 9081
    <transports
    xmi:type="applicationserver:HTTPTransport"
    xmi:id="HttpTransport_1" hostname="*"
    port="9081">
    HTTPs 9443 9444
    <transports
    xmi:type="applicationserver:HTTPTransport"
    xmi:id="HttpTransport_2" hostname="*" port="9444"
    sslEnabled="true">
    Administrative console 9090 9091
    <transports
    xmi:type="applicationserver:HTTPTransport"
    xmi:id="HttpTransport_3" hostname="*" port="9091"
    external="false">
    Bootstrap 900 901
    <orbSettings xmi:id="ORBConfig_1" enable="true"
    bootstrapHost="localhost" bootstrapPort="901">
    LSD 9000 9001
    <locationServiceDaemon
    xmi:id="LocationServiceDaemon_1"
    hostname="localhost" port="9001" mode="NONE"/>
    OLT 2102 2103
    <objectLevelTraceSettings
    xmi:id="ObjectLevelTrace_1" enable="false"
    hostname="localhost" port="2103" debug="false"
    sourcePath=""/>
    Administrative debugging 7000 7001
    <traceService xmi:id="TraceServiceConfig_1"
    enable="true" traceSpecification="*=all=disabled"
    traceOutputFilename="stdout"
    diagThreadPort="7001"/>
  3. Define a virtual host entry for HTTP transport. For Instance 2, define ports 9081 and 9091 in the virtual host list of the server-cfg2.xml file.
  4. Define unique file names or directory names within the server configuration file. Below are the file names that need to be unique. To define unique names, you can use the administrative console or edit the server configuration .xml file. The default files are shown in brackets. If you change the directory, ensure that the directory already exists.
    Log files
    [ $(LOG_ROOT)/default_stderr.log and default_stdout.log ]

    You can change the log file names or the LOG_ROOT directory name.

    Passivation directory
    [ $(WAS_ROOT)/temp ]

    Security key file name, if used
    [ $(WAS_ROOT)/etc/DummyServerKeyFile.jks ] and
    [ $(WAS_ROOT)/etc/DummyServerTrustFile.jks ]

    The key file name only needs to be different if you want to use a different key ring file on each server.

    Transaction log
    [ $(TRANLOG)/tran1.log ] and [ ${TRANLOG_ROOT}/tran2.log ]

    Installed application directory
    [ $(APP_INSTALL_ROOT) ]

    The directory name only needs to be different if you want to have two different applications with the same .ear file name installed on the two servers. You define the actual applications that will run on a particular server instance in the server configuration file, and not by changing the contents of the installedApps directory. Therefore, two server instances can share the same directory and still run different applications.

    APP_INSTALL_ROOT is a path map entry that you change using the administrative console or by editing the server configuration .xml file.

    Note that there are hard coded paths to the installedApps directory for sample resources. You must change these paths.

    LOG_ENTRY and TRANLOG_ENTRY are path map entries that you change using the administrative console or by editing the server configuration .xml file. To edit the .xml file manually, search for the elements defining LOG_ENTRY or TRANLOG_ENTRY and modify the location. For example:

    <entries xmi:id="PathMapEntry_2" symbolicName="LOG_ROOT" path="${WAS_ROOT}/logs"
    description="The file system path to the directory which will contain server log files."/>
  5. Specify a different directory for JSP generated code and compiled code if two instances will not share the same directory. Specify the directory through a system property com.ibm.websphere.servlet.temp.dir. In the server-cfg2.xml file, specify the system property in JVM settings as follows:
    <jvmSettings xmi:id="JavaVirtualMachine_1" verboseModeClass="false"
    verboseModeGarbageCollection="false" verboseModeJNI="false" initialHeapSize="0"
    maximumHeapSize="256" runHProf="false" debugMode="false"
    genericCommandLineArgs="com.ibm.ws.runtime.StandardServer" disableJIT="false">
    <systemProperties xmi:id="SystemProperty_1" name="com.ibm.websphere.servlet.temp.dir"
    value="E:/WebSphere/AppServer/mytemp"/>
    </jvmSettings>
  6. To specify an instance-specific activity.log file, do the following:
    1. Copy the WAS_HOME/properties/logging.properties file to a named file, for example, mylogging.properties.
    2. Open an editor for the mylogging.properties file and change the com.ibm.was.ras.ActivityLogName property.
    3. Specify the file name using the system property com.ibm.ws.ras.RasProperties.

      An example follows:

      <jvmSettings xmi:id="JavaVirtualMachine_1" verboseModeClass="false"
      verboseModeGarbageCollection="false" verboseModeJNI="false"
      initialHeapSize="0"
      maximumHeapSize="256" runHProf="false" debugMode="false"
      genericCommandLineArgs="com.ibm.ws.runtime.StandardServer" disableJIT
      ="false">
      <systemProperties xmi:id="SystemProperty_1" name
      ="com.ibm.websphere.servlet.temp.dir" value="E:\WebSphere\AppServer"/>
      <systemProperties xmi:id="SystemProperty_2" name
      ="com.ibm.ws.ras.RasProperties"
      value="mylogging.properties"/>
      </jvmSettings>
      

    In order for the setting change to work properly, the mylogging.properties file must be in the application server classpath. If the WAS_HOME/properties directory is already in the application server classpath, no change needed.

  7. If the two instances require different security settings, copy the sas.*.props files (sas.server.props and sas.client.props) located in the directory \WebSphere\AppServer\properties and modify the files as needed. (See the Version 4.0 InfoCenter for information on these files.) Open an editor on the \WebSphere\AppServer\bin\setupCmdLine(sh/bat) file and change SERVERSAS, CLIENTSAS, WSCPCLIENTSAS settings to point to the new properties file; and then save the setupCmdLine(sh/bat) file with a different name (for example, setupCmdLine2(sh/bat)). Also, modify the startServer(sh/bat) file to invoke setupCmdLine2(sh/bat) and save the startServer(sh/bat) file as startServer2(sh/bat).
  8. Copy the installed applications directory to the new installedApps directory (or create an empty directory). You only need to do this step if you decided above to have separate application directories.
  9. Set up a single, shared Web server instance. Manually merge the plugin-cfg.xml files for the two server instances into a single plugin-cfg.xml file for use by the server:
    1. Run the command
      GenPluginCfg.(bat/sh) -configFile server1_configuration_file -outputFile /temp/server1_directory
    2. Run the command
      GenPluginCfg.(bat/sh) -configFile server2_configuration_file -outputFile /temp/server2_directory
    3. Manually merge the contents of the two files into the WebSphere_installation_root/config/plugin-cfg.xml file.
  10. Start the servers.
Starting the servers

To start the servers on Windows platforms, run the commands:

$WAS_HOME/bin/startServer.bat -configFile $WAS_HOME/config/server-cfg.xml
$WAS_HOME/bin/startServer.bat -configFile $WAS_HOME/config/server-cfg2.xml

To start the servers on UNIX platforms, run the commands:

$WAS_HOME/bin/startServer.sh -configFile $WAS_HOME/config/server-cfg.xml
$WAS_HOME/bin/startServer.sh -configFile $WAS_HOME/config/server-cfg2.xml

Note that if you have changed the sas.*.props files and renamed the startServer file for a second instance, use startServer2(sh/bat) to start the second instance.

Enabling coexistence of WebSphere Application Server Advanced Single Server Edition Version 4.0 from a single installation using multiple instances of a Web server

This section describes how to configure multiple instances of one installation of WebSphere Application Server Advanced Single Server Edition. Having multiple instances allows, for example, different developers to have their own environment (instance) of the Advanced Single Server Edition running their application on a single machine.

To begin, install Version 4.0 FixPak 2 (4.0.2) of the Advanced Single Server Edition once on a single machine. Then, for each instance of the Advanced Single Server Edition, complete the steps below.

Configuring two instances
  1. Make two copies of the server-cfg.xml file and name the copies server-cfg1.xml and server-cfg2.xml.
  2. Define unique ports within the configuration XML files. The unique ports that need to be different are listed below, along with the port numbers used for this example. Specify the ports in the server configuration files. You can use different port numbers. The port numbers listed for Instance 1 are the default supplied with server-cfg.xml. Choose ports that no other applications use.
    Port used for... Instance 1 Instance 2 XML element in .xml file
    HTTP transport port 9080 9081
    <transports
    xmi:type="applicationserver:HTTPTransport"
    xmi:id="HttpTransport_1" hostname="*"
    port="9081">
    HTTPs 9443 9444
    <transports
    xmi:type="applicationserver:HTTPTransport"
    xmi:id="HttpTransport_2" hostname="*" port="9444"
    sslEnabled="true">
    Administrative console 9090 9091
    <transports
    xmi:type="applicationserver:HTTPTransport"
    xmi:id="HttpTransport_3" hostname="*" port="9091"
    external="false">
    Bootstrap 900 901
    <orbSettings xmi:id="ORBConfig_1" enable="true"
    bootstrapHost="localhost" bootstrapPort="901">
    LSD 9000 9001
    <locationServiceDaemon
    xmi:id="LocationServiceDaemon_1"
    hostname="localhost" port="9001" mode="NONE"/>
    OLT 2102 2103
    <objectLevelTraceSettings
    xmi:id="ObjectLevelTrace_1" enable="false"
    hostname="localhost" port="2103" debug="false"
    sourcePath=""/>
    Administrative debugging 7000 7001
    <traceService xmi:id="TraceServiceConfig_1"
    enable="true" traceSpecification="*=all=disabled"
    traceOutputFilename="stdout"
    diagThreadPort="7001"/>
  3. Define a virtual host entry for HTTP transport. For Instance 2, define ports 9081 and 9091 in the virtual host list of the server-cfg2.xml file.
  4. Define unique file names or directory names within the server configuration file. Below are the file names that need to be unique. To define unique names, you can use the administrative console or edit the server configuration .xml file. The default files are shown in brackets. If you change the directory, ensure that the directory already exists.
    Log files
    [ $(LOG_ROOT)/default_stderr.log and default_stdout.log ]

    You can change the log file names or the LOG_ROOT directory name.

    Passivation directory
    [ $(WAS_ROOT)/temp ]

    Security key file name, if used
    [ $(WAS_ROOT)/etc/DummyServerKeyFile.jks ] and
    [ $(WAS_ROOT)/etc/DummyServerTrustFile.jks ]

    The key file name only needs to be different if you want to use a different key ring file on each server.

    Transaction log
    [ $(TRANLOG)/tran1.log ]

    Installed application directory
    [ $(APP_INSTALL_ROOT) ]

    The directory name only needs to be different if you want to have two different applications with the same .ear file name installed on the two servers. You define the actual applications that will run on a particular server instance in the server configuration file, and not by changing the contents of the installedApps directory. Therefore, two server instances can share the same directory and still run different applications.

    APP_INSTALL_ROOT is a path map entry that you change using the administrative console or by editing the server configuration .xml file.

    Note that there are hard coded paths to the installedApps directory for sample resources. You must change these paths.

    LOG_ENTRY and TRANLOG_ENTRY are path map entries that you change using the administrative console or by editing the server configuration .xml file. To edit the .xml file manually, search for the elements defining LOG_ENTRY or TRANLOG_ENTRY and modify the location. For example:

    <entries xmi:id="PathMapEntry_2" symbolicName="LOG_ROOT" path="${WAS_ROOT}/logs"
    description="The file system path to the directory which will contain server log files."/>
  5. Specify a different directory for JSP generated code and compiled code if two instances will not share the same directory. Specify the directory through a system property com.ibm.websphere.servlet.temp.dir. In the server-cfg2.xml file, specify the system property in JVM settings as follows:
    <jvmSettings xmi:id="JavaVirtualMachine_1" verboseModeClass="false"
    verboseModeGarbageCollection="false" verboseModeJNI="false" initialHeapSize="0"
    maximumHeapSize="256" runHProf="false" debugMode="false"
    genericCommandLineArgs="com.ibm.ws.runtime.StandardServer" disableJIT="false">
    <systemProperties xmi:id="SystemProperty_1" name="com.ibm.websphere.servlet.temp.dir"
    value="E:/WebSphere/AppServer/mytemp"/>
    </jvmSettings>
  6. To specify an instance-specific activity.log file, do the following:
    1. Copy the WAS_HOME/properties/logging.properties file to a named file, for example, mylogging.properties.
    2. Open an editor for the mylogging.properties file and change the com.ibm.was.ras.ActivityLogName property.
    3. Specify the file name using the system property com.ibm.ws.ras.RasProperties.

      An example follows:

      <jvmSettings xmi:id="JavaVirtualMachine_1" verboseModeClass="false"
      verboseModeGarbageCollection="false" verboseModeJNI="false"
      initialHeapSize="0"
      maximumHeapSize="256" runHProf="false" debugMode="false"
      genericCommandLineArgs="com.ibm.ws.runtime.StandardServer" disableJIT
      ="false">
      <systemProperties xmi:id="SystemProperty_1" name
      ="com.ibm.websphere.servlet.temp.dir" value="E:\WebSphere\AppServer"/>
      <systemProperties xmi:id="SystemProperty_2" name
      ="com.ibm.ws.ras.RasProperties"
      value="mylogging.properties"/>
      </jvmSettings>
      

    In order for the setting change to work properly, the mylogging.properties file must be in the application server classpath. If the WAS_HOME/properties directory is already in the application server classpath, no change needed.

  7. If the two instances require different security settings, copy the sas.*.props files (sas.server.props and sas.client.props) located in the directory \WebSphere\AppServer\properties and modify the files as needed. (See the Version 4.0 InfoCenter for information on these files.) Open an editor on the \WebSphere\AppServer\bin\setupCmdLine(sh/bat) file and change SERVERSAS, CLIENTSAS, WSCPCLIENTSAS settings to point to the new properties file; and then save the setupCmdLine(sh/bat) file with a different name (for example, setupCmdLine2(sh/bat)). Also, modify the startServer(sh/bat) file to invoke setupCmdLine2(sh/bat) and save the startServer(sh/bat) file as startServer2(sh/bat).
  8. Copy the installed applications directory to the new installedApps directory (or create an empty directory). You only need to do this step if you decided above to have separate application directories.
  9. Generate a plug-in configuration for each instance:
    1. Run the command
      GenPluginCfg.(bat/sh) -configFile server1_configuration_file
    2. Run the command
      GenPluginCfg.(bat/sh) -configFile server2_configuration_file -outputFile /temp/server2_directory
  10. Create a second instance of the Web server. Specify information for the WebSphere plug-in and the location of the plug-in configuration file (/temp/server2_directory) in the second instance of the Web server configuration file. See "Creating and configuring multiple instances of IBM HTTP Server for multiple installations of WebSphere Application Server Version 4.0."
  11. Specify a virtual host, if needed. For information on virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
  12. Start the servers.
Starting the servers

To start the servers on Windows platforms, run the commands:

$WAS_HOME/bin/startServer.bat -configFile $WAS_HOME/config/server-cfg.xml
$WAS_HOME/bin/startServer.bat -configFile $WAS_HOME/config/server-cfg2.xml

To start the servers on UNIX platforms, run the commands:

$WAS_HOME/bin/startServer.sh -configFile $WAS_HOME/config/server-cfg.xml
$WAS_HOME/bin/startServer.sh -configFile $WAS_HOME/config/server-cfg2.xml

Note that if you have changed the sas.*.props files and renamed the startServer file for a second instance, use startServer2(sh/bat) to start the second instance.

Enabling coexistence of multiple instances of WebSphere Application Server Advanced Single Server Edition Version 4.0 from multiple installations

This section describes how to run multiple instances of WebSphere Application Server Advanced Single Server Edition. Having multiple instances allows, for example, different developers to have their own environment (instance) of the Advanced Single Server Edition running their application on a single machine.

To begin, install Version 4.0 FixPak 2 (4.0.2) of the Advanced Single Server Edition once on a single machine. Then, complete the steps below.

  1. If you want to use a different Web server for the second instance, create a second instance of the Web server.
  2. Install the second instance of WebSphere Advanced Single Server Edition in a different location from that of previous installation (for example, /WebSphere/AppServer2/). If you use a different web server instance for the second installation, choose that Web server configuration when installing. With IBM HTTP Server as the Web server, the installation program will not give you the option to select the second instance configuration file; thus, after successfully installing WebSphere Application Server, fix the IBM HTTP Server configuration manually. If you use a single instance of the Web server for both instances, do not select a plug-in in the installation program.
  3. Define unique ports within the configuration of the second installation XML file. The unique ports that need to be different are listed below, along with the port numbers used for this example. Specify the ports in the server configuration files. You can use different port numbers. The port numbers listed for Instance 1 are the default supplied with /WebSphere/AppServer2/server-cfg.xml. Choose ports that no other applications use.
    Port used for... Instance 1 Instance 2 XML element in .xml file
    HTTP transport port 9080 9081
    <transports
    xmi:type="applicationserver:HTTPTransport"
    xmi:id="HttpTransport_1" hostname="*"
    port="9081">
    HTTPs 9443 9444
    <transports
    xmi:type="applicationserver:HTTPTransport"
    xmi:id="HttpTransport_2" hostname="*" port="9444"
    sslEnabled="true">
    Administrative console 9090 9091
    <transports
    xmi:type="applicationserver:HTTPTransport"
    xmi:id="HttpTransport_3" hostname="*" port="9091"
    external="false">
    Bootstrap 900 901
    <orbSettings xmi:id="ORBConfig_1" enable="true"
    bootstrapHost="localhost" bootstrapPort="901">
    LSD 9000 9001
    <locationServiceDaemon
    xmi:id="LocationServiceDaemon_1"
    hostname="localhost" port="9001" mode="NONE"/>
    OLT 2102 2103
    <objectLevelTraceSettings
    xmi:id="ObjectLevelTrace_1" enable="false"
    hostname="localhost" port="2103" debug="false"
    sourcePath=""/>
    Administrative debugging 7000 7001
    <traceService xmi:id="TraceServiceConfig_1"
    enable="true" traceSpecification="*=all=disabled"
    traceOutputFilename="stdout"
    diagThreadPort="7001"/>
  4. Define a virtual host entry for HTTP transport. For Instance 2, define ports 9081 and 9091 in the virtual host list of the server-cfg.xml file.
  5. If you are using a single Web server for both instances, to set up a single, shared Web server instance, manually merge the plugin-cfg.xml files for the two server instances into a single plugin-cfg.xml file for use by the server:
    1. Run the command
      GenPluginCfg.(bat/sh) -configFile server1_configuration_file -outputFile  /temp/server1_directory
    2. Run the command
      GenPluginCfg.(bat/sh) -configFile server2_configuration_file -outputFile /temp/server2_directory
    3. Manually merge the contents of the two files into the /WebSphere/AppServer/config/plugin-cfg.xml file.
Enabling coexistence of WebSphere Application Server Advanced Edition Version 4.0 and WebSphere Application Server Advanced Single Server Edition Version 4.0

This section describes how to run WebSphere Application Server Advanced Edition Version 4.0 and WebSphere Application Server Advanced Single Server Edition Version 4.0 on the same machine. Having multiple instances allows, for example, different developers to have their own environment (instance) of the Advanced Edition running their application on a single machine.

To begin, install Version 4.0 FixPak 2 (4.0.2) of the Advanced Single Server Edition once on a single machine. Then, complete the steps below.

  1. If you want to use a different Web server for the second instance, create a second instance of the Web server.
  2. Install the WebSphere Advanced Edition in a different location from that of the WebSphere Advanced Single Server Edition previously installed (for example, /WebSphere/AppServer2/). If you want a different Web server instance for the second installation, choose that Web server configuration when installing. If you want to use a single instance of the Web server for both instances, do not select a plug-in in the installation program.
  3. Open an editor on the /WebSphere/AppServer2/bin/admin-sec.config file and change the conflicting ports. Add the following to the bottom of the file:
    com.ibm.ejs.sm.adminServer.lsdPort=9001
    com.ibm.ejs.sm.adminServer.bootstrapPort=901
  4. Start the WebSphere Application Server Advanced Single Server product:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run sartupServer(sh/bat).
  5. Start the WebSphere Application Server Advanced Edition product:
    1. Go to a command prompt and move to the \WebSphere\AppServer2\bin directory.
    2. Run adminserver-sec.(sh/bat).
    3. Start the administrative console using the command
      adminclient.(sh/bat) localhost 901
  6. If you are using the default server in the Advanced Edition, modify conflicting ports in the default server of the Advanced Edition. (If you are not using the default server in the Advanced Edition, this step is not required.)
    1. In the Advanced Edition administrative console started in a previous step, select Virtual Hosts, right-click on default_host in the right pane, and select Properties. Under Aliases in the Virtual Host Properties dialog, change the list host aliases so it includes the aliases *:81 and *:9081 and click OK.
    2. In the second administrative console, select your server, Application Servers, Default Server and, on the right in the Services tab of the Default Server, select Web Container Service and click Edit Properties. In the Web Container Service dialog, under HTTP transports, change the port for host * to 9081 and click OK.
  7. To set up a single, shared Web server instance, manually merge the plug-in configuration files for the two server instances into a single plugin-cfg.xml file for use by the server:
    1. Run the command for the Advanced Single Server Edition (shown here on two lines to improve readability):
      /WebSphere/AppServer/GenPluginCfg.(bat/sh) -configFile server1_configuration_file
      -outputFile /temp/server1_directory

      The command generates /WebSphere/AppServer/config/plugin-cfg.xml.

    2. Run the command for the Advanced Edition:
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 901

      The command generates /WebSphere/AppServer2/config/plugin-cfg.xml.

    3. Manually merge the contents of the two generated files and replace both the files with the merged one.

Configuring Web servers

This section covers the following:

Upgrading from IBM HTTP Server Version 1.3.12 to Version 1.3.19

To upgrade from IBM HTTP Server Version 1.3.12 to 1.3.19, do the following for the appropriate platform. The following steps assume that WebSphere Application Server Version 3.5 is installed with IBM HTTP Server Version 1.3.12. After upgrading to IBM HTTP Server Version 1.3.19, fix the configuration for WebSphere Application Server Version 3.5.

AIX
  1. Stop the IBM HTTP Server and IBM HTTP Administration servers.
  2. Copy the httpd.conf file in the IBM HTTP Server conf directory and name the copy httpd-35.conf.
  3. Install IBM HTTP Server 1.3.19 over the existing 1.3.12 product using the smit option Update Installed Software to Latest Level (Update ALL) or the installp command:
    installp_cmd -a -d 'IHS_source_directory -f' '_update_all' '-c' '-N' '-g' '-x'

To execute the new ikeyman installed with IBM HTTP Server, you might need to point ikeyman to the IBM Software Developer Kit installed with WebSphere. Set the JAVA_HOME environment variable to point to the software development kit and then run ikeyman.

HP-UX and Solaris
  1. Stop the IBM HTTP Server and IBM HTTP Administration servers.
  2. Copy the httpd.conf file in the IBM HTTP Server conf directory and name the copy httpd-35.conf.
  3. Uninstall IBM HTTP Server Version 1.3.12 and then install IBM HTTP Server Version 1.3.19.

To execute the new ikeyman installed with IBM HTTP Server, you might need to point ikeyman to the Java Development Kit or to the Kit installed with WebSphere. Set the JAVA_HOME environment variable to point to Kit supported by WebSphere and then run ikeyman.

Windows NT or 2000
  1. In a Services dialog, stop the IBM HTTP Server and IBM HTTP Administration services.
  2. Copy the httpd.conf file in the IBM HTTP Server conf directory and name the copy httpd-35.conf.
  3. Uninstall IBM HTTP Server 1.3.12.
  4. Install IBM HTTP Server 1.3.19.
Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 3.5
UNIX

Open an editor on the httpd.conf file for IBM HTTP Server Version 1.3.19 and add the following lines at the bottom of the file based on your installation root. Following are the entries for Solaris. Check in the backed-up configuration file httpd-35.conf for the appropriate extensions for other UNIX platforms. For AIX, WebSphere Application Server usually installs into the /usr directory.

LoadModule ibm_app_server_module  /opt/WebSphere/AppServer/bin/mod_ibm_app_server.so
AddModule mod_app_server.c
NcfAppServerConfig BootFile  /opt/WebSphere/AppServer/properties/bootstrap.properties
Alias /IBMWebAS/  /opt/WebSphere/AppServer/web/

If the directory structure is not deleted when IBM HTTP Server 1.3.12 was uninstalled and IBM HTTP Server 1.3.19 is installed in the same location, settings in httpd.conf are preserved. In that case above steps are optional. Check the httpd.conf file to make sure entries are there in the file.

Windows NT

Open an editor on the httpd.conf file for IBM HTTP Server 1.3.19 and add the following lines at the bottom of the file. (These entries are in the backed-up httpd-35.conf file.)

LoadModule ibm_app_server_module drive_letter:/WebSphere/AppServer/bin/mod_ibm_app_server.dll
NcfAppServerConfig BootFile drive_letter:\WebSphere\AppServer\properties\bootstrap.properties
Alias /IBMWebAS/ "drive_letter:/WebSphere/AppServer/web/"
Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 4.0

Websphere Application Server Version 4.0 requires the following entries in the HTTP configuration file for the Web server:

UNIX
LoadModule ibm_app_server_http_module/opt/WebSphere40/AppServer/bin/mod_ibm_app_server_http.so
AddModule mod_app_server_http.c
Alias /Wssamples "/opt/WebSphere40/AppServer/WSsamples/"
WebSpherePluginConfig /opt/WebSphere40/AppServer/configplugin-cfg.xml

Note that the above entry for LoadModule points to the mod_ibm_app_server_http.so file, which is Solaris-specific. For other UNIX platforms specify the library accordingly by checking the file extension in the /WebSphere/AppServer/bin directory. For AIX, usually WebSphere Application Server installs under the /usr directory. So, change the file based on your installation root.

Windows NT or 2000
LoadModule ibm_app_server_http_module drive_letter:/WebSphere40/AppServer/bin/mod_ibm_app_server_http.dll
Alias /Wssamples "drive_letter:/WebSphere40/AppServer/WSsamples/"
WebSpherePluginConfig drive_letter:\WebSphere40\AppServer\config\plugin-cfg.xml
Creating multiple instances of IBM HTTP Server for WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have upgraded to IBM HTTP Server Version 1.3.19 and configured IBM HTTP Server for Version 3.5 using the previous section.

  1. Copy the httpd.conf file and name the copy httpd2.conf. Open an editor on httpd2.conf and remove lines corresponding to Version 3.5. That is, remove the lines that added in the previous section, "Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 4.0."
  2. Select the port for the second instance. Select the port that is not in use by any other application. Open an editor on the httpd2.conf file and change the port 80 to 81.
  3. UNIX only: Copy the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl and name the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl2. Open and editor on apachectl2 and modify the variables PIDFILE and HTTPD to point to httpd2.pid and httpd2.conf as shown below (the directory /opt/IBMHTTPD is assumed to be IBM_HTTP_SERVER_ROOT_DIR:
    PIDFILE=/opt/IBMHTTPD/logs/httpd2.pid
    
    HTTPD="/opt/IBMHTTPD/bin/httpd -f /opt/IBMHTTPD/conf/httpd2.conf"
      Warning: The above steps in this section have you configure the httpd.conf file. The http.conf file contains information such as log files, root directory, and security information in addition to configuration information. If changes beyond those outlined in these steps are needed, consult the IBM HTTP Server documentation before making the changes. Also, you might want to create a corresponding IBM HTTP Server administrative server for each IBM HTTP Server instance created. An IBM HTTP Server administrative server is basically another instance of IBM HTTP Server using a different port (8008 instead of 80) and a different configuration file (admin.conf instead of httpd.conf).

  4. Start the IBM HTTP Server instances.

    UNIX

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command

    apachectl start
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command
    apachectl2 start

    Windows NT

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command

    apache-f .\conf\httpd.conf
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command
    apache-f .\conf\httpd2.conf

Creating and configuring multiple instances of IBM HTTP Server for a single installation of WebSphere Application Server Version 4.0

The following steps assume that you have installed WebSphere Application Server Version 4.0 and configured it for IBM HTTP Server 1.3.19.

  1. Copy the httpd.conf file and name the copy httpd2.conf. Open an editor on httpd2.conf and modify it to point to the WebSphere plug-in configuration file of the second instance. For example:
    WebSpherePluginConfig I:/WebSphere/AppServer/config/plugin-cfg2.xml
  2. Select the port for the second instance. Select the port that is not being used by any other application. Open an editor on the httpd2.conf file and change the port 80 to 81.
  3. UNIX only: Copy the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl and name the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl2. Open and editor on apachectl2 and modify the variables PIDFILE and HTTPD to point to httpd2.pid and httpd2.conf as shown below (the directory /opt/IBMHTTPD is assumed to be IBM_HTTP_SERVER_ROOT_DIR:
    PIDFILE=/opt/IBMHTTPD/logs/httpd2.pid
    
    HTTPD="/opt/IBMHTTPD/bin/httpd -f /opt/IBMHTTPD/conf/httpd2.conf"
      Warning: The above steps in this section have you configure the httpd.conf file. The http.conf file contains information such as log files, root directory, and security information in addition to configuration information. If changes beyond those outlined in these steps are needed, consult the IBM HTTP Server documentation before making the changes. Also, you might want to create a corresponding IBM HTTP Server administrative server for each IBM HTTP Server instance created. An IBM HTTP Server administrative server is basically another instance of IBM HTTP Server using a different port (8008 instead of 80) and a different configuration file (admin.conf instead of httpd.conf).

  4. Start the IBM HTTP Server instances.

    UNIX

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command

    apachectl start
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command
    apachectl2 start

    Windows NT

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command

    apache-f .\conf\httpd.conf
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command
    apache-f .\conf\httpd2.conf

Creating and configuring multiple instances of IBM HTTP Server for multiple installations of WebSphere Application Server Version 4.0

The following steps assume that you have installed WebSphere Application Server Version 4.0 and configured it for IBM HTTP Server 1.3.19.

  1. Copy the httpd.conf file and name the copy httpd2.conf. Open an editor on httpd2.conf and modify it to point to the WebSphere plug-in configuration file of the second instance. For example:
    WebSpherePluginConfig I:/WebSphere/AppServer2/config/plugin-cfg.xml
  2. Select the port for the second instance. Select the port that is not being used by any other application. Open an editor on the httpd2.conf file and change the port 80 to 81.
  3. UNIX only: Copy the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl and name the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl2. Open and editor on apachectl2 and modify the variables PIDFILE and HTTPD to point to httpd2.pid and httpd2.conf as shown below (the directory /opt/IBMHTTPD is assumed to be IBM_HTTP_SERVER_ROOT_DIR:
    PIDFILE=/opt/IBMHTTPD/logs/httpd2.pid
    
    HTTPD="/opt/IBMHTTPD/bin/httpd -f /opt/IBMHTTPD/conf/httpd2.conf"
      Warning: The above steps in this section have you configure the httpd.conf file. The http.conf file contains information such as log files, root directory, and security information in addition to configuration information. If changes beyond those outlined in these steps are needed, consult the IBM HTTP Server documentation before making the changes. Also, you might want to create a corresponding IBM HTTP Server administrative server for each IBM HTTP Server instance created. An IBM HTTP Server administrative server is basically another instance of IBM HTTP Server using a different port (8008 instead of 80) and a different configuration file (admin.conf instead of httpd.conf).

  4. Start the IBM HTTP Server instances.

    UNIX

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command

    apachectl start
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command
    apachectl2 start

    Windows NT

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command

    apache-f .\conf\httpd.conf
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command
    apache-f .\conf\httpd2.conf

Configuring a single instance of a Web server with WebSphere Application Server Versions 3.5 and 4.0

The following section provides the steps required for using a single Web server with WebSphere Application Server Versions 3.5 and 4.0. When you use a single instance of a Web server with multiple instances of WebSphere, there cannot be a common Web context root present in both instances of WebSphere. If common context roots are present, then the last-configured plug-in will service the requests.

Configuring a single instance of IBM HTTP Server with WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have installed WebSphere Application Server Version 3.5 and configured it for IBM HTTP Server 1.3.19 and that you installed Version 4.0 without selecting the plug-in choice during installation.

To confgure a single instance, add the following lines at the bottom of the httpd.conf file of IBM HTTP Server based on your WebSphere Application Server Version 4.0 installation root.

UNIX

LoadModule ibm_app_server_http_module/opt/WebSphere/AppServer40/bin/mod_ibm_app_server_http.so
AddModule mod_app_server_http.c
Alias /WSsamples "/opt/WebSphere/AppServer40/WSsamples/"
WebSpherePluginConfig /opt/WebSphere/AppServer40/configplugin-cfg.xml

Note that the above entry for LoadModule points to mod_ibm_app_server_http.so, which is Solaris-specific. For other UNIX platforms, specify the library according to the file extension in the /WebSphere/AppServer/bin directory. For AIX, WebSphere Application Server usually installs into the /usr directory.

Windows NT

LoadModule ibm_app_server_http_module e:/WebSphere/AppServer40/bin/mod_ibm_app_server_http.dll
Alias /WSsamples "e:/WebSphere/AppServer40/WSsamples/"
WebSpherePluginConfig e:\WebSphere\AppServer40\config\plugin-cfg.xml
Configuring a single instance of iPlanet Web Server with WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have installed WebSphere Application Server Version 3.5 and configured it for iPlanet Web Server and that you installed WebSphere Application Server Version 4.0 without selecting the plug-in choice during installation.

To configure a single instance, add the following lines at the bottom of the obj.conf file of Sun ONE (iPlanet) Web Server V4.1, or at the bottom of the magnus.conf file of Sun ONE (iPlanet) Web Server V6.0, based on your WebSphere Application Server Version 4.0 installation root.

UNIX

Init fn="load-modules" funcs="as_init,as_handler,as_term" shlib="/opt/WebSphere40/AppServer/bin/libns41_http.so"
Init fn="as_init" bootstrap.properties=" /opt/WebSphere40/AppServer/config/plugin-cfg.xml"
Service fn="as_handler"

Note that the above entry for LoadModule points to libns41_http.so, which is Solaris-specific. For other UNIX platforms, specify the library according to the file extension in the /WebSphere/AppServer/bin directory. For AIX, WebSphere Application Server usually installs into the /usr directory.

Windows NT

Init fn="load-modules" funcs="as_init,as_handler,as_term" shlib="E:\WebSphere40\AppServer\bin\libns41_http.dll"
Init fn="as_init" bootstrap.properties=" E:\WebSphere40\AppServer\config\plugin-cfg.xml"
Service fn="as_handler"
Configuring a single instance of Microsoft IIS with WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have installed WebSphere Application Server Version 3.5 and configured it for IIS and that you installed WebSphere Application Server Version 4.0 without selecting the plug-in choice during installation.

  1. Start the Internet Service Manager application.
  2. Create a new Virtual Directory for the Web site instance you want to work with WebSphere Application Server. To do this with a default installation, expand the tree on the left until you see Default Web Site. Right-click on Default Web Site and select New -> Virtual Directory. In the wizard for adding a Virtual Directory, do the following:
    1. In the space provided for Alias to be used to Access Virtual Directory, type sePlugins.
    2. In the space provided for Enter the physical path of the directory containing the content you want to publish, browse the WebSphere Application Server bin directory. For What access permissions do you want to set for this directory, check the Allow Execute Access check box.
    3. Click Finish and a virtual directory will be added to your default Web site entitled sePlugins.
  3. Add the ISAPI filter into the IIS configuration. Right-click on the host name in the tree on the left and select Properties. In the Properties dialog, do the following:
    1. On the Internet Information Services tab, select WWW Service in the Master Properties drop-down box and click Edit.
    2. In the WWW Service Master Properties window that opens, click on the ISAPI Filters tab and then the Add button. This opens the Filter Properties window.
    3. For Filter Name, type iisWASPlugin.
    4. For Executable, click Browse and go into the WebSphere bin directory and select the iisWASPlugin_http.dll file. Then, click OK until all open windows are closed.
  4. Add the variable Plugin Config to the registry under the path HKEY_LOCAL_MACHINE -> SOFTWARE -> IBM -> WebSphere Application Server -> 4.0. Set the value for this variable to the location of the plugin-cfg.xml file.
Configuring a single instance of Domino with WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have installed WebSphere Application Server Version 3.5 and configured it for Domino. Follow the steps to enable the HTTP Transport plug-in to work correctly with Domino Version 5.05 or 5.06. The following modifications are not made by the WebSphere installation program and must be performed manually.

  1. Start the Domino server.
  2. Access the file /webadmin.nsf using your Web browser (for example, http://hokie2ks.raleigh.ibm.com/webadmin.nsf). The browser should prompt you for a password. Give the short name for the administrator and the administrator password.
  3. Click on the Configuration link on the left side of the page.
  4. Click on the Servers link on the top-left center of the page.
  5. Double-click on the server you want to work with WebSphere Application Server.
  6. Click Edit Server on the top-left of the center window.
  7. Click Internet Protocols in the middle of the page.
  8. Under DSAPI in the middle-right of the page, add the path to the Domino plug-in. The plug-in is installed into the WebSphere Application Server bin directory.
  9. Click Save and Close on the upper-left of the center window.
  10. Define the location of the configuration file.

    UNIX

    Set the WAS_HOME environment variable to point to WebSphere Application Server Version 4.0 root directory.

    Windows

    Add the variable Plugin Config to the registry under the path HKEY_LOCAL_MACHINE -> SOFTWARE -> IBM -> WebSphere Application Server -> 4.0. Set the value for this variable to the location of the plugin-cfg.xml file.

  11. Restart the Domino server. When the server is starting, you should see something similar to the following:
    02/12/2001 03:05:09 PM  JVM: Java Virtual Machine initialized.
    WebSphere DSAPI filter loaded
    02/12/2001 03:05:10 PM  HTTP Web Server started

Configuring virtual hosts in WebSphere Application Server Version 4.0

This section describes how to configure virtual hosts for Version 4.0. For general information on virtual hosts, see the Version 4.0 InfoCenter.

Configuring a virtual host for the Advanced Edition
  1. Write down the port used by the Web server configured for this WebSphere Application Server instance. For example, the port is 81.
  2. Start the administrative server and administrative client. In the administrative console, select Virtual Hosts, select the default_host in the right-hand pane, right click on the default_host, and select Properties.
  3. Add *.81 to the Host Aliases list and apply the changes.
Configuring a virtual host for the Advanced Single Server Edition
  1. Write down the port to be added to the list of virtual hosts. For example, the port is 81.
  2. Open the \WebSphere\AppServer40\config\server-cfg.xml file and add the above port (for example, 81) under virtual hosts:
    <aliases xmi:id="HostAlias_5" hostname="*" port="81"/>

    Following is the sample section of the file after adding the above entry:

    <virtualHosts xmi:id="VirtualHost_1" name="default_host">
    <aliases xmi:id="HostAlias_1" hostname="*" port="9080"/>
    <aliases xmi:id="HostAlias_2" hostname="*" port="9443"/>
    <aliases xmi:id="HostAlias_3" hostname="*" port="80"/>
    <aliases xmi:id="HostAlias_4" hostname="*" port="443"/>
    <aliases xmi:id="HostAlias_5" hostname="*" port="81"/>
    ...

Uninstalling WebSphere Application Server

This section covers the following:

Uninstalling WebSphere Application Server Version 3.5 where there is a co-existant installation of WebSphere Application Server Version 4.0 FixPak 2 (4.0.2)
Uninstalling Version 3.5 on AIX

To uninstall Version 3.5 on AIX, do the following:

  1. Move to a command prompt for the /usr/lpp directory.
  2. Delete the package directories corresponding to the Version 3.5 installation. Remove the directories starting with IBMWebAS but not having the identifier WAS.

    WARNING: Do not remove the packages starting with IBMWEBAS.base.WAS.

  3. Run smit and remove Version 3.5.
Uninstalling Version 3.5 on Windows NT or 2000

You might encounter unexpected behavior when uninstalling an installation of WebSphere Application Server where there are co-existent installations. This section provides some additional steps that you might need to take when uninstalling Version 3.5 on Windows. It is recommended that you manually execute uninstse.exe for uninstalling Version 3.5 and uninstWAS40.exe for uninstalling WebSphere 4.0. These files are located in root directory of the installation. Note that, after installing 4.0, the Windows Add/Remove Programs Panel no longer indicates that 3.5 is installed, the only way to uninstall is using uninstse.exe command. After uninstalling 3.5, the Windows Add/Remove Programs Panel believes that Version 4.0 is no longer installed. The only way to uninstall 4.0 is to execute uninstWAS40.exe.

To uninstall Version 3.5 on Windows, go to the Websphere Application Server Version 3.5 directory \WebSphere35\AppServer and run uninstse.exe. The program will uninstall Version 3.5.

As a consequence of the uninstallation, if single instance of IBM HTTP Server is the Web server used, the WebSphere plug-in information for Version 4.0 is removed while the Version 3.5 plug-in is left in the configuration file. After uninstalling 3.5, validate that the Version 4.0 Web server configuration file is correct. Refer to "Configuring a single instance with WebSphere Application Server Versions 3.5 and 4.0" to find out the entries required in a Web server configuration file to support Version 4.0.

Uninstalling Version 3.5 or Version 4.0 on HP-UX (Defect 115384.RN)

If you have installed WebSphere Application Server Version 3.5 before installing Version 4.0 on your machine, you could receive the following error message when uninstalling Version 3.5:

java.lang.NoClassDefFoundError: installer/util/PTFAndExtensionsUninstaller

Or, if you have installed WebSphere Application Server Version 4.0 after installing Version 3.5, you could receive the following error message when uninstalling Version 4.0:

java.lang.NoZClassDefFoundError: JConfig

To work around this problem, perform one of the following steps:

  • Back up the /usr/bin/juninst file to the /usr/bin/juninst_35 file before installing WebSphere Application Server Version 3.5 and back up the /usr/bin/juninst file to the /usr/bin/juninst_40 file before installing WebSphere Application Server Version 4.0.

    You can uninstall WebSphere Application Server Version 3.5 or Version 4.0 by copying back the respective backed up files and running the respective uninstaller.

  • If you have installed WebSphere Application Server Version 3.5 or Version 4.0 on your machine, then use these techniques:
    1. Back up the /usr/bin/juninst file to the /usr/bin/juninst_40 file.
    2. Create the /usr/bin/juninst file with the following lines in it:
      /usr/WebSphere/AppServer/java/bin/java -classpath /usr/bin/uinstall.jar Uninstaller $1 $2 $3.

      Note: This is assuming that the WebSphere Application Server Version 3.5 installation is in the /usr/WebSphere/AppServer directory.

    3. Save the file and give rx permission and run the uninstaller.
    4. Rename the /usr/bin/juninst_40 file to the /usr/bin/juninst file for WebSphere Application Server Version 4.0 uninstallation.
Uninstalling WebSphere Application Server Version 4.0 Advanced Edition or Advanced Single Server Edition if there are multiple installations

The following section discusses uninstalling when you have more than one version of WebSphere Application Server Version 4.0 installed on your system.

UNIX

When you have multiple installations of WebSphere Application Server, packages contain information of only the last installation. Use uninstall.sh in the Websphere Application Server installation root to uninstall a particular installation.

Windows NT or 2000

When you have multiple installations of WebSphere Application Server, the registry contains information of only the last installation. In case of multiple installations of the Advanced Edition, the Services panel contains reference to only the last installation. To uninstall each Websphere Application Server installation, run a command such as the following in a command window:

c:\winnt\isuninst.exe -y -f WEBSPHERE_INSTALLATION_ROOT\DeISL1.isu

For example, to uninstall an installation in C:\WebSphere40\AppServer, run the command:

c:\winnt\isuninst.exe -y -f C:\WebSphere40\AppServer40\DeISL1.isu

Note that, when an instance of WebSphere Application Server is uninstalled, the Windows registry information for WebSphere Application Server is deleted (and the entry is removed from the Services panel if an Advanced Edition is uninstalled).

Using WebSphere Application Server tools

Use WebSphere Application Server tools as needed to support coexistence.

Updating the PATH variable for multiple tools on Windows

Installing WebSphere Application Server Version 4.0 on Windows updates the system variable PATH, potentially affecting tools with the same name across installations. To run tools with conflicting names, alter the PATH environment variable in a command window and place the directory for the former WebSphere installation before the directory for the latter WebSphere installation (for example: PATH=E:\WebSphere\AppServer\35\bin;%PATH%). Then, invoke the tools from bin directory.

Specifying the bootstrap port

Specify the bootstrap port if it changes. In coexistence environments, you must configure different WebSphere instances with different bootstrap ports. While invoking the tools, specify the bootstrap port of the server you are trying to access. For example, if the bootstrap port is 901, to start the administrative client on Windows, enter adminclient.bat localhost 901. Note that invoking such tools with the help option will provide information on how to specify the bootstrap port.

For the WSCP tool, to specify a different bootstrap port and host name, you must create a properties file specifying the details. See the Version 4.0 InfoCenter for details on using the WSCP tool.

Programmatic changes to the bootstrap port

Make programmatic changes required for coexistence. For example, as noted above, you must configure different WebSphere Application Server instances with different bootstrap ports. While accessing the JNDI service by the clients running in a different process than that of the WebSphere process, specify the provider URL with the the bootstrap port. This is required only if bootstrap port is other than 900. For example:

Properties env = new Properties();
env.put("java.naming.provider.url",iiop://localhost:901);
InitialContext ic = new InitialContext(env);
Go to previous article: Migrating to supported transaction support Go to next article: Developing applications

 

 
Go to previous article: Migrating to supported transaction support Go to next article: Developing applications