PQ77134, 5.0.2: WebSphere Application Server does
not accept SymLink in Ear dir.
Downloadable files
Abstract
Using symbolic links to represent modules in installed
applications fails at startup.
Download Description
PQ77134 resolves the following problem:
ERROR DESCRIPTION:
Problem description: After upgrading to WebSphere App Svr fixpack 5.0.2,
when attempting to install web applications using an unpacked EAR
directory with a symlink to the real directory that contains the unpacked
war file, it fails.
However, if the contents of the unpacked war file are copied into the EAR
directory (i.e. not using a symlink), everything works fine. This is a
regression from WebSphere Application Server version 5.0 and 5.0.1
USERS AFFECTED:
WebSphere Application Server users installing applications that use
symbolic links on a UNIX platform.
PROBLEM DESCRIPTION:
Using symbolic links to represent modules in installed applications fails
at startup.
A regression had been introduced with a fix for a previously reported
problem with double file separators in configuration files. The fix for
that problem was to canonicalize the file path before opening modules.
Canonicalizing the path causes symbolic links to fail. The fix for this is
not to use canonical paths in the case of symbolic links.
The symptom of is this problem is a runtime exception, for example:
---- Begin backtrace for nested exception
ModuleRefImpl.com.ibm.etools.archive.exception.
NoModuleFileException:
A file does not exist for module element having uri: xxx.war
at
com.ibm.etools.commonarchive.impl.ModuleRefImpl.checkType(ModuleRefImpl.java:715)
at
com.ibm.etools.commonarchive.impl.ModuleRefImpl.initModuleFileFromEAR(ModuleRefImpl.java:270)
at
com.ibm.etools.commonarchive.impl.ModuleRefImpl.getModuleFile(ModuleRefImpl.java:247)
PROBLEM CONCLUSION:
The relevant common archive classes were updated to correctly handle
symbolic links.
Prerequisites
Please download the Updateinstaller tool to install this fix.