Yeah, we definitely need more test cases for this.
Thanks,
James.
Hi James,
On Mon, Nov 06, 2006 at 10:13:38AM +0800, James Mao wrote:
Hi peter ,
Sorry that i didn't mention that Tom have not commit the change.
He'll commit soon.
I was just trying out the changes committed to the URIResolver earlier
today and I still had to make a small change to get things to work with
the mtosi wsdls and schemas I was using. I haven't looked at it closely
enough to tell for sure, but I think it might be the assumption in
URIResolver.getAbsoluteFileStr() that the last history element was the
parent - i.e. the file that imported the file we are looking for... some
of the mtosi schemas import several schemas which import other schemas...
Anyway, there's a slight change to my work-around though, since the
URIResolver.tryFileSystemState() doesn't seem to set the file member.
if (resolver.getURI().isAbsolute()) {
// When importing a relative file,
// setSystemId with an absolute path so the
// resolver finds any files which that file
// imports with locations relative to it.
URI resolved = resolver.getURI();
schemaLocation = resolver.getURI().toString();
}
I can probably check in this work-around for now, until I can put
together a smaller test case to help track down the problem?
Cheers,
Peter
Cheers,
James.
Peter Jones 写�:
Hi there,
There is still an issue here. If you import a relative file, and then that
file imports another file with a path relative to the import (in a
different directory) then this imported file isn't resolved correctly.
I've worked around this problem in my tree in XmlSchemaURIResolver by
resetting the schemaLocation:
if (resolver.isResolved()) {
if (resolver.isFile()) {
// When importing a relative file,
// setSystemId with an absolute path so the
// resolver finds any files which that file
// imports with locations relative to it.
URI resolved = resolver.getURI();
schemaLocation = resolved.toString();
}
InputSource source = new InputSource(resolver.getInputStream());
source.setSystemId(schemaLocation);
return source;
}
So, when the resolver is called to resolve the second import, the baseUri
passed in is an absolute path instead of a relative path, which allows the
resolver to find the second file.
Cheers,
Peter
On Sun, Nov 05, 2006 at 02:19:32PM +0800, James Mao wrote:
I thought Tom already fix this problem last Friday.
And i think the better solution is to report a bug to ws-common , not in
cxf.
But anyway, tom already fix that.
[...]
