I'm using WSIF 2.0 dynamic invocation to access the operation getAllServiceSummaries of http://www.xmethods.net/interfaces/query.wsdl
 
The operation returns a soap array type (but the WSDL forgets to import the soap-encoding schema, so for the sake of my code, which must parse it, I've tweaked a copy of the wsdl to do so).
 
In my WSIF invocation, which uses the axis protocol, I register a serializer/deserializer for the type in question, which is called
ArrayOfServiceSummary, supposedly directing it to use a java class of mine called ComplexTypeWrapper (which just encloses the Element from the soap body).  The serializer/deserializer was registered by provider-specific code like this:
 
     log.debug("registering Axis ser/deser factories for "
                          + (forInputEncoding ? "input " : "output ")
                          + "parameter " + part.getName()
                          + " java type " + jtype
                          + " xml type " + part.getTypeName()
                          );
     ((WSIFPort_ApacheAxis)port).getCall()
  .registerTypeMapping(jtype,
         part.getTypeName(),
         ComplexTypeWrapperSerializerFactory.class,
         ComplexTypeWrapperDeserializerFactory.class);
 
and I see the log message with the right stuff in it when I run the program.  (This code is old, and perhaps is failing to use a more generic WSIF type mapping facility that might have been added more recently.)
 
The program, when run, falls over in the Axis-specific deserialization of the response, with the exception below, on receipt of the Soap body excerpted below that.  Somehow, the right deserialization class has been found, but the RPCHandler code is doing an extra "consistency" check against something that looks a bit peculiar (a variable called xsiClass which is supposed to be based on xsi:type values, which are not present in this particular Soap body!) and rejecting what it finds.  The line numbers below refer to axis.jar from Axis 1.1 final, which I tried in place of the original axis.jar that came with WSIF 2.0, and which also crashed the same way near line 285.)
 
Does anyone have a suggestion about how to attack this problem?  In particular, should I be addressing this to the Axis mailing list instead of the wsif one?
 
Jeff  
 
- Exception:
org.xml.sax.SAXException: Bad types (class [Ljava.lang.Object; -> class com.webalo.wsdlclient.ComplexTypeWrapper)
        at org.apache.axis.message.RPCHandler.onStartChild(RPCHandler.java:311)
        at org.apache.axis.encoding.DeserializationContextImpl.startElement(Dese
rializationContextImpl.java:963)
        at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.ja
va:198)
        at org.apache.axis.message.MessageElement.publishToHandler(MessageElemen
t.java:722)
        at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:323)
        at org.apache.axis.message.RPCElement.getParams(RPCElement.java:347)
        at org.apache.axis.client.Call.invoke(Call.java:2272)
        at org.apache.axis.client.Call.invoke(Call.java:2171)
        at org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis.in
vokeAXISRPCStyle(Unknown Source)
        at org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis.in
vokeRequestResponseOperation(Unknown Source)
        at org.apache.wsif.providers.soap.apacheaxis.WSIFOperation_ApacheAxis.ex
ecuteRequestResponseOperation(Unknown Source)
...
 
Soap Response:
...
  <n:getAllServiceSummariesResponse xmlns:n="http://www.xmethods.net/interfaces/query">
    <Result soapenc:arrayType="n4:ServiceSummary[355]">
         <i><name>StrikeIron Simple Statistics Web Service</name><id>uuid:DE745F1B-6775-0A4E-DCFE-7A0CFD0623A0</id><shortDescription>This Web service takes a string of numbers (separated by a space) as input and allows the user to perform various statistical functions using this string of numbers.</shortDescription><wsdlURL>http://www.strikeiron.com/scripts/statistics.asmx?WSDL</wsdlURL><publisherID>StrikeIron</publisherID></i>...

Reply via email to