Note: This problem is for only those OS-es in which file names are case
insensitive, such as Windows.

In org.globus.wsrf.tools.wsdl.GenerateBinding

145: portTypeFile = new File(portTypeFile).getCanonicalPath();
146: portTypeInput = new FileInputStream(portTypeFile);
.
.
.
178: String relativePortTypeFile =
179:                RelativePathUtil.getRelativeFileName(new File(portTypeFile),
180:                                                    new File(bindingFile));


Under Windows, the filenames are case-insensitive. Hence, if the bindingFile
string wasnt in the os-dependent canonical format when passed to
GenerateBinding, it wont match exactly with the portTypeFile string (which gets
canonicalized). This creates a problem when the gar file is deployed in a
different machine/filesystem/partition because the directory structure in the
<portType>_bindings.wsdl that gets created by GenerateBinding doesnt match up to
the directory structure of the deployed location.

Example:
If the schema file is in C:\ABC\build\schema\abc.wsdl. If the parameters passed
to GenerateBinding are 
java ...GenerateBinding -i C:\abc\build\schema\abc_flattened.wsdl -o
C:\abc\build\schema\abc

Now, since only the portTypeFile gets canonicalized, the relative path inside
the generated abc_bindings.wsdl will become
../../../ABC/build/schema/abc_flattened.wsdl

[ This kind of scenario can occur from various Windows shells such as 4NT. ]

Now when we deploy our gar into a different machine/filesystem, the above
relative path doesnt work anymore even though both abc_flattened.wsdl and
abc_bindings.wsdl are in the same directory.

Hence, canonicalizing both the filenames will solve the issue. I propose a
single line of code to be added, between lines 145-146 of
org.globus.wsrf.tools.wsdl.GenerateBinding

bindingFile = new File(bindingFile).getCanonicalPath();

This will solve the above issue.