• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

elementFormDefault configuration in generated package-info.java

Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


using the wsdl2java provided by the cxf framework ( version 2.7.5), I am able to generate the JaxB classes
for the elements defined in the xsd.

The generated package-info.java class for this xsd is as follows :-

The elementFormDefault is set to QUALIFIED, however, in the xsd it is set to unqualified.

I beleive this discrepency is causing the unmarshalling functionality to fail for me because the element
does not have a namespace prefix.

Any suggestions as to why the package-info.java has elementFormDefault set to QUALIFIED when in
the xsd it is set to "unqualified".

Thank you your help.

Ranch Hand
Posts: 733
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That can happen (to wsdl2jave, in particular, or possibly to whatever code-generation tools) usually if your local element(s) is in some namespace(s) other than the global element containing it and that, in consequence, your xsd contains also xs:import element for instance... The code-generation engine may thereby consider annotating the package with QUALIFIED be more convenient in those cases...

But, at the end, the apparent non-honouring of elementFormDefault in the package-info should not be a cause of failure of validating or unmarshalling the xml that is constructed with xsd as its blueprint. What I mean is also that you have to, if in doubt, first of all, validate the xml from within the xml-xsd line as the test before looking into what might be wrong in the data binding. Also looking from xml-xsd-centric angle, the elementFormDefault unqualified in the xsd can always be rewritten in an equivalent form with an xsd combination all with elementFormDefault scripted as qualified instead.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic