Quantcast
Channel: Apache Timeline
Viewing all articles
Browse latest Browse all 5648

Best way to handle bad WSDLs?

$
0
0
Hi, CXF users and devs,

What are the best practices for using CXF with "broken" or problematic
WSDLs, especially on the client side?

I'm working on a project where I need to create clients to connect to
several established SOAP web services. Some of them have WSDLs which
seem invalid or have other issues. Getting the services or published
WSDLs to change is not an option, since these are provided by large
organizations and have been in production for a long time. So I'm having
to hack up the WSDLs on the client side to get wsdl2java to validate
them and generate code, and will need to do additional adjustments.

For example, I'm trying to get this to work.
https://misapi.ercot.com/2007-08/Nodal/eEDS/EWS/?WSDL
CXF doesn't like it because the <types> just has <complexType> and
<element> elements under it, instead of them being wrapped up in
<xsd:schema>, so references fail to resolve. And CXF doesn't like
multiple operations with the same signature. I'm editing a local copy to
use <xsd:schema> and so on.

Anyone have ideas on the best way to do this? Most of the doco on CXF
assumes you're working with a "correct" web service that's published out
on the web, and has a valid WSDL. How should I be storing and referring
to the local hacked-up copy of the WSDL? As a resource under the Java
source tree, using getResource() to locate it in my client code? Should
I be "patching" the WSDL with a different technique? Are there any other
tools or guides that could help with doctoring problematic WSDLs?

Cheers,
Andrew

Viewing all articles
Browse latest Browse all 5648

Trending Articles