Good explanation. Hopefully this note will be a common search result. Some comments inline.
> -----Original Message----- > From: Ladislav Lenčucha [mailto:[email protected]] > Sent: Friday, December 07, 2012 11:28 AM > To: [email protected] > Subject: Re: Why would XJC not generate a class for a root element? > > 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). The lack of the @XmlRootElement on the type was what led me to figure out why this was happening. I would have just used the type if it had that. > 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. > 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.ht > ml) > > 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. > >
