DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8680>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8680 echoHexBinary returns base64Binary...affects OperationDesc design Summary: echoHexBinary returns base64Binary...affects OperationDesc design Product: Axis Version: nightly Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Serialization/Deserialization AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The echoHexBinary is returning a xsd:base64Binary type instead of xsd:hex. This bug was discovered by Sam Ruby. (I set the severity to Major because it breaks the Round2 interop contract...) The root of the problem is that xsd:base64Binary and xsd:hexBinary both map to byte[]. Question: So how does the input to echoHexBinary get sent over correctly as a xsd:HexBinary? Answer: The stub code generates an addParameter call that indicates the type QName as xsd:hexBinary. This results in a ParameterDesc being built and ultimately a RPCParam being built which is tied to the ParameterDesc. Thus when the byte[] is serialized, the proper typeQName is known. Question: So why doesn't this happen on the server side for the return ? Answer: A number of reasons. There is no such thing as a ParameterDesc for a Return. If there was, the ParameterDesc could be attached to the return RPCParam and the serialization would work the same way as the serialization on the client side. In addition, the Return QName type needs to be communicated to the deployed service, so there needs to be a WSDDParameterDesc for the return in the wsdd file. So the proper way to fix this bug is to. 1) Create a ReturnDesc which inherits from ParameterDesc. 2) Change the OperationDesc object to locate the ReturnDesc. 3) Change the WSDD syntax to have a <return...> element similar to the <parameter...> element, implement a WSDDReturn similar to WSDDParameter. And make changes to WSDDOperation. 4) Change the WSDL2Java emitter to emit the return elements. 5) Change the RPCProvider (and possibly others to attach the ReturnDesc to the RPCParam element). Alternatively I could change xsd:HexBinary to map to our exclusive Hex class...but this is not exactly RPC compliant.
