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:
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.
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 domain configuration of WebSphere Application Server Advanced
Edition from a single installation
Multiple domain configuration of WebSphere Application Server Advanced
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.
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.
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 WebSphere Application Server Advanced Edition Version 4.0, where both use a
common Web server
Assuming Version 3.5 is already installed on your system, complete the following steps
to enable installations of WebSphere
Application Server to co-exist. For these steps, the assumed Version 3.5
installation root is \WebSphere35\AppServer.
Use XMLConfig in WebSphere Application Server Version 3.5 to back up the
configuration so that you can repair inadvertent mistakes in configurations.
Stop WebSphere Application Server Version 3.5.
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.
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.
Install WebSphere Application Server Advanced Edition Version 4.0.
For coexistence of Versions 3.5 and 4.0, specify a different
database for your repository when prompted by the Version 4.0 installation
program. Also, 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.
After successfully installing WebSphere Application Server Advanced Edition Version
4.0, create the database that is specified in the install screens (for
example, WAS40). On Windows with DB2 as the repository, the specified
database will be created when system reboots.
Fix conflicting ports in the WebSphere Application Server instances. Choose
port numbers not being used by other applications. For the Version 4.0
Advanced Edition, add com.ibm.ejs.sm.adminServer.lsdPort=9001 and
com.ibm.ejs.sm.adminServer.bootstrapPort=901 to the 4.0
admin.config file in the \WebSphere40\AppServer\bin directory. Select an unused port.
Write down the name of the bootstrap port.
Configure a virtual host, if needed. For information on
virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
Start both releases of WebSphere Application Server.
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 example, if the bootstrap port is 901, to start the
administrative client on Windows, enter adminclient.bat localhost 901.
For information, see "Using WebSphere Application Server
tools."
Stop the WebSphere Application Server administrative server.
Note that, on Windows, if both versions are running and the administrative
server (either Version 3.5 or 4.0) is stopped using the
Services panel, the last-started application server stops and leaves the other
instance running, but the Services panel shows both instances as stopped. Thus, use
the WebSphere administrative console to stop an administrative server (stop the node).
Enabling coexistence of WebSphere Application Server Version 3.5
and and later releases and WebSphere Application Server Advanced Edition Version 4.0 and
later releases 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.
Use XMLConfig in WebSphere Application Server Version 3.5 to back up the
configuration so that you can repair inadvertent mistakes in configurations.
Stop WebSphere Application Server Version 3.5.
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.
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.
Install WebSphere Application Server Advanced Edition Version 4.0.
For coexistence of Versions 3.5 and 4.0, specify a different
database for your repository when prompted by the Version 4.0 installation
program. Also, specify a different location (for example, \WebSphere40\AppServer) for
the installation directory from that of Version 3.5. When installing Version
4.0, select the Web server plug-in that you need to supoort a second
instance of the Web server. If you are using IBM HTTP Server, the installation
program does not give the option of creating a second instance configuration file;
thus, after installation, fix the Web server configuration
manually.
After successfully installing WebSphere Application Server Advanced Edition Version
4.0, create the database that is specified in the install screens (for
example, WAS40). On Windows with DB2 as the repository, the specified
database will be created when system reboots.
Fix conflicting ports in the WebSphere Application Server instances. Choose
port numbers not being used by other applications. For the Version 4.0
Advanced Edition, add com.ibm.ejs.sm.adminServer.lsdPort=9001 and
com.ibm.ejs.sm.adminServer.bootstrapPort=901 to the 4.0
admin.config file in the \WebSphere40\AppServer\bin directory. Select an unused port.
Write down the name of the bootstrap port.
Configure a virtual host to support the second Web server
instance, if needed. For information on virtual hosts, see the WebSphere
Application Server Version 4.0 InfoCenter.
Start both releases of WebSphere Application Server.
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 example, if the bootstrap port is 901, to start the
administrative client on Windows, enter adminclient.bat localhost 901.
For information, see "Using WebSphere Application Server
tools."
Stop the WebSphere Application Server administrative server.
Note that, on Windows, if both versions are running and the administrative
server (either Version 3.5 or 4.0) is stopped using the
Services panel, the last-started application server stops and leaves the other
instance running, but the Services panel shows both instances as stopped. Thus, use
the WebSphere administrative console to stop an administrative server (stop the node).
Enabling coexistence of multiple domains of WebSphere Application
Server Advanced Edition Version 4.0 from a single installation using a single instance
of a Web server
This section describes how to configure multiple domains from one installation of
WebSphere Application Server Advanced Edition.
Install WebSphere Application Server Advanced Edition Version 4.0. For
these steps, the installation root directory is \WebSphere\AppServer.
Copy the admin.config file in the directory \WebSphere\AppServer, naming it
admin-sec.config. If you have already started the WebSphere Application
Server before making a copy, open an editor on the admin-sec.config file and
change the following properties to true.
install.initial.config=true
com.ibm.ejs.sm.adminServer.createTables=true
Open an editor on the admin-sec.config file and make the following changes:
Change the conflicting ports. Add the following to the bottom of the file:
Change the log file names. Edit the respective properties to the following. Note that
the properties should each be on one line, though some appear here on more than one
line to improve readability.
Copy the adminserver.(sh/bat) file in \WebSphere\AppServer\bin and name the copy
adminserver-sec.(sh/bat).
Optional: If you need different security settings for different domains, copy
the \WebSphere\AppServer\properties\sas.server.properties file and change the copy
to meet your needs. See the Version 4.0 InfoCenter for more details.
Change the property com.ibm.CORBA.ConfigURL in the admin.config file to point
to the new file. For example:
Copy the setupCmdLine.(sh/bat) file and name it setupCmdLine-sec.(sh/bat).
Then, open an editor on setupCmdLine-sec.(sh/bat) and change SERVERSAS to point to
the new properties file. Also, if desired, change CLIENTSAS and WCSCLIENTSAS to
point to the new files.
Open an editor on the adminserver-sec.(sh/bat) file and change
%WAS_HOME%\bin\admin.config to %WAS_HOME%\bin\admin-sec.config.
If you changed the location of the sas.*.properties files in earlier steps,
look for the setupCmdLine.(sh/bat) invocation in the adminserver-sec.(sh/bat) file and
change adminserver-sec(sh/bat) to invoke the setupCmdLine-sec.(sh/bat) file.
Start the first WebSphere Application Server domain:
Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
Run adminserver.(sh/bat).
Start the administrative console using the command adminclient.(sh/bat).
Start the second WebSphere Application Server domain:
Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
Run adminserver-sec.(sh/bat).
Start the administrative console using the command
adminclient.(sh/bat) localhost 901
If you modified client CLIENTSAS properties in an earlier step,
create a separate copy of the adminclient.(sh/bat) file to invoke the modified
setupcmdline.(sh/bat) file and run the modified adminclient script for the
second instance.
Deploy your application.
Copy the EAR file. You need two copies of the EAR file.
Give each EAR file a unique name. Each EAR file needs a unique name because all instances share the installableApps directory.
Deploy the uniquely named EAR files. During deployment, each instance accesses a subdirectory in the installedApps directory named for each unique EAR file.
The result is each instance deployed into a subdirectory in the installedApps directory.
It is recommended that you use the Application Assembly Tool to build the EAR file
for deployment. The EAR file can then be installed using the administrative console.
If you are using the default server in the second domain, modify conflicting ports
in the default server of the second domain. (If you are not using the default server
in the second domain, this step is not required.)
In the second administrative console started in the 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.
In the second administrative console, select your server, Application
Servers, Default Server and, on the right in
the Default Server's Services tab, 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.
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:
Remove or rename the \WebSphere\AppServer\config\plugin-cfg.xml file.
The command generates \WebSphere\AppServer\config\plugin-cfg.xml. Copy the file
and name it plugin-cfg2.xml.
Manually merge the contents of the two files into the
/WebSphere/AppServer/config/plugin-cfg.xml file.
If you are using WebSphere Application Server versions that do not support the same version of a specific Web server, you must do the following steps to configure the plug-ins for multiple WebSphere Application Server instances:
Configure multiple Web servers instances with only one instance listening on port 80. The Web server listening on port 80 can have as few as 0 (zero) or one WebSphere plug-in.
For URLs that are handled by another Web server instance, you need to redirect the request of the Web server listening on port 80 to a different port so that the appropriate Web server/WebSphere product combination serves the request.
Change files and locations:
Select the default server in the administrative console of the second domain.
Specify different log files for the default server:
Select File in the right-hand panel.
Change the Standard Output and Standard Input file names so they are different
from that of the first domain.
Specify a different temporary directory for JSP files:
Select JVM Settings in the right-hand panel.
Specify the system property com.ibm.websphere.servlet.temp.dir=\WebSphere\AppServer\mytemp.
See the Version 4.0 InfoCenter for more information on specifying system properties.
Enabling coexistence of multiple domains of WebSphere Application
Server Advanced Edition Version 4.0 from a single installation using multiple
instances of a Web server
This section describes how to configure multiple domains from one installation of
WebSphere Application Server Advanced Edition.
Install WebSphere Application Server Advanced Edition Version 4.0. For
these steps, the installation root directory is \WebSphere\AppServer.
Copy the admin.config file in the directory \WebSphere\AppServer, naming it
admin-sec.config. If you have already started the WebSphere Application
Server before making a copy, open an editor on the admin-sec.config file and
change the following properties to true.
install.initial.config=true
com.ibm.ejs.sm.adminServer.createTables=true
Open an editor on the admin-sec.config file and make the following changes:
Change the conflicting ports. Add the following to the bottom of the file:
Change the log file names. Edit the respective properties to the following. Note that
the properties should each be on one line, though some appear here on more than one
line to improve readability.
Copy the adminserver.(sh/bat) file in \WebSphere\AppServer\bin and name the copy
adminserver-sec.(sh/bat).
Optional: If you need different security settings for different domains, copy
the \WebSphere\AppServer\properties\sas.server.properties file and change the copy
to meet your needs. See the Version 4.0 InfoCenter for more details.
Change the property com.ibm.CORBA.ConfigURL in the admin.config file to point
to the new file. For example:
Copy the setupCmdLine.(sh/bat) file and name it setupCmdLine-sec.(sh/bat).
Then, open an editor on setupCmdLine-sec.(sh/bat) and change SERVERSAS to point to
the new properties file. Also, if desired, change CLIENTSAS and WCSCLIENTSAS to
point to the new files.
Open an editor on the adminserver-sec.(sh/bat) file and change
%WAS_HOME%\bin\admin.config to %WAS_HOME%\bin\admin-sec.config.
If you changed the location of the sas.*.properties files in earlier steps,
look for the setupCmdLine.(sh/bat) invocation in the adminserver-sec.(sh/bat) file and
change adminserver-sec(sh/bat) to invoke the setupCmdLine-sec.(sh/bat) file.
Start the first WebSphere Application Server domain:
Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
Run adminserver.(sh/bat).
Start the administrative console using the command adminclient.(sh/bat).
Start the second WebSphere Application Server domain:
Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
Run adminserver-sec.(sh/bat).
Start the administrative console using the command
adminclient.(sh/bat) localhost 901
If you modified client CLIENTSAS properties in an earlier step,
create a separate copy of the adminclient.(sh/bat) file to invoke the modified
setupcmdline.(sh/bat) file and run the modified adminclient script for the
second instance.
If you are using the default server in the second domain, modify conflicting ports
in the default server of the second domain. (If you are not using the default server
in the second domain, this step is not required.)
In the second administrative console started in the 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.
In the second administrative console, select your server, Application
Servers, Default Server and, on the right in the
Default Server's Services tab, 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.
To set up multiple instances of the Web server instance, generate the plugin-cfg.xml
files for the two server instances:
where node_name is the host name that appears in the WebSphere Application
Server administrative console under the WebSphere administrative domain. The
command generates \WebSphere\AppServer\config\plugin-cfg.xml.
Specify a virtual host, if needed. For information on
virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
Change files and locations:
Select the default server in the administrative console of the second domain.
Specify different log files for the default server:
Select File in the right-hand panel.
Change the Standard Output and Standard Input file names so they are different
from that of the first domain.
Specify a different temporary directory for JSP files:
Select JVM Settings in the right-hand panel.
Specify the system property com.ibm.websphere.servlet.temp.dir=\WebSphere\AppServer\mytemp.
See the Version 4.0 InfoCenter for more information on specifying system properties.
Enabling coexistence of multiple domains of WebSphere Application
Server Advanced Edition Version 4.0 from multiple installations
This section describes how to run multiple instances of WebSphere Application
Server Advanced Edition. 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 Edition once
on a single machine. Then, complete the steps below.
Install the second instance of WebSphere Advanced 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. Further, choose a different database
repository than that of the previous installation.
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:
Start the first WebSphere Application Server domain:
Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
Run adminserver.(sh/bat).
Start the administrative console using the command adminclient.(sh/bat).
Start the second WebSphere Application Server domain:
Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
Run adminserver-sec.(sh/bat).
Start the administrative console using the command
adminclient.(sh/bat) localhost 901
If you modified client CLIENTSAS properties in an earlier step,
create a separate copy of the adminclient.(sh/bat) file to invoke the modified
setupcmdline.(sh/bat) file and run the modified adminclient script for the
second instance.
If you are using the default server in the second domain, modify conflicting ports
in the default server of the second domain. (If you are not using the default server
in the second domain, this step is not required.)
In the second 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.
In the second administrative console, select your server, Application
Servers, Default Server and, on the right in the
Default Server's Services tab, 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.
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:
Remove or rename the \WebSphere\AppServer\config\plugin-cfg.xml file.
where node_name is the host name that appears in the WebSphere Application
Server administrative console under WebSphere administrative domain. The command
generates \WebSphere\AppServer\config\plugin-cfg.xml.
The command generates \WebSphere\AppServer2\config\plugin-cfg.xml.
Manually merge the contents of the two generated files and replace both the files with
the merged one.
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.
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.
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:
Start the WebSphere Application Server Advanced Single Server product:
Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
Run sartupServer(sh/bat).
Start the WebSphere Application Server Advanced Edition product:
Go to a command prompt and move to the \WebSphere\AppServer2\bin directory.
Run adminserver-sec.(sh/bat).
Start the administrative console using the command
adminclient.(sh/bat) localhost 901
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.)
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.
In the second administrative console, select your server, Application
Servers, Default Server and, on the right in the
Default Server's Services tab, 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.
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:
Run the command for the Advanced Single Server Edition (shown here on two lines
to improve readability):
The command generates /WebSphere/AppServer2/config/plugin-cfg.xml.
Manually merge the contents of the two generated files and replace both the files with
the merged one.
Enabling coexistence of WebSphere Application Server Advanced Edition
Version 3.5 and WebSphere Application Server Advanced Edition Version 4.0 with security on
When security is enabled, it is also needed to configure each instance with a different
LSDSSL port which is not used. WebSphere Application Server Version 3.5 uses 9001 as LSDSSL port.
To specify LSDSSL port in WebSphere Application Server Advanced Edition Version 4.0, add the
following property in the admin.config file:
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
Stop the IBM HTTP Server and IBM HTTP Administration servers.
Copy the httpd.conf file in the IBM HTTP Server conf directory
and name the copy httpd-35.conf.
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
Stop the IBM HTTP Server and IBM HTTP Administration servers.
Copy the httpd.conf file in the IBM HTTP Server conf directory and name the
copy httpd-35.conf.
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 system's 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
In a Services dialog, stop the IBM HTTP Server and IBM HTTP Administration services.
Copy the httpd.conf file in the IBM HTTP Server conf directory
and name the copy httpd-35.conf.
Uninstall IBM HTTP Server 1.3.12.
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.
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.
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.
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:
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).
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.
Copy the httpd.conf file and name the copy httpd2.conf. Open an editor
on httpd2.conf and modify it to point to the second instance's WebSphere plug-in
configuration file. For example:
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.
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:
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).
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.
Copy the httpd.conf file and name the copy httpd2.conf. Open an editor
on httpd2.conf and modify it to point to the second instance's WebSphere plug-in
configuration file. For example:
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.
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:
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).
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.
Start the Internet Service Manager application.
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:
In the space provided for Alias to be used to Access Virtual Directory,
type sePlugins.
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.
Click Finish and a virtual directory will be added to your
default Web site entitled sePlugins.
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:
On the Internet Information Services tab, select WWW
Service in the Master Properties drop-down box and
click Edit.
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.
For Filter Name, type iisWASPlugin.
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.
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.
Start the Domino server.
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.
Click on the Configuration link on the left side of the page.
Click on the Servers link on the top-left center of the page.
Double-click on the server you want to work with WebSphere Application Server.
Click Edit Server on the top-left of the center window.
Click Internet Protocols in the middle of the page.
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.
Click Save and Close on the upper-left of the center window.
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.
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
Write down the port used by the Web server configured for this WebSphere
Application Server instance. For example, the port is 81.
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.
Add *.81 to the Host Aliases list and
apply the changes.
Configuring a virtual host for the Advanced Single Server Edition
Write down the port to be added to the list of virtual hosts. For example, the
port is 81.
Open the \WebSphere\AppServer40\config\server-cfg.xml file and add the
above port (for example, 81) under virtual hosts:
Uninstalling WebSphere Application
Server Version 3.5 where there is a coexistant 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:
Move to a command prompt for the /usr/lpp directory.
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.
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:
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:
Back up the /usr/bin/juninst file to the /usr/bin/juninst_40
file.
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.
Save the file and give rx permission and run the uninstaller.
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:
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).