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. > 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. 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. 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? ...ant
