You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Michael Bricout <mi...@iona.com> on 2006/10/25 15:16:22 UTC
Possible WSDL/Schema multiple import bug
Hi,
I have a test case that uses a set of WSDLs and schemas with multiple
imports using relative URIs.
ie: A.wsdl imports B.xsd that imports C.xsd, all are located in the
same directory.
In A.wsdl:
<xsd:import namespace="http://foo" schemaLocation="./B.xsd"/>
In B.xsd:
<xsd:import namespace="http://foo/bar" schemaLocation="./C.xsd"/>
Code generation works fine, however I have a problem at runtime where
the server fails to initialize with the following exception:
java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException:
/[my project path]/C.xsd (No such file or directory)
The problem is that the URI for importing C.xsd is incorrectly determined.
In the example above, C.xsd would actually be located in
/[my project path]/target/test/wsdl/C.xsd
I see the following behavior in org.apache.cxf.resource.URIResolver:
For A imports B, we create a URIResolver with the following parameters:
baseUriStr = "file:[path to A]/A.wsdl" (correct)
uriStr = "./B.xsd"
Then tryFileSystem(baseUriStr, uriStr) is invoked and B.xsd is correctly
resolved.
Now for B import C, we create a URIResolver with the following parameters:
baseUriStr = "./B.xsd"
uriStr = "./C.xsd"
The value for the base URI being set to a relative path, we fail to resolve
C.xsd. tryFileSystem ends up calling tryClasspath("./C.xsd"), which in
turn calls tryRemote(), which aborts on a MalformedURLException.
I simplified my test case a bit in an effort to isolate the issue, but
I get the same problem when using relative URIs to import schemas
from different directories.
Should I file a bug report for this, or am I doing something wrong ?
This use case was working before the switch from XmlSchema 1.0.2 to 1.1
Best regards,
Michael
Re: Possible WSDL/Schema multiple import bug
Posted by James Mao <ja...@iona.com>.
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.
>>>>
>>>> [...]
>>>>
>
>
Re: Possible WSDL/Schema multiple import bug
Posted by Peter Jones <pe...@iona.com>.
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.
> >>
> >> [...]
--
Peter Jones
IONA Technologies Inc.
E-Mail: mailto:peter.jones@iona.com
Tel: (w) 709-738-3725 x22 | Fax: 709-738-3745
84-86 Elizabeth Ave. St. John's, NL A1A 1W7 Canada
Re: Possible WSDL/Schema multiple import bug
Posted by James Mao <ja...@iona.com>.
Hi peter ,
Sorry that i didn't mention that Tom have not commit the change.
He'll commit soon.
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.
>>
>>
>> Dan Diephouse 写é“:
>>
>>> Michael - did this ever get resolved? If not, can you create a JIRA
>>> issue so we make sure it doesn't get lost?
>>>
>>> - Dan
>>>
>>> Michael Bricout wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> I have a test case that uses a set of WSDLs and schemas with multiple
>>>> imports using relative URIs.
>>>>
>>>> ie: A.wsdl imports B.xsd that imports C.xsd, all are located in the
>>>> same directory.
>>>>
>>>> In A.wsdl:
>>>> <xsd:import namespace="http://foo" schemaLocation="./B.xsd"/>
>>>>
>>>> In B.xsd:
>>>> <xsd:import namespace="http://foo/bar" schemaLocation="./C.xsd"/>
>>>>
>>>> Code generation works fine, however I have a problem at runtime where
>>>> the server fails to initialize with the following exception:
>>>>
>>>> java.lang.RuntimeException:
>>>> org.apache.ws.commons.schema.XmlSchemaException:
>>>> /[my project path]/C.xsd (No such file or directory)
>>>>
>>>> The problem is that the URI for importing C.xsd is incorrectly
>>>> determined.
>>>> In the example above, C.xsd would actually be located in
>>>> /[my project path]/target/test/wsdl/C.xsd
>>>>
>>>>
>>>> I see the following behavior in org.apache.cxf.resource.URIResolver:
>>>>
>>>>
>>>> For A imports B, we create a URIResolver with the following parameters:
>>>> baseUriStr = "file:[path to A]/A.wsdl" (correct)
>>>> uriStr = "./B.xsd"
>>>>
>>>> Then tryFileSystem(baseUriStr, uriStr) is invoked and B.xsd is correctly
>>>> resolved.
>>>>
>>>>
>>>> Now for B import C, we create a URIResolver with the following
>>>> parameters:
>>>> baseUriStr = "./B.xsd"
>>>> uriStr = "./C.xsd"
>>>>
>>>> The value for the base URI being set to a relative path, we fail to
>>>> resolve
>>>> C.xsd. tryFileSystem ends up calling tryClasspath("./C.xsd"), which in
>>>> turn calls tryRemote(), which aborts on a MalformedURLException.
>>>>
>>>>
>>>> I simplified my test case a bit in an effort to isolate the issue, but
>>>> I get the same problem when using relative URIs to import schemas
>>>> from different directories.
>>>>
>>>>
>>>> Should I file a bug report for this, or am I doing something wrong ?
>>>>
>>>> This use case was working before the switch from XmlSchema 1.0.2 to 1.1
>>>>
>>>> Best regards,
>>>> Michael
>>>>
>
>
Re: Possible WSDL/Schema multiple import bug
Posted by Peter Jones <pe...@iona.com>.
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.
>
>
> Dan Diephouse åé:
> > Michael - did this ever get resolved? If not, can you create a JIRA
> > issue so we make sure it doesn't get lost?
> >
> > - Dan
> >
> > Michael Bricout wrote:
> >
> >> Hi,
> >>
> >> I have a test case that uses a set of WSDLs and schemas with multiple
> >> imports using relative URIs.
> >>
> >> ie: A.wsdl imports B.xsd that imports C.xsd, all are located in the
> >> same directory.
> >>
> >> In A.wsdl:
> >> <xsd:import namespace="http://foo" schemaLocation="./B.xsd"/>
> >>
> >> In B.xsd:
> >> <xsd:import namespace="http://foo/bar" schemaLocation="./C.xsd"/>
> >>
> >> Code generation works fine, however I have a problem at runtime where
> >> the server fails to initialize with the following exception:
> >>
> >> java.lang.RuntimeException:
> >> org.apache.ws.commons.schema.XmlSchemaException:
> >> /[my project path]/C.xsd (No such file or directory)
> >>
> >> The problem is that the URI for importing C.xsd is incorrectly
> >> determined.
> >> In the example above, C.xsd would actually be located in
> >> /[my project path]/target/test/wsdl/C.xsd
> >>
> >>
> >> I see the following behavior in org.apache.cxf.resource.URIResolver:
> >>
> >>
> >> For A imports B, we create a URIResolver with the following parameters:
> >> baseUriStr = "file:[path to A]/A.wsdl" (correct)
> >> uriStr = "./B.xsd"
> >>
> >> Then tryFileSystem(baseUriStr, uriStr) is invoked and B.xsd is correctly
> >> resolved.
> >>
> >>
> >> Now for B import C, we create a URIResolver with the following
> >> parameters:
> >> baseUriStr = "./B.xsd"
> >> uriStr = "./C.xsd"
> >>
> >> The value for the base URI being set to a relative path, we fail to
> >> resolve
> >> C.xsd. tryFileSystem ends up calling tryClasspath("./C.xsd"), which in
> >> turn calls tryRemote(), which aborts on a MalformedURLException.
> >>
> >>
> >> I simplified my test case a bit in an effort to isolate the issue, but
> >> I get the same problem when using relative URIs to import schemas
> >> from different directories.
> >>
> >>
> >> Should I file a bug report for this, or am I doing something wrong ?
> >>
> >> This use case was working before the switch from XmlSchema 1.0.2 to 1.1
> >>
> >> Best regards,
> >> Michael
--
Peter Jones
IONA Technologies Inc.
E-Mail: mailto:peter.jones@iona.com
Tel: (w) 709-738-3725 x22 | Fax: 709-738-3745
84-86 Elizabeth Ave. St. John's, NL A1A 1W7 Canada
Re: Possible WSDL/Schema multiple import bug
Posted by James Mao <ja...@iona.com>.
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.
Dan Diephouse 写道:
> Michael - did this ever get resolved? If not, can you create a JIRA
> issue so we make sure it doesn't get lost?
>
> - Dan
>
> Michael Bricout wrote:
>
>> Hi,
>>
>> I have a test case that uses a set of WSDLs and schemas with multiple
>> imports using relative URIs.
>>
>> ie: A.wsdl imports B.xsd that imports C.xsd, all are located in the
>> same directory.
>>
>> In A.wsdl:
>> <xsd:import namespace="http://foo" schemaLocation="./B.xsd"/>
>>
>> In B.xsd:
>> <xsd:import namespace="http://foo/bar" schemaLocation="./C.xsd"/>
>>
>> Code generation works fine, however I have a problem at runtime where
>> the server fails to initialize with the following exception:
>>
>> java.lang.RuntimeException:
>> org.apache.ws.commons.schema.XmlSchemaException:
>> /[my project path]/C.xsd (No such file or directory)
>>
>> The problem is that the URI for importing C.xsd is incorrectly
>> determined.
>> In the example above, C.xsd would actually be located in
>> /[my project path]/target/test/wsdl/C.xsd
>>
>>
>> I see the following behavior in org.apache.cxf.resource.URIResolver:
>>
>>
>> For A imports B, we create a URIResolver with the following parameters:
>> baseUriStr = "file:[path to A]/A.wsdl" (correct)
>> uriStr = "./B.xsd"
>>
>> Then tryFileSystem(baseUriStr, uriStr) is invoked and B.xsd is correctly
>> resolved.
>>
>>
>> Now for B import C, we create a URIResolver with the following
>> parameters:
>> baseUriStr = "./B.xsd"
>> uriStr = "./C.xsd"
>>
>> The value for the base URI being set to a relative path, we fail to
>> resolve
>> C.xsd. tryFileSystem ends up calling tryClasspath("./C.xsd"), which in
>> turn calls tryRemote(), which aborts on a MalformedURLException.
>>
>>
>> I simplified my test case a bit in an effort to isolate the issue, but
>> I get the same problem when using relative URIs to import schemas
>> from different directories.
>>
>>
>> Should I file a bug report for this, or am I doing something wrong ?
>>
>> This use case was working before the switch from XmlSchema 1.0.2 to 1.1
>>
>> Best regards,
>> Michael
>>
>>
>>
>
>
Re: Possible WSDL/Schema multiple import bug
Posted by Dan Diephouse <da...@envoisolutions.com>.
Michael - did this ever get resolved? If not, can you create a JIRA
issue so we make sure it doesn't get lost?
- Dan
Michael Bricout wrote:
>Hi,
>
>I have a test case that uses a set of WSDLs and schemas with multiple
>imports using relative URIs.
>
>ie: A.wsdl imports B.xsd that imports C.xsd, all are located in the
>same directory.
>
>In A.wsdl:
> <xsd:import namespace="http://foo" schemaLocation="./B.xsd"/>
>
>In B.xsd:
> <xsd:import namespace="http://foo/bar" schemaLocation="./C.xsd"/>
>
>Code generation works fine, however I have a problem at runtime where
>the server fails to initialize with the following exception:
>
>java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException:
>/[my project path]/C.xsd (No such file or directory)
>
>The problem is that the URI for importing C.xsd is incorrectly determined.
>In the example above, C.xsd would actually be located in
>/[my project path]/target/test/wsdl/C.xsd
>
>
>I see the following behavior in org.apache.cxf.resource.URIResolver:
>
>
>For A imports B, we create a URIResolver with the following parameters:
> baseUriStr = "file:[path to A]/A.wsdl" (correct)
> uriStr = "./B.xsd"
>
>Then tryFileSystem(baseUriStr, uriStr) is invoked and B.xsd is correctly
>resolved.
>
>
>Now for B import C, we create a URIResolver with the following parameters:
> baseUriStr = "./B.xsd"
> uriStr = "./C.xsd"
>
>The value for the base URI being set to a relative path, we fail to resolve
>C.xsd. tryFileSystem ends up calling tryClasspath("./C.xsd"), which in
>turn calls tryRemote(), which aborts on a MalformedURLException.
>
>
>I simplified my test case a bit in an effort to isolate the issue, but
>I get the same problem when using relative URIs to import schemas
>from different directories.
>
>
>Should I file a bug report for this, or am I doing something wrong ?
>
>This use case was working before the switch from XmlSchema 1.0.2 to 1.1
>
>Best regards,
>Michael
>
>
>
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com