Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 0.9.5.2
-
Fix Version/s: None
-
Component/s: XML code generator
-
Labels:None
-
Environment:Operating System: All
Platform: PC
-
Bugzilla Id:1537
-
Number of attachments :
Description
i've discovered this source generator bug in version 0.9.3.21, and patched it
for our project. It still seems to be present in 0.9.5.2.
The example schema i'll include contains the following
- two Model Group Definitions (named group-1 and group-2)
- a Complex Type (named GroupBase) that has 'group-1' as Model Group.
- another Complex Type (named GroupImpl) that extends from 'GroupBase' and
has 'group-2' as Model Group
The source generator fails to generate a field for 'group-2', which lead to
runtime errors like
org.xml.sax.SAXException: unable to find FieldDescriptor for 'element-c' in
ClassDescriptor of group-element
at org.exolab.castor.xml.UnmarshalHandler.startElement
(UnmarshalHandler.java:1566)
at org.exolab.castor.xml.UnmarshalHandler.startElement
(UnmarshalHandler.java:1149)
This is what happens (i've checked this in 0.9.5.2)
- org.exolab.castor.builder.MemberFactory creates a FieldInfo object
to describe groups, and calls (line 388, method createFieldInfo(...))
fieldInfo.setNodeName("error-if-this-is-used");
because groups don't correspond to node names in xml documents.
FieldInfo extends from XmlInfo, and has a property nodeType, that is
initialized to XmlInfo.NODE_TYPE. In this case the default isn't changed.
- for FieldInfo's of nodeType XmlInfo.NODE_TYPE,
org.exolab.castor.builder.SourceFactory (line 1895, method handleField())
checks, whether the field does not already exist in the class will extend
from, using the nodeName as a key. Because both
group-1 and group-2 have nodeName "error-if-this-is-used", no fields are
generated for group-2
The solution I implemented was to change the line in MemberFactory to
fieldInfo.setNodeName("error-if-this-is-used"+xmlName);
thereby making the bogus nodeName unique for each group.
The conceptual problem underneath this bogus nodeName is that groups are
modelled as xml nodes in the castor builder code. At least i would add a
nodeType to XmlInfo (e.g. OTHER or SYNTHETIC or ...) to indicate Info objects
that do not correspond to something in the XML info set.
Created an attachment (id=385)
Example Xml schema for which source generation fails