During development and binding of Java classes to schema components it's important to know whether the binding expressed with Java annotations match the existing XSD structure and components and if they don't what the binding inconsistencies are.
In JBossXB-2.0.2.XX there is org.jboss.xb.util.SchemaBindingValidator interface that can be used to check that the XSD and SchemaBinding are consistent. Well, consistent to a certain degree. Current default implementation catches basic things:
- the presence of global/root types and elements
- the presence of elements and attributes in types
- model group types and their contents should match and if it's a sequence the order of elements should match as well
With void excludeType(QName qName) certain types can be excluded from validation. Or even schema components (types, elements, model groups) from a specific namespace can be excluded from validation by calling void excludeNs(String ns). By default, standard built-in XSD types are excluded.
In case an inconsistency is found, IllegalStateException is thrown with the message describing the error. You can override this behavior by overriding protected void handleError(String msg) of default implementation.
Sometimes, an error message may not carry enough information (such as location of the invalid component in the XSD, etc) to identify or locate the error in the schema. In that case, enabled logging should help. Default logging is turned on by enabling TRACE for org.jboss.xb.util.SchemaBindingValidator.
Alternatively, you can override protected void log(String msg) and use
- public boolean isLoggingEnabled()
- public void enableLogging(boolean value)
Automatic SchemaBinding validation during schema resolution
Default implementations of SchemaBindingResolver interface (MultiClassSchemaResolver and DefaultSchemaResolver) now have a boolean property validateBinding which is false by default. If validateBinding is true every schema successfully resolved and built from JAXB/JBossXB annotations and for which the XSD could be found will be validated using SchemaBindingValidator.
If validateBinding is true but XSD could not be found a warning about skipping validation step will be logged.
You can create and initialize implementation of SchemaBindingValidator yourself and use public void setBindingValidator(SchemaBindingValidator validator) to set it. If validateBinding is on and SchemaBindingValidator is not set then for each resolved SchemaBinding a new instance of DefaultSchemaBindingValidator will be used.