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 ------- Additional Comments From [EMAIL PROTECTED] 2002-04-30 20:54 ------- The reason the client is sending the hexBinary correctly is that the stub is passing an org.apache.axis.encoding.Hex object down into invoke() (InteropTestSoapBindingStub.java:462), and THAT Java class maps uniquely to the right XML. (See lines 285/286 in JavaWriter.java) In fact, the ParameterDesc containing the JavaType/XMLType pair which is attached to the RPCParam is never even looked at on the client side - we only use that in RPCProvider on the server side at present. The simple and correct fix here, IMO, is in fact to change the signature in our impl as follows: public Hex echoHexBinary(Hex inputHexBinary) That will, I believe, work correctly with the HexDeserializer, and we'll uniquely know how to serialize the result Hex, just like we do on the client side. There are certainly other issues about OperationDesc/returns/etc (not to mention how to cope with multiply-mapped classes/XMLtypes) which should be discussed, but let's take that to the mailing list rather than trying to do it on Bugzilla. P.S. hexBinary already does map to Hex (DefaultTypeMappingImpl.java:144), which is why this works on the client side - what did you mean by "not RPC compliant"?
