Raymond, for the all-simple-inputs case, couldn't we continue to do what we do today? We default to the JavaBeansDataBinding which has no wrapper handler so the input args are processed one-at-a-time.
So to rephrase my proposal, what if we said, in DataBindingJavaInterfaceProcessor, that the operation DB will be set to a specific non-default DB if the following holds: * the operation DB is not set directly by an annotation * one of the input types, output type, fault types has a non-default DB * no two of the input types, output type, fault types have two different non-default DBs (e.g. SDO and JAXB). If we made such a change, then my app would work without a need for annotations. If unable to calculate an operation DB, we continue to process the child elements one at a time like today. We'd still be left with some work needed to support mixed-DB operations, as my problem converting from Axiom to a child input SDO shows. However, I'm not especially interested in this and it could wait until someone was interested as I don't think I'm proposing breaking anything which works today. (The apparent bug in Output2OutputTransformer I mentioned would be easier to patch if you agree it's a problem.) Hopefully this makes some sense. I don't know this code in and out as well as Raymond as I've just been looking at pieces to get past this particular problem. Thanks, Scott. On 5/25/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, In the case that one of the arguments is complex type (Person in SDO in Scott's case), we can use it as the databinding for the operation. But what should we do if all the unwrapped chidren are simple types? Thanks, Raymond ----- Original Message ----- From: "ant elder" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, May 25, 2007 9:43 AM Subject: Re: SDO-Axiom DB problem: Element name from data source is dataObject, not the expected... > 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
