Everyone-
I've been playing around with the compile-time class descriptors, and I'm running into a strange behavior I'd like help with. I started out with a simple class that has no fields -- I just created a {ClassName}Descriptor class that extended XMLClassDescriptorImpl and supplied the correct values to the super class's constructor. Using an XML file that I already had, I was able to unmarshal the object correctly. I then moved on to more complex classes with fields, and (IMHO the worst part) collections. I finally got all these classes to unmarshal.
As an after thought I decided I needed to attempt marshalling the objects out to XML. And while the marshalling to XML worked fine (other than some odd attributes, see below), when I unmarshal the new XML file, I get an exception because Castor cannot find an implementing class for one of my interfaces. A parent class holds a reference to an implementing class of an interface, so the marshalled XML looks like (in this case, the simple implementing class with no fields):
<parent-name> <field-name xsi:type="implementing-class-short-name" /> </parent-name>
The exception I get is:
org.xml.sax.SAXException: unable to instantiate a new type of: foo.bar.InterfaceA{file: [not available]; line: 67; column: 49}
If I change the XML to include the fully qualified class name, the XML unmarshals with no problem. So I guess my question is can I "preload" class descriptors into Castor (or better yet, have Castor search for them) so that Castor knows when it sees "implementing-class-short-name" to use the ClassDescriptor provided? Or on the flip side, can I make the marshaller use the fully qualified name for the xsi:type attribute?
The second issue I'm having may relate to the first, but just in case, here it is. Using a more complex class that contains an array of interface-implementing-classes, marshalling produces the following XML:
<parent-name>
<field-name xsi:type="implementing-class-short-name">
<class-derived-name att1="val1" xsi:type="class-derived-name" />
<class-derived-name att1="val2" />
<class-derived-name att1="val3" />
</field-name>
</parent-name>In this case, the array is populated with objects (with varying parameters) of the same interface-implementing class. What puzzles me is the xsi:type in only the first element. I would think Castor would either insert it in all locations, or none at all... If I use the work-around mentioned above (replace the xsi:type in the outer element, not the inner), the object tree unmarshals correctly. And I just tested, and if I remove the xsi:type from the first element, it still unmarshals correctly.
I have to admit, my ClassDescriptors are real hacks, but any help anyone can give would be appreciated. Thanks for your time!
Stephen
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-user
