Chapter 8. Bootstrapping

By default, available Bean Validation providers are discovered using the Java Service Provider mechanism.

For that purpose, each provider includes the file META- INF/services/javax.validation.spi.ValidationProvider, containing the fully qualified classname of its ValidationProvider implementation. In the case of Hibernate Validator this is org.hibernate.validator.HibernateValidator.

Depending on your environment and its classloading specifics, provider discovery via the Java’s service loader mechanism might not work. In this case you can plug in a custom ValidationProviderResolver implementation which performs the provider retrieval. An example is OSGi, where you could implement a provider resolver which uses OSGi services for provider discovery.

To use a custom provider resolver pass it via providerResolver() as shown shown in Example 8.4, “Using a custom ValidationProviderResolver”.

package org.hibernate.validator.referenceguide.chapter08;

public class OsgiServiceDiscoverer implements ValidationProviderResolver {

	@Override
	public List<ValidationProvider<?>> getValidationProviders() {
		//...
	}
}

ValidatorFactory validatorFactory = Validation.byDefaultProvider()
		.providerResolver( new OsgiServiceDiscoverer() )
		.configure()
		.buildValidatorFactory();
Validator validator = validatorFactory.getValidator();

Message interpolators are used by the validation engine to create user readable error messages from constraint message descriptors.

In case the default message interpolation algorithm described in Chapter 4, Interpolating constraint error messages is not sufficient for your needs, you can pass in your own implementation of the MessageInterpolator interface via Configuration#messageInterpolator() as shown in Example 8.5, “Using a custom MessageInterpolator”.

package org.hibernate.validator.referenceguide.chapter08;

public class MyMessageInterpolator implements MessageInterpolator {

	@Override
	public String interpolate(String messageTemplate, Context context) {
		//...
	}

	@Override
	public String interpolate(String messageTemplate, Context context, Locale locale) {
		//...
	}
}

ValidatorFactory validatorFactory = Validation.byDefaultProvider()
		.configure()
		.messageInterpolator( new MyMessageInterpolator() )
		.buildValidatorFactory();
Validator validator = validatorFactory.getValidator();

In some cases the validation engine should not access the state of a bean property. The most obvious example for that is a lazily loaded property or association of a JPA entity. Validating this lazy property or association would mean that its state would have to be accessed, triggering a load from the database.

Which properties can be accessed and which ones not is controlled by querying the TraversableResolver interface. Example 8.6, “Using a custom TraversableResolver” shows how to use a custom traversable resolver implementation.

package org.hibernate.validator.referenceguide.chapter08;

public class MyTraversableResolver implements TraversableResolver {

	@Override
	public boolean isReachable(
			Object traversableObject,
			Node traversableProperty,
			Class<?> rootBeanType,
			Path pathToTraversableObject,
			ElementType elementType) {
		//...
	}

	@Override
	public boolean isCascadable(
			Object traversableObject,
			Node traversableProperty,
			Class<?> rootBeanType,
			Path pathToTraversableObject,
			ElementType elementType) {
		//...
	}
}

ValidatorFactory validatorFactory = Validation.byDefaultProvider()
		.configure()
		.traversableResolver( new MyTraversableResolver() )
		.buildValidatorFactory();
Validator validator = validatorFactory.getValidator();

If no specific traversable resolver has been configured, the default behavior is to consider all properties as reachable and cascadable. When using Hibernate Validator together with a JPA 2 provider such as Hibernate ORM, only those properties will be considered reachable which already have been loaded by the persistence provider and all properties will be considered cascadable.

ConstraintValidatorFactory is the extension point for customizing how constraint validators are instantiated and released.

The default ConstraintValidatorFactory provided by Hibernate Validator requires a public no-arg constructor to instantiate ConstraintValidator instances (see Section 6.1.2, “The constraint validator”). Using a custom ConstraintValidatorFactory offers for example the possibility to use dependency injection in constraint validator implementations.

To configure a custom constraint validator factory call Configuration#constraintValidatorFactory() (see Example 8.7, “Using a custom ConstraintValidatorFactory”.

package org.hibernate.validator.referenceguide.chapter08;

public class MyConstraintValidatorFactory implements ConstraintValidatorFactory {

	@Override
	public <T extends ConstraintValidator<?, ?>> T getInstance(Class<T> key) {
		//...
	}

	@Override
	public void releaseInstance(ConstraintValidator<?, ?> instance) {
		//...
	}
}

ValidatorFactory validatorFactory = Validation.byDefaultProvider()
		.configure()
		.constraintValidatorFactory( new MyConstraintValidatorFactory() )
		.buildValidatorFactory();
Validator validator = validatorFactory.getValidator();

In case a method or constructor parameter constraint is violated, the ParameterNameProvider interface is used to retrieve the parameter name and make it available to the user via the property path of the constraint violation.

The default implementation returns parameter names in the form of arg0, arg1 etc, while custom implementations can retrieve the parameter names using methods such as parameter annotations, debug symbols, or Java 8 reflection.

An implementation for retrieving the parameter names using reflection in Java 8 is provided with ReflectionParameterNameProvider. For this parameter name provider to work, the source must be compiled using the –parameters compiler argument. Otherwise, the provider will return synthetic names in the form of arg0, arg1, etc.

To use ReflectionParameterNameProvider or another custom provider either pass an instance of the provider during bootstrapping as shown in Example 8.8, “Using a custom ParameterNameProvider”, or specify the fully qualified class name of the provider as value for the <parameter-name-provider> element in the META-INF/validation.xml file (see Section 7.1, “Configuring the validator factory in validation.xml”). This is demonstrated in Example 8.8, “Using a custom ParameterNameProvider”.

package org.hibernate.validator.referenceguide.chapter08;

public class MyParameterNameProvider implements ParameterNameProvider {

	@Override
	public List<String> getParameterNames(Constructor<?> constructor) {
		//...
	}

	@Override
	public List<String> getParameterNames(Method method) {
		//...
	}
}

ValidatorFactory validatorFactory = Validation.byDefaultProvider()
		.configure()
		.parameterNameProvider( new MyParameterNameProvider() )
		.buildValidatorFactory();
Validator validator = validatorFactory.getValidator();

As discussed earlier you can configure the constraints applying for your Java beans using XML based constraint mappings.

Besides the mapping files specified in META-INF/validation.xml you can add further mappings via Configuration#addMapping() (see Example 8.9, “Adding constraint mapping streams”). Note that the passed input stream(s) must adhere to the XML schema for constraint mappings presented in Section 7.2, “Mapping constraints via constraint-mappings”.

InputStream constraintMapping1 = ...;
InputStream constraintMapping2 = ...;
ValidatorFactory validatorFactory = Validation.byDefaultProvider()
		.configure()
		.addMapping( constraintMapping1 )
		.addMapping( constraintMapping2 )
		.buildValidatorFactory();
Validator validator = validatorFactory.getValidator();

You should close any passed input stream after the validator factory has been created.

Via the configuration object returned by Validation#byProvider() provider specific options can be configured.

In case of Hibernate Validator this e.g. allows you to enable the fail fast mode and pass one or more programmatic constraint mappings as demonstrated in Example 8.10, “Setting Hibernate Validator specific options”.

ValidatorFactory validatorFactory = Validation.byProvider( HibernateValidator.class )
		.configure()
		.failFast( true )
		.addMapping( (ConstraintMapping) null )
		.buildValidatorFactory();
Validator validator = validatorFactory.getValidator();

Alternatively, provider-specific options can be passed via Configuration#addProperty(). Hibernate Validator supports enabling the fail fast mode that way, too:

ValidatorFactory validatorFactory = Validation.byProvider( HibernateValidator.class )
		.configure()
		.addProperty( "hibernate.validator.fail_fast", "true" )
		.buildValidatorFactory();
Validator validator = validatorFactory.getValidator();

Refer to Section 11.2, “Fail fast mode” and Section 11.4, “Programmatic constraint definition and declaration” to learn more about the fail fast mode and the constraint declaration API.