What purpose of @Valid
annotation when putting it on method parameter level?
public void (@Valid Person p) { ... }
I created a test, and passed to this method non-valid object, but nothing happens.
I expect to get an exception.
Hibernate Validator allows to express and validate application constraints. The default metadata source are annotations, with the ability to override and extend through the use of XML. It is not tied to a specific application tier or programming model and is available for both server and client application programming.
In controller class: The @Valid annotation applies validation rules on the provided object. The BindingResult interface contains the result of validation.
The @Valid annotation ensures the validation of the whole object. Importantly, it performs the validation of the whole object graph. However, this creates issues for scenarios needing only partial validation. On the other hand, we can use @Validated for group validation, including the above partial validation.
When Spring Boot finds an argument annotated with @Valid, it automatically bootstraps the default JSR 380 implementation — Hibernate Validator — and validates the argument. When the target argument fails to pass the validation, Spring Boot throws a MethodArgumentNotValidException exception.
The @Valid
annotation on an object is an indication to the validation framework to process the annotated object. When used on a parameter of a method this is referred to as method level validation. Note that method level validation is not part of the core specification, and in fact is only supported when Bean Validation is integrated into a container type framework (JSF, CDI, Java EE). When Bean Validation is integrated into such a supporting container, what happens is that, as lifecycle methods are called on the bean, the container detects JSR 303 annotations on the methods parameters and triggers validation of the associated bean.
So for example, if you had the following method definition in a JAX-RS resource class:
@Path("/example")
public class MyExampleResourceImpl {
@POST
@Path("/")
public Response postExample(@Valid final Example example) {
// ....
}
}
When the postExample
method is called in response to a request being handled by the JAX-RS container, the example
bean will be validated. Contrast this behavior with what would happen if you were running a standalone Java SE app:
public class MyMainClass {
public static void main(final String[] args) {
final MyMainClass clazz = new MyMainClass();
clazz.echo(new Example());
}
public Example echo(@Valid final Example example) {
// ...
}
}
In this case, running the program will not trigger validation of the Example
parameter, even if you included all the JSR 303 runtime JARs. This is because there is no container available that implements method level validation. The Bean Validation Specification describes all this in some detail in Appendix C. I've quoted some of it below for your benefit:
Proposal for method-level validation
This proposition has not been integrated into the core specification and is not part of it. It remains here for archaeological purposes and will be seriously considered for a future revision of this specification. This proposal is likely to be a bit out of sync with the rest of the specification artifacts.
Note: Bean Validation providers are free to implement this proposal as a specific extension. Such specific extension could for example be accessed via the use of the Validator.unwrap method.
A popular demand was to provide a method and parameter level validation mechanism reusing the constraint descriptions of the specification. This set of APIs is meant to be used by interceptor frameworks such as:
- application frameworks like
- JSR-299
- component frameworks like Enterprise Java Beans
- aspect based frameworks
These frameworks can call the validation APIs to validate either the parameter list or the returned value of a method when such method is called. More precisely, validation occurs around a method invocation. This extension of the Bean Validation API allows to reuse the core engine as well as the constraint definition and declaration for such method level validations.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With