In your case the answer is simple - it is the way jaxb works. It is a matter of optimization and xml -> java mapping.
Why do you need fooConfig anyway? Imagine 2 scenarios: 1. you have fooConfig root element that is a complexType 2. you have fooConfig root element that is of type fooConfigType What will happen when you try to unmarshal a xml file? 1. In first case, instance of class named after root element (fooConfig) will be created, because there is no other way for jaxb to include the nested elements in java as a class (xsd element without type, declared as complexType, is in fact handled as anonymous/noname type and these are not available in java). 2. In 2nd case, instance of object named after root element type (fooConfigType) will be created, because in fact you don't need wrapper class - fooConfig from first scenario would extend fooConfigType without any addition (ok, maybe @XmlRootElement annotation could be added). If you'd like to force jaxb to create root element type class and also root element class or you simple want to understand why it doesn't make sense to create root element class when it is of named type, declare fooConfig as follows: <xs:element name="fooConfig"> <xs:complexType> <xs:complexContent> <xs:extension base="tns:fooConfigType" /> </xs:complexContent> </xs:complexType> </xs:element> and check fooConfig.java content. -- S pozdravom Ladislav Lenčucha [email protected] On Fri, Dec 7, 2012 at 7:37 PM, KARR, DAVID <[email protected]> wrote: > > -----Original Message----- > > From: KARR, DAVID > > Sent: Thursday, December 06, 2012 4:58 PM > > To: [email protected] > > Subject: Why would XJC not generate a class for a root element? > > > > I have a JAX-RS app that uses XJC to generate classes from 4 different > > schemas. All four xjc calls in the pom reference a binding file > > specific to that schema. All 4 schemas are pretty simple, along with > > very similar binding files, and the reference in the pom. They all > > define a single top-level "element" element, along with several > > complexType elements. > > > > For some reason, the processing of one of those schemas is refusing to > > generate the class corresponding to the root element. I have a > > complexType that the element references, and it generated the class for > > that, but not for the element. The other three schemas get the > > generated class corresponding to the root element. > > > > There are no processing errors. > > > > I'd like to get a solution, but is there some additional debugging I > > can turn on that might give me some useful information? > > Hmph. I've got it to work, but I'd like to understand better why I had to > do what I did. > > Previously, my schema declared the root element and the type of the root > element separately, with a reference from the former to the latter. I was > reading an old blog entry from Kohsuke ( > http://weblogs.java.net/blog/kohsuke/archive/2006/03/why_does_jaxb_p.html) > that talked about possibly using the "xjc:simple" experimental feature in > the binding, but it gave me the idea to change the definition so that the > type of the root element was declared inline in the element, instead of > being standalone. That fixes the problem. It doesn't generate the class > for the Type (which I don't need), but it does for the element, which I do > need. >
