I think you would need to ask on the jaxb lists. There may be a valid reason
why it doesn't work with sub-groups, but I'm not really sure. :-(
Dan
On Fri April 24 2009 3:34:35 am Sapna Srivastava wrote:
> 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?
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
