• 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 ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

Hi,



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.

Pete
 
Ranch Hand
Posts: 734
7
  • 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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic