Raymond,
I finally found some time to take another look at this (though I haven't
updated my code in a couple weeks if you've done something new).
The problem I'm seeing is that the the newer DataObject2OMElement does not
write the xsi:type into XML whereas the older DataObject2XMLStreamReader
did.
This is a problem if I try when deserializing (i.e. converting from AXIOM to
SDO). Interestingly, I'm experiencing a problem when I try to pass my SDO
as an input parm but not when I pass it as output.
The reason is, that, with input like the following in doc-lit-wrapped-style:
<element name="myOperationName">
<complexType>
<sequence>
<element name="id" type="xsd:string"/>
<element name="person" type="tns:Person"/>
</sequence>
</complexType>
</element>
the child input parms will be deserialized one-at-a-time with the <person>
element here being set as a document root element by the SDO/EMF
deserialization logic. Apparently this logic throws up a
FeatureNotFoundException as it does not recognize the local element,
'person'.
On the other hand an output elem like this is no problem:
<element name="getGreetingsResponse">
<complexType>
<sequence>
<element name="getGreetingsReturn"
type="tns:Person"/>
</sequence>
</complexType>
</element>
since the root element on output deserialization is getGreetingsResponse,
not "getGreetingsReturn" of type 'tns:Person".
So, maybe I'll stop there in case someone knows what to do next (or has
fixed this in a newer code level). However, I could provide more info if
that would help.
What is the rule defining when the xsi:type attr needs to appear in the SOAP
anyway? Is there a spec one could point to or is it more complex than
that?
Thanks,
Scott
