Re: Axis 1.4 and gSoap interoperability problems
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]
RE: Axis 1.4 and gSoap interoperability problems
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]
Re: Axis 1.4 and gSoap interoperability problems
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]
