Does this work for Substitution Groups as well?
My xsd is
<xs:element name="name" type="xs:string"/>
<xs:element name="navn" substitutionGroup="name" />
<xs:complexType name="custinfo">
<xs:sequence>
<xs:element ref="name"/>
</xs:sequence>
</xs:complexType>
<xs:element name="customer" type="custinfo" />
I am using the same
<jaxb:globalBindings generateElementProperty="false"/>
But this doesnot work with SubstitutionGroups. Any idea of how the
JAXBELement<String> could be restricted to String?
Thomas S. wrote:
>
> 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-tp20704977p23211378.html
Sent from the cxf-user mailing list archive at Nabble.com.
