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