Thursday, April 12, 2012

Binding fails for new SOAP request in existing project

I've added a new SOAP request to an existing project that already uses a lot of SOAP requests. They all work fine. I add my new one in exactly the same way (code generated from WSDL through Apache CXF), yet somehow it fails.

I get this error: Could not find wsdl:binding operation info for web method foo.
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(
at $ Source)

This is a Grails project, and the code is called like this:

FooRequest request = new FooRequest()
processResponse(order) { getPort().foo(request) }

It's the getPort().foo() at the bottom that apparently fails. In fact, I believe it's not the call that fails, but the creation of the closure, since processResponse() doesn't seem to get executed (I put a println on the first line of that method). Edit: It's the execution of the closure that fails, not the creation. So it really cannot find getPort().foo(), despite the fact that my generated interface does have this method:

public nl.wecompany.portal.webserviceQopi.QOPIResponse foo(
@WebParam(name = "in", targetNamespace = "")
com.myproject.FooRequest in

getPort() returns a org.apache.cxf.jaxws.JaxWsClientProxy@41079622, which it also does for other SOAP requests (the ones that work).

I cannot find any meaningful difference between my new code and the existing code. Any ideas what could be wrong? Any suggestions on where to look?

Edit: port.metaClass.methods*.name.sort().unique() does include my new foo() method. Yet when I call it, I get this weird wsdl:binding error, and the method doesn't get executed (it doesn't reach the println on the first line).

Edit: anonymized some stuff I intended to anonymize.

1 comment:

  1. I think I figured it out. The JaxWsClientProxy may have a foo() method, but that's not my foo() method. It's a proxy for my foo() method that first checks whether this method actually exists in the WSDL on the remote server. And if I haven't updated the WSDL on the remote server with the foo request, then it throws the exception instead of calling my actual foo() method. I didn't expect this kind of check in the middle of what seemed like a regular method call, but apparently that check is the entire point of having such a WSDL/SOAP binding framework.

    Connecting to a server that has the updated WSDL fixed the problem.