An xsd:import/ instruction for an invalid file name causes the following exception on context initialization:
org.apache.ws.commons.schema.XmlSchemaException
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:351)
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1839)
at org.apache.ws.commons.schema.SchemaBuilder.handleInclude(SchemaBuilder.java:1615)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:181)
at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:83)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:424)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:347)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:379)
at org.springframework.xml.xsd.commons.CommonsXsdSchemaCollection.afterPropertiesSet(CommonsXsdSchemaCollection.java:133)
The root cause is a file not found exception, but it's not at all obvious which XSD caused this, nor what file is missing. (In my case there was a typo in a the import instruction so it was quite hard to spot by just examining the schema files.) I think it's mostly org.apache.ws.commons.schema.XmlSchemaException to blame for not correctly displaying the root cause, but it would be even nicer if CommonsXsdSchemaCollection would trap the exception, report explicitly which XSD resource caused it and re-throw it as a CommonsXsdSchemaException.
It seems that org.apache.ws.commons.schema.XmlSchemaException is not the only exception to be thrown in case of error in the xsd. For instance, org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema wraps every exception with a RuntimeException. In some other cases a NPE is thrown.
Thus the simplest and safest option seems to me to surround Commons Xsd code with a try/catch(Exception).
patch+unit test.
Pavel Tcholakov opened SWS-409 and commented
An xsd:import/ instruction for an invalid file name causes the following exception on context initialization:
org.apache.ws.commons.schema.XmlSchemaException
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:351)
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1839)
at org.apache.ws.commons.schema.SchemaBuilder.handleInclude(SchemaBuilder.java:1615)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:181)
at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:83)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:424)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:347)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:379)
at org.springframework.xml.xsd.commons.CommonsXsdSchemaCollection.afterPropertiesSet(CommonsXsdSchemaCollection.java:133)
The root cause is a file not found exception, but it's not at all obvious which XSD caused this, nor what file is missing. (In my case there was a typo in a the import instruction so it was quite hard to spot by just examining the schema files.) I think it's mostly org.apache.ws.commons.schema.XmlSchemaException to blame for not correctly displaying the root cause, but it would be even nicer if CommonsXsdSchemaCollection would trap the exception, report explicitly which XSD resource caused it and re-throw it as a CommonsXsdSchemaException.
Affects: 1.5.4
Attachments:
Referenced from: commits 3e11385
The text was updated successfully, but these errors were encountered: