Default behavior about validation is unclear

[oliviercailloux]

I believe that the current text in the specification does not specify clearly what should happen “by default” in case of (different kinds of) validation errors, and even contains inconsistencies, at least if one considers the javadoc on the API classes as part of the spec (as should be, I suppose).

The specification PDF (The JavaTM Architecture for XML Binding (JAXB) 2.3 Final Release, July 11, 2017) insists that the “default event hander aborts the unmarshalling process when the first validation error event is encountered” (4.4 Unmarshalling): “If the client application does not set an event handler on a Unmarshaller or Marshaller instance prior to invoking the unmarshalor marshal operations, then a default event handler will receive notification of any errors or fatal errors
encountered and stop processing the XML data. In other words, the default event handler will fail on the first error that is encountered.” (4.3.1.3 Fail-fast validation) (Also, “There are three ways to handle validation events encountered during the unmarshal and marshal operations: 4.3.1.4. Rely on the default validation event handler The default handler will fail on the first error or fatal error encountered.”)

But the section 3.5.2. Validation distinguishes type constraints, local structural constraints, global structural constraints that can make a document invalid, but does not specify clearly what an implementation should do by default with these various constraints and how this relates to the text cited above in 4.3.1.3 and 4.4. The section enumerates those ways of enforcing schema constraints: static enforcement, simple dynamic enforcement, and complex dynamic enforcement. “It is straightforward to implement both static and simple dynamic checks so as to satisfy the fail-fast principle. Constraints that require complex dynamic checks could, in theory, also be implemented so as to fail as soon as possible. The resulting classes would be rather clumsy to use, however (…) A similar analysis applies to most other sorts of structural constraints, and especially to global structural constraints. Schema-derived classes have the ability to enable or disable a mode that verifies type constraints. JAXB mapped classes can optionally be validated at unmarshal and marshal time.”.
Also, 3.5.2.1 Validation Rearchitecture: “The detection of complex schema constraint violations has been redesigned to have a JAXB 2.0 implementation to delegate to the validation API in JAXP 1.3. JAXP 1.3 defines a standard validation API ( javax.xml.validation package) for validating XML content against constraints within a schema.”

It is not clear, reading all this, if the default setting (when not setting a schema and not touching the validation event handler, thus leaving the default one in place) will check some constraints, and fail fast if any problem happens (even if recoverable), or if it will do this only when setSchema is called.

In any case, the Unmarshaller Javadoc is inconsistent.

setEventHandler agrees with the specification PDF:
void setEventHandler​(ValidationEventHandler handler) throws JAXBException
Allow an application to register a ValidationEventHandler.
The ValidationEventHandler will be called by the JAXB Provider if any validation errors are encountered during calls to any of the unmarshal methods. If the client application does not register a ValidationEventHandler before invoking the unmarshal methods, then ValidationEvents will be handled by the default event handler which will terminate the unmarshal operation after the first error or fatal error is encountered.

But the header of the Unmarshall class disagrees (italics mine):
“Validation and Well-Formedness A client application can enable or disable JAXP 1.3 validation mechanism via the setSchema(javax.xml.validation.Schema) API. Since unmarshalling invalid XML content is defined in JAXB 2.0, the Unmarshaller default validation event handler was made more lenient than in JAXB 1.0.
When schema-derived code generated by JAXB 1.0 binding compiler is registered with JAXBContext, the default unmarshal validation handler is DefaultValidationEventHandler and it terminates the marshal operation after encountering either a fatal error or an error.
For a JAXB 2.0 client application, there is no explicitly defined default validation handler and the default event handling only terminates the unmarshal operation after encountering a fatal error. ”

And the setSchema method javadoc strongly suggests that validation is disabled by default:
void setSchema​(javax.xml.validation.Schema schema)
Specify the JAXP 1.3 Schema object that should be used to validate subsequent unmarshal operations against. Passing null into this method will disable validation.
This method replaces the deprecated setValidating(boolean) API.
Initially this property is set to null.

Also, an example in the header of the Unmarshall javadoc indicates:
// turn off the JAXB provider's default validation mechanism to
// avoid duplicate validation
u.setValidating( false )

but this is deprecated.

Please consider clarifying the default behavior when validation errors occur, and restoring consistency.