You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have been provided a large set of WSDLs as an artifact. These WSDLs are including their schemas through xs:include using a relative path. Schemas are also located in a hierarchical structure.
When configuring such a WSDL in Imposter, we encounter a Schema compilation error.
In the end it turns out to be an XmlBeans error: Caused by: org.apache.xmlbeans.XmlException: error: Could not load resource "schema-include.xsd" (network downloads disabled).
I found issue https://issues.apache.org/jira/browse/XMLBEANS-479 but when enabling downloads (using XmlOptions().setCompileDownloadUrls()) other issues appear (with existing tests): Caused by: org.apache.xmlbeans.XmlException: error: URL "schema.xsd" is not well-formed
(Error is also mentioned in comments of that XmlBeans issue, however issue is resolved...)
A quick solution I've found was to provide a custom entity resolver using XmlOptions().setEntityResolver(...). That entity resolver will look for XML schemas relative to the configured WSDL.
This worked for the parsing part. However the same problem appears when generating sample responses in SoapExampleService by calling XmlBean's SchemaInstanceGenerator. The latter does not let you configure XmlOptions directly.
Therefore the alternative I found was to configure this entity resolver globally. This was however a challenge on its own as the resolver needs the WSDL path, which is config specific. Given multiple threads are being used, I opted for a ThreadLocal.
I'll provide a PR with these changes.
The text was updated successfully, but these errors were encountered:
driesva
added a commit
to driesva/imposter
that referenced
this issue
Apr 11, 2024
Currently, WSDLs with xs:include fail parsing.
This fix configures XMLBeans to look for XML schemas which are include/imported relative to the folder having the configured WSDL.
fixesoutofcoffee#548
Currently, WSDLs with xs:include fail parsing.
This fix configures XMLBeans to look for XML schemas which are include/imported relative to the folder having the configured WSDL.
fixes#548
We have been provided a large set of WSDLs as an artifact. These WSDLs are including their schemas through
xs:include
using a relative path. Schemas are also located in a hierarchical structure.When configuring such a WSDL in Imposter, we encounter a Schema compilation error.
In the end it turns out to be an XmlBeans error:
Caused by: org.apache.xmlbeans.XmlException: error: Could not load resource "schema-include.xsd" (network downloads disabled).
I found issue https://issues.apache.org/jira/browse/XMLBEANS-479 but when enabling downloads (using
XmlOptions().setCompileDownloadUrls()
) other issues appear (with existing tests):Caused by: org.apache.xmlbeans.XmlException: error: URL "schema.xsd" is not well-formed
(Error is also mentioned in comments of that XmlBeans issue, however issue is resolved...)
A quick solution I've found was to provide a custom entity resolver using
XmlOptions().setEntityResolver(...)
. That entity resolver will look for XML schemas relative to the configured WSDL.This worked for the parsing part. However the same problem appears when generating sample responses in SoapExampleService by calling XmlBean's SchemaInstanceGenerator. The latter does not let you configure XmlOptions directly.
Therefore the alternative I found was to configure this entity resolver globally. This was however a challenge on its own as the resolver needs the WSDL path, which is config specific. Given multiple threads are being used, I opted for a ThreadLocal.
I'll provide a PR with these changes.
The text was updated successfully, but these errors were encountered: