I'm using CXF (Version 2.1.3) to generate client stubs for the google adwords
api from their wsdl.
Especially I use the maven cxf-codegen-plugin and JAXB for data binding.
After some time of trial and error almost everything is working fine now!
But one thing is very annoying: The occurence of JAXBElement classes within
the client method signatures! This forces you to write more code while using
the client stub, and (even worse!) you have to know about XML specific stuff
like a QName or xsd:nill!
Let me give an example. Let this be a type description within the wsdl:
<complexType name="A">
<sequence>
<element name="a" nillable="true" minOccurs="0" type="xsd:string"/>
<element name="b" minOccurs="0" type="xsd:string"/>
<element name="c" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
The resulting class within client stub is:
public class A {
@XmlElementRef(name = "a", namespace = "https://my.namespace";, type =
JAXBElement.class)
protected JAXBElement<String> a;
protected String b;
@XmlElement(required = true, nillable = true)
protected String c;
(...)
}
I'm aware, that an element marked both nillable="true" and minOccurs="0"
forces JAXB to generate code that makes it possible to distinguish between
"no element" and "element value is null", so it's hardly possible to use an
String object for attribute a. For b and c an object of class String works
perfecly, cause the are either nillable (c) or must not occure (b).
But now I'm wondering, why the example code from google, which uses client
stubs generated with Axis 1.2.1 and is based on the same wsdl, uses objects
of class String, Long and Integer in such situations!
So is there some way to get rid of these JAXBElements?
I'm almost sure, that google will not differ between nill of null on server
side, so maybe it's worth to think about some kind of flag to let CXF remove
the nillable="true" or minOccurs="0" attribute from XML element, if both are
existing, perhaps in the scope of one wsdl file?
Yes, I know this isn't very accurate, but it gives you a much simpler client
stub, and I would prefer this right here!
You may argue, that this is an imprecision within googles wsdl, and I will
totally agree! But actually I have to live with this fault, cause I'm also
not happy to copy googles wsdl and fix it in my local copy. And maybe there
are other wsdls out there containing the same issue!
What do you think?
--
View this message in context:
http://www.nabble.com/Generated-code-with-minOccurs%3D%220%22-and-nillable%3D%22true%22-contains-JAXBElement-tp20704977p20704977.html
Sent from the cxf-user mailing list archive at Nabble.com.
