local part cannot be "null" when creating a QName using Soap UI Mock Service

This week we fixed a major issue in our project.

Case
We're building a support portal in Web Center for an international customer. The portal interfaces to a number of back office systems, like Siebel, eBusiness Suite etc.
These interfaces are serviced by IBM Web Sphere and the logic in the service bus has (of course) to be developed.
The development starts with the WSDL of the web service we need to call. Once this WSDL is defined, we can start building.
However, we need an actual web service to test our implementation.

Solution
We used Soap UI in the past to test web services. Amazingly Soap UI has a feature to create a mock service. Basically a stub web service, based upon a WSDL.
In this mock service, you can define the response that is sent back upon a request, so you can test your application with 'live' data.
With this mock service, we created a data control based on the web service in JDeveloper and added this to a page (pretty straight forward, see a number of blog posts regarding this topic)
However, when we run the page we get an error: local part cannot be "null" when creating a QName

What is going on???
We read a lot of posts, forum entries and even raised a Service Request at Oracle Support. No answer however in more then a week.
Since all generated code is xml, we can't debug properly to see what went wrong.

Analysis
The WSDL and associated includes a lot of complex types. Is this causing the issue?
Will this work with a web service without complex input or output parameters?Also, we see six calls to the mock service in Soap UI (in the log section). Is this caused by some sort of retry mechanism?

To investigate, we built two separate web services, one with complex output and one without complex output.  When we created mock services in Soap UI, both resulted in the same error. Is there something wrong with the 'data control based on a web service' in ADF?
To test, we deployed the web services to an actual WebLogic Server.
When we call this web service from the application, we don't get an error!
So the mechanism works, but what goes wrong?

There is a potential issue in the headers. The mock service gzips the response. Also, the content type header value is set to test/xml, which 'should' be application/xml
Can it be ADF handles this incorrect (or not at all)??
With Soap UI we call the deployed web service to view the differences. Besides the fact that there are more header variables, the ones that also exist in the mock service header, have the same values.
Can it then be in the response itself???
The XML in the response seems the same. Only differences are namespaces and how the namespaces are defined, but that should not be a problem.
The response from the mock service also contains some comments to indicate which fields are optional and which sections can be repeated. But comments in XML is legal so this too should not be a problem...

But it is :(
We copied the response from the deplloyed web service to the mock service (the mock service response can be edited to return the data you want) and with the response copied from the deployed service, the call worked in ADF!
It took another 10 minutes to identify the comments to be the cause.

Solution
We're still not sure what goes wrong in the ADF application, but apparently one of the layers cannot handle comments in the response.
Edit the response to not include any comments. This will run the application smoothly.
Total Time Spent: Over a week.
Time Spent Next Time: None (thanks to this post ;)