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

A quick disclaimer...

Although I put in a great effort into researching all the topics I cover, mistakes can happen. Use of any information from my blog posts should be at own risk and I do not hold any liability towards any information misuse or damages caused by following any of my posts.

All content and opinions expressed on this Blog are my own and do not represent the opinions of my employer (Oracle). Use of any information contained in this blog post/article is subject to this disclaimer.
Hi! You can search my blog here ⤵
NOTE: (2022) This Blog is no longer maintained and I will not be answering any emails or comments.

I am now focusing on Atari Gamer.