According to the axis doc and the jax-rpc spec. The following is true <!--- Axis Doc snippet ----->
XML <-> Java Data Mapping in Axis How your Java types map to SOAP/XML types Interoperability, interop, is an ongoing challenge between SOAP implementations. If you want your service to work with other platforms and implementations, you do need to understand the issues. There are some external articles on the subject that act as a good starting place. The basic mapping between Java types and WSDL/XSD/SOAP in Axis is determined by the JAX-RPC specification. Read chapters 4 and 5 of the specification to fully understand how things are converted. Here are some of the salient points. Standard mappings from WSDL to Java xsd:base64Binary byte[] xsd:boolean boolean xsd:byte byte xsd:dateTime java.util.Calendar xsd:decimal java.math.BigDecimal xsd:double double xsd:float float xsd:hexBinary byte[] xsd:int int xsd:integer java.math.BigInteger xsd:long long xsd:QName javax.xml.namespace.QName xsd:short short xsd:string java.lang.String If the WSDL says that an object can be nillable, that is the caller may choose to return a value of nil, then the primitive data types are replaced by their wrapper classes, such as Byte, Double, Boolean, etc. <!--- Axis Doc snippet from user-guide.html -----> So Axis SHOULD map byte[] to xsd:base64Binary which is what you want. I know there has been a discussion about that here on the mailing list and a bug report concering this and also a fix for this. But obviously Axis does not do it correctly. Also the JAX-RPC says to this: 5.3.3 Array of Bytes Both byte[] and Byte[] are mapped to the xsd:base64Binary type. The mapping of the java.lang.Byte[] type to the xsd:base64Binary type is now deprecated because it cannot represent null values accurately. Instead, Byte[] should be mapped to a regular array following the rules in section 5.3.4. 5.3.4 Java Array The JAX-RPC specification maps a Java array to one of the following XML types: * An array derived from the soapenc:Array using the wsdl:arrayType attribute for restriction. This case is specified in the WSDL 1.1 [7] specification * An array with the soapenc:arrayType in the schema instance as specified in the SOAP 1.1 encoding * An array derived from the soapenc:Array by restriction as specified in the SOAP 1.1 specification * An element in a xsd:complexType with the maxOccurs attribute set to an integer greater than 1 or unbounded. This is one form of mapping used for Java arrays defined in a JAX-RPC value type. Refer to the section 5.4 for more details on the JAX-RPC value types. Obviously Axis treated the byte[] as Byte[] and mapped it according to 5.4.3. last paragraph as a type xsd:complexType. Search the jira bug database to find the bug I was talking about. Hope this helps, Paul > -----Original Message----- > From: Brown, Mike [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 14. Dezember 2004 15:48 > To: '[EMAIL PROTECTED]' > Subject: RE: Long: Problem with a method that returns byte[] > > > Your problem is simple. You defined the return type as an > array of bytes and > that is what it looks like as SOAP. Using attachments would > be best in this > case. Another option would be to return a String that is the > file Base64 > encoded (that's what I did on a project using SOAP before > attachments were > part of the spec). Of course DIME does practically the same thing > "automagically" for you. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 14, 2004 12:10 AM > To: Axis User > Subject: Long: Problem with a method that returns byte[] > > Hi all, > sorry for the long post but we're facing this problem and any > help would be > greatly appreciated. > We have a method with this signature: > > > byte[] getDocumentDataByteArray(String param1, String param2) > > This method, based on param1 and param2, retrieves a document from the > server > > and returns it to the client with a byte array. > > Using JBuilder we'have generated both client and server code > with the Axis > Toolkit integrated in this IDE. After making some test with > little files > (40/50Kb), we'have tried with bigger files (1/2 Mb). With > these files we > experienced a serious performance problem so we decided to > see what was > happening "behind the scene" with Ethereal. The sniffing is attached: > ------------------ Start request ---------------------- > > POST /my-services/services/myServices HTTP/1.0 > Content-Type: text/xml; charset=utf-8 > Accept: application/soap+xml, application/dime, > multipart/related, text/* > User-Agent: Axis/1.1 > Host: localhost.localdomain > Cache-Control: no-cache > Pragma: no-cache > SOAPAction: "" > Content-Length: 706 > > <?xml version="1.0" encoding="UTF-8"?> > <soapenv:Envelope > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > <soapenv:Body> > <ns1:getDocumentDataByteArray > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; > xmlns:ns1="http://filenet";> > <param1 > xsi:type="xsd:string">uWlkqDM045IfYRgD8rouTX4FBw9TILtfzC52Kk27 > ehQVd4AeqpijKu > cpJDXlPmnz+RdJjKH2ViJPhMR/XyiAWC+t83jV0vgA25Hwh6oA/YitfBBFTDm0 > tkmXDD8VOTkmBu > 2iwHW45IcZXqEhQvnHTPUN77HXkDljuu6vsYAiMUM=</param1> > <param2 xsi:type="xsd:string">003670716</param2> > </ns1:getDocumentDataByteArray> > </soapenv:Body> > </soapenv:Envelope> > ------------------ End request ---------------------- > > > ------------------ Start response ---------------------- > > HTTP/1.1 200 OK > X-Powered-By: Servlet 2.4; Tomcat-5.0.28/JBoss-3.2.6 (build: > CVSTag=JBoss_3_2_6 > date=200410140106) > Content-Type: text/xml;charset=utf-8 > Date: Mon, 13 Dec 2004 14:07:28 GMT > Server: Apache-Coyote/1.1 > Connection: close > <?xml version="1.0" encoding="UTF-8"?> > > <soapenv:Envelope > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > <soapenv:Body> > <ns1:getDocumentDataByteArrayResponse > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; > xmlns:ns1="http://myservices";> > <ns1:getDocumentDataByteArrayReturn xsi:type="soapenc:Array" > soapenc:arrayType="xsd:byte[1671291]" > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";> > > <item>80</item> > <item>75</item> > <item>3</item> > <item>4</item> > <item>20</item> > <item>0</item> > <item>0</item> > <item>0</item> > <item>12</item> > <item>0</item> > <item>54</item> > <item>117</item> > <item>-92</item> > <item>48</item> > <item>-17</item> > <item>100</item> > <item>-57</item> > <item>34</item> > <item>-23</item> > <item>127</item> > <item>25</item> > <item>0</item> > <item>0</item> > <item>-40</item> > .....and so on until the end > > ------------------ End Response ---------------------- > > As you can see we think that the big problem is related to > the fact that the > byte array of this file of 1,6 Mb is returned using 1,6M > element <item> > containing the value of a single byte (16 byte to send 1 byte of > payload...). > Why do this happens? We have another method which create a > document with > this signature > > <return_type> createDocument(String param1, byte[] documentData) > > and this document passes the content of the file as an > encoded string and > not with all this <item> elements. Why the getDocument method > does not use > the same way to send a byte array? > > We know that to send large file DIME would be best but we > would like to > understand why this happens before investigating DIME...... > > Thank you in advance > iuser > > > > > > ____________________________________________________________ > Libero ADSL: 3 mesi gratis e navighi a 1.2 Mega, senza costi > di attivazione. > Abbonati subito su http://www.libero.it > > >
