Geoff, I guess this is a bug. Feel free to open a new issue at
http://jira.codehaus.org/browse/CASTOR Any patches would be welcome by definition. Regards Werner Geoff Morrison wrote: > It appears that the XML code generator does not obey the equalsmethod or > superclass properties for the *Item classes generated for nested groups. > > I have this sequence of choices: > > <xs:element name="Reason" minOccurs="0"> > <xs:complexType> > <xs:sequence minOccurs="1" maxOccurs="unbounded"> > <xs:choice> > <xs:element name="Trace" type="UnifiedTrace"/> > <xs:element name="TraceRef" type="UnifiedRef"/> > </xs:choice> > </xs:sequence> > </xs:complexType> > </xs:element> > > and these codegen properties: > > org.exolab.castor.builder.superclass=com.fortify.io.CastorBase > org.exolab.castor.builder.equalsmethod=true > > The top-level element creates a UnifiedReason class that contains a list > of UnifiedReasonItem objects, and each UnifiedReasonItem contains a > single ReasonChoice object. The UnifiedReason and ReasonChoice classes > both extend CastorBase and have equals/hashCode methods, but the > UnifiedReasonItem has neither of these. This seems to run counter to the > descriptions of these properties. > > It looks like this is done explicitly in SourceFactory.java: > > 482 // -- if we have a superclass, make sure that the actual type > extends it, not the > 483 // xxxItem holder class. > 484 String actSuperClass = classes[1].getSuperClassQualifiedName(); > 485 jClass.setSuperClass(actSuperClass); > 486 classes[1].setSuperClass(null); > > Is this a Castor bug, or is this behavior intentional? Is there another > way to get the code generator to do what I want? > > I'm running 1.1.2.1, but I see this behavior with 1.3 as well. > > Thanks, > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
