Hi, Scott.
It's a bit wierd here. By the code in Input2InputTransformer, if the target
databinding supports wrapping (for SDO, it's true), we try to convert at the
wrapper element level first, i.e., transform the OMElement to a wrapper SDO,
and then get the children from the wrapper.
Do you have a simple test case that I can try?
Thanks,
Raymond
----- Original Message -----
From: "Scott Kurz" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, May 24, 2007 3:04 PM
Subject: Re: SDO-Axiom DB problem: Element name from data source is
dataObject, not the expected...
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
