Hi, Scott.
For now, you can use @DataBinding at the operation level to declare the
databinding behind the interface mapping.
Do you have better ideas to avoid this annotation? I don't see a good one
that can cover all cases.
Thanks,
Raymond
----- Original Message -----
From: "Scott Kurz" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, May 25, 2007 9:21 AM
Subject: Re: SDO-Axiom DB problem: Element name from data source is
dataObject, not the expected...
Raymond,
You helped me figure out what was going on.
For my service, with Java operation like:
retType myOperationName(String,Person)
SDO was not detected as the target databinding and therefore no
"wapperHandler" was found by Input2InputTransformer.
Now, the reason SDO wasn't detected as the databinding relates to the fact
I've been avoiding using the @DataType annotation. The
DataBindingJavaInterfaceProcessor, then, sets up my input type with
SDODataBinding but nothing at the operation or interface level.
However, (in my old level at least), Input2InputTransformer does:
} else if (sourceWrapped && (!targetWrapped)) {
// Wrapped to Unwrapped
Object sourceWrapper = source[0];
// List<ElementInfo> childElements = sourceOp.getWrapper
().getInputChildElements();
Object[] target = null;
targetWrapperHandler =
getWapperHandler(targetType.getOperation().getDataBinding(),
false);
and tries to find the "wapperHandler" from the operation-level
databinding.
I'd have to think about how to adjust for this while still being able to
avoid using @DataType.
Based on your comments how this should all work, it seems like you're
already previously making the assumption that two input args on a single
operation can not have different databindings. If so I'd say that during
DataBindingJavaInterfaceProcessor processing we could set the databinding
we
find at the input type level on the operation level as well.
I'm sure you might have a better idea. I know this was discussed awhile
back.
Thanks,
Scott
On 5/24/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
