Bugzilla – Bug 3492
org.globus.wsrf.tools.wsdl.GenerateBinding should use canonical paths for both the bindingFile and serviceFile
Last modified: 2005-06-17 13:14:45
You need to
before you can comment on or make changes to this bug.
Note: This problem is for only those OS-es in which file names are case
insensitive, such as Windows.
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.
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
Now, since only the portTypeFile gets canonicalized, the relative path inside
the generated abc_bindings.wsdl will become
[ 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
bindingFile = new File(bindingFile).getCanonicalPath();
This will solve the above issue.
Created an attachment (id=642) [details]
Patch for bug #3942
Patch committed to cvs trunk and globus_4_0_branch. Thanks!