ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (XMLSCHEMA-21) MalformedURLException - no protocol - when reading schema with recursive schema imports
Date Mon, 02 Apr 2012 18:01:26 GMT

    [ https://issues.apache.org/jira/browse/XMLSCHEMA-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244385#comment-13244385
] 

Daniel Kulp commented on XMLSCHEMA-21:
--------------------------------------


I'd need a full (preferably maven based) test case for this.   I cannot really reproduce it
using any "normal" usage of the API's.   When you call the various read methods, you need
to provide a proper URI for the base document, otherwise imports will not be resolvable. 
In SOME cases, we can try and detect the base URI, but that is very unreliable and it's MUCH
better to make sure you pass the proper system id URI into the read methods.

                
> MalformedURLException - no protocol - when reading schema with recursive schema imports
> ---------------------------------------------------------------------------------------
>
>                 Key: XMLSCHEMA-21
>                 URL: https://issues.apache.org/jira/browse/XMLSCHEMA-21
>             Project: XmlSchema
>          Issue Type: Bug
>    Affects Versions: XmlSchema 2.0.1
>         Environment: Windows7
>            Reporter: Arik Goldstein
>              Labels: MalformedURLException, import, schemalocation
>
> I have the following xsd files:
> schema1.xsd - contains import to schema2.xsd
> schema2.xsd
> schema3.xsd - contains import to schema1.xsd
> imports are with relative paths (plain file name, all schema files are in the same directory)
> Reading of schema1 and schema2 works fine.
> Reading of schema3 fails with the following exception and call stack:
> Caused by: java.lang.RuntimeException: java.net.MalformedURLException: no protocol: schema1.xsd
> 	at org.apache.ws.commons.schema.resolver.DefaultURIResolver.resolveEntity(DefaultURIResolver.java:72)
> 	at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:684)
> 	at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:538)
> 	at org.apache.ws.commons.schema.SchemaBuilder.handleSchemaElementChild(SchemaBuilder.java:1513)
> 	at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:659)
> 	at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:157)
> 	at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:499)
> 	at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:709)
> 	at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:706)
> 	at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:732)
> 	at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:541)
> 	at org.apache.ws.commons.schema.SchemaBuilder.handleSchemaElementChild(SchemaBuilder.java:1513)
> 	at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:659)
> 	at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:157)
> 	at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:499)
> 	at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:709)
> 	at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:556)
> 	at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:586)
> Debugging shows that:
> * when reading schema1.xsd and resolving schema2.xsd (in SchemaBuilder.resolveXmlSchema),
the baseUri is file and the operation succeeds
> * when reading schema3.xsd and resolving schema1.xsd->schema2.xsd, the baseUri is
plain text (schema1.xsd) and not file (file:/c:/schema1.xsd) and the   operation fails
> Workaround: use full path in the schema location (c:\schema1.xsd instead of schema1.xsd)
fixes the problem.
> However this workaround is ugly and the recursive import should work without  it. 
> I would be glad to hear your opinions. 
> Thanks in advance, 
> Arik Goldstein

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


Mime
View raw message