Last updated 8/21/2001
This document contains the Release Notes for the WebSphere Application Server Advanced Single Server Edition Version 4.0.1 and Advanced Edition Version 4.0.1.
These notes will be updated periodically. For the latest version of these Release Notes, check the IBM WebSphere Application Server InfoCenter page at http://www.ibm.com/software/webservers/appserv/infocenter.html.
The following Web site lists the prerequisite products needed for IBM WebSphere Application Server:
http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html
The Connector Architecture for WebSphere Application Server Advanced Edition technology preview is available on the following Web site:
http://www.ibm.com/websphere/developer/downloads/jca.html
You can find the complete installation instructions at http://www.ibm.com/software/webservers/appserv/infocenter.html under "Installation documentation."
The Release Notes contain information about known defects and the workarounds. This document also includes some supplemental information for topics covered in the Application Server documentation.
Installation
and configuration
Migration
Starting
Application Server Components
Administrative
Console (GUI) and Command Line Tools
Application
Assembly Tool (AAT)
Resource
Analyzer
Web
servers
Data
access
Enterprise
Beans
Java
programming
Security
Object
Level Trace (OLT) and IBM Distributed Debugging
Transports
Workload
Management
National
Language Version Issues/Limitations
Samples
InfoCenter
If you install WebSphere Application Server on an AIX machine, and issue the
installp
command, you will receive errors for some of the installed
files. These errors do not affect the installation, running and uninstallation
of the product.
When you install WebSphere Application Server 4.0.1 on Linux (Intel), the packages are not registered with the RPM database. As a result, administrators cannot use native tools to uninstall WebSphere Application Server 4.0.1 Instead, follow the instructions in the article "Uninstalling WebSphere Application Server" to remove WebSphere Application Server from your machine. If you want to migrate an existing WebSphere Application Server installation to version 4.0.1, refer to the Migration overview for instructions.
When running a make file to compile Apache HTTP Server 1.3.19 on SuSE 7.1, kernel 2.4, an error is thrown because the ndbm.h header file is missing from the SuSE 7.1 Linux distribution.
To install Apache 1.3.19 on SuSE 7.1, kernel 2.4, complete steps such as the following to ensure that all needed header files are obtained:
apache_1.3.19.tar.Z 28-Feb-2001 06:11 2.9M 1.3.19 compressed source apache_1.3.19.tar.gz 28-Feb-2001 06:11 1.8M 1.3.19 gzipped source apache_1.3.19.zip 28-Feb-2001 10:34 2.4M 1.3.19 pkzipped source
Unpack the packaged source file that you downloaded using the appropriate
utility (uncompress
, gzip -d
or unzip
)
into a directory of your choice.
rpm -qa |
grep gdbm
to peek at the package. Note that there is normally a second
package named gdbm-1.8.0-25 also on the system when used with the above
command; the package gdbm-1.8.0-25 is not the right package.
rpm -ivh gdbm-devel
. You can verify the
installation by entering the command rpm -qa | grep gdbm
. You
should see: gdbm-devel-1.8.0-25.
configure --prefix=/usr/local/apache \ --enable-module=rewrite --enable-shared=rewrite \ --enable-module=proxy --enable-shared=proxy
make
to build the Apache server. Then,
install the Apache server by issuing the command make install
from the same directory. For more information on configuring, building and installing Apache HTTP Server, refer to the INSTALL file that comes with the Apache HTTP Server distribution.
The WebSphere Application Server installation program does not automatically upgrade the IBM HTTP Server product from an earlier version to the appropriate level that is needed for WebSphere 4.0.1. If you would like to preserve your IBM HTTP Server configuration information, do the following:
Updates to the WebSphere 4.0.1 httpd.conf file are done differently than in previous releases. In version 4.0.1, the WebSphere installion program updated the httpd.conf file with the new HTTP Transport plug-in directives. See InfoCenter section 3.2.4 for more information on WebSphere plug-in changes for 4.0.1
If you install WebSphere Application Server Advanced Single Server Edition with SuSe Version 7.1 and Netscape Version 4.7.6, you must change the following Netscape configuration values in order for the tree view on the left side of the administrative console to display properly.
http://your_machine_name:9090/admin
. If you used WebSphere Application Server Version 3.5 on Windows 2000 Server and then, while installing the Advanced Single Server Edition Version 4.0.1 using the Version 4.0.1 installation program, you select Backup and Uninstall, some of the Version 3.5 applications and other files or work may not be backed up.
If you attempt to uninstall the WebSphere Application Server on a Linux machine as a non-root user, the following error messages display:
Error trying to calculate for /opt/WebSphere/AppServer/properties/sas.server.props Error trying to calculate for /opt/WebSphere/AppServer/properties/sas.client.props
To avoid the errors, log in with the root
user ID and try
uninstalling the product again.
When running Apache HTTP Server on Redhat 7.1 Linux systems with the plug-in configured for SSL, before starting Apache you must set the LD_PRELOAD environment variable to the following value:
/usr/lib/libstdc++-libc6.1-1.so.2
For example, if you are using the korn shell, you enter the following before starting Apache HTTP Server:
export LD_PRELOAD=/usr/lib/libstdc++-libc6.1-1.so.2
The RR_MOVED directory may appear on the WebSphere product CD because of the limitation of eight directory levels on a CD. If the product documentation does not mention this directory, follow the documentation steps as though this directory does not exist.
The WebSphere Application Server installation program prompts you to specify one obj.conf file if you select the iPlanet plug-in. But, if you use more than one iPlanet server instance (more than one port), you must do some additional work to use more than one instance of iPlanet with WebSphere Application Server because each iPlanet instance uses a separate obj.conf file. When installing WebSphere Application Server, specify the obj.conf file for one of the iPlanet instances. Then, after installation, edit the obj.conf file for each of the other iPlanet instances so they also can serve WebSphere Application Server resources.
The setup log file after silent installation is wssetup.log. The log file can show up in a logs subdirectory off the root directory or off a product directory.
The WebSphere Application Server Advanced Single Server Edition installation information for Linux is located on the product Web site at www.ibm.com/software/webservers/appserv/infocenter.html.
If you select the Lotus Domino plug-in during WebSphere Application Server installation, the new DSAPI filter may not work properly on AIX and WIN platforms. This is because the WebSphere installation did not add the correct DSAPI filter file name.
The DSAPI filter files, which are located under the WAS_HOME/bin directory, include--
Use the following steps to enable the new DSAPI filter. (These steps assume AIX is the example operating system.)
/usr/WebSphere/AppServer/bin/libdomino5_http.a
The SSL enabled plug-in is not supported on Solaris with iPlanet Web Server. Nor is the SSL enabled plug-in supported on HP-UX with Apache HTTP Server or with iPlanet Web Server Version 4.1 SP7.
On Solaris 2.8 systems running the Domino Web server with the plug-in configured for SSL, the server will have an exception at startup. This results from some incompatibilities with Domino and C++ code. The fix for this is to disable the SSL transports in the plugin-cfg.xml file.
This problem has not been seen on Solaris 2.7 systems.
If you attempt to install WebSphere Application Server from a Windows 2000 remote machine, you will receive an error. To resolve this problem, copy the installation executable file to your local machine and run the install program from that machine.
If you are running Websphere Application Server Version 3.5 and Version 4.0.1 on the same Windows machine, remove the system environment variable WAS_HOME prior to running the PTF installer for Version 3.5. For completeness, you should also remove %WAS_HOME%\bin from the system PATH environment variable.
If you want to use the JNDI client on WebSphere Application Server Version 3.5.3 or Version 3.5.4 to access a Version 4.0.1 name server, you must apply efix PQ51387. This efix is available on the following Web site:
Follow the instructions in the readme.txt file to update the ujc.jar and ns.jar on WebSphere Application Server Version 3.5.x.
During installation, if you select Informix as the backend database and also select the remote database option, the installation program will not be able to configure the Informix database with the remote database option. To manually configure Informix, set the following property in the admin.config file after the installation completes.
com.ibm.ejs.sm.adminServer.dbifxIFXHOST=remote_host_name
If you are running WebSphere Application Server on a Solaris or HP-UX machine, you may receive the following error with a JSP file:
Failed to create a write with encoding:EUC-JP
The default EUC-JP of the converter.properties file is Cp33722C, but Solaris and HP-UX platforms do not support Cp33722C.
To work around this problem, change EUC-JP=Cp33722C
to
EUC-JP = EUC-JP
.
On some installations of iPlanet on an HP-UX machine, it is necessary to manually set the SHLIB_PATH variable to /usr/lib before starting iPlanet with a plug-in configured for SSL. For example, in the korn shell, issue the following command before invoking the command to start iPlanet.
export SHLIB_PATH=/usr/lib
After installing, Informix IDS_2000 has a load libc_r.a problem on AIX 4.3.3
even if the software installed without problems. If you run any Informix
command, such as oninit -ivy
, onstat -l
, or
onmode
, you will receive error messages.
To work around this error condition, do one of the following:
smit
tool.
mkdev -l aio0 ; chdev -P -l aio0 -a autoconfig=available
Please make sure that you install the DB2 fixpack as pointed out in the Supported Software Table at the following Web site:
www-4.ibm.com/software/webservers/appserv/doc/latest/idx_eas.htm
The patch allows a DB2 Version 7 DataSource to support the required cursor hold value. If you fail to apply the patch, and you have a connection which returns a resultSet, and then you commit the connection without closing the resultSet and try an operation on the connection which requires the connection to be "clean", that operation fails.
After you install WebSphere Application Server and all of its prerequisites on AIX, Netscape Communicator 4.73 (or older) may not start the next time. The following error message will indicate this failure:
Could not load program /afs/torolab.ibm.com/common/progs/netscape47/netscape_aix4: Symbol resolution failed for /usr/lib/libpthreads.a(shr.o) because: Symbol thread_unlock (number 121) is not exported from dependent module /afs/torolab.ibm.com/common/progs/netscape47/lib433/libc_r.a(shr.o). Symbol thread_waitlock (number 122) is not exported from dependent module /afs/torolab.ibm.com/common/progs/netscape47/lib433/libc_r.a(shr.o).
This error is caused because Netscape Communicator V4 uses a private copy of libc.a which must stay synchronized with other shared AIX libraries. If AIX updates are applied to your system, you may need to update the copy of libc.a used by Netscape Communicator.
You can download the updated version of libc.a and replace the one in the Netscape installation directory from the following URL:
ftp://aix.software.ibm.com/aix/efixes/netscape/aix433_libc/
Read and follow the instructions (in the README file) for downloading and replacing the libc.a in your existing Netscape installation.
If you run Netscape from AFS or DFS locations, you may not be able to do it yourself because of lack of write permission to the Netscape directory. If this is the case you need to contact your AFS/DFS administrator.
Alternatively, there is a new version (4.76i) of Netscape available for download that corrects this problem as well. You can download and install this version onto your local machine. The location for the download is:
ftp://aix.software.ibm.com/aix/efixes/netscape/aix43_installp/
If you uninstall WebSphere Application Server on an HP-UX machine without shutting down the server or if you attempt to install the product to the same directory as an existing version, the installation fails. In these cases, when the second installation process attempts to copy over files laid down by the first install, the process finds the files locked by the operating system and the installation fails.
To work around this problem, complete the following steps:
rm -rf
install_directory
, where install_directory is the
fully qualified location of the previous WebSphere installation.
After you install WebSphere Application Server on a Windows machine, you cannot change the name of the host machine. If you need to change the name of the machine, you will need to reinstall WebSphere Application Server.
If you click Cancel during the installation process, check the WebSphere Application Server installation directory to see if the product was installed. If the product was installed, then it is unusable and should be uninstalled using the normal uninstall procedures.
If your /usr partition is full, and you cannot find the IBM HTTP Server config file when installing Websphere Application Server with IBM HTTP Server and the IBM HTTP Server plugin, there might have been a problem installing IHS. Check /tmp/install.log. If you see a failure with the install_ihs_128.sh script, please check /var/adm/sw/swagent.log for errors. In that file, you will find a detailed error of what went wrong. IHS installs a 4 kilobyte file in /usr. Due to the way HP handles their partitions, you might have one megabyte of space left in /usr, and the IHS installation will still fail. If swagent.log says you are out of room in /usr while trying to install IHS, you will need to extend the /usr file system by the amount defined in /var/adm/sw/swagent.log. Once that is done, start the WebSphere Application Server installation again, and select IBM HTTP Server, and the IBM HTTP Server plug-in to install.
The install.sh script from the Merant Sequelink Server 5.1CD for Solaris
contains the statement which NISCAT
, which might cause the script
to fail for some systems.
This script assumes that this module is available on every Solaris system. If you run the install.sh script and it fails on this command, remove the command and the Merant Sequelink Server should install correctly.
To uninstall the WebSphere Application Server Advanced Edition, follow the instructions below for the appropriate platform:
AIX:
cd WASROOT rm -rf * cd /usr/lpp rm -rf IBMWebAS*
smit
and uninstall the IBMWebAS packages to do a final
cleanup.
cd /usr/bin
HP-UX:
cd WASROOT rm -rf * cd /var/adm/sw/products rm -rf IBMWebAS* cd /usr/bin
Linux platforms:
cd WASROOT rm -rf * cd /usr/bin
Solaris:
cd WASROOT rm -rf * cd /var/sadm/spool rm -rf WAS* cd /var/sadm/pkg rm -rf WAS* cd /usr/bin
Windows NT, Windows 2000:
regedit
to start the regedit.exe
file.
Remove all previous versions of IBM HTTP Server before installing WebSphere Application Server. Use the proper package removal utility for the given UNIX system to remove both the IBM HTTP Server directories as well as the IBM HTTP Server package registration with the given system's package repository. Simply removing the directories will cause an invalid detection of the old installation, as this leaves the system with an invalid package registry.
If the installation program finds a previous version of IBM HTTP Server on the system and you have selected to install the new version of this product, a warning dialog will display. The warning dialog requests that you cancel the current install, remove the older version of IBM HTTP Server, and restart the WebSphere Application Server install. However, the install will continue after clicking OK on this dialog, not giving you a chance to cancel the installation. Do not cancel the installation. Instead allow the installation to continue to completion and then manually remove the IBM HTTP Server packages and run the WebSphere Application Server installation process again, selecting only IBM HTTP Server and the IBM HTTP Server plug-in for installation and configuration. These steps will function properly in both migration and non-migration situations.
If the WebSphere Application Server Advanced Edition is installed and migrated into the same directory as a previous Advanced Single Server Edition installation, the Advanced Single Server Edition installation is no longer a valid installation. Do not run the Uninstall program, because it will uninstall the new Advanced Edition installation.
Further, if the WebSphere Application Server Advanced Edition is installed and migrated into the same directory as a previous Advanced Single Server Edition installation, the Advanced Single Server Edition property files will be lost. If you plan on manually migrating any of your property files, you should back up the Advanced Single Server Edition property files before installing the Advanced Edition.
If you installed the administrative component only, open an editor on the file $WASROOT/properties/sas.client.props and find the following line in the file:
com.ibm.CORBA.securityTraceOutput=$(WASROOT)/logs/sas.client.log
Replace $(WASROOT) with your WebSphere Application Server home directory.
If the WebSphere Application Server prerequisite checker finds Solaris patches that are higher or lower than the required patches on your system and there are multiple versions of a particular patch installed on the same system, the prerequisite checker will show all versions of the patch found. If a higher or equal version of the patch is installed, you can ignore the warning associated with the lower-version patch entry.
The Object Level Trace (OLT) and IBM Distributed Debugger install image requires that it be installed from a writable file system. Thus, on HP-UX, the default installation from the WebSphere Application Server installation program does not function.
To install the OLT/Debugger application on HP-UX, copy the install.class file in the hp/olt directory on the WebSphere CD to a writable file system. Assuming the WebSphere CD is mounted at /cdrom and the writable file system is at /tmp, the command is--
cp /cdrom/hp/olt/install.class /tmp
Next, install the OLT/Debugger using a graphical installation program or silent installation. To run the OLT/Debugger graphical installation program using the Java binary included with the WebSphere installation, enter the following command:
/cdrom/hp/java/bin/java -classpath /tmp install
To use a silent installation process:
destinationDirectory=/opt/ibm/debugger scriptPlay=true logToScreen=false
/cdrom/hp/java/bin/java -classpath /tmp install /tmp/install.script
When installing WebSphere Application Server Advanced Edition using a Typical Installation (installs the Application Server, IBM HTTP Server and DB2 UDB), you will receive a message to use JDBC 2 and to refer to the documentation. If your system is not set up for JDBC 2, the administrative server will not start and you will receive a data source error. To use JDBC 2, refer to the InfoCenter article "6.6.14.5: Additional administrative tasks for specific databases." The article states as follows as to using JDBC 2:
Enabling JDBC 2.0 with DB2 on Windows
To enable JDBC 2.0 use on Windows systems:
Perform the steps once for each system.
To see what JDBC level is in use on your system:
Enabling JDBC 2.0 with DB2 on UNIX
Before starting WebSphere Application Server, you need to call $INSTHOME/sqllib/java12/usejdbc2 to use JDBC 2.0. For convenience, you might want to put this in your root user's startup script. For example on AIX, add the following to the root user's .profile:
if [ -f /usr/lpp/db2_07_01/java12/usejdbc2 ] ; then . /usr/lpp/db2_07_01/java12/usejdbc2 fi
To determine if you are using JDBC 2.0, you can echo $CLASSPATH. If it
contains $INSTHOME/sqllib/java12/db2java.zip
, then JDBC 2.0 is in
use. If it contains $INSTHOME/sqllib/java/db2java.zip
, then JDBC
1.0 is in use.
If you have installed DB2 UDB 7.1 or have installed a version of DB2 UDB 7.2 that you did not obtain from the CD-ROM supplied with WebSphere Application Server Advanced Edition 4.0.x:
You must upgrade your installation with a special fixpack to make it compatible with WebSphere Application Server Advanced Edition 4.0.x. Obtain fixpack 3W from the following Web site: ftp://ftp.software.ibm.com/ps/products/db2/fixes/english-us/WAS4_FP3/. Follow the installation instructions in the patch README to apply it to your DB2 UDB installation.
If you install the version of DB2 UDB 7.2 provided with WebSphere Application Server Advanced Edition 4.0.x:
You are instructed by the installation information to check the prerequisites site at http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html to determine if your installation requires any fixpack. The prerequisites site instructs you to download and apply a special patch. This patch is not needed because the DB2 UDB 7.2 supplied with WebSphere Application Server Advanced Edition 4.0.x (otherwise known as DB2 UDB 7.2w) already has the patch.
When you are installing WebSphere Application Server, with the GUI installer in the Database Options panel or silently by using a response file, you are instructed to enter the path of the directory containing the database software for DBHome. This value does not work if you have chosen Informix as your administrative database. Enter the path of the directory containing the Informix Type 4 JDBC driver for DBHome field, rather than the path to the directory containing the database software.
When migrating from Version 3.0.2.x to Version 4.0.1, the WASPreUpgrade program is run. The program returns java.io.FileNotFoundException messages. Ignore those exception messages.
After you uninstall WebSphere Application Server, if you cannot restart the iPlanet Web server or the Apache HTTP server, the problem may be that the uninstall program did not remove the plugin information from the obj.conf file.
To work around this problem for iPlanet, remove the following lines from the obj.conf file:
Init fn="load-modules" funcs="as_init,as_handler,as_term" shlib="full/path/to/module" Init fn="as_init" bootstrap.properties="full/path/to/plugin/config/file" Service fn="as_handler"
To work around this problem for Apache, remove the following lines from the httpd.conf or srm.conf file:
LoadModule app_server_http_module full/path/to/module Optional AddModule mod_app_server_http.c WebSpherePluginConfig full/path/to/config
Then, restart the server.
Several differences exist between the migration process on Windows platforms and the migration process on UNIX or Linux platforms:
Topic | Windows platforms | UNIX platforms |
---|---|---|
Backup directory | c:\was3_backup\wasx_backup | $WAS_HOME/migration/backup |
Migration temporary directory | c:\was_migration | $WAS_HOME/migration/tmp |
Migration log file directory | c:\was_migration\logs | $WAS_HOME/migration/logs |
These differences may not be noted in the InfoCenter documentation on automated migration in article 3.2.2.1.
If you are migrating WebSphere from Release 3.x to Release 4.0.1
while running the WebSphere installation program and a severe error occurs while
saving the existing Release 3.x environment, perform the steps below to
migrate the Release 3.x configuration. Note that the steps are for
Windows- based systems; for UNIX-based systems add .sh
to the
command line.
waspreupgrade c:\backup_directory c:\current_3.x.x_WebSphere_directory wssylvester
where wssylvester is the adminNodeName. Note that in some cases the waspreupgrade command may not be totally successful. To ensure that a valid configuration has been saved, verify that the file c:\backup_directory\websphere_3x_backup.xml exists. If it does not, then enter the following command from the c:\current_3.x.x_WebSphere_directory:
xmlconfig -export c:\backup_directory\websphere_3x_backup.xml -adminNodeName wssylvester
WASPostUpgrade c:\backup-directory -adminNodeName wssylvester
A problem may occur after migrating a configuration from Release 3.x to Release 4.0.1 relating to the JDBC Driver configuration. The problem shows up with an error message similar to--
javax.naming.NamingException: ClassNotFoundException: COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource
This can happen if the data store in use required a prerequisite upgrade and this upgrade is stored in a different directory location than the original data store version. The problem occurs because the JDBC configuration that is defined in the Release 3.x configuration uses drivers from the original data store version and its related directory names. When this configuration is exported and then imported into the Release 4.0.1, the original directory names are used instead of the new data store version.
To correct the problem on the Advanced Edition, change the JDBC Driver Server class path entry to use the new data store directory names in the administrative console under the Resources tree.
To correct the problem on the Advanced Single Server Edition, modify the server configuration file in the config directory. The default file is server-cfg.xml but you can choose to use a different file. Modifications are required to Resource Provider stanzas to use the correct class path name. For example, if you are using DB2, change the following from:
<installedResourceProviders xmi:id="ResourceProviderRef_3" classpath="/home/ db2inst1//sqllib/java/db2java.zip" resourceProvider="JDBCDriver_3"/>
to:
<installedResourceProviders xmi:id="ResourceProviderRef_3" classpath="/home/ db2inst1//sqllib/java12/db2java.zip" resourceProvider="JDBCDriver_3"/>
The problem also may occur if you migrate and use the same directory structure. As to Windows NT, an old copy of db2java.zip remains in your lib directory. That copy is loaded instead of the one pointed to by the JDBC Driver Server class path. The solution is to remove the db2java.zip in the WebSphere lib directory.
If the following error is seen after completing migration, the server-cfg.xml file will not match up with the .ear file directories included in the installedApps directory:
Exception - No resource for object: com.ibm.ejs.models.base.config.applicationserver.impl.WebModuleRefImpl (uri: ChainTest.war) com.ibm.xmi.base.NoResourceException com.ibm.websphere.migration.exceptions. WASUpgradeInternalErrorException: MIGR0228E: Unable to save configuration files.
To correct this problem, manually delete any .ear directory found under the installedApps directory that is not listed as an installedApp in the server-cfg.xml file.
To run WASPostUpgrade more than once after migration has completed successfully and .ear files have been installed in the installedApps directory including a DefaultApplication.ear, the DefaultApplication.ear must be uninstalled before invoking WASPostUpgrade. No other .ear files must be uninstalled.
To uninstall the DefaultApplication.ear, do the following:
The term localhost might be localhost or the host name of the machine on which the product is running.
When you migrate from a previous version of WebSphere Application Server on a non-English Sun Solaris machine, the installation program will not detect the proper installation location of the previous install when attempting to migrate a Solaris, non-English, native-package that was installed to a location other than the default /opt location.
When migrating a multi-node model-clone domain to WebSphere Application Server 4.0.x, the following error will be displayed in the output of the XMLConfig Import when the same .ear file is migrated and installed on nodes other than the first node that is migrated:
XMC0100E: Update action is not supported on this type of object. To reinstall the application, use "delete" action followed by "create" action, on enterprise-application element.
Disregard this error message.
In addition, the Web and EJB module names contained in the .ear file installed on the first node that is migrated will be included in the repository. If the Web and EJB module names contained in the same .ear file installed on subsequent nodes through migration do not match, the .ear file installed on the first node that contains those modules must be manually installed and expanded on the node where the names do not match. Complete steps such as the following (for Windows NT or Windows 2000; do the equivalent for UNIX platforms):
EARExpander -ear e:\WebSphere\AppServer\installableApps\Big3App.ear -expandDir e:\WebSphere\AppServer\installedApps\Big3App.ear -operation expand -expansionFlags war
where e:\WebSphere\AppServer\installableApps\Big3App.ear is the .ear file you want to expand and e:\WebSphere\AppServer\installedApps\Big3App.ear is the directory in which to expand the .ear file.
If you plan to migrate from WebSphere Application Server Advanced Single Server Edition to the Advanced Edition, save a copy of the following directories before starting the migration process:
\config \installableApps \installedApps \properties
After the migration is successfully performed by the install process, restore the above mentioned directories back to the Advanced Edition install directory.
The format of the Systems Management database has changed significantly between release 3.x and release 4.0.x. If the database name that will be used for release 4.0.x is the same as was used for release 3.x, then the database must be removed and recreated during the migration process at the same time that prerequisites are updated. It is recommended that you use the default database name of was40.
When the pre-migration process completes, a file named WAS_MIGRATION_TEMP.properties is stored in /tmp directory and is also stored in the migration backup directory specified during the pre-migration process. If you upgrade the operating system level on this machine, you need to copy this file from the migration backup directory to the /tmp directory. The /tmp directory is emptied during the operating system level upgrade.
If you want to migrate from a previous version of WebSphere Application Server on a Solaris 2.6 machine, you must install all patches required by JDK 1.3 in order to run the pre-migration process. These patches are listed in the file README.sparc that comes with JDK 1.3.
When migrating from version 3.02 on Linux, an error may occur during pre-migration if JAVA_HOME is not defined in the WebSphere 3.02 setupCmdLine.sh file in the bin directory and the JAVA_HOME value cannot be correctly derived in the WebSphere 3.02 XMLConfig.sh file in the bin directory. To complete the migration, JAVA_HOME must be set to a valid value. Modify the JAVA_HOME setting in the WebSphere 3.02 setupCmdLine.sh file to point to a valid Java JDK 1.1.x directory to correct the problem and rerun the migration process again.
An error might occur if multiple ports are migrated for the same application server. Ports with duplicate entries might result. Use the WebSphere administrative console to modify the port values in the Web Services settings.
When migrating a multi-node model-clone domain to WebSphere Application Server 4.0.x, you must manually updated the Web server plug-in for each node after the final node has been inserted into the domain. To manually trigger an update of the configuration for the WebSphere plug-in, for each node:
When migrating a multi-node model-clone domain to WebSphere Application Server 4.0.x where the DefaultApplication.ear is created and installed in a server group, the following exception will be thrown when the second node and any subsequent nodes are inserted into the domain:
Exception: Failed to load other_node/defaultApplication com.ibm.ejs.sm.exception.ActiveObjectException: Failed to load "otherNode"/defaultApplication
where other_node is the nodename of the node to which the console is not connected.
Disregard this exception as the application will run on all servers.
The default error page will not be migrated if it is not specified in the websphere_3x_backup.xml file. If it is not specified in the file, use the Application Assembly Tool to configure the web module(s) to use the ErrorReporter Servlet:
/ErrorReporter
.
WebSphere Application Server 4.0.x uses IBM JSSE for secure communication. The IKeyMan key management tool that is packaged with WebSphere Application Server 4.0.x supports standard key and trust file formats such as Java Key Store (JKS), PKCS12, and JCEK. JKS is the default. The IKeyMan tool in WebSphere Application Server 4.0.x does not recognize the IBM proprietary key file formats used by WebSphere Application Server 3.5 and IBM HTTP Server such as CMS (.kdb) and class files. Some of the key files you used with the 3.5 product need to be recreated when you migrate to WebSphere Application Server 4.0.x. There is no tool to convert those key files to the new format.
Follow the steps described in the InfoCenter to create the key and trust files that use the WebSphere 4.0.x IKeyMan. SSL configuration should be done using the administrative console for ORB, LDAP, and the WebSphere internal HTTP server. WebSphere 4.0.x still uses the sas.server.props properties file, which contains global security configuration, SSL configuration, and Security Association Services (SAS) trace properties. However, the global security settings and SSL configurations are managed by the administrative server and should only be modified using the administrative console. Manual editing of those properties in the sas.server.props file will not have any effect. You still can modify the tracing properties in sas.server.props to enable trace of the SAS code. Rules for using the properties are documented in the WebSphere 4.0.x sas.server.props file.
Note that, besides the key and trust file format, WebSphere Application Server 4.0.x has changed SSL properties names to better match JSSE terminology. Hence, you should not use sas.server.props and sas.client.props files of WebSphere Application Server 3.5.x products with 4.0.x products. A partial list of properties that have different names follows:
sas.server.props file in version 3.5.x:
com.ibm.CORBA.SSLKeyRing=com.ibm.websphere.DummyKeyring com.ibm.CORBA.SSLKeyRingPassword=WebAS com.ibm.CORBA.SSLClientKeyRing=com.ibm.websphere.DummyKeyring com.ibm.CORBA.SSLClientKeyRingPassword=WebAS
sas.server.props file in version 4.0.x:
com.ibm.ssl.protocol=SSLv3 com.ibm.ssl.keyStoreType=JKS com.ibm.ssl.keyStore=C:/WebSphere/AppServer/etc/DummyServerKeyFile.jks com.ibm.ssl.keyStorePassword={xor}CDo9Hgw\= com.ibm.ssl.trustStoreType=JKS com.ibm.ssl.trustStore=C:/WebSphere/AppServer/etc/DummyServerTrustFile.jks com.ibm.ssl.trustStorePassword={xor}CDo9Hgw\=
sas.client.props file in version 3.5.x:
com.ibm.CORBA.SSLKeyRing=com.ibm.websphere.DummyKeyring com.ibm.CORBA.SSLKeyRingPassword=WebAS com.ibm.CORBA.SSLServerKeyRing=com.ibm.websphere.DummyKeyring com.ibm.CORBA.SSLServerKeyRingPassword=WebAS
sas.client.props file in version 4.0.x:
com.ibm.ssl.keyStore=C:/WebSphere/AppServer/etc/DummyClientKeyFile.jks com.ibm.ssl.keyStorePassword=WebAS com.ibm.ssl.trustStore=C:/WebSphere/AppServer/etc/DummyClientTrustFile.jks com.ibm.ssl.trustStorePassword=WebAS
It is a good practice to encode the key and trust store password. There is a utility to encode the password for the client property file called PropFilePasswordEncoder.bat found in the WebSphere_main_directory/bin directory. You can encode the sas.client.props passwords by excuting the command below. If you need to change the password, simply type over the entire string after the = symbol and rerun the utility.
PropFilePasswordEncoder.bat ..\properties\sas.client.props -SAS
The encoded passwords for version the 4.0.x client include--
com.ibm.ssl.trustStore=C\:/WebSphere/AppServer/etc/DummyClientTrustFile.jks com.ibm.ssl.trustStorePassword={xor}CDo9Hgw\= com.ibm.ssl.keyStore=C\:/WebSphere/AppServer/etc/DummyClientKeyFile.jks com.ibm.ssl.keyStorePassword={xor}CDo9Hgw\=
If you have enabled the web trust association in WebSphere Application Server
3.5.x products, the settings in
WebSphere_main_directory/properties/trustedservers.properties will not
automatically migrate to WebSphere Application Server 4.0.x. You must
manually edit the version 4.0.x trustedservers.properties file. Note
that in version 3.5.x, the web trust association is enabled by setting
com.ibm.websphere.security.trustassociation.enabled=true
in the
trustedservers.properties file. This property is not in the version
4.0.x trustedservers.properties file. To enable the web trust
association, you must use the Security Center (accessible from the
administrative console) and enable the trust association flag.
If you are using the IBM Tivoli WebSeal server, note that its trust association interceptor class name is different in version 4.0.x than from version 3.5.x. For version 3.5.x, the class name was--
com.ibm.websphere.security.trustassociation.webseal36.interceptor=com.ibm.ejs.security.web.WebSealTrustAssociationInterceptor
For version 4.0.x, the class name is--
com.ibm.websphere.security.trustassociation.webseal36.interceptor=com.ibm.ws.security.web.WebSealTrustAssociationInterceptor
The migration commands, except for Linux and Solaris 3.02 platforms, use an internal version of XMLConfig during the pre-migration stage. If an internal version of XMLConfig is used, the WebSphere 3.x versions of the XMLConfig commands are not called. If fixes have been applied to the WebSphere 3.x product that affect calling XMLConfig commands, then other actions might be required. (One example of when other action might be required is if e-fix PQ47370 has been applied to fix the expiring dummy key ring problem. This fix required installing classes into a subdirectory and modifying the XMLConfig command to ensure these new classes were before all others in the classpath.)
This fix will not be available to the internal version of XMLConfig using this technique. However, an alternative is to place those classes in the classes subdirectory of the WebSphere 3.x directory. This subdirectory will be referenced by the internal version of XMLConfig and will, in effect, do the same as this eFix required.
The migration process for the WebSphere Application Server Advanced Edition updates the admin.config file in the WebSphere 4.0.x bin directory. One of the side effects of this update is that blank characters and comments are removed from the file during this processing.
After WebSphere is installed, there is a copy of the admin.config file called admin.config.bak in the bin subdirectory. However, this file is erased when the administrative server is started. It is advisable to copy the admin.config.bak file to another name before the administrative server is started. This file can then be used as a record of the original values in the installed admin.config file.
When migrating from Linux or Solaris 3.02, the security information will not be mapped into the WebSphere Application Server 4.0.x environment. It is saved in the backup directory if WebSphere 3.02 or later was previously installed. You can use this information to re-create the security information for these environments.
The sas.server.props file contains critical information for the administrative server. Back up the sas.server.props file before migrating.
When migrating Websphere Application Server 3.5 to Websphere 4.0.x, you might have an application server running a servlet engine in a WebSphere 3.5 domain that is accessing an application server running an EJB Container in a WebSphere 4.0.x domain. If this is the case in your enterprise, warning messages such as the following might be displayed in the client's stderr output:
[time_stamp] thread_ID ProxySelector W Encountered an invalid proxy selector type [time_stamp] thread_ID ServerGroup W Server group was not found in the configuration information manager within the read method
These warning messages are displayed due to a context data missmatch between WebSphere 3.5 and WebSphere 4.0.x but the context data is not used or needed in 3.5 and will be ignored. There will be no adverse affect on the functioning of the system.
When migrating a system whose node name is the computer's fully qualified name, there is a mismatch between the computer's short name and the computer's fully qualified name. As a result, some applications might not expand into the installedApps directory. Specifically, the sampleApp.ear file is not expanded into the installedApps directory. You might find that all applications are deployed in the console and appear to be loaded properly but there are no files in the installedApps directory corresponding to the deployed application.
To resolve this problem, manually expand any .ear files that are not expanded into the installedApps directory. Enter the command below appropriate for your platform to expand .ear files. Enter the command on one line; the commands are shown here on multiple lines to improve readability. Note that WebSphere_root is the main directory of your WebSphere installation and sampleFile.ear is the name of the .ear file you want to expand into the installedApps directory.
Windows:
WebSphere_root\bin\EARExpander.bat -ear WebSphere_root\installableApps\sampleFile.ear -expandDir WebSphere_root\installedApps\sampleFile.ear -operation expand -expansionFlags all
UNIX:
WebSphere_root/bin/EARExpander.sh -ear WebSphere_root/installableApps/sampleFile.ear -expandDir WebSphere_root/installedApps/sampleFile.ear -operation expand -expansionFlags all
Websphere Application Server 4.0.x will not run on AIX 4.3.2. Upgrade to AIX version 4.3.3 before migrating to WebSphere Application Server 4.0.x.
If the administrative console is used to create two different resources and the same name and JNDI name are assigned to both of the resources, the error will be detected and reported but the Default Server will still start successfully. However, when an application program does a lookup using the duplicate JNDI name, it may get the wrong resource and try to use it, which could cause problems.
For example, suppose a user creates a JavaMail mail session with one set of properties (Mail Transport Host = transhost1.com, Mail Store Host = storehost1.com, and so on) and with a name of "Test MailSession" and a JNDI name of "mail/DefaultMailSession". Further suppose the user then creates a second JavaMail mail session with a different set of properties (Mail Transport Host = transhost25.com, Mail Store Host = storehost25.com, and so on) and with the same name and JNDI name as the first mail session. Error messages similar to the following will be reported by the administrative console when the duplicate resource is created and in the default_server_stdout.log file when the server is started:
CHKW3050E: Duplicated resource factory name Test MailSession. [MailSession_3] CHKW3051E: Duplicated resource factory JNDI name mail/DefaultMailSession. [MailSession_3]
If the user runs an application affected by the duplicate name errors, transhost1.com and storehost1.com might be used when the user really wants to use transhost25.com and storehost25.com.
When you see a duplicate name message (either at resource creation time or server startup time), change the names of one of the resources to resolve the problem. You can then start the server and run your application.
After you start the application server, the server runs as a background application with little indication of it running. However, the application server is not running as a service, so if you perform a logoff on the machine the application server will stop. Because of this, you need to have a user logged on all the time while running the application server.
To stop the application server, run the stopServer.bat or stopServer.sh file. Or use the administrative console to stop the application server.
The application server process will not start, preventing access to the administrative console. As a result, you cannot use the administrative console to correct any configuration problems that may be preventing the server from starting.
To fix this situation:
startServer -configFile ../config/admin-server-cfg.xml
http://localhost:9091/admin
Alternatively, you can attempt to manually edit the offending server configuration file. You should always make a backup before making any manual changes.
WebSphere Application Server will fail to start if certain ports are in use. When the bootstrap port is in use, you may see the following error when starting WebSphere Application Server:
009.765.6005c5b F Nameserver Failed to start the Bootstrap server org.omg.CORBA.INTERNAL: minor code: 8 completed: No
This error is similar to the Port 9000 in use error when starting WebSphere Application Server.
To fix the problem, do one of the following:
com.ibm.ejs.sm.adminServer.bootstrapPort
If this property does not exist in file admin.config, add it. For more information, see this topic in the WebSphere Application Server InfoCenter.
./startupServer.sh
and the
administrative server will start successfully. Corruption of the sas.server.props file might cause the administrative server to fail to start. sas.server.props contains critical information for the administrative server. Back up the sas.server.props file regularly.
If you can not start the administrative server because of a JDBC problem, the possible reason is that the DB2 UDB environment was not set up correctly. To set up the DB2 environment:
DB2_HOME/sqllib/java12/usejdbc2
DB2_HOME/sqllib/db2profile
If the WebSphere Application Server Advanced Edition is installed on an AIX system with a local DB2 server and the commands below (as described in the InfoCenter) were executed previously to configure DB2, the administrative server should start successfully when first started.
4. Set the EXTSHM environment variable by entering the following commands: $ EXTSHM=ON $ export EXTSHM $ db2set DB2ENVLIST=EXTSHM
Later, when the administrative server is stopped or the system is shut down, DB2 will stop as well. However, when you next back up the system and start DB2, the administrative server might fail with the following error when you try to start it:
Could not initialize persistent storage for serious events. Got exception COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command. SQLSTATE=55032
To recover from this problem, enter the above commands that set the EXTSHM environment variable and restart the server.
To prevent the environment variable from being turned off accidently again, add the above three lines of commands to the db2profile (assuming the db2profile is sourced using .profile) to ensure the variable is always valid.
Server groups have two types of attributes that can be changed using the administrative console: normal attributes and clone-only attributes.
When a normal attribute is changed, the changed value is propagated to all server clones of that server group. For example, if the Ping interval is changed from 60 to 61, the Ping interval is changed for all server clones as well. These normal attributes cannot be changed for individual server clones; they are read-only. This means that all servers in a given server have the same values for these attributes.
Clone-only attributes are those attributes which might need tailoring for individual server clones. When such an attribute is changed for a server group, the change is not propagated to the server clones. For example, if the Working directory attribute is changed to a new value, the Working directory attribute for all existing server clones remains unchanged. Server clones created subsequently using this server group will get the changed value.
In the Advanced Edition 4.0.x, the administrative console representation of these clone-only attributes is the same as for normal attributes. You can determine the type of an attribute in one of two ways:
The Adding EJB Reference window does not show the Name field when it first opens. The window is accessed by clicking Add on the Adding EJB Reference window of the the Create Application Client wizard. You have to resize the window to see the field.
If the JDBC driver, DB2XADataSource, is configured and you restart the administrative server, a NullPointerException error occurs. To work around this error condition, complete the following steps:
tran1.log.org
.
trans.log.org
.
After installing an EAR file with SEAppInstall.bat or SEAppInstall.sh, the following message is displayed:
CHKW6505W: A subject (user or group) has not been assigned for security role, DenyAllRole. The security role assignment should be made prior to running the application.
Ignore this message. It is appropriate for the DenyAllRole to not have any users or groups assigned to it.
When using Microsoft Internet Explorer version 5.00, after you add a new URL Provider, JDBC Driver or JMS Provider resource, the tree view in the left pane of the administrative console might not update. To see the newly added resource, save the configuration file, exit the administrative console, stop and restart the server, and then restart the console. In the left pane, expand Resources and then the resource type for which you just created a new instance. You should be able to see the new resource instance.
If you are running WebSphere Application Server Advanced Single Server Edition, the administrative console might not refresh with the correct information if the Cache settings for the browser you are using are not set to get a page Every time. To change this setting, see the Help information for the brower you are using.
The default size of the activity log (com.ibm.ws.ras.ActivityLogSize) in logging.properties is 1024 KB which yields a log size of 1 megabyte. The minimum is 8 KB and maximum is 51200 (50 MB).
There is currently no panel in the administrative console that you can use to define environment variables that can be used during launching of the server process. A workaround is to edit the server-cfg.xml file in a text editor as follows:
EnvVar_x
, where
x is a unique ID for this environment varariable within the process
definition.For example, to add an environment variable for computer name COMPUTERNAME=MyMachine, the relevant part of the server configuration would look like the following (see the line starting with <environment):
... <servers xmi:type="applicationserver:ApplicationServer" xmi:id="ApplicationServer_1" desiredExecutionState="START" name="Default Server" id="-1" moduleVisibility="COMPATIBILITY"> <processDefinition xmi:type="server:JavaProcessDef" xmi:id="ProcessDef_1" executableName="${JAVA_HOME}/bin/java" commandLineArguments="" workingDirectory="${WAS_ROOT}/bin" executableTargetKind="JAVA_CLASS" executableTarget="com.ibm.ws.bootstrap.WSLauncher"> <environment xmi:id="EnvVar_1" name="COMPUTERNAME" value="MyComputer"/> <executionSettings xmi:id="ProcessExecution_1" processPriority="1000" umask="777" runAsUser="root"/> <ioRedirect xmi:id="OutputRedirect_1" stdoutFilename="${LOG_ROOT}/default_server_stdout.log" stderrFilename="${LOG_ROOT}/default_server_stderr.log"/> <jvmSettings xmi:id="JavaVirtualMachine_1" classpath="${WAS_ROOT}/lib/bootstrap.jar;${WAS_ROOT}/properties" verboseModeClass="false" verboseModeGarbageCollection="false" verboseModeJNI="false" maximumHeapSize="256000000" runHProf="false" debugMode="false" genericCommandLineArgs="com.ibm.ws.runtime.StandardServer" disableJIT="false"> ... <systemProperties xmi:id="SystemProperty_1" name="server.root" value="${WAS_ROOT}"/> ... </jvmSettings> </processDefinition> ...
The next time the server is launched using either the administrative console or the command-line launcher, the new environment variable will be set in the server's process.
There are limitations of some Netscape browser implementations on UNIX or Linux platforms which may cause the WebSphere Advanced Single Server Edition administrative console to operate incorrectly with respect to accessibility. The administrative console has been designed to support accessibility requirements, when viewed in a browser than can run in accessiblity mode. If the console is viewed within a browser than cannot run in an accessibility mode, tab or cursor keys may become unavailable.
The workaround is to view the administrative console using an accessibility-mode capable browser, such as Microsoft Internet Explorer 5.5 or Netscape 4.73 on Windows NT or Windows 2000.
If you installed WebSphere Application Server Advanced Edition and you want to specify a new context root, you must change the module's context root in the application's .xml configuration file and then re-install the application.
If you attempt to install an application using smitty
or
smit
on AIX 5.1, the application does not install. The *.toc file
is not created. After issuing one of the following commands, you should be able
to install your application:
cd directory_containing_images inutoc .
or
inutoc directory_containing_images
Because the directory browsing scenario for a web module is not meaningful if
file serving is not enabled, the directory browsing option will be ignored in
cases where file serving is set to false
.
The administrative console or login panel for WebSphere Advanced Single Server Edition might display incorrectly in a Netscape Web browser on Linux platforms. Instead of using a Netscape browser, use a Mozilla Web browser to display the administrative console and login panel.
By default, the temp directory for the ServletContext is set to the following:
$(WAS_HOME)/temp/$(MACHINE_NAME)/$(application_name)/$(server_name)/$(web_module_name)
Because the operating system imposes a limitation on the length of the absolute file path, you can choose to shorten the path to the temporary directory. In the administrative application's web.xml file $(WAS_HOME)/installedApps/admin.ear/admin.war/WEB-INF/web.xml, specify the chosen temp directory as the value for the init-param parameter tempDir of the action servlet.
A dummy value already exists for the tempDir init-param of the action servlet. However, this value is commented out. If you want to use your own temp dir, uncomment the segment and edit the value.
Due to restrictions from struts on a multipart form and DBCS names, you cannot install modules using the direct upload method with DBCS names or modules with application names in DBCS using Advanced Single Server Edition. To install an application with a DBCS name, complete the following steps:
When creating an application in the application install process, do not include a / character in the application name.
Similarly, when creating an application server using the WebSphere Application Server Advanced Edition, do not include a / character in the application server name. This is regardless of the method used to create an application server (wscp, AdminConsole, or XMLConfig).
The WebSphere Application Server Advanced Edition will not always correctly determine the state of an application during a remove operation. Normally, it will prevent the removal of an application while the application is running in order to ensure an orderly shutdown of the application but under some circumstances the application will be removed even though some of the application's modules are running. If you are unsure of an application's status, you should first stop the application before trying to remove it.
The Log Analyzer gets installed as part of the WebSphere Application Server Advanced Single Server Edition Version 4.0.1 installation and its executable is in the main_WebSphere_directory/bin directory by the name waslogbr.sh (on UNIX) or waslogbr.bat (on Windows).
You can view the trace output in three different formats: basic, advanced, or log analyzer. By default, the trace format is basic. You can change it to advanced or log analyzer format.
To see the trace output in advanced format, open an editor on the file
main_WebSphere_directory/properties/logging.properties. Change the line
com.ibm.ws.ras.TraceFormat=basic
to
com.ibm.ws.ras.TraceFormat=advanced
and you will get detailed trace
output on stdout.
To see the trace output in log analyzer format, open an editor on the file
main_WebSphere_directory/properties/logging.properties and change the
line com.ibm.ws.ras.TraceFormat=basic
to
com.ibm.ws.ras.TraceFormat=loganalyzer
. After you set this, the
trace output is displayed in the Log Analyzer viewable format on stdout.
You can dump a ring buffer file and then view it in Log Analyzer panes. If the you set the option of enabling trace on the administrative console and direct it to a file, and you have set the trace format as Log Analyzer, the output on stdout is in basic format but the file which gets written is in log analyzer format.
On the File tab of the EJB Server property sheet, you can specify file permissions for log files. The current GUI shows file permissions as Read/Write/Execute for Owner, Group and User. Instead of User, the GUI should show Other; resulting in file permissions for Owner, Group and Other.
If you install WebSphere Application Server Advanced Edition on a Linux RedHat machine that uses the Gnome desktop, double-clicking on the folder name or folder icon will not open the folder or file. This error is caused by an inconsistency between the JVM and the Sawfish window manager with respect to the X Events generated by multi-clicks.
There are two ways to work around this multi-click problem:
To open a file using AAT without double clicking, specify the folder name and file name in the file name field. For example:
/opt/WebSphere/AppServer/installableApps
The deploy tool uses two working directories:
The exception java.lang.ClassCastException may be thrown when you do the following:
These steps verify the .ear file even though executing the steps may throw the exception.
When you do the following in the Application Assembly Tool:
You cannot drag the war file. To work around this problem, import the file (Ejb .jar/Web Module .war/Ejb client .jar ) from new application window tree node.
When specifying additional classpaths (for dependent code not contained in
the module's archive file), specify the values relative to the root of the EAR
file and separate the values with spaces. Absolute values that reference files
or directories on the hard drive are ignored. To specify classes that are not in
JAR files but are in the root of the EAR file, use a period and a forward slash
(./
).
Consider the following example directory structure in which myapp.ear contains an application client JAR file named client.jar. Additional classes reside in class1.jar and class2.zip. A class named xyz.class is not packaged in a JAR file but is in the root of the EAR file.
myapp.ear/client.jar myapp.ear/class1.jar myapp.ear/class2.zip myapp.ear/xyz.class
Specify class1.jar class2.zip ./
as the value of the
Classpath field. (You only name the directory for .class
files). This information applies to the Classpath field for
application client modules and for EJB modules, and to the Additional
classpath field for Web modules.
When starting the Application Assembly Tool of the WebSphere Advanced Edition
by entering assembly.sh
on AIX, a java.lang.OutOfMemoryError
exception may be returned. To resolve this problem, try adding the
-mx192m option to the java command line in the assembly.sh file. The
resulting java command line should resemble--
$JAVA_HOME/jre/bin/java \ -Xmx192m \ -Dcom.ibm.itp.location=$WAS_HOME/bin \ -Dserver.root=$WAS_HOME \ -Dws.ext.dirs=$WAS_EXT_DIRS \ -classpath $WAS_CLASSPATH com.ibm.ws.bootstrap.WSLauncher \ com.ibm.ejs.assembly.gui.AssemblyTool
The following features have been added to the Resource Analyzer GUI:
Opens the Performance Monitoring Settings dialog box.
Turns logging on or off. When logging is turned on, a dialog box with a default file name for the log file is displayed. You can specify a file name, if desired.
If the application server is stopped and restarted, the Resource Analyzer might display incorrect values for JSP files and servlets. To display correct values for these resources, restart the Resource Analyzer.
IBM HTTP Server might hang during initialization when it is configured for SSL and the Websphere administrative server is running.
To solve this problem, try any of the following workarounds:
SSLAcceleratorDisable
in
the IBM HTTP Server configuration file httpd.conf. Place this directive
outside of VirtualHost
and Directory
stanzas.
com.ibm.ejs.sm.adminServer.lsdPort=a_port_number
to the
admin.conf file in the appserver/bin subdirectory. After installing WebSphere Application Server, if you cannot start the iPlanet server, check the obj.conf file and make sure the plugin configuration information is in the correct order. The installation program may have placed the plugin configuration information into obj.conf in the incorrect order. The correct order should be:
Init fn="load-modules" funcs="as_init,as_handler,as_term" shlib="C:/WebSphere/AppServer/bin/ns41_http.dll" Init fn="as_init" bootstrap.properties= "C:/WebSphere/AppServer/config/plugin-cfg.xml"
When running the WebSphere administrative server, a server error is returned when you try to run a servlet such as the sample servlet snoop. To enable the iPlanet plugin to send the servlet to WebSphere Application Server, turn off the iPlanet servlet support:
Support for cryptographic devices in the Single Server Edition is only provided at the Web server level by IBM HTTP Server 1.3.19. The following cryptographic devices are supported on the following platforms:
Cryptographic devices | Interface | Platform |
---|---|---|
Rainbow Cryptoswift | BSAFE 3.0 | Windows NT, Solaris, HP-UX |
nCipher nFast | BHAPI plug-in under BSAFE 4.0.1 | Windows NT, Solaris |
nCipher nForce - accelerator mode | BHAPI/BSAFE | Windows NT, Solaris |
nCipher nForce - key storage mode | PKCS11 | Windows NT, Solaris, HP-UX, AIX, Linux |
IBM4758 | PKCS11 | Windows NT, AIX |
Other cryptographic devices may also work with IBM HTTP Server on the appropriate platforms. However, they have not been specifically tested with IBM HTTP Server as of the date of this WebSphere product release.
If you install IBM HTTP Server with WebSphere JDK 1.3.0 and WebSphere Application Server and attempt to define a key using the IBM HTTP Server ikeyman Hardware Crypto Menu options, the resulting window might be difficult to see and navigate in. Use a workaround for the appropriate platform to correct this problem:
AIX:
$JAVA_EXECUTABLE $IKEYMAN_TEMP_JAVA_INPUT
with this one-line statement (shown here on two lines to improve readability):
$JAVA_EXECUTABLE -Djava.ext.dirs=/usr/opt/ibm/gskkm/classes/ikmuser.properties $IKEYMAN_TEMP_JAVA_INPUT
Linux platforms:
$JAVA_EXECUTABLE $IKEYMAN_TEMP_JAVA_INPUT
with this one-line statement (shown here on two lines to improve readability):
$JAVA_EXECUTABLE -Djava.ext.dirs=/usr/local/ibm/gsk5/classes/ikmuser.properties $IKEYMAN_TEMP_JAVA_INPUT
If you are using IBM HTP Server, Fast Cache Response Accelerator (FRCA) is not supported on an AIX 5.1L.
On Unix platforms, the log of Domino plug-in configuration failures might include a false negative when Domino configuration code is run. If the DSAPI plug-in does not load, then use the manual Domino configuration instructions to troubleshoot the configuration. If the plug-in appears to load properly (that is, it is viewable in the Domino console startup messages), you can disregard the log error.
On Solaris and with Oracle as the administrative repository, the administrative console might hang intermittently if you try to stop and start the application server multiple times. If you experience this problem, recurrence can be minimized or eliminated by the doing all or some of the following:
0
.
This can be done by adding the following to the admin.config file: com.ibm.ejs.sm.adminServer.dbstatementCacheSize=0
Then, restart the administrative server.
Choices 1, 3, and 4 might eliminate the problem. Choices 2, 3, and 4 will reduce the appearance of the problem.
If you are using Oracle for the administrative repository on the WebSphere Application Server Advanced Edition, the default user is set to EJSADMIN. To specify an alternative user, you must edit the admin.config file in the bin directory and set the following property to the desired user name:
com.ibm.ejs.sm.adminServer.dbSchema=username
If your .ear file uses multiple data sources with the DB2XADataSource class, when you deploy the .ear file into the application server and restart the Administrative Server, an "UnsatisfiedLink Error" may be returned on the AIX platform.
The problem is in the LD_LIBRARY_PATH and LIBPATH on AIX. After running
DB2 usejdbc2
, the LIBPATH includes $INSTHOME/sqllib/java12, but the
StartServer.sh overwrites the existing content of LIBPATH and sets it to
$WAS_HOME/bin:$LD_LIBRARY_PATH. To fix the problem, include $INSTHOME
/sqllib/java12 in the LD_LIBRARY_PATH. That is, for example, export
LD_LIBRARY_PATH to /home/test/sqllib/java12:/home/test/sqllib/lib. Then, restart
the server without errors.
If you are using connection pooling with Oracle on Sun Solaris or Linux, it
is recommended that you set the maximum number of files allowed open per user to
at least 2048. You can do this using the ulimit command. Simply enter
ulimit -n 2048
in the session where you will be running the
application server.
It is also recommended on the Linux system that the JVM initial heap size and
maximum heap size be set to 256 megabytes and 512 megabytes, respectively. Using
the administrative interface, select Nodes -> node_name
-> Application Servers -> server_name -> Process Definition
-> JVM Settings. In the Initial Heap Size field,
enter 256
and in the Maximum Heap Size field enter
512
. Save the configuration and restart the application server to
have the settings take effect.
DB2 databases are local and multiple connections cannot be established successfully. The solution is to catalog the DB2 databases using a TCP/IP loopback. To implement TCP/IP loopback without having to change the application to connect to the new alias and the USER and USING parameters, see step 5 below:
db2set DB2COMM
. To update the DB2COMM registry
variable to include TCP/IP, use the db2set command. For example: db2set DB2COMM=,tcpip
db2 update dbm cfg using svcename
db2 catalog tcpip node remote 127.0.0.1 server
db2 catalog db as db2 uncatalog db db2 catalog db as at node
Restart DB2 to refresh to directory cache.
If you are using WebSphere Application Server on a Solaris machine and connecting to Sybase as the administrative repository, you may experience network problems. When you start an application server, numerous JZ006 errors may occur with chained JZOEM errors. At this point, the connection pool will get dropped. In addition, other connections may start to experience the following error:
SET CHAINED command not allowed within multi-statement transaction
To work around the SET CHAINED errors, place the following line into the admin.config file:
com.ibm.ejs.sm.adminserver.dberrorMap=EC226=com.ibm.websphere.ce.cm.StaleConnectionException
Note that JZ006/JZOEM and SET CHAINED errors will still occur with this workaround. However, the frequency will be reduced and WebSphere will be able to recover from the errors.
When using DB2 UDB as the Sessions data source, you must set
CURSORHOLD=1
to prevent statements from hanging in the
database.
Set the CURSORHOLD property for the Sessions data source by specifying the following connectionAttribute custom property in the data source configuration, as follows:
property name: connectionAttribute type: java.lang.String value: cursorhold=1
Note that the type field has to be set for the Advanced Single Server Edition only.
When you run DB2 on any UNIX platform, you may see the following error message:
java.lang.NoSuchFieldError: batchReturn
This error is caused because of a mismatch of db2java.zip files. To work
around this problem, ensure that the db2java.zip file in the java12 directory is
before the db2java.zip in the java directory in your classpath. A common problem
is to install a JDBC driver using
~db2inst1/sqllib/java/db2java.zip
, while you should have specified
~db2inst1/sqllib/java12/db2java.zip
.
The net driver for accessing DB2 remotely is not supported in this version of WebSphere Application Server. If you are using DB2 remotely, do not modify the dbServerName and dbPortNumber fields in the admin.config file. The use of the DB2 client installation and DB2 aliases is supported in order to access DB2 remotely.
If you are using Sybase as the administrative repository, the following DatabaseMetaData methods are not implemented as of the last Sybase EBF and will throw UnimplementedOperationExceptions.
getSchemaName() getTableName() getCatalogName()
When you install and use Sybase, be sure that you apply the latest EBF and search the accompanying Cover.ROLL.EBF# document that lists what patches and enhancements are a part of EBF# (where EBF# is the number of the latest e-fix available). In particular, look for the following EBF IDs:
1074408-11 CR255096 1074408-12 CR255094 1074408-13 CR255097
The IEEE 754 standard requires at least 6-decimal digits of precision for a datatype of FLOAT. While some database products will maintain precision greater than required by this standard, Oracle does not. For example, 10590.75 minus 50 may not result in 10540.75. If your application deals with numerical quantities having greater than 6 significant digits, Oracle recommends that you use DOUBLE instead of FLOAT.
The Oracle JDBC driver has problems with re-use of PreparedStatement objects
under certain conditions. Even though your application may not explicitly reuse
PreparedStatement objects, the objects may be reused because of WebSphere
Statement caching. This problem may occur following a BatchUpdateException
thrown by PreparedStatement.executeBatch(). Later, when the addBatch() method on
the same PreparedStatement object is called, the Oracle JDBC driver throws an
SQLException with the message, Missing IN or OUT parameter at index
....
.
The Oracle JDBC driver will return null instead of an empty array of int if Statement.executeBatch() is called when the Statement batch is empty, for example, just after calling stmt.clearBatch().
The Oracle JDBC driver does not support SQL-92 escape syntax for Outer Join functions (using the OJ token) and scalar functions (using the FN token). Use the alternative Oracle-specific SQL syntax as needed.
The JDBC method Statement.setQueryTimeout(int seconds) throws an SQLException for negative values of the parameter, seconds. The Merant SequeLink 5.1 JDBC driver for SQL Server does not throw an exception for a negative value.
For the WebSphere connection manager to work with DB2/400, you must apply the upcoming (scheduled for October 2001) e-fix for the AS/400 (iSeries) Toolbox. This fix is available today, though, and its fix number (PTR) from the Toolbox team is JACL 9950956.
The Informix JDBC driver version 2.20 JC2 has a defect which causes XA transactions to fail. The Informix defect number is 151841. A fix will hopefully be available in the next release of the Informix JDBC driver. Until then, data sources created with the com.informix.jdbcx.IfxXADataSource class will not work.
When running WebSphere Application Server on Solaris 8 with a DB2 UDB database as the repository, your system might develop a hang condition. The hang condition occurs because of networking problems on Solaris. To fix the condition, do the following:
Depending on your specific system, you may need one, two, or all three of these solutions.
You may receive errors when creating database tables using Oracle when running the "Assembling, installing, deploying and accessing an EJB 1.1 application." To manually deploy the beans, do the following:
ejbdeploy EJB11Big3.jar tmp Ejb11Big3depl.jar -novalidate -dbvendor ORACLE_V8
During EJB deployment, the following GenerationException may be thrown:
null com.ibm.etools.codegen.api.GenerationException at com.ibm.etools.java.codegen.JavaCompilationUnitGenerator.addImport (JavaCompilationUnitGenerator.java:50) ...
To correct the situation, run deployment again.
In WebSphere Application Server Version 3.5, applications that were doing resource access in EJB methods specified to run under an "unspecified transactional context" normally got back connections with autocommit set to true. If the application set autocommit to false, the transactional work on the connection was automatically committed at the end of the method.
In Version 4.0.1, the default behavior in the above case is to rollback the work on the connection at the end of the method. If the application sets autocommit to false, it is required to explicitly issue commit on the connection before the method completes to avoid the rollback. However, you can restore the Version 3.5 behavior without requiring a change to the application by changing the "local transaction unresolved action" setting for the bean from its default value of roll back to commit using the Application Assembly Tool.
Use of EJB QL for defining finder methods is not supported in the version of Deployment Tool for Enterprise JavaBeans shipped with the Advanced Single Server Edition of this product. Also, there are restrictions on the use of SQL SELECT and WHERE clauses for defining finder methods.
For information on restrictions, see the documentation on the Deployment Tool for Enterprise JavaBeans.
For CMP entity beans, the Application Assembly Tool invokes the Deployment Tool for Enterprise JavaBeans to generate the SQL code (Table.ddl file) for creating database tables. For the Advanced Single Server Edition of this product, only the Table.dll file is generated. Default (top-down) mapping is used. Customized mappings are not supported.
For information on default mappings, see the documentation on the Deployment Tool for Enterprise JavaBeans.
Generated code for a CMP bean when using a Merant JDBC driver to access Microsoft SQL Server might cause [HY104][SQL Server]Invalid precision value errors if a TEXT column type for the database is used. The code updating the TEXT field is bad if the field to be updated is NULL at the particular instance. The code generated asks the database to update the field as LONGVARCHAR when the field is NULL and as VARCHAR when field is not NULL.
Due to a bug in the Merant SequeLink Driver, the clearParameters method does
not adequately reset parameters to allow prepared statements to be reused in all
cases. The solution is to disable prepared statement caching on the BRBeans data
source by setting the Statement Cache Size to 0
. For the Advanced
Single Server Edition, the Statement Cache Size property among the data source
properties. For the Advanced Edition, it will be among the connection pooling
properties of the data source.
When compiling an EJBModule that has CMP-based entity beans which use primitive primary keys, an error message resembling the following may be returned:
Compiling content of ejbModule/com/ibm/ejb/cb/samples/big3/tier2 (12 problems found) Copying all resources on the classpath (12 problems found) Build done Java build completed Invoking Validation on /Big3BRB.jar. ejbModule/com/ibm/ejb/cb/samples/big3/tier2/EJSCMPClaimHomeBean.java(62): The constructor java.lang.Integer() is undefined ... ejbModule/com/ibm/ejb/cb/samples/big3/tier2/EJSJDBCPersisterCMPPolicyBean.java(197): The constructor java.lang.Integer() is undefined Shutting down workbench. Execution Halted: Compilation Errors Reported 12 Errors, 0 Warnings, 0 Informational Messages
Compilation was halted because the deployment descriptor specified used a primitive object key (java.lang.Integer) but did not specify a key field to which the deployment descriptor should map. It was left as a compound key. Therefore, the deploy tool did not know which field to use as the key and returned the error messages.
As to the generated deployment descriptor in the above example, the <prim-key-class> element was set to java.lang.Integer but there was no <primkey-field> element specifying which <cmp-field> element should map to the primary key.
The solution is to use the Application Assembly Tool to specify which key field (other than compound key) should be used or to manually edit the ejb-jar.xml and add the <primkey-field> elements.
A javax.ejb.FinderException can occur when a finder method is called for an entity bean with CMP and the finder is defined incorrectly. This failure occurs when the finder returns more than one EJB object (returns either a java.util.Enumeration or a java.util.Collection) and the finder logic is encapsulated in a String constant named findMethodNameQueryString. The failure occurs because the SQL select statement encapsulated by the Java String constant is incorrect. Either the encapsulated SQL select statement does not include a complete list column names for each of the CMP fields, or the list column names does not appear in the order required to successfully hydrate the entity bean. The following is an example of the error that occurs when the encapsulated SQL select statement does not include all required column names:
ERROR: javax.ejb.FinderException: com.ibm.ejs.persitence.EnumeratorException original exception: com.ibm.ejs.container.ContainerInternalError:; nested exception is: COM.ibm.db2.jdbc.DB2Exception: [IBM][JDBCDriver] CLI0610E Invalid column number. SQLSTATE=S1002
Note that encapsulating the logic in a String constant named findMethodNameQueryString has been deprecated. What follows describes how to correctly create the finder logic in a EJB server so that the above failure and similar failures do not occur.
Creating finder logic in the EJB server
For the EJB server environment, the following finder logic is required for each finder method (other than the findByPrimaryKey method) contained in the home interface of an entity bean with CMP:
As an example, suppose the AccountHome home interface defines the following finder method:
Enumeration findLargeAccounts(float amount) throws RemoteException, FinderException;
You must also create the AccountBeanFinderHelper interface as follows:
public interface AccountBeanFinderHelper { String findLargeAccountsWhereClause = "balance > ?"; }
You can use the Application Assembly Tool to define the finder logic as well. For each CMP entity bean, select your entity bean and Method Extensions choice in the Application Assembly Tool's tree view and set the Finder descriptor for each finder method. Using the Full select radio button is not recommeded because it can easily result in the javax.ejb.FinderException being thrown when the required list and order of column names is not used. Use the Where clause radio button to obtain the correct list of column names and order.
When using the default value of the Module visibility setting, if the application server Module property and your application includes multiple EJB JAR modules and the client module, without any dependency specification among the JAR modules, the Java client might return an exception such as the following:
Exception within loop - continuing - java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: com.ibm.ejs.container.UncheckedException: ; nested exception is: java.lang.LinkageError: Class com/ibm/wssvt/tc/pli/ejb/Person violates loader constraints java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: com.ibm.ejs.container.UncheckedException: ; nested exception is: java.lang.LinkageError: Class com/ibm/wssvt/tc/pli/ejb/Person violates loader constraints com.ibm.ejs.container.UncheckedException: ; nested exception is: java.lang.LinkageError: Class com/ibm/wssvt/tc/pli/ejb/Person violates loader constraints java.lang.LinkageError: Class com/ibm/wssvt/tc/pli/ejb/Person violates loader constraints
To fix this problem of class duplication among JAR modules, do the following:
Manifest-Version: 1.0 Main-Class: com.ibm.wssvt.tc.pli.apps.TestClient Class-Path: liagentna11.jar lipersonna11.jar lipolicyna11.jar
For example, using the example in step 1, note that lipersonna11.jar created the classes "Person.class, PersonHome.class, PersonKey.class", which are also referenced by the other two jars, liagentna11.jar and lipolicyna11.jar. However, during an earlier exporting of the EJB JAR file, the option Select reference types and resources included all referenced classes, meaning that the other two JARs, liagentna11.jar and lipolicyna11.jar, got the "Person ..." classes included too. The duplicate "Person ..." classes must be removed from these two JARs.
When using the Application Assembly Tool to assemble EJB modules containing BMP EJB's and the EJB module is verified, the verifier may incorrectly report that the bean has multiple findByPrimaryKey methods. You can ignore these extra messages.
If a CMP bean is defined with one CMP field of type StringBuffer and a deployed ear is generated with a database type of image in the Table.ddl file, the table can be created successfully when the Table.ddl file is run but testing the CMP bean causes the following error message:
<operation failed>: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: com.ibm.websphere.cpi.CPIException: java.sql.SQLException: [MERANT][SequeLink JDBC Driver]Driver cannot perform requested operation: ResultSet.getBlob().; nested exception is: java.sql.SQLException: [MERANT][SequeLink JDBC Driver]Driver cannot perform requested operation: ResultSet.getBlob().
The exception is caused by a limitation of the Merant/SQLServer driver: the driver does not support the get and setBlob() operators which WebSphere drivers use to access binary fields.
Try mapping the StringBuffer to a character type such as text for large character fields on SQL Server. It may require a converter because StringBuffer is not directly supported by JDBC String APIs.
If you created a VisualAge for Java association, the default name of the relationship will cause problems because of the generated hyphen (-) in the table.ddl file. The hyphen creates a syntax error when attempting to create tables in an Informix database. You cannot use a table.ddl if the association was created using VisualAge for Java.
If you install the session bean in EJBCommandTarget.jar that is contained in the WebSphere_installation_root\lib directory, you will then have an EJBCommandTarget.jar in the WebSphere_installation_root\installedApps\EJBCommandTarget.ear directory. Having EJBCommandTarget.jar in these two places can cause classloader problems. To fix this problem, move this jar file out of the WebSphere_installation_root\lib directory and place it in the WebSphere_installation_root\installableApps directory. This way, you will still have a copy of the original jar, but it will not get picked up at run time by the wrong classloader.
When a JSP file in a Web Module relies on classes found in a JAR that is installed at the enterprise application level, you should set the Precompile JSPs option in the administrative console to No. This is because the JSP batch compiler, which is used to precompile JSP files, is not picking up JARs at the enterprise application level.
For example, as to WAS_ROOT\InstalledApps\MyApp.ear\foo.jar, if there is a JSP file WAS_ROOT\InstalledApps\MyApp.ear\MyModule.war\MyJsp.jsp that needs classes in foo.jar, the batch compiler will fail with Class not found or Package not found errors.
The JSP compiler may fail to compile a JSP that includes a file whose name starts with a lowercase u. This only occurs when the JSP is not pre-compiled. For example, the following code may fail to compile when the JSP is first touched using a Web browser:
<html> <body> <%@ include file="u.htinc" %> </body> </html>
This problem does not occur when the JSP is compiled with the JspBatchCompiler command. To work around the problem, rename the file that is being included so that it does not start with a lowercase u or precompile the JSP using the JspBatchCompiler command.
To enable using the silent mode of the SoapEarEnabler, the SoapEarEnabler.sh file or the SoapEarEnabler.bat file needs to be modified:
For SoapEarEnabler.sh, change the line:
$JAVA_HOME/jre/bin/java -cp $CP com.ibm.soap.soapenabler.SoapEnabler
to:
$JAVA_HOME/bin/java -cp $CP com.ibm.soap.soapenabler.SoapEnabler $*
For SoapEarEnabler.bat, change the line:
@%JAVA_HOME%\jre\bin\java -cp "%CP%" com.ibm.soap.soapenabler.SoapEnabler
to:
@%JAVA_HOME%\jre\bin\java -cp "%CP%" com.ibm.soap.soapenabler.SoapEnabler %*
If the SoapEarEnabler.sh script on Solaris fails with function: unknown command, it is due to the level of bourne shell on the system. To fix the problem, open an editor on SoapEarEnabler.sh and modify the script by changing the line:
function run
to:
run()
Assigning a large number of users or groups (greater than 5000) to a role might fail (in the Security Center).
When possible, assign roles to groups. There typically are fewer groups than users. Also, this will improve performance during server startup and during the authorization check.
SSL settings are managed by the administrative console. Any editing changes made to the following properties in sas.server.props will be overwritten at runtime.
While receiving a CA Certificate into a new SSL key file using WebSphere JSSE iKeyman, the product may return the error message An error occurred while receiving the certificate from the given file.
The workaround is to save the SSL key file before creating a certificate request:
HTTP digest authentication is not supported as a login configuration in this product. Also, not all login configurations are supported in all of the product's global security authentication mechanisms (Local Operating System, LTPA, and custom user registry). HTTP basic authentication and form-based login authentication are the only login methods supported by the Local Operating System user registry. Because Advanced Single Server Edition uses the local operating system as the user registry for authentication, it can only support these two login methods. LTPA and the custom user registry are capable of supporting HTTP basic authentication, form-based login, and HTTPS client authentication. But LTPA and the custom user registry are available only in the Advanced Edition.
After you enable security, you cannot access enterprise java beans (EJBs) spread across other nodes. The error throws authorization failed exceptions and CORBA TRANSACTION_ROLLBACK exceptions. To work around this problem, ensure all the nodes involved are in the same time zone.
When LTPA is selected as the authentication mechanism in the global security settings and if you use Form Login in any Web applications, then Single-Sign-On (SSO) must also be enabled. If SSO is not enabled, then authentication during Form login will fail with a configuration error. SSO is required because it generates an HTTP cookie that contains information that represents the identity of the user at the Web browser. This information is used for SSO purposes but, in the case where login is done using a Form Login, it is also required for the authorization check of a protected resource.
A key file and trust file can be used to store certificates in the Advanced Edition 4.0.x, conforming to JSSE guidelines. The key file is typically for private keys and the trust file is typically for signer certificates. With this approach, you can pass the trust file to anyone with the same trust requirements but keep the private key of the key file separate for each machine. However, when you add a signer certificate to the trust file (ORB SSL connections only), the certificate does not get picked up and you might see Unknown CA or Unknown Certficate errors and the SSL handshake will fail.
As a workaround to this problem, you should add your signer certificates to the key file's signer certificates section from within iKeyMan. See the InfoCenter for information on using the iKeyMan tool. The key file can be specified in the Security Center under Default SSL Configuration, or you can override these defaults by specifying a different SSL configuration for each ORB. To do this you should go to the Service tab of the application server and edit the Object Request Broker service. Go to the Advanced tab and select Configure SSL.
SSL Key File Name and associated password and format fields are required fields when SSL is enabled on the following panels:
The fields must not be left blank, even when a hardware cryptographic card is used and the key file is stored on the cryptographic card. A file must be specified in the SSL configuration panel but it will not be used at run time.
When importing an XML configuration that has multiple HTTP ports configured in the WebContainer of an application server, configuration data of second and subsequent ports will be overwritten by the first port. For example, if both ports 9080 and 9443 are configured for the Default Server and SSL is enabled on port 9443 in a configuration, port 9443 will be overwritten by port 9080 and Default Server will have two 9080 ports and SSL disabled after a configuration is imported into the administrative repository.
Although both the WebSphere Application Server Advanced Edition 4.0.x and the WebSphere Enterprise Edition 3.6 (Component Broker) support up to 128-bit encryption for SSL connections, only 40-bit encryption works when a WebSphere Advanced Edition EJB client or servlet connects with a WebSphere Enterprise server. Refer to article 5.7.3 in the WebSphere InfoCenter for more information about SSL interoperability issues and how to use the property com.ibm.ssl.enabledCipherSuites to specify encryption levels.
When the Object Level Trace service is enabled while you perform system administration using the administrative console, error messages may show up in the console from which the administration server was started. These error messages are harmless and may be ignored.
However, to avoid these error messages, do not do system administration while
the application server is running with the Object Level Trace service enabled.
If this is not an option for you, run two instances of the
startServer
command. To run multiple server instances
simultaneously, you must use different configuration files (for example,
server-cfg.xml) for each instance. Ensure that there are no port conflicts
between the two instances.
When debugging on the HP-UX platform, there is a known HP-UX JDK defect that may cause the application server to crash. To work around this problem, restart the machine.
The IBM distributed debugger requires that Object Level Tracing is enabled. If you modify your application server configuration such that OLT is not enabled and the IBM distributed debugger is enabled and click the Apply button, you will receive the following message:
ADGU3124W: The IBM Distributed debugger only works when Object Level Tracing is enabled. Do you want OLT enabled now?
If you select Yes, OLT is enabled and your property changes are saved. If you select No, the Apply selection is canceled and your changes are not saved. To save any changes, go to the Advanced JVM Settings dialog, de-select Enable IBM distributed debugger, and click OK and then Apply.
When you select Enable IBM distributed debugger from the Advanced JVM Settings dialog and OLT is not enabled, you are asked whether you want to enable OLT. If you select Yes, both OLT and the IBM distributed debugger are enabled.
During installation of OLT, the installation program displays the directory to which OLT will be installed. You might find that OLT is, in fact, installed into a different directory than that designated. For example, the installation program displays that OLT will be installed into /opt/idebug yet, in fact, OLT is installed into /opt/IBMdebug.
When opening a socket on UNIX, the socket is assigned a file descriptor and treated like an open file. When you close the socket, the behavior changes slightly and the socket goes into a state called TIME_WAIT. This state is designed to prevent rogue packets destined for the previous holder of the file descriptor from affecting the new holder of the file descriptor. TIME_WAIT is approximately two times the maximum time-to-live of a packet and, once the state expires, the file descriptor is released and the file (socket) is closed.
UNIX systems generally set a default limit on the maximum number of open files. On Solaris, the limit is 256; on Linux, the limit is 1024; and so on. So, under high stress where sockets are opened and closed rapidly (WebSphere 4.0 HTTP transport does this under load), it is possible to reach the maximum and get transport errors because the operating system will not complete the request to open another socket. Over time, as the sockets in the TIME_WAIT state expire, the operating system allows more sockets to be opened until the maximum files setting is reached again.
You can see whether the maximum number of open files limit has been reached if the following occur:
netstat -a
, which shows all current
network activity, shows many sockets in the TIME_WAIT state. To get a rough
count, use the command netstat -a | grep TIME_WAIT | wc -l
. It
gives a line count, and a number, of all sockets in the TIME_WAIT state. If
the number is considerably greater than the maximum files limit, then
exceeding the limit is the likely cause of the transport errors. The solution is to change the operating system settings for the number of open file descriptors:
ulimit -a
ulimit -n new_number_of_files
where new_number_of_files is the new maximum of open files limit. A rough setting for machines expected to be under load should be 8192 or more.
Alternatively, the maximum can be increased system-wide by modifying the /etc/security/limits file. See the ulimit(5) man page for more information.
Suppose there are two administrative servers, adminServerA and adminServerB, and each server has its own administrative console, adminConsoleA and adminConsoleB. Further suppose the administrative servers and consoles run properly for a while, and then one of the administrative servers (adminServerA) to which one of the consoles (adminConsoleA) is connecting is shut down by an unintentionally wrong operation. Because workload management (WLM) code supports the administrative server failover, adminConsoleA will automatically connect to adminServerB and all repository-based operations will function as usual. For example, the users should be able to modify the property sheet and apply the changes, even though the users cannot start or stop the server or applications hosted by adminServerA since it is not reachable now.
However, there is one exception to this scenario: if the users click the Application and Module folders for adminConsoleA, they will see quite a few error messages from both log files and in the Console Event Viewer if the users previously installed applications to the node where adminServerA is installed. (If adminServerA does not host any applications, the switch to adminServerB should cause no exceptions.)
The reason for the error messages is that each time the users try to view an application or module property sheet, the current administrative console implemention will go to the node where the .ear or .jar files are hosted and look for the deployment descriptor. If that node is down, the users will see COMM_FAILURE exceptions similar to the following:
[01.07.27 10:30:49:132 EDT] 6ed846f5 ExceptionUtil X CNTR0020E: Non-application exception occurred while processing method getRemoteArchiveInfo on bean BeanId(admin#repository.jar#FileBrowserService, e7f4be730c): java.rmi.MarshalException: CORBA COMM_FAILURE 3 No; nested exception is: org.omg.CORBA.COMM_FAILURE: minor code: 3 completed: No org.omg.CORBA.COMM_FAILURE: minor code: 3 completed: No at com.ibm.CORBA.iiop.HTTPConnection.send(HTTPConnection.java:439) ... at com.ibm.ws.util.CachedThread.run(ThreadPool.java:122)
Basically, it is a COMM_FAILURE exception due to the lost connection. Though you will see error messages, the administrative console should continue to function.
On AIX and for Korean and other languages, some WebSphere Application Server pages may be corrupted. To fix the page display, uncheck the Auto-select in the View -> Encoding menu option of Microsoft Internet Explorer browsers or the View -> Character Set option of Netscape browsers.
The installation destination directory path for WebSphere Application Server Advanced Edition and for WebSphere Application Server Advanced Single Server Edition does not support double-byte characters.
For supported locales, see InfoCenter article 6.6.49.
If you are running WebSphere Application Server on an AIX machine, true type fonts (TTFs) must be installed in order for the characters to display properly. These fonts are not installed automatically with AIX default installation.
If you are installing the Japanese version of WebSphere Application Server, after the install process completes, the FirstSteps window appears. If you select Start Server from the FirstSteps window, a new window appears and the Japanese characters appear corrupted. However, if you cancel the FirstSteps window and open a terminal session, you can start the server from the command line and the messages will appear without corruption.
If you are using one of the supported DBCS locales, one of the following filesets is required:
AIX:
X11.fnt.ucs.ttf (for ja_JP or Ja_JP) X11.fnt.ucs.ttf_CN (for zh_CN or Zh_CN) X11.fnt.ucs.ttf_KR (for ko_KR) X11.fnt.ucs.ttf_TW (for zh_TW or Zh_TW)
Solaris:
SUNWjxcft, SUNWjxmft (for ja) SUNWkcoft (for ko) SUNWgttf (for zh_GBK) SUNW5ttf (for zh_TW.BIG5)
When installing on UNIX, certain traditional Chinese characters will not be displayed properly due to a JDK 1.3 limitation. Some characters will be displayed wrong or will be unreadable.
Data files that contain the information for the default and sample configurations are not translated in this release. For example, objects such as Default Server and Sample DB Driver will have English names and descriptions even in non-English locales.
echo
statements from batch files and shell scripts (for example,
ejbdeploy
and adminclient
) also are not
translated.
If you are installing WebSphere Application Server Advanced Single Server
Edition on a Sun Solaris machine (Simplified Chinese Only), change the
GB2312 key in the converter.properties file from Cp1386
to
GBK
to avoid corruption on the administrative console. The
converter.properties file is located in the following directory:
WebSphere/AppServer/properties.
This release of WebSphere Application Server provides the English (en_US) installation of the application client (J2EE client and Java thin client) only.
You might encournter the following problems with the Simplified Chinese release of WebSphere Application Server:
com.ibm.ejs.sm.client.command.ExecutionException: command server.start failure
To fix the problem, do not assign a new application server a Simplified Chinese name.
./waslogbr
in the directory
WebSphere_main_directory/bin. A log analyzer console will open with
an English interface. Open one log file, such as activity.log, and the
correct output pops up.
rservs
to
rerv
. (If the editor is Windows Notepad, the two s
characters in rservs
are displayed as garbage characters.)
If you are using the Java Pet Store sample with Oracle as the database, be aware that repeated transactions (same user re-ordering same item) are not supported on Oracle.
To use a remote Informix database for the Samples, complete the following steps for the appropriate platform:
Windows:
wsdemo
with a password of wsdemo1
. Be sure to
use all lowercase letters when creating the wsdemo user. The wsdemo user does
not need any special privileges.
INFORMIXSERVER.cmd
.
INFORMIXSERVER is the name of your Informix Server Instance (for example,
ol_myserver.cmd
).
dbaccess - InformixSampleDB.sql
XMLConfig.bat -import ImportSamples.xml -adminNodeName NODENAME -substitute "was.install.root=WAS_ROOT;server_root=WAS_ROOT;com.ibm.ejs.sm.adminServer.primaryNode=NODENAME"
where WAS_ROOT is the main WebSphere directory and NODENAME is the name of the node.
GenPluginCfg.bat -adminNodeName NODENAME
where NODENAME is the name of the node.
UNIX:
wsdemo
with a password of wsdemo1
. Be sure to
use all lowercase letters when creating the wsdemo user. The wsdemo user does
not need any special privileges.
su -
informix
).
dbaccess - InformixSampleDB.sql
XMLConfig.sh -import ImportSamples.xml -adminNodeName NODENAME -substitute "was.install.root=WAS_ROOT;server_root=WAS_ROOT;com.ibm.ejs.sm.adminServer.primaryNode=NODENAME"
where WAS_ROOT is the main WebSphere directory and NODENAME is the name of the node.
./GenPluginCfg.sh -adminNodeName NODENAME
where NODENAME is the name of the node.
Information in the InfoCenter on Object Level Trace (OLT) and the IBM Distributed Debugger should address starting the WebSphere server with the -host command parameter for remote OLT or debugger. Specifically, if you are running the OLT viewer or the debugger user interface on a machine that is separate from the machine running WebSphere Application Server, start the WebSphere server with a command that includes the -host parameter:
startServerBasic -oltenabled -host hostname -debug
The Log Analyzer help files, articles # 6.6.0.13.* in the InfoCenter, contain technical information that is specific to Component Broker. For example, they occasionally refer to features that can only be found in the Log Analyzer that ships with Component Broker.
Please disregard information that does not seem to apply to your IBM WebSphere Application Server Log Analyzer interface.
The following are corrections and additions to the InfoCenter article "4.6.1.4: Running the JavaMail sample:"
After the install, you can invoke the servlet or JSP by using one of the following URLs: http://localhost/jmsample/servlet http://localhost/jmsample/Email.jsp
You should not use these links to bring up the JavaMail servlet and JSP. These are internal documentation links which point to tables that give the actual links that should be used to invoke the JavaMail servlet and JSP.
The hyperlinks to DER_DBG_TAB and DER_DBG_TABGRID at the bottom of the article "Setting environment variables for the Debugger" in information in English on the Distributed Debugger incorrectly go to a Spanish page.
In the installation documentation, all references to the following selections from the Advanced Edition Start menu folder Programs -> IBM WebSphere -> Application Server 4.0 should be stated as:
Programs -> IBM WebSphere -> Application Server V4.0 AE.
The following information on configuring DB2 UDB on Linux platforms supplements information on this topic already in the InfoCenter:
Configuring the Linux ipcs parameters for the enterprise application environment
To configure the Linux ipcs parameters:
# ipcs -l
.
The output should resemble the following:
------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 32768 max total shared memory (kbytes) = 8388608 min seg size (bytes) = 1 ------ Semaphore Limits -------- max number of arrays = 128 max semaphores per array = 250 max semaphores system wide = 32000 max ops per semop call = 128 semaphore max value = 32767 ------ Messages: Limits -------- max queues system wide = 128 max size of message (bytes) = 8192 default max size of queue (bytes) = 16384
# echo 128 > /proc/sys/kernel/msgmni
# echo 250 32000 128 128 > /proc/sys/kernel/sem
These parameters will resume to the original value after rebooting your system. You can set these in the user profile.
Increasing the database logfile size to prevent TRANSACTION_ROLLEDBACK error caused by DB2 deadlock or timeout
$ db2 UPDATE DATABASE CONFIGURATION for <database-alias> USING LOGFILSIZ 4095
$ db2stop $ db2start
Using the KSH shell for RedHat 7.1
For RedHat7.1, use the KSH shell:
]] then
change the lines to:
]] ; then
(Add a semi-colon.)
. usejdbc2
# env | grep PATH
The correct setting should resemble--
[db2inst1@lifeng-was4 bin]$ env | grep PATH LD_LIBRARY_PATH=/home/db2inst1/sqllib/java12:/home/db2inst1/sqllib/lib CLASSPATH=/home/db2inst1/sqllib/function:/home/db2inst1/sqllib/java12/db2java.zip :/home/db2inst1/sqllib/java/runtime.zip:. LIBPATH=/home/db2inst1/sqllib/java12:/home/db2inst1/sqllib/lib PATH=/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/X11R6/bin :/home/db2inst1/sqllib/bin :/home/db2inst1/sqllib/adm :/home/db2inst1/sqllib/misc :/home/db2inst1/bin :/opt/WebSphere/AppServer/bin :/opt/WebSphere/AppServer/java/bin :/home/db2inst1/sqllib/java12 :/home/db2inst1/sqllib/lib
Note that the CLASSPATH and PATH settings are shown here on multiple lines, instead of each on one line, to improve readability.
If you are configuring DB2 UDB on Linux (Intel), additional steps must performed to ensure that DB2 is configured properly for use with WebSphere Application Server 4.0.x.
After completing the steps in the section titled "Creating a database for WebSphere Application Server" in the article "Configuring and testing DB2 UDB 7.2," perform the following steps:
Configuring the database manager to use TCP/IP
You must configure the database manager to use TCP/IP to connect to WebSphere remotely on Linux. Because you are using a local DB2 database with WebSphere Application Server (both DB2 and WebSphere Application Server are installed on the same machine), you will perform all of the steps in the following procedure on the same machine.
Perform the following steps to configure the database manager to use TCP/IP to connect to WebSphere remotely:
db2set
command, as
follows: $ db2set DB2COMM=tcpip
db2cdb2inst1 50000/tcp # DB2 connection service port
Note that you must authenticate as a user with superuser (root) privileges to edit the /etc/services file.
db2
update
command: $ db2 update dbm cfg using svcename DB2_connection_service_port
In this command, DB2_connection_service_port represents the name of the DB2 connection service port you specified in the /etc/services file (for example, db2cdb2inst1).
db2 catalog
command: $ db2 catalog tcpip node WASNODE remote 127.0.0.1 \ server DB2_connection_service_port
In this command, DB2_connection_service_port represents the DB2 connection service port server name specified in the /etc/services file (for example, db2cdb2inst1).
$ db2 catalog db WAS40 as WASLOOP $ db2 uncatalog db WAS40 $ db2 catalog db WASLOOP as WAS40 at node WASNODE
$ db2stop $ db2start
In addition, the steps below supercede those in the section titled "Verifying
the connection to the database" in the InfoCenter article "Configuring
and testing DB2 UDB 7.2.". Note that, although the steps below instruct you
to verify a connection to the database named wasloop
, the name of
the WebSphere Application Server repository is was40
.
Verifying the connection to the database
Perform the following steps to verify a connection to a database named
wasloop
:
wasloop
using the db2
connect
command: $ db2 connect to wasloop
Correct output resembles the following:
Database Connection Information Database server = DB2/LINUX 7.2.1 SQL authorization ID = DB2INST1 Local database alias = WASLOOP
was40
using the db2
connect
command: $ db2 connect to was40
Correct output resembles the following:
SQL1403N The username and/or password supplied is incorrect. SQLSTATE=08004
exit
at the command prompt. Step 6 in instructions in the InfoCenter on "Mounting a CD-ROM in HP-UX" should be changed to following:
/usr/sbin/pfs_mount /dev/dsk/c0t6d0 /cdrom
The /dev/dsk/c0t6d0
part is missing in the instructions
currently in the InfoCenter.
Step 2 in instructions in the InfoCenter on "Installing Oracle 8i Release 3 (8.1.7)" for HP-UX should not reference the SHMMIN parameter. There is no such configurable parameter in HP-UX 11.0.
If you receive the following message after requesting help on a UNIX platform, your locale may be set to the default C locale.
ADGU2030E: The browser could not start with the command: netscape /opt/WebSphere/AppServer/web/InfoCenter/was/06060200.html. Received return code 255. Verify that you can run the browser from a command line and that access control is disabled.
There are two work arounds for this problem. You can either set your locale in the shell where your administrative console is launched, or you can launch a Netscape browser window before accessing help.
To see a list of the valid locales for your machine, run locale
-a
To set the locale, run export LANG=locale
, where
locale is a valid locale. For example, to set United States English,
run
export LANG=en_US.iso88591
This problem is common on HP-UX and Solaris but may occur on AIX if the locale is not set properly.
If you receive the ADGU2030E message with a return code of 1
,
verify that access control is disabled. To turn off access control, run
xhost +
The instructions in the InfoCenter on "Installing DB2 UDB 7.2" and "Configuring DB2 UDB 7.2" state that the directory used for DB2 UDB is /opt/IBMdb2/V7.2 for Solaris and /usr/lpp/db2_07_02 for AIX. The AIX installation might, in fact, use the directory /usr/lpp/db2_07_01. Similarly, the Solaris installation might use the directory /opt/IBMdb2/V7.1, which is the correct directory for installation on Solaris. For the latest product documentation, see the IBM WebSphere Application Server InfoCenter at www.ibm.com/software/webservers/appserv/infocenter.html.
The instructions in the InfoCenter on "3.2.3: Upgrading Version 4.0 Advanced Single Server Edition" should provide as follows:
To upgrade version 4.0 of the Advanced Single Server Edition with IBM HTTP Server to version 4.0.1 of the Advanced Single Server Edition with IBM HTTP Server:
The information in the InfoCenter on security as to z/OS interoperability needs to be changed as follows:
c:\temp\wsserver.key
.
The Full Select feature for Entity EJB finders has been removed from the Application Assembly Tool. Information on the Application Assembly Tool should no longer document the feature.
The article "5.6.3: Writing a custom interceptor" in the InfoCenter needs to be changed. The section "Using the TrustAssociationInterceptor interface" should state that the interceptor Java interface com.ibm.websphere.security.TrustAssociationInterceptor defines the following methods:
public boolean isTargetInterceptor(HttpServletRequest req) throws WebTrustAssociationException;
public void validateEstablishedTrust(HttpServletRequest req) throws WebTrustAssociationFailedException;
public String getAuthenticatedUsername(HttpServletRequest req) throws WebTrustedAssociationUserException;
The statement that "each server group and clone must be secured individually" in the InfoCenter article "6.6.18.1.2: Securing cloned applications" is incorrect. To secure a cloned application, you secure an enterprise application, put that secured application into a server group, and then make clones of the server group.
The InfoCenter article "5.7.3: ORB SSL Configuration" has incorrect information. The correct values for the com.ibm.ssl.protocol property and the versions of SSL that each supports are as follows:
Also, the documentation in this section states: "First try the TLS_SSL protocol for the highest version support, then try the SSL protocol to step down to SSLv3." The correct statement is as follows: "First try the SSL protocol for the highest version support, then try the SSLv3 protocol to step down to SSLv3."
On the Advanced Single Server Edition, you might not be able to open PDF versions of the documentation if you accessed help through the administrative console. As a workaround, point your Web browser to the index.html page of the InfoCenter, which is located in the subdirectory main_WebSphere_directory/web/InfoCenter and has the URL main_WebSphere_directory/web/InfoCenter/index.html.
To correct the problem, do not install the InfoCenter jar files into the same directory as the WebSphere Application Server product. Install into a separate directory. The following steps describe how to download and install the full WebSphere Application Server InfoCenter from a self-extracting .jar file.
java
command is recognized.
InfoCenter_name.jar.zip
to:
InfoCenter_name.jar
In other words, remove the .zip from the end of the file. Web browsers often treat .jar files as corrupted so .zip is added to the end of the file to avoid this problem.
java
command to install the
InfoCenter:
java -jar InfoCenter_name.jar
java -classpath InfoCenter_name.jar;%CLASSPATH InfoCenterDoc.class
The information on installing WebSphere Application Server on Windows instructs users who have downloaded a new prereq.properties file or disabled the Prerequisite Checker to enter the command:
setup.exe -prereqfile c:\tmp\prereq.properties
The -prereqfile option is not need on Windows. Instead, enter the command:
setup.exe c:\temp\prereq.properties
InfoCenter articles on installing DB2 Universal Database (UDB) 7.2 require the following clarifications: articles on installing DB2 UDB 7.2 document how to install DB2 UDB Version 7.2w, which is provided as part of the WebSphere Application Server Advanced Edition Version 4.0 CD package. DB2 UDB Version 7.2w is the same as the generally available DB2 UDB Version 7.2 with DB2 UDB fixpack 3 and with a DB2 UDB fixpack for WebSphere Application Server.