FYI...I sent the zip directly to Robert since the Apache servers don't seem to like attachments (ie. 12kb zip).
-----Original Message----- From: Vinh Nguyen (vinguye2) Sent: Friday, April 18, 2008 5:39 PM To: [email protected] Subject: RE: Muse interoperability? Hi Robert, Attached is a test of your schema using Muse 2.2.0. I ran into a couple problems: 1) Your schema is probably not doc-literal. The best solution is to use the "wrapped object" approach. So your input/output schemas should contains a sequence of element refs. See the SimpleResource.wsdl in the attached zip which shows modifications to your schemas. 2) Muse seems to have a problem when sending a primitive int[]. The request has nested xml that doesn't match the schema. I encountered this problem back in 2.1.0 that was fixed in 2.2.0, but perhaps not entirely now that I sort of see it again. A response containing an int[] is fine though. See the test-output.txt in the attached zip. <pfx0:ReverseArray xmlns:pfx0="http://ws.disco.xerox.com/ComplexTypes";> <pfx1:intValue xmlns:pfx1="http://schemas.xmlsoap.org/wsdl/";> <pfx1:intValue>2</pfx1:intValue> <--- These shouldn't be nested in here! <pfx1:intValue>3</pfx1:intValue> <pfx1:intValue>4</pfx1:intValue> <pfx1:intValue>45</pfx1:intValue> <pfx1:intValue>56</pfx1:intValue> </pfx1:intValue> </pfx0:ReverseArray> <muse-op:ReverseArrayResponse xmlns:muse-op="http://ws.disco.xerox.com/ComplexTypes"; xmlns:tns="http://axis2.platform.core.muse.apache.org";> <intValue xmlns="http://schemas.xmlsoap.org/wsdl/";>2</intValue> <--- This is correct! <intValue xmlns="http://schemas.xmlsoap.org/wsdl/";>3</intValue> <intValue xmlns="http://schemas.xmlsoap.org/wsdl/";>4</intValue> <intValue xmlns="http://schemas.xmlsoap.org/wsdl/";>45</intValue> <intValue xmlns="http://schemas.xmlsoap.org/wsdl/";>56</intValue> </muse-op:ReverseArrayResponse> The test was created by modifying the Muse "simple" sample project. You can load the test files into that project and just run the Ant script to rebuild. Hope this helps! -Vinh -----Original Message----- From: St Jacques, Robert [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 12:40 PM To: [email protected] Subject: RE: Muse interoperability? This message turned out to be long :P Hm. Not sure what you'd like to see exactly. Here are my WSDL definitions: <wsdl:definitions name="ComplexTypes" targetNamespace="http://ws.disco.xerox.com/ComplexTypes"; xmlns:tns="http://ws.disco.xerox.com/ComplexTypes"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:wsdl-soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:wsa="http://www.w3.org/2005/08/addressing";> And the related type definitions: <wsdl:types> <xsd:schema elementFormDefault="qualified" targetNamespace="http://ws.disco.xerox.com/ComplexTypes";> <xsd:element name="PutArray"> <xsd:complexType> <xsd:sequence> <xsd:element name="intArray" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="PutArrayResponse" type="xsd:int"/> <xsd:element name="ReverseArray"> <xsd:complexType> <xsd:sequence> <xsd:element name="intArray" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="ReverseArrayResponse" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/> </xsd:schema> </wsdl:types> I've defined "PutArray" as a complex type because for some reason if I define it as such: <xsd:element name="PutArray" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/> Muse generates a method with no input parameters; it seems to want a complex type to break down into individual parameters and if it doesn't get one, it ignores the element entirely. Which is particurly odd because if I want to write a method that returns an array, that is exactly what I need to do (as I demonstrate in the "ReverseArrayResponse" element). My schema validator complains that the "minOccurs" and "maxOccurs" attributes are not allowed here, but the Muse documentation says to use them if you want to return an array. That concerns me because, again, I am worried about interoperability if the WSDL contains invalid attributes in some of the tags. The resulting method signature looks something like this: public int[] reverseArray( int[] intArray ); Of course when I do that the server works fine; it accepts the arrays generated by the client (such as the example I gave below), translates to a Java int[] and passes it into the appropriate method. It also translates the int[] I return back into SOAP and returns that to the client, which causes the client to promptly crash with a class cast exception (trying to cast a java.lang.Integer to an int[]). The exception I get is: Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to [I at com.xerox.disco.ws.ComplexTypes.MyServiceProxy.reverseArray(MyServicePro xy.java:32) at com.xerox.disco.ws.ComplexTypes.ComplexTypesClient.main(ComplexTypesClie nt.java:45) And, for what it's worth, here is the body of the method that is causing the exception in MyServiceProxy (generated by the Muse tools): public int[] reverseArray(int[] intArray) throws SoapFault { Object[] params = new Object[1]; params[0] = intArray; ProxyHandler handler = getHandler("reverseArray"); return (int[])invoke(handler, params); } By modifying the last line to do this instead: Object obj = invoke(handler, params); System.out.println( "result: " + obj.getClass() + ":" + obj ); return (int[])obj; I can see that the "invoke" method is actually returning a java.lang.Integer with a value of 1. So it seems that the Muse client is parsing only the first entry in the array, and returning that (which results in the class cast exception). So my concerns are that the SOAP being generated doesn't contain as much information as I would expect to describe the array (such as the content type and the number of elements). This concerns me that other clients will not be able to interpret the SOAP that I return. I'm also curious as to how well the server-side will handle arrays generated by other clients. Additionally, the Muse client seems to be very fragile. I've easily made it crash several times just by doing things like returning arrays or longs (which it again parses as Integers and then tries to cast into a long, which fails). Thanks, Bob -----Original Message----- From: Vinh Nguyen (vinguye2) [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 1:50 PM To: [email protected] Subject: RE: Muse interoperability? Hi Bob, Can you share your XSD? -Vinh -----Original Message----- From: St Jacques, Robert [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 10:42 AM To: [email protected] Subject: Muse interoperability? Has anyone tested the interoperability of Muse with other Web Service stacks (e.g. Axis, .Net, etc)? I have serious doubts about how Muse will playw ith others, which is troubling considering one of the chief resons for using a WS stack is interoperability between disparate platforms. For example, I wrote a WSDL operation that accepts an int array as a parameter. Here is the SOAP that Muse generated: <soap:Body> <pfx0:PutArray xmlns:pfx0="http://ws.disco.xerox.com/ComplexTypes";> <pfx0:intArray> <pfx0:intArray>0</pfx0:intArray> <pfx0:intArray>1</pfx0:intArray> <pfx0:intArray>2</pfx0:intArray> <pfx0:intArray>3</pfx0:intArray> <pfx0:intArray>4</pfx0:intArray> <pfx0:intArray>5</pfx0:intArray> <pfx0:intArray>4</pfx0:intArray> <pfx0:intArray>3</pfx0:intArray> <pfx0:intArray>2</pfx0:intArray> <pfx0:intArray>1</pfx0:intArray> </pfx0:intArray> </pfx0:PutArray> </soap:Body> Now I am by no means a SOAP expert (I have just started playing with Muse recently) but what little reading I have done has lead me to believe that arrays should look more like this: <intArray xmlns:ns2="http://schemas.xmlsoap.org/soap/encoding/"; xsi:type="ns2:Array" ns2:arrayType="xsd:string[10]"> <item xsi:type="xsd:int">0</item> <item xsi:type="xsd:int">1</item> <item xsi:type="xsd:int">2</item> <item xsi:type="xsd:int">3</item> <item xsi:type="xsd:int">4</item> <item xsi:type="xsd:int">5</item> <item xsi:type="xsd:int">4</item> <item xsi:type="xsd:int">3</item> <item xsi:type="xsd:int">2</item> <item xsi:type="xsd:int">1</item> </intArray> I also wrote a simple method that returns an int array, the Java signature of which looks like this: public int[] reverseArray( int[] intArray ) I am troubled by the fact that, in order to specify an int return type, I need to define an element like this in my WSDL: <xsd:element name="ReverseArrayResponse" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/> And my schema validator warns me that "minOccurs" and "maxOccurs" are not valid attributes. Also, when calling the method I found that, again, Muse returned SOAP that did not look as I would have expected: <soap:Body> <muse-op:ReverseArrayResponse xmlns:muse-op="http://ws.disco.xerox.com/ComplexTypes";> <muse-op:ReverseArrayResponse>1</muse-op:ReverseArrayResponse> <muse-op:ReverseArrayResponse>2</muse-op:ReverseArrayResponse> <muse-op:ReverseArrayResponse>3</muse-op:ReverseArrayResponse> <muse-op:ReverseArrayResponse>4</muse-op:ReverseArrayResponse> <muse-op:ReverseArrayResponse>5</muse-op:ReverseArrayResponse> <muse-op:ReverseArrayResponse>4</muse-op:ReverseArrayResponse> <muse-op:ReverseArrayResponse>3</muse-op:ReverseArrayResponse> <muse-op:ReverseArrayResponse>2</muse-op:ReverseArrayResponse> <muse-op:ReverseArrayResponse>1</muse-op:ReverseArrayResponse> <muse-op:ReverseArrayResponse>0</muse-op:ReverseArrayResponse> </muse-op:ReverseArrayResponse> </soap:Body> And to make matters even worse, when the Muse client crashed when trying to handle the return value! While parsing the SOAP it seemed to extract only a single integer value, and the client crashed when the proxy tried to cast the lone int into an int[]. I found similar errors when I tried to return an xsd:long; the Muse client parsed the return value as an int, and crashed trying to cast the int into a long. If anyone has experimented with interoperability between muse and other WS platforms (particularly Axis and .Net) I would appreciate hearing about your experiences. Thanks, Bob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
