Examples of org.hibernate.validator.method.MethodValidator

• org.hibernate.validator.method.MethodValidator
  rg/en/jsr/detail?id=303">JSR 303: Bean Validation, Appendix C ("Proposal for method-level validation").

  The purpose of this API is to provide a facility for the Programming by Contract approach to program design based on the concepts defined by the Bean Validation API. More specifically this means that any Bean Validation constraints (built-in as well as custom constraints) can be used to describe

  • any preconditions that must be met before a method may legally be invoked (by annotating method parameters with constraints) and
  • any postconditions that are guaranteed after a method invocation returns (by annotating methods).

  These constraints may be declared directly on a method's parameters and/or return values. Alternatively, by annotating method parameters/return values with the special {@link javax.validation.Valid}annotation a recursive validation of those parameters/return values against the constraints defined on their types can be triggered. Consider for instance the method declaration

   @NotNull @Valid Customer findCustomerByName(@NotNull @Size(min = 5) String name) { // ... } 

  Here, the validation engine will check for the following pre- and postconditions (provided the method validation is triggered automatically by some integration layer, see below):

  • The name parameter is guaranteed to be not null and at least 5 characters long. In particular it is not necessary for the implementor of this method to perform these checks manually.
  • It is guaranteed that the call yields a non-null object, which itself is valid according to all the bean validation constraints declared on its type. In particular it is not necessary for the caller to perform these checks manually.

  This service only deals with the actual validation of method parameters/return values itself, but not with the invocation of such a validation. It is expected that this invocation is triggered by an integration layer using AOP or similar method interception facilities such as the JDK's {@link java.lang.reflect.Proxy} API or CDI ( "JSR 299: Contexts and Dependency Injection for the Java^TM EE platform" ).

  Such an integration layer would typically intercept each method call to be validated, validate the call's parameters, proceed with the method invocation and finally validate the invocation's return value. If any of the validation steps yields a non-empty set of constraint violations the integration layer would typically throw a {@link MethodConstraintViolationException} wrappingthese violations which in turn guarantees that the call flow only arrives at the method's implementation respectively call site if all pre- respectively postconditions are fulfilled.

  MethodValidator instances are obtained by {@link javax.validation.Validator#unwrap(Class) unwrapping} a {@link javax.validation.Validator} object:

   Validator validator = ...; MethodValidator methodValidator = validator.unwrap(MethodValidator.class); 

  Method level validation is (currently) a proprietary feature of Hibernate Validator (HV), so the unwrapped Validator instance must be HV's implementation. In case there are multiple Bean Validation implementations on the classpath, this can be done be explicitly choosing HV as validation provider:

   MethodValidator methodValidator = Validation.byProvider(HibernateValidator.class) .configure() .buildValidatorFactory() .getValidator() .unwrap(MethodValidator.class); 

  If not stated otherwise, none of this interface's methods allow null as parameter value.

  @author Gunnar Morling

Related Classes of org.hibernate.validator.method.MethodValidator