How about what was suggested - " during DataBindingJavaInterfaceProcessor processing we could set the databinding we find at the input type level on the operation level as well." - what are the issues with doing that?
...ant 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]
