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,
--
Geoff
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
