Bean Validation provides a common way of validation through constraint declaration and metadata for Java applications. To use it, you annotate domain model properties with declarative validation constraints which are then enforced by the runtime. There are built-in constraints, and you can also define your own custom constraints.

Consider the following example, which shows a simple PersonForm model with two properties:

A Bean Validation validator then validates instances of this class based on the declared constraints. See Bean Validation for general information about the API. See the Hibernate Validator documentation for specific constraints. To learn how to set up a bean validation provider as a Spring bean, keep reading.

Spring provides full support for the Bean Validation API including the bootstrapping of a Bean Validation provider as a Spring bean. This lets you inject a jakarta.validation.ValidatorFactory or jakarta.validation.Validator wherever validation is needed in your application.

You can use the LocalValidatorFactoryBean to configure a default Validator as a Spring bean, as the following example shows:

import org.springframework.validation.beanvalidation.LocalValidatorFactoryBean;
@Configuration
public class AppConfig {
	@Bean
	public LocalValidatorFactoryBean validator() {
		return new LocalValidatorFactoryBean();
The basic configuration in the preceding example triggers bean validation to initialize by
using its default bootstrap mechanism. A Bean Validation provider, such as the Hibernate
Validator, is expected to be present in the classpath and is automatically detected.
Inject Jakarta Validator

LocalValidatorFactoryBean implements both jakarta.validation.ValidatorFactory and
jakarta.validation.Validator, so you can inject a reference to the latter to
apply validation logic if you prefer to work with the Bean Validation API directly,
as the following example shows:
Inject Spring Validator

In addition to implementing jakarta.validation.Validator, LocalValidatorFactoryBean
also adapts to org.springframework.validation.Validator, so you can inject a reference
to the latter if your bean requires the Spring Validation API.
For example:
When used as org.springframework.validation.Validator, LocalValidatorFactoryBean
invokes the underlying jakarta.validation.Validator, and then adapts
ConstraintViolations to FieldErrors, and registers them with the Errors object
passed into the validate method.
Configure Custom Constraints

Each bean validation constraint consists of two parts:
An implementation of the jakarta.validation.ConstraintValidator interface that implements
the constraint’s behavior.
To associate a declaration with an implementation, each @Constraint annotation
references a corresponding ConstraintValidator implementation class. At runtime, a
ConstraintValidatorFactory instantiates the referenced implementation when the
constraint annotation is encountered in your domain model.
By default, the LocalValidatorFactoryBean configures a SpringConstraintValidatorFactory
that uses Spring to create ConstraintValidator instances. This lets your custom
ConstraintValidators benefit from dependency injection like any other Spring bean.
The following example shows a custom @Constraint declaration followed by an associated
ConstraintValidator implementation that uses Spring for dependency injection:
@Target({ElementType.METHOD, ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy=MyConstraintValidator.class)
public @interface MyConstraint {
@Target(AnnotationTarget.FUNCTION, AnnotationTarget.FIELD)
@Retention(AnnotationRetention.RUNTIME)
@Constraint(validatedBy = MyConstraintValidator::class)
annotation class MyConstraint
import jakarta.validation.ConstraintValidator;
public class MyConstraintValidator implements ConstraintValidator {
	@Autowired;
	private Foo aDependency;
	// ...
import jakarta.validation.ConstraintValidator
class MyConstraintValidator(private val aDependency: Foo) : ConstraintValidator {
	// ...
As the preceding example shows, a ConstraintValidator implementation can have its dependencies
@Autowired as any other Spring bean.
	@Bean
	public static MethodValidationPostProcessor validationPostProcessor() {
		return new MethodValidationPostProcessor();
To be eligible for Spring-driven method validation, target classes need to be annotated
with Spring’s @Validated annotation, which can optionally also declare the validation
groups to use. See
MethodValidationPostProcessor
for setup details with the Hibernate Validator and Bean Validation providers.
Method validation relies on AOP Proxies around the
target classes, either JDK dynamic proxies for methods on interfaces or CGLIB proxies.
There are certain limitations with the use of proxies, some of which are described in
Understanding AOP Proxies. In addition remember
to always use methods and accessors on proxied classes; direct field access will not work.
Spring MVC and WebFlux have built-in support for the same underlying method validation but without
the need for AOP. Therefore, do check the rest of this section, and also see the Spring MVC
Validation and
Error Responses sections, and the WebFlux
Validation and
Error Responses sections.
Method Validation Exceptions

By default, jakarta.validation.ConstraintViolationException is raised with the set of
ConstraintViolations returned by jakarta.validation.Validator. As an alternative,
you can have MethodValidationException raised instead with ConstraintViolations
adapted to MessageSourceResolvable errors. To enable set the following flag:
	@Bean
	public static MethodValidationPostProcessor validationPostProcessor() {
		MethodValidationPostProcessor processor = new MethodValidationPostProcessor();
		processor.setAdaptConstraintViolations(true);
		return processor;
		@JvmStatic
		fun validationPostProcessor() = MethodValidationPostProcessor().apply {
			setAdaptConstraintViolations(true)
<bean class="org.springframework.validation.beanvalidation.MethodValidationPostProcessor">
	<property name="adaptConstraintViolations" value="true"/>
</bean>
MethodValidationException contains a list of ParameterValidationResults which
group errors by method parameter, and each exposes a MethodParameter, the argument
value, and a list of MessageSourceResolvable errors adapted from
ConstraintViolations. For @Valid method parameters with cascaded violations on
fields and properties, the ParameterValidationResult is ParameterErrors which
implements org.springframework.validation.Errors and exposes validation errors as
FieldErrors.
Customizing Validation Errors

The adapted MessageSourceResolvable errors can be turned into error messages to
display to users through the configured MessageSource with locale and language specific
resource bundles. This section provides an example for illustration.
Given the following class declarations:
To customize the default message, you can add properties to
MessageSource
resource bundles using any of the above errors codes and message arguments. Note also that the
message argument "name" is itself a MessageSourceResolvable with error codes
"person.name" and "name" and can be customized too. For example:
Properties
Size.person.name=Please, provide a {0} that is between {2} and {1} characters long
person.name=username
Additional Configuration Options

The default LocalValidatorFactoryBean configuration suffices for most
cases. There are a number of configuration options for various Bean Validation
constructs, from message interpolation to traversal resolution. See the
LocalValidatorFactoryBean
javadoc for more information on these options.
You can configure a DataBinder instance with a Validator. Once configured, you can
invoke the Validator by calling binder.validate(). Any validation Errors are
automatically added to the binder’s BindingResult.
The following example shows how to use a DataBinder programmatically to invoke validation
logic after binding to a target object:
Foo target = new Foo();
DataBinder binder = new DataBinder(target);
binder.setValidator(new FooValidator());
// bind to the target object
binder.bind(propertyValues);
// validate the target object
binder.validate();
// get BindingResult that includes any validation errors
BindingResult results = binder.getBindingResult();
You can also configure a DataBinder with multiple Validator instances through
dataBinder.addValidators and dataBinder.replaceValidators. This is useful when
combining globally configured bean validation with a Spring Validator configured
locally on a DataBinder instance. See
Spring MVC Validation Configuration.
        
Apache®, Apache Tomcat®, Apache Kafka®, Apache Cassandra™, and Apache Geode™ are trademarks or registered trademarks of the Apache Software Foundation in the United States and/or other countries. Java™, Java™ SE, Java™ EE, and OpenJDK™ are trademarks of Oracle and/or its affiliates. Kubernetes® is a registered trademark of the Linux Foundation in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. Windows® and Microsoft® Azure are registered trademarks of Microsoft Corporation. “AWS” and “Amazon Web Services” are trademarks or registered trademarks of Amazon.com Inc. or its affiliates. All other trademarks and copyrights are property of their respective owners and are only mentioned for informative purposes. Other names may be trademarks of their respective owners.