Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

About a month after I posted an article with a similar error when generating a SoapUI project, I've come across this issue once more. The root cause for this one took longer to analyse, wasting a number of days pursuing the wrong lead, but eventually I found out what was causing it and how to fix it.

This is the error that SoapUI was showing me. I've edited this slightly to highlight the issue and to make it a bit more readable. The error is reporting that one of my types appears to be referenced from an incorrect namespace i.e. a namespace where it is not actually defined.

SoapUI was encountering [email protected]://incorrect_namespace, when the WSDL/XSD should have had it as [email protected]://correct_namespace.
 SoapUI Error Log
org.apache.xmlbeans.XmlException: error: src-resolve.a: Could not find type '[email protected]://incorrect_namespace'. Do you mean to refer to the type named [email protected]://correct_namespace?
at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
at org.apache.xmlbeans.XmlBeans.compileXsd(XmlBeans.java:553)
at com.eviware.soapui.impl.wsdl.support.xsd.SchemaUtils.buildSchemaTypes(SchemaUtils.java:260)
at com.eviware.soapui.impl.wsdl.support.xsd.SchemaUtils.loadSchemaTypes(SchemaUtils.java:179)
...


Ok so what was causing this? Turns out the error had nothing to do with the data type that SoapUI was having issues finding. This is because JAX-WS has made a tremendous mess of the generated XSDs. In my case the issue was not very obvious, but eventually I stumbled upon something like this in my 'common' XSD...


 Common XSD
<xs:element name="myNumber">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="16"/>
<xs:maxLength value="16"/>
</xs:restriction>
</xs:simpleType>
</xs:element>


On its own this is not a big deal, just an element definition with a restricted simple type. What could go wrong?! Well, when you make a reference to this element from another XSD, which is what I saw, it looks like JAX-WS blows up.

This is what a second XSD had as a part of a complex type definition...
 Second XSD
...
<xs:complexType>
<xs:sequence>
<xs:element ref="ns2:myNumber"/>
...



The knock-on effect was when JAX-WS generated all of the XSDs for the WSDL file, it got some namespaces in a tangle.

The solution? Simple, change the element in the 'common' XSD to a type (simpleType in my case), and then use this type instead of making an element reference.

So my 'common' XSD had this now...
 Common XSD
<xs:simpleType name="myNumber">
<xs:restriction base="xs:string">
<xs:minLength value="16"/>
<xs:maxLength value="16"/>
</xs:restriction>
</xs:simpleType>


...and I've changed my second XSD to use the new type as a type. To keep backwards compatibility, the name I used for this element is the same as its type.
 Second XSD
...
<xs:element name="myNumber" type="ns2:myNumber"/>
...


-i

Hope you found this post useful...

...so please read on! I love writing articles that provide beneficial information, tips and examples to my readers. All information on my blog is provided free of charge and I encourage you to share it as you wish. There is a small favour I ask in return however - engage in comments below, provide feedback, and if you see mistakes let me know.

If you want to show additional support and help me pay for web hosting and domain name registration, donations, no matter how small, are always welcome!

Use of any information contained in this blog post/article is subject to this disclaimer.
comments powered by Disqus
Other posts you may like...