Raymond,
I don't have a better idea to cover all cases... but I think it would be
nice to optimize for the case that all inputs (and maybe all inputs,output
and faults together even) use the same databinding.. in a way that a
Tuscany-specific annotation isn't needed.
Also, I thought we must have already made the assumption that all inputs
shared a DB since we are getting a wrapperhandler to handle all of them at
once.
I'll have to study the code more to understand how mixed-DB input would be
unwrapped.
.....
On a related note... it seems there is a bug in
Output2OutputTransformer.transform()
} else if (sourceWrapped && (!targetWrapped)) {
// Wrapped to Unwrapped
Object sourceWrapper = response;
List<ElementInfo> childElements = sourceOp.getWrapper
().getOutputChildElements();
if (childElements.isEmpty()) {
// The void output
return null;
}
targetWrapperHandler =
getWrapperHandler(getDataBinding(targetOp), false);
if (targetWrapperHandler != null) {
ElementInfo wrapperElement = sourceOp.getWrapper
().getInputWrapperElement();
That last line assumes the input and output are using the same DB.
Should I open a JIRA or do you just want to patch it ?
Thanks,
Scott
On 5/25/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
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]
