Class ConstraintValidatorContextImpl

java.lang.Object
org.hibernate.validator.internal.engine.constraintvalidation.ConstraintValidatorContextImpl
All Implemented Interfaces:
ConstraintValidatorContext, HibernateConstraintValidatorContext
Direct Known Subclasses:
CrossParameterConstraintValidatorContextImpl

public class ConstraintValidatorContextImpl extends Object implements HibernateConstraintValidatorContext
Author:
Hardy Ferentschik, Gunnar Morling, Guillaume Smet
  • Constructor Details

  • Method Details

    • disableDefaultConstraintViolation

      public final void disableDefaultConstraintViolation()
      Description copied from interface: ConstraintValidatorContext
      Disables the default ConstraintViolation object generation (which is using the message template declared on the constraint).

      Useful to set a different violation message or generate a ConstraintViolation based on a different property.

      Specified by:
      disableDefaultConstraintViolation in interface ConstraintValidatorContext
    • getDefaultConstraintMessageTemplate

      public final String getDefaultConstraintMessageTemplate()
      Specified by:
      getDefaultConstraintMessageTemplate in interface ConstraintValidatorContext
      Returns:
      the current un-interpolated default message
    • buildConstraintViolationWithTemplate

      public 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
      Parameters:
      messageTemplate - new un-interpolated constraint message
      Returns:
      returns a constraint violation builder
    • 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
      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
    • addExpressionVariable

      public HibernateConstraintValidatorContext addExpressionVariable(String name, Object value)
      Description copied from interface: HibernateConstraintValidatorContext
      Allows to set an additional expression variable which will be available as an EL variable during interpolation. The variable will be available for interpolation for all constraint violations generated for this constraint. This includes the default one as well as all violations created by the ConstraintValidatorContext.ConstraintViolationBuilder. To create multiple constraint violations with different variable values, this method can be called between successive calls to ConstraintValidatorContext.ConstraintViolationBuilder.addConstraintViolation().

      For example:

       
       public boolean isValid(String value, ConstraintValidatorContext constraintValidatorContext) {
           HibernateConstraintValidatorContext context = constraintValidatorContext.unwrap( HibernateConstraintValidatorContext.class );
      
           context.addExpressionVariable( "foo", "bar" );
           context.buildConstraintViolationWithTemplate( "${foo}" )
                  .addConstraintViolation();
      
           context.addExpressionVariable( "foo", "snafu" );
           context.buildConstraintViolationWithTemplate( "${foo}" )
                  .addConstraintViolation();
      
           return false;
        }
        
      
       
      Specified by:
      addExpressionVariable in interface HibernateConstraintValidatorContext
      Parameters:
      name - the name under which to bind the expression variable, cannot be null
      value - the value to be bound to the specified name
      Returns:
      a reference to itself to allow method chaining
    • addMessageParameter

      public HibernateConstraintValidatorContext addMessageParameter(String name, Object value)
      Description copied from interface: HibernateConstraintValidatorContext
      Allows to set an additional named parameter which can be interpolated in the constraint violation message. The variable will be available for interpolation for all constraint violations generated for this constraint. This includes the default one as well as all violations created by the ConstraintValidatorContext.ConstraintViolationBuilder. To create multiple constraint violations with different variable values, this method can be called between successive calls to ConstraintValidatorContext.ConstraintViolationBuilder.addConstraintViolation().

      For example:

       
       public boolean isValid(String value, ConstraintValidatorContext constraintValidatorContext) {
           HibernateConstraintValidatorContext context = constraintValidatorContext.unwrap( HibernateConstraintValidatorContext.class );
      
           context.addMessageParameter( "foo", "bar" );
           context.buildConstraintViolationWithTemplate( "{foo}" )
                  .addConstraintViolation();
      
           context.addMessageParameter( "foo", "snafu" );
           context.buildConstraintViolationWithTemplate( "{foo}" )
                  .addConstraintViolation();
      
           return false;
        }
        
      
       
      Specified by:
      addMessageParameter in interface HibernateConstraintValidatorContext
      Parameters:
      name - the name under which to bind the parameter, cannot be null
      value - the value to be bound to the specified name
      Returns:
      a reference to itself to allow method chaining
    • getClockProvider

      public ClockProvider getClockProvider()
      Description copied from interface: ConstraintValidatorContext
      Returns the provider for obtaining the current time in the form of a Clock, e.g. when validating the Future and Past constraints.
      Specified by:
      getClockProvider in interface ConstraintValidatorContext
      Returns:
      the provider for obtaining the current time, never null. If no specific provider has been configured during bootstrap, a default implementation using the current system time and the current default time zone as returned by Clock.systemDefaultZone() will be returned.
    • withDynamicPayload

      public HibernateConstraintValidatorContext withDynamicPayload(Object violationContext)
      Description copied from interface: HibernateConstraintValidatorContext
      Allows to set an object that may further describe the violation. The user is responsible himself to ensure that this payload is serializable in case the jakarta.validation.ConstraintViolation has to be serialized.
      Specified by:
      withDynamicPayload in interface HibernateConstraintValidatorContext
      Parameters:
      violationContext - an object representing additional information about the violation
      Returns:
      a reference to itself to allow method chaining
    • getConstraintValidatorPayload

      public <C> C getConstraintValidatorPayload(Class<C> type)
      Description copied from interface: HibernateConstraintValidatorContext
      Returns an instance of the specified type or null if the current constraint validator payload isn't of the given type.
      Specified by:
      getConstraintValidatorPayload in interface HibernateConstraintValidatorContext
      Parameters:
      type - the type of payload to retrieve
      Returns:
      an instance of the specified type or null if the current constraint validator payload isn't of the given type
      See Also:
    • getConstraintDescriptor

      public final ConstraintDescriptor<?> getConstraintDescriptor()
    • getConstraintViolationCreationContexts

      public final List<ConstraintViolationCreationContext> getConstraintViolationCreationContexts()
    • getCopyOfBasePath

      protected final PathImpl getCopyOfBasePath()