Prevent the WebSphere Application Server V5 updateInstaller Java SDK from using library files related to other Java SDKs
 Technote (troubleshooting)
 
Problem(Abstract)
The WebSphere Application Server V5 updateInstaller Java SDK may improperly invoke libraries which belong to other Java SDKs under some circumstances. This can lead to unpredictable behavior in the updateInstaller. This article describes methods of preventing this from occurring.
 
Cause
The WebSphere Application Server V5 updateInstaller Java SDK may improperly invoke libraries which belong to other Java SDKs under some circumstances. This can lead to unpredictable behavior in the updateInstaller. For example, the updateInstaller may report "Fix Pack data corrupted", when the Fix Pack is actually intact. Alternatively, the updateInstaller may throw a prereq-checker failure, stating that the Fix Pack is not appropriate to be installed on the current product, when the Fix Pack does actually meet the requirements.
 
Resolving the problem
Under some circumstances, it is possible for the IBM Java SDK responsible for running the updateInstaller to load libraries from other Java SDK packages installed on the system, even when the "java_tmp" directory contains the correct version of Java. Often, this will cause problems with the updateInstaller's XML parser, resulting in "corrupted fix pack data" messages.

In order to prevent this, remove references to other Java SDK packages installed on the system. Be sure that the following environment variables contain no references to external Java SDK packages:

PATH
CLASSPATH
LIBPATH

References can be removed from those variables either by redefining them without the references or redefining them with empty values.

Do not define the PATH variable with an empty value on Unix-based systems, as this will compromise the functionality of the current command session. The PATH should at least contain the following four directory references, delimited by colon ( " : " ) characters, on UNIX-based systems:

/bin:/sbin:/usr/bin:/usr/sbin

On Windows-based systems, the PATH should at least contain a reference to the "system32" directory under the Windows-root directory. For example, this path might be C:\Windows\System32. The %SystemRoot% environment variable should contain a reference to the Windows-root directory.

Alternatively, instead of removing references to external Java SDK packages, it is also possible to rename or move the path containing the external Java SDK packages before invoking the updateInstaller. This prevents the updateInstaller from loading the libraries referenced in the external packages. Once the updateInstaller is finished, the external Java SDK packages can be moved back to their original location.


Here are examples which show the sequence of commands necessary to wipe out the relevant variables in the current environment to help ensure the updateInstaller's Java SDK loads the proper libraries:


On UNIX-based systems:

export PATH=
/usr/bin:/usr/sbin:/sbin
export CLASSPATH=
export LIBPATH=


On Windows-based systems:

set PATH=%SystemRoot%\system32
set CLASSPATH=

set LIBPATH=
 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers Runtimes for Java Technology Java SDK
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Install
Operating system(s): AIX
Software version: 5.1
Software edition:
Reference #: 1205243
IBM Group: Software Group
Modified date: May 31, 2005