Looks like this was not a library isssue. The vendor's documentation [_including_ the wsdl file published on the server] had the wrong namespace.
Now that that's resolved, the next hurdle is finding out that the other test service ['process'] is currently configured to refuse connections that are not originating from their local network. On 10/26/07, Dave Levitt <[EMAIL PROTECTED]> wrote: > Since the libraries at each end are fixed, I was wondering about > modifying the wsdl2java generated code in the 'ServiceStub' class [the > createCall() method and / or the settings and parameters before the > call.invoke() method is performed. > > I would not like to change the library on the client side, as it is > working fine for RPC style calls to several other services [including > a .NET service]. > > On 10/26/07, Cort, Tom <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I experienced a similar problem. The code generators for gsoap and axis > > generated incompatible implementations, even when I gave each of them > > the exact same WSDL file. During my debugging I did some packet > > sniffing. It appeared that they could not agree on where the xmlns > > attribute should go. I ended up trying csoap ( > > http://csoap.sourceforge.net/ ). It worked with axis, but I strongly > > warn against using it. I've discovered nearly 30 buffer overflows and at > > least 1 memory leak in csoap. The project hasn't had much activity > > lately and the csoap author didn't respond to the patch I sent him. I've > > since created a new project cshampoo ( http://cshampoo.sourceforge.net ) > > to clean up csoap. I should be releasing the first beta in the next week > > or two. > > > > -Tom > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
