reposting my thoughts from dev-list:
I just debugged your junit test, and you are right, the cast to String is the problem in this particular case. But I don't think just chanching the String to Object in IDRefValidator does the trick.
I'm trying to get the big picture, let me just tell you my first unstructured thoughts, maybe we find a solution together:
- the IDValidator is only used with XSId. XSId maps to java.lang.String. So the IDValidator extends StringValidator, it evens throws a validation exception if the given object is no string.
-the id*REF*validator just implements TypeValidator, as XSIDREF refers to java.lang.Object
- looking at their behavior, it only makes sense to use them together: idrefvalidator puts unresolved ids into a collection, idvalidator takes occuring ids out of this collection. if the collections is empty in the end -> everything is fine
- in our case - just marshalling with a mapping file, without descriptor classses - we have a strange situation: The XmlClassDescriptors describing the objects are created dynamicaly and they create the following:
- Class A:
FieldDescriptor for "aid" with a FieldValidator (no IDValidator)
- Class B:
FieldDescriptor for "aRef" with a FV WITH IDRefValidator
So attribute A.aId is treated as normal field (not as id), but B.aref is treated as IDREF.
- But it makes no sense to use the idrefvalidator without a idvalidator. Being nosy, I changed the String cast in idrefvalidator into object, and our testcase succeeds. So the final "are-there-unreferenced-ids-left-check" is not performed.