Ok? Are you saying those links are the solutions and we shouldn't do anything over what jaxb supports?
...ant On Tue, Jun 9, 2009 at 5:04 PM, Raymond Feng<[email protected]> wrote: > Let's step back and get all the issues on the table first: > > 1) JAXB default rules for POJO to XML namespace mapping is not > straightforward > > 2) JAXB silently ignores the XML elements/attributes that are not conforming > to the XSD. As a result, some of the POJO propeties are left unpopulated. > https://jaxb.dev.java.net/guide/Unmarshalling_is_not_working__Help_.html > > 3) JAXB cannot handle POJO interfaces > https://jaxb.dev.java.net/guide/Mapping_interfaces.html > > 4) JAXB cannot handle non JavaBeans > https://jaxb.dev.java.net/guide/XML_layout_and_in_memory_data_layout.html > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Tuesday, June 09, 2009 2:58 AM > To: <[email protected]> > Subject: Re: Fwd: using webservices transparent > >> On Sat, Jun 6, 2009 at 7:31 PM, Raymond Feng<[email protected]> wrote: >>> >>> >>> -------------------------------------------------- >>> From: "ant elder" <[email protected]> >>> Sent: Saturday, June 06, 2009 12:00 AM >>> To: <[email protected]> >>> Subject: Re: Fwd: using webservices transparent >>> >>>> On Fri, Jun 5, 2009 at 7:20 PM, Raymond Feng<[email protected]> wrote: >>>>> >>>>> The problem users run in is not that POJOs don't work out-of-the-box >>>>> with >>>>> the binding.ws from Tuscany SCA. >>>> >>>> Isn't that exaclty what this problem is in this case i've forwarded to >>>> the dev list? They're trying to call the WeatherService web service >>>> from a Tuscany Java client and the result is returned to the Tuscany >>>> client as a null which is incorrect, and the service did actually >>>> return a reponse just Tuscany didn't pass the response on to the >>>> client, can't get much more _not_ working out-of the-box than that. >>> >>> The WeatherService WS is implemented using .NET. Tuscany receives the >>> response in XML. The issue is how to map the XML into Java. There are two >>> ways: >>> >>> 1) Use a non-typed in-memory Java representation of the XML, for example, >>> OMElement, DOM, StAX. No type checking is performed and the XML is >>> unmarshaled as-is no matter whether it conforms to the XSD or not. In >>> such >>> cases, the client has to make sure the incoming data is valid. >>> >>> 2) Use a typed java class, for example, a POJO or JAXB, SDO generated >>> classes. For most databindings, it requires the XML to conform to the >>> XSDs >>> that are used to generate the java classes. In Tuscany, we use JAXB for >>> POJO >>> and JAXB mapping rules are used. Sure, you can invent something for POJO >>> to >>> be more heuristic but it will lead to more inconsistencies too. >>> >>>> >>>>> Different WS stacks have different mapping rules to deal with POJO >>>>> to/from >>>>> XML conversions. It's only guaranteed that you the POJO would work with >>>>> the >>>>> same runtime and tool or you start with the same POJO at both server >>>>> and >>>>> client sides. >>>>> >>>>> JAXB is the only industry standard that defines the default Java/XML >>>>> mapping >>>>> rules for unannotated POJOs. It also provides the capability to enrich >>>>> the >>>>> POJOs with more accurate XML mappings so that it will produces the XML >>>>> payment conforming to the XSD on the server side. >>>>> >>>>> I don't think moving away from JAXB will solve the problem at all. It >>>>> might >>>>> get one framework happier but it probably screws the others. >>>>> >>>> >>>> Sure yes, I'm not questioning Tuscanys use of JAXB, I'm wondering if >>>> there's anything else we could be doing as well to handle these other >>>> cases better than we do today. >>>> >>>>> I agree that we need to document the best practice for POJO-based WS >>>>> though. >>>>> >>>> >>>> Documenting things is fine but working where possible would be even >>>> better, just giving a helpful error message might be more useful than >>>> returning null like is happening here. >>> >>> To be precise, it's NOT returning null but an empty POJO. >>> >>>> >>>> IIUC currently we don't always work when the interface uses parameter >>>> types that are unannotated pojos or interfaces. We regularly get posts >>>> from users asking about these and assuming most users don't bother >>>> emailing then this is likely a _lot_ of people who run into this issue >>>> so if there's anything we could do it might make a big difference to >>>> how they perceive Tuscany. >>> >>> Using POJO for WS definitely imposes the Java-specific behavior. If the >>> POJO >>> cannot be accurately mapped to the XSD-compliant XML and vice versa, >>> there >>> will be interop issues. >>> >>>> >>>> In this example the user simply changes their interface to have the >>>> reponse be an OMElement instead of a String and then they do get the >>>> correct response so this _is_ a problem with Tuscany. We shouldn't be >>>> returning null we should either throw an error saying there is a >>>> problem with the client or much better would be to have the runtime >>>> spot that there isn't the correct annotations and just handle the >>>> response correctly automatically anyway. That must be possible mustn't >>>> it as we have both the wsdl and the java interface and the impl class >>>> so can see that its all not quite matching what JAXB needs? >>> >>> As we have observed, the default behavior for JAXB unmarshaling is best >>> effort and to ignore the invalid XML pieces silently. We can try to see >>> if >>> there is any flag to control such thing. >>> >> >> I'm not questioning the use of JAXB, I'm questioning if there are >> other things we could be doing as well as or along side of JAXB to >> make this easier and work more seemlessly for some of the cases that >> today just fail. These questions come up a lot, for example there are >> three going on currently - this thread and [1] and [2], and for every >> user that does send an email to the user list there's likely lots more >> users who hit these problems but don't bother emailing. >> >> So for example with using interfaces as parameter types is there >> really nothing we can do? What about if the service interface uses >> interfaces but the implementation uses concrete implementations >> couldn't we get it to work by finding those impl classes, or even >> using cglib to generate mock classes for the interfaces? >> >> And for the unannotated pojo cases what about ways for "smoothing over >> differences" as suggested in TUSCANY-2992. Or could the runtime try >> alternative datatbindings when JAXB doesn't work? >> >> ...ant >> >> [1] http://apache.markmail.org/message/eelvu7onmpyfxb5x >> [2] https://issues.apache.org/jira/browse/TUSCANY-2992 >> >
