Countless times I come across quite astonishing things in software. I cannot even imagine what creators of the software were thinking: so obviously broken is the end result.
Authors of even otherwise very useful products have their moments.
Take soapUI for example: a very powerful and useful tool. But it has a number of quirks or downright stupid "features". One of them is the topic of this post.
Many webservice frameworks expose webservice WSDLs online: if a webservice is accessible at some <ws_endpoint_url>, then quite often the relevant WSDL is available at <ws_endpoint_url?wsdl>. By the way I could not find out whether this is just a useful convention or some kind of a standard.
And soapUI can load wsdl files from filesystem location or from some URL.
With these things combined it is quite easy to create a soapUI project targeting an available webservice. Just use <ws_endpoint_url?wsdl> as "Initial WSDL" in the "New soapUI project" dialog, and you are in business.
This works as a charm for simple webservices where all definitions are held in a single WSDL file. But the world is tough and real men use things like wsdl:import or include. And this causes endless pain.
You see quite often the server responds to <ws_endpoint_url?wsdl> not with the content of the WSDL file but with HTTP redirect with the real location of the WSDL. And soapUI is intelligent enough to follow this redirect automatically. Then it parses the WSDL and tries to load any "imported" or "included" WSDLs and XSDs.
Here its intelligence stopped. soapUI did not realize that the "base url" was changed as result of the redirect. soapUI continues resolving all relative locations from WSDL file using the original <ws_endpoint_url> as "base url". This results in soapUI using urls to non-existing resources or even completely invalid urls. WTF?
