BindingResultUtils

Convenience methods for looking up BindingResults in a model Map.

DefaultBindingErrorProcessor

Default BindingErrorProcessor implementation.

Uses the "required" error code and the field name to resolve message codes for a missing field error.

Creates a FieldError for each PropertyAccessException given, using the PropertyAccessException's error code ("typeMismatch", "methodInvocation") for resolving message codes.

DefaultMessageCodesResolver

Default implementation of the MessageCodesResolver interface.

Will create two message codes for an object error, in the following order (when using the prefixed formatter):

• 1.: code + "." + object name
• 2.: code

Will create four message codes for a field specification, in the following order:

• 1.: code + "." + object name + "." + field
• 2.: code + "." + field
• 3.: code + "." + field type
• 4.: code

For example, in case of code "typeMismatch", object name "user", field "age":

• 1. try "typeMismatch.user.age"
• 2. try "typeMismatch.age"
• 3. try "typeMismatch.int"
• 4. try "typeMismatch"

This resolution algorithm thus can be leveraged for example to show specific messages for binding errors like "required" and "typeMismatch":

• at the object + field level ("age" field, but only on "user");
• at the field level (all "age" fields, no matter which object name);
• or at the general level (all fields, on any object).

In case of array, List or java.util.Map properties, both codes for specific elements and for the whole collection are generated. Assuming a field "name" of an array "groups" in object "user":

• 1. try "typeMismatch.user.groups[0].name"
• 2. try "typeMismatch.user.groups.name"
• 3. try "typeMismatch.groups[0].name"
• 4. try "typeMismatch.groups.name"
• 5. try "typeMismatch.name"
• 6. try "typeMismatch.java.lang.String"
• 7. try "typeMismatch"

By default the errorCodes will be placed at the beginning of constructed message strings. The messageCodeFormatter property can be used to specify an alternative concatenation MessageCodeFormatter.

In order to group all codes into a specific category within your resource bundles, e.g. "validation.typeMismatch.name" instead of the default "typeMismatch.name", consider specifying a prefix to be applied.

DirectFieldBindingResult

Special implementation of the Errors and BindingResult interfaces, supporting registration and evaluation of binding errors on value objects. Performs direct field access instead of going through JavaBean getters.

Since Spring 4.1 this implementation is able to traverse nested fields.

MapBindingResult

Map-based implementation of the BindingResult interface, supporting registration and evaluation of binding errors on Map attributes.

Can be used as errors holder for custom binding onto a Map, for example when invoking a Validator for a Map object.

ObjectError

Encapsulates an object error, that is, a global reason for rejecting an object.

See the DefaultMessageCodesResolver javadoc for details on how a message code list is built for an ObjectError.

ValidationUtils

Utility class offering convenient methods for invoking a Validator and for rejecting empty fields.

Checks for an empty field in Validator implementations can become one-liners when using #rejectIfEmpty or #rejectIfEmptyOrWhitespace.

BindException

Thrown when binding errors are considered fatal. Implements the BindingResult interface (and its super-interface Errors) to allow for the direct analysis of binding errors.

As of Spring 2.0, this is a special-purpose class. Normally, application code will work with the BindingResult interface, or with a DataBinder that in turn exposes a BindingResult via org.springframework.validation.DataBinder#getBindingResult().