[
https://issues.apache.org/jira/browse/WODEN-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lauri Carlson updated WODEN-229:
--------------------------------
Description:
Running axis2 version 1.5.4 WSDLJava on w3c sparql protocol wsdl 2.0, got the
following errors from woden:
java org.apache.axis2.wsdl.WSDL2Java -uri protocol-query.wsdl -p my.service -wv
2 -d jaxbri -ss -sd -ssi -o /my/dir
Woden[Error],0:0,WSDL521,Could not parse an inline schema in the WSDL at URL
"jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/SparqlService.wsdl".,java.lang.RuntimeException:org.apache.ws.commons.schema.XmlSchemaException:
JAR entry
jar:file:///usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/xml.xsd
not found in /usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar
Woden[Error],0:0,WSDL521,Could not parse an inline schema in the WSDL at URL
"jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/SparqlService.wsdl".,java.lang.RuntimeException:org.apache.ws.commons.schema.XmlSchemaException:
JAR entry
jar:file:///usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/result.xsd
not found in /usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar
To me this looks like another woden resolver bug, like the one discussed in
http://marc.info/?l=woden-dev&m=119929918928610&w=2,
this time caused by references to xsd imports two level deep inside sparql
protocol wsdl, specifically these:
result.xsd: <xs:import namespace="http://www.w3.org/XML/1998/namespace";
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
protocol-types.xsd:
<xs:import namespace="http://www.w3.org/2007/SPARQL/results#";
schemaLocation="result.xsd" />
--- original issue:
As per the woden-dev thread at [1], when the WSDL and XSD files are packaged
inside a jar file, a relative path URI on the schemaLocation attribute of a
schema import is not resolved correctly against the base jar URI of the
containing WSDL file.
For example, if the WSDL base URI is
"jar:file:///C:/temp/test.jar!/META-INF/foo.wsdl" and this WSDL has an inlined
schema containing a schema import with schemaLocation="bar.xsd" and this XSD
file is also packaged in the META-INF directory of the jar file, the resolved
XSD URI should be "jar:file:///C:/temp/test.jar!/META-INF/bar.xsd".
Currently, this will only work if a catalog is configured which maps the
schemaLocation URI to the jar file URI (see the email thread for more info).
Then, Woden's SimpleURIResolver will resolve the XSD path correctly. But this
is not convenient for applications that don't have direct access to Woden (e.g.
Axis2 user apps).
The problem is that Woden's SchemaResolverAdapter class, which gets registered
with WS-Commons XmlSchema, uses the resolve(URI) method of java.net.URI to
resolve the the baseURI and schemaLocation URI - as in,
baseURI.resolve(schemaLocation). However, this method does not work if baseURI
is opaque - instead, it just returns the schemaLocation which in turn gets
resolved against the current directory. A jar file URI ("jar:file:/...") is an
opaque URI (see URI javadoc).
[1]
http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200712.mbox/%[email protected]%3e
was:
As per the woden-dev thread at [1], when the WSDL and XSD files are packaged
inside a jar file, a relative path URI on the schemaLocation attribute of a
schema import is not resolved correctly against the base jar URI of the
containing WSDL file.
For example, if the WSDL base URI is
"jar:file:///C:/temp/test.jar!/META-INF/foo.wsdl" and this WSDL has an inlined
schema containing a schema import with schemaLocation="bar.xsd" and this XSD
file is also packaged in the META-INF directory of the jar file, the resolved
XSD URI should be "jar:file:///C:/temp/test.jar!/META-INF/bar.xsd".
Currently, this will only work if a catalog is configured which maps the
schemaLocation URI to the jar file URI (see the email thread for more info).
Then, Woden's SimpleURIResolver will resolve the XSD path correctly. But this
is not convenient for applications that don't have direct access to Woden (e.g.
Axis2 user apps).
The problem is that Woden's SchemaResolverAdapter class, which gets registered
with WS-Commons XmlSchema, uses the resolve(URI) method of java.net.URI to
resolve the the baseURI and schemaLocation URI - as in,
baseURI.resolve(schemaLocation). However, this method does not work if baseURI
is opaque - instead, it just returns the schemaLocation which in turn gets
resolved against the current directory. A jar file URI ("jar:file:/...") is an
opaque URI (see URI javadoc).
[1]
http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200712.mbox/%[email protected]%3e
> CLONE -schemaLocation URI not resolved correctly using jar files - xsd two
> deep?
> --------------------------------------------------------------------------------
>
> Key: WODEN-229
> URL: https://issues.apache.org/jira/browse/WODEN-229
> Project: Woden
> Issue Type: Bug
> Components: Parser
> Reporter: Lauri Carlson
> Assignee: John Kaputin
> Fix For: M8
>
>
> Running axis2 version 1.5.4 WSDLJava on w3c sparql protocol wsdl 2.0, got the
> following errors from woden:
> java org.apache.axis2.wsdl.WSDL2Java -uri protocol-query.wsdl -p my.service
> -wv 2 -d jaxbri -ss -sd -ssi -o /my/dir
> Woden[Error],0:0,WSDL521,Could not parse an inline schema in the WSDL at URL
> "jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/SparqlService.wsdl".,java.lang.RuntimeException:org.apache.ws.commons.schema.XmlSchemaException:
> JAR entry
> jar:file:///usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/xml.xsd
> not found in
> /usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar
> Woden[Error],0:0,WSDL521,Could not parse an inline schema in the WSDL at URL
> "jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/SparqlService.wsdl".,java.lang.RuntimeException:org.apache.ws.commons.schema.XmlSchemaException:
> JAR entry
> jar:file:///usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/result.xsd
> not found in
> /usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar
> To me this looks like another woden resolver bug, like the one discussed in
> http://marc.info/?l=woden-dev&m=119929918928610&w=2,
> this time caused by references to xsd imports two level deep inside sparql
> protocol wsdl, specifically these:
> result.xsd: <xs:import namespace="http://www.w3.org/XML/1998/namespace";
> schemaLocation="http://www.w3.org/2001/xml.xsd"/>
> protocol-types.xsd:
> <xs:import namespace="http://www.w3.org/2007/SPARQL/results#";
> schemaLocation="result.xsd" />
> --- original issue:
> As per the woden-dev thread at [1], when the WSDL and XSD files are packaged
> inside a jar file, a relative path URI on the schemaLocation attribute of a
> schema import is not resolved correctly against the base jar URI of the
> containing WSDL file.
> For example, if the WSDL base URI is
> "jar:file:///C:/temp/test.jar!/META-INF/foo.wsdl" and this WSDL has an
> inlined schema containing a schema import with schemaLocation="bar.xsd" and
> this XSD file is also packaged in the META-INF directory of the jar file, the
> resolved XSD URI should be "jar:file:///C:/temp/test.jar!/META-INF/bar.xsd".
> Currently, this will only work if a catalog is configured which maps the
> schemaLocation URI to the jar file URI (see the email thread for more info).
> Then, Woden's SimpleURIResolver will resolve the XSD path correctly. But this
> is not convenient for applications that don't have direct access to Woden
> (e.g. Axis2 user apps).
> The problem is that Woden's SchemaResolverAdapter class, which gets
> registered with WS-Commons XmlSchema, uses the resolve(URI) method of
> java.net.URI to resolve the the baseURI and schemaLocation URI - as in,
> baseURI.resolve(schemaLocation). However, this method does not work if
> baseURI is opaque - instead, it just returns the schemaLocation which in turn
> gets resolved against the current directory. A jar file URI ("jar:file:/...")
> is an opaque URI (see URI javadoc).
> [1]
> http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200712.mbox/%[email protected]%3e
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
