Package org.hibernate.validator.internal.engine.constraintvalidation

Class CrossParameterConstraintValidatorContextImpl

java.lang.Object
org.hibernate.validator.internal.engine.constraintvalidation.ConstraintValidatorContextImpl
org.hibernate.validator.internal.engine.constraintvalidation.CrossParameterConstraintValidatorContextImpl
All Implemented Interfaces:
ConstraintValidatorContext, HibernateConstraintValidatorContext, HibernateCrossParameterConstraintValidatorContext
public class CrossParameterConstraintValidatorContextImpl extends ConstraintValidatorContextImpl implements HibernateCrossParameterConstraintValidatorContext
Author:
Marko Bekhta

  • Constructor Details

  • Method Details

    • buildConstraintViolationWithTemplate

      public final HibernateConstraintViolationBuilder buildConstraintViolationWithTemplate(String messageTemplate)
      Description copied from interface: ConstraintValidatorContext
      Returns a constraint violation builder building a violation report allowing to optionally associate it to a sub path. The violation message will be interpolated.

      To create the ConstraintViolation, one must call either one of the addConstraintViolation() methods available in one of the interfaces of the fluent API. If another method is called after addConstraintViolation() on ConstraintViolationBuilder or any of its associated nested interfaces an IllegalStateException is raised.

      If ConstraintValidator.isValid(Object, ConstraintValidatorContext) returns false, a ConstraintViolation object will be built per constraint violation report including the default one (unless ConstraintValidatorContext.disableDefaultConstraintViolation() has been called).

      ConstraintViolation objects generated from such a call contain the same contextual information (root bean, path and so on) unless the path has been overridden.

      To create a different ConstraintViolation, a new constraint violation builder has to be retrieved from ConstraintValidatorContext Here are a few usage examples: 

       //assuming the following domain model
 public class User {
     public Map<String,Address> getAddresses() { ... }
 }

 public class Address {
     public String getStreet() { ... }
     public Country getCountry() { ... }
 }

 public class Country {
     public String getName() { ... }
 }

 //From a property-level constraint on User.addresses
 //Build a constraint violation on the default path - i.e. the "addresses" property
 context.buildConstraintViolationWithTemplate( "this detail is wrong" )
             .addConstraintViolation();

 //From a class level constraint on Address
 //Build a constraint violation on the default path + "street"
 //i.e. the street property of Address
 context.buildConstraintViolationWithTemplate( "this detail is wrong" )
             .addPropertyNode( "street" )
             .addConstraintViolation();

 //From a property-level constraint on  User.addresses
 //Build a constraint violation on the default path + the bean stored
 //under the "home" key in the map
 context.buildConstraintViolationWithTemplate( "Incorrect home address" )
             .addBeanNode()
                 .inContainer( Map.class, 1 )
                 .inIterable().atKey( "home" )
             .addConstraintViolation();

 //From a class level constraint on User
 //Build a constraint violation on the default path + addresses["home"].country.name
 //i.e. property "country.name" on the object stored under "home" in the map
 context.buildConstraintViolationWithTemplate( "this detail is wrong" )
             .addPropertyNode( "addresses" )
             .addPropertyNode( "country" )
                 .inContainer( Map.class, 1 )
                 .inIterable().atKey( "home" )
             .addPropertyNode( "name" )
             .addConstraintViolation();

 //From a class level constraint on User
 //Build a constraint violation on the default path + addresses["home"].<map key>
 //i.e. a container element constraint violation for the map key
 context.buildConstraintViolationWithTemplate( "the map key is invalid" )
             .addPropertyNode( "addresses" )
             .addContainerElementNode( "<map key>", Map.class, 0 )
                 .inIterable().atKey( "invalid" )
             .addConstraintViolation();

      Cross-parameter constraints on a method can create a node specific to a particular parameter if required. Let's explore a few examples: 

       //Cross-parameter constraint on method
 //createUser(String password, String passwordRepeat)
 //Build a constraint violation on the default path + "passwordRepeat"
 context.buildConstraintViolationWithTemplate("Passwords do not match")
             .addParameterNode(1)
             .addConstraintViolation();

 //Cross-parameter constraint on a method
 //mergeAddresses(Map<String,Address> addresses,
 //        Map<String,Address> otherAddresses)
 //Build a constraint violation on the default path + "otherAddresses["home"]
 //i.e. the Address bean hosted in the "home" key of the "otherAddresses" map parameter
 context.buildConstraintViolationWithTemplate(
         "Map entry home present in both and does not match")
             .addParameterNode(1)
             .addBeanNode()
                 .inContainer( Map.class, 1 )
                 .inIterable().atKey("home")
             .addConstraintViolation();

 //Cross-parameter constraint on a method
 //mergeAddresses(Map<String,Address> addresses,
 //        Map<String,Address> otherAddresses)
 //Build a constraint violation on the default path + "otherAddresses["home"].city
 //i.e. on the "city" property of the Address bean hosted in
 //the "home" key of the "otherAddresses" map
 context.buildConstraintViolationWithTemplate(
         "Map entry home present in both but city does not match")
             .addParameterNode(1)
             .addPropertyNode("city")
                 .inContainer( Map.class, 1 )
                 .inIterable().atKey("home")
             .addConstraintViolation();
      Specified by:
      buildConstraintViolationWithTemplate in interface ConstraintValidatorContext
      Specified by:
      buildConstraintViolationWithTemplate in interface HibernateConstraintValidatorContext
      Overrides:
      buildConstraintViolationWithTemplate in class ConstraintValidatorContextImpl
      Parameters:
      messageTemplate - new un-interpolated constraint message
      Returns:
      returns a constraint violation builder

    • getMethodParameterNames

      public List<String> getMethodParameterNames()
      Specified by:
      getMethodParameterNames in interface HibernateCrossParameterConstraintValidatorContext
      Returns:
      the list of the parameter names of the validated method.

    • unwrap

      public <T> T unwrap(Class<T> type)
      Description copied from interface: ConstraintValidatorContext
      Returns an instance of the specified type allowing access to provider-specific APIs. If the Jakarta Bean Validation provider implementation does not support the specified class, ValidationException is thrown.
      Specified by:
      unwrap in interface ConstraintValidatorContext
      Overrides:
      unwrap in class ConstraintValidatorContextImpl
      Type Parameters:
      T - the type of the object to be returned
      Parameters:
      type - the class of the object to be returned
      Returns:
      an instance of the specified class