public class ConstraintValidatorContextImpl extends Object implements HibernateConstraintValidatorContext
ConstraintValidatorContext.ConstraintViolationBuilder| Constructor and Description |
|---|
ConstraintValidatorContextImpl(List<String> methodParameterNames,
TimeProvider timeProvider,
PathImpl propertyPath,
ConstraintDescriptor<?> constraintDescriptor) |
| Modifier and Type | Method and Description |
|---|---|
HibernateConstraintValidatorContext |
addExpressionVariable(String name,
Object value)
Allows to set an additional named variable which can be interpolated in the constraint violation message.
|
ConstraintValidatorContext.ConstraintViolationBuilder |
buildConstraintViolationWithTemplate(String messageTemplate)
Returns a constraint violation builder building a violation report
allowing to optionally associate it to a sub path.
|
void |
disableDefaultConstraintViolation()
Disables the default
ConstraintViolation object generation (which
is using the message template declared on the constraint). |
ConstraintDescriptor<?> |
getConstraintDescriptor() |
List<ConstraintViolationCreationContext> |
getConstraintViolationCreationContexts() |
String |
getDefaultConstraintMessageTemplate() |
List<String> |
getMethodParameterNames() |
TimeProvider |
getTimeProvider()
Returns the provider for obtaining the current time, e.g.
|
<T> T |
unwrap(Class<T> type)
Returns an instance of the specified type allowing access to
provider-specific APIs.
|
public ConstraintValidatorContextImpl(List<String> methodParameterNames, TimeProvider timeProvider, PathImpl propertyPath, ConstraintDescriptor<?> constraintDescriptor)
public final void disableDefaultConstraintViolation()
ConstraintValidatorContextConstraintViolation 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.disableDefaultConstraintViolation in interface ConstraintValidatorContextpublic final String getDefaultConstraintMessageTemplate()
getDefaultConstraintMessageTemplate in interface ConstraintValidatorContextpublic final ConstraintValidatorContext.ConstraintViolationBuilder buildConstraintViolationWithTemplate(String messageTemplate)
ConstraintValidatorContextConstraintViolation, 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 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()
.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" )
.inIterable().atKey( "home" )
.addPropertyNode( "name" )
.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 addresses, Map 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()
.inIterable().atKey("home")
.addConstraintViolation();
//Cross-parameter constraint on a method
//mergeAddresses(Map addresses, Map 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")
.inIterable().atKey("home")
.addConstraintViolation();
buildConstraintViolationWithTemplate in interface ConstraintValidatorContextmessageTemplate - new un-interpolated constraint messagepublic <T> T unwrap(Class<T> type)
ConstraintValidatorContextValidationException is thrown.unwrap in interface ConstraintValidatorContexttype - the class of the object to be returnedpublic HibernateConstraintValidatorContext addExpressionVariable(String name, Object value)
HibernateConstraintValidatorContextConstraintViolationBuilder.
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;
}
addExpressionVariable in interface HibernateConstraintValidatorContextname - the name under which to bind the parameter, cannot be nullvalue - the value to be bound to the specified namepublic TimeProvider getTimeProvider()
HibernateConstraintValidatorContextFuture and Past
constraints.getTimeProvider in interface HibernateConstraintValidatorContextnull. If no specific provider has been
configured during bootstrap, a default implementation using the current system time and the current
default time zone will be returned.public final ConstraintDescriptor<?> getConstraintDescriptor()
public final List<ConstraintViolationCreationContext> getConstraintViolationCreationContexts()
Copyright © 2016 JBoss by Red Hat. All rights reserved.