Hi, //this has been sent to the axis-users list before with no feedback
I think I stumbled over a bug but I wanted to check here first in case I'm just being stupid. I have a webservice (using axis2 to handle the soap stuff) and I wanted to use this service with both, WSDL-based access and anonymous operation invocation (with the ServiceClient.sendReceive(OMElement elem) method). Using WSDL base access everything works as intended (e.g.: using the following SOAP envelope) <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"; xmlns:ns="http://myNS.com";> <soap:Header/> <soap:Body> <ns:GetCapabilitiesRequest/> </soap:Body> </soap:Envelope> At service implementation site within the method getCapabilities(OMElement e); (<-- this is the invoked method) the parameter e is <ns:GetCapabilitiesRequest/> So far so good. Now when trying to access anonymously I have to encode the operation somewhere so I have the following envelope <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"; xmlns:ns="http://myNS.com";> <soap:Header/> <soap:Body> <ns:getCapabilities> <in0> <ns:GetCapabilitiesRequest/> </in0> </ns:getCapabilities> </soap:Body> </soap:Envelope> The request gets resolved correcty by axis (using the SOAPMessageBodyBasedDispatcher) BUT here's the catch. Suddenly the parameter which the (correct!) service operation gets is <ns:getCapabilities> <in0> <ns:GetCapabilitiesRequest/> </in0> </ns:getCapabilities> This is rather useless because in that case the service operation must be ready to handle all kinds of different parameters depending on the invocation method used!? Shouldn't the SOAPMessageBodyBasedDispatcher remove the 'meta-informational' stuff (in this case the getCapabilities (aka operation-name), and in0 (parameter direction)) and only send the real parameter to the operation? If I'm mistaken, how can I invoke an operation anonymously and does not have the problem of ending up with wrong parameters on the service side? If I'm correct please let me know and I will file a bug report. Many thanks in advance! Cheers, Severin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
