IDREF has no ID

Marek, did you realize that we improved validation of IDs/IDHREF attributes when switching to 1.1. and later releases. In other words, if your IDREF attribute points to an ID attribute (value) that does not exist, Castor (1.1. and above) will complain by throwing an exception.

Well, actually, ignore above comment, as clearly your problem is related to marshalling only ...

It looks like the problem is with the following code in IdRefValidator at lines 58ff:

        try {
            ClassDescriptorResolver classDescriptorResolver = context.getResolver();
            ClassDescriptor classDescriptor = classDescriptorResolver.resolve(object.getClass());
            FieldDescriptor fieldDescriptor = classDescriptor.getIdentity();
            FieldHandler fieldHandler = fieldDescriptor.getHandler();
            id = (String) fieldHandler.getValue(object);
        } catch (Exception e) {
            String err = "The object associated with IDREF \"" + object
            + "\" of type " + object.getClass() + " has no ID!";
            throw new ValidationException(err);
        }

There's a cast to java.util.String, which suggests that this won't work with your identities typed 'long'. Let me do some more investigations, though. For the time being, you could use the following property to skip id/href validation altogether:

#

1. Property specifying whether id/href validation should be lenient;
2. defaults to false
   org.exolab.castor.xml.lenient.id.validation=true

JUnit test case relative to src/bugs to highlight the issue at hand.

Marek, when working towards Castor 1.1 months ago, we decided to fix a couple issues related to mis-handling of IDs/IDHREFs, incl. duplicate IDS, missing IDs, etc. As a result of this work, we (not knowingly) committed ourselves to allow Strings for IDs only - as this is what the XML code generator produces for element definitions typed with <xs:ID>.

Question: would it be a problem for you to switch to String, or would you insist on seeing that being fixed, as it worked with Castor 1.0.5 and earlier ?

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.

patch for review:

• adds the IDValidator to the FieldDescriptors for aid, bid
• performs the "are-any-unresolved-ids-left" check in the validate method of the Marshaller
• in order to get the xmlctf-suite run without problems, I also changed the cast

String value = (String) object; -> to String value = object.toString()

in IDValidator and IDRefValidator.

If this patch turns out to have no sideeffects, it adds validation of ids (Strings, or other objects with suitable toStribg-method) and idrefs to Marshalling.

As a result of this, I think the new requirement for the toString() method on the identities needs to be exposed somewhere. Can you please try to find the right place in the user documentation ? In the worst case, you'll have to create a new page .. .

Matthias ?

Updated patch, necessary after SVN move of all XML artifacts to the 'xml' module.