Note that there are potential security implications in failing to set an array of allowed fields. In the case of HTTP form POST data for example, malicious clients can attempt to subvert an application by supplying values for fields or properties that do not exist on the form. In some cases this could lead to illegal data being set on command objects or their nested objects. For this reason, it is highly recommended to specify the allowedFields property on the DataBinder.

The binding results can be examined via the Errors interface, available as BindException instance. Missing field errors and property access exceptions will be converted to FieldErrors, collected in the Errors instance, with the following error codes:

• Missing field error: "required"
• Type mismatch error: "typeMismatch"
• Method invocation error: "methodInvocation"

Custom validation errors can be added afterwards. You will typically want to resolve such error codes into proper user-visible error messages; this can be achieved through resolving each error via a MessageSource. The list of message codes to try can be customized through the MessageCodesResolver strategy. DefaultMessageCodesResolver's javadoc gives details on the default resolution rules.

By default, binding errors are resolved through the binding error processor for required binding errors and property access exceptions. You can override those if needed, for example to generate different error codes.

This generic data binder can be used in any sort of environment. It is heavily used by Spring's web MVC controllers, via the subclass org.springframework.web.bind.ServletRequestDataBinder.