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.


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...




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...



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...


...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.


-i