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] New: - echoHexBinary returns base64Binary...affects OperationDesc design
Date Tue, 30 Apr 2002 20:05:22 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

           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: axis-dev@xml.apache.org
        ReportedBy: scheu@us.ibm.com


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.

Mime
View raw message