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
