axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 8680] - echoHexBinary returns base64Binary...affects OperationDesc design
Date Tue, 30 Apr 2002 20:54:27 GMT
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 gdaniels@macromedia.com  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"?

Mime
View raw message