JSR-380: Bean Validation 2.0 TCK Coverage

Applying a constraint annotation to an incompatible type will raise an UnexpectedTypeException.

At most one ConstraintValidator supporting cross-parameter validation must be present for a given constraint. A ConstraintDefinitionException is raised otherwise.

If a constraint definition is not valid, a ConstraintDefinitionException is raised either at validation time or when the metadata is requested.

A constraint definition may have attributes that are specified at the time the constraint is applied to a JavaBean.

Annotation elements starting with valid are not allowed

Every constraint annotation must define a message element of type String.

Every constraint annotation must define a groups element that specifies the processing groups with which the constraint declaration is associated.

The type of the groups parameter is Class<?>[].

The default value must be an empty array.

If no group is specified when declaring the constraint on an element, the Default group is considered declared.

Constraint annotations must define a payload element that specifies the payload with which the constraint declaration is associated. The type of the payload parameter is Payload[].

The default value must be an empty array.

Each attachable payload extends Payload.

The element validationAppliesTo must only be present for constraints that are both generic and cross-parameter, it is mandatory in this situation. A ConstraintDefinitionException is raised if these rules are violated.

The type of the validationAppliesTo parameter is ConstraintTarget. The default value must be ConstraintTarget.IMPLICIT.

If a ConstraintTarget is used in an illegal situation, a ConstraintDeclarationException is raised either at validation time or when the metadata is requested.

Using IMPLICIT in a situation that cannot be inferred (see the JavaDoc for the detailed rules),

Using PARAMETERS on a constructor or method that has no parameter,

Using RETURN_VALUE on a method with no return value,

Using PARAMETERS or RETURN_VALUE on a type - class or interface - or on a field.

The Bean Validation provider treats regular annotations (annotations not annotated by @Constraint) whose value element has a return type of an array of constraint annotations in a special way. Each element in the value array are processed by the Bean Validation implementation as regular constraint annotations.

This marks the constraint annotation type as repeatable and lets users specify the constraint several times without explicitly using the List annotation.

More formally, each constraint annotation hosted on a constraint annotation is applied to the target element and this is done recursively.

Note that the main annotation and its constraint validation implementation is also applied.

By default, each failing constraint generates an error report.

Groups from the main constraint annotation are inherited by the composing annotations.

Any groups definition on a composing annotation is ignored.

Payload from the main constraint annotation is inherited by the composing annotations.

Any payload definition on a composing annotation is ignored.

The constraint target from the main constraint annotation is inherited by the composing annotations.

Any validationAppliesTo definition on a composing annotation is ignored.

The type upon which composed constraint is placed must be compatible with all constraints (composing and composed).

All composed and composing constraints must have a constraint type in common.

More specifically, if a composed constraint is marked as @ReportAsSingleViolation, the evaluation of the composing constraints stops at the first failing constraint and the error report corresponding to the composed constraint is generated and returned.

Composing annotations can define the value of message and custom attributes (excluding groups, payload and validationAppliesTo) but these are fixed in the composed constraint definition.

It is possible to override attributes and messages defined on a composing annotation. An attribute from the main annotation is used to override one or more attributes of the composing annotations. Such an attribute is annotated with one or more @OverridesAttribute annotations.

If left undefined, the default value for @OverridesAttribute.name is the name of the composed constraint attribute hosting the @OverridesAttribute annotation.

The types of the overridden and overriding attributes must be identical.

A composing constraint can itself be a composed constraint. In this case, attribute values are overridden recursively according to the described rules.

If a constraint is used more than once as a composing constraint, the multi value constraints model as described in 3.2 is used.

If the composing constraints are directly given on the composed constraint (i.e. via the repeatable annotation feature), constraintIndex refers to the left-to-right order of the constraints of this type in which they are given on the composed constraint.

If the composing constraints are specified using their corresponding List annotation, constraintIndex refers to the index within the value array.

A composing constraint must not be given directly on the composed constraint and using the corresponding List annotation at the same time. A ConstraintDeclarationException will be raised in this case.

If index is undefined, the single constraint declaration is targeted.

If the composition is invalid, e.g. infinitely recursive composition wrong attribute overriding a single attribute mapped to more than one source attribute a composing and composed constraint marked as different constraint types (i.e., generic and cross-parameter) etc. a ConstraintDefinitionException is raised either at validation time or when the metadata is requested.

A constraint validation implementation performs the validation of a given constraint annotation for a given type.

The implementation classes are specified by the validatedBy element of the @Constraint annotation that decorates the constraint definition.

By default, a ConstraintValidator targets the (returned) element annotated by the constraint. You can make a ConstraintValidator target the array of parameters of a method or constructor (aka cross-parameter) by annotating the validator implementation with @SupportedValidationTarget.

A ConstraintValidator implementation can target both annotated elements and array of parameters.

If a ConstraintValidator targets array of parameters (cross-parameter), T must resolve to Object[] (or Object) in order to have the array of parameter values passed to the isValid() method. A ConstraintDefinitionException is raised otherwise.

The initialize() method is called by the Bean validation provider prior to any use of the constraint implementation.

As of Bean Validation 2.0, initialize() has an empty default implementation, allowing to omit the implementation from validators that don't need to access any constraint attributes.

The isValid() method is evaluated by the Bean Validation provider each time a given value is validated.

If the property is of an unanticipated type, an UnexpectedTypeException is raised.

If an exception occurs either in the initialize() or isValid() method, the runtime exception is wrapped into a ValidationException by the Bean Validation engine.

By default, each invalid constraint leads to the generation of one error object represented by a ConstraintViolation object. This object is built from the default constraint message template as defined by the constraint declaration and the context in which the constraint declaration is placed (bean, property, executable parameter, cross-parameter, executable return value or container element).

The ConstraintValidatorContext methods let the constraint implementation disable the default ConstraintViolation generation and create one or more custom ones.

The non-interpolated message passed as a parameter is used to build the ConstraintViolation message (the message interpolation operation is applied to it).

By default, the Path exposed on the ConstraintViolation represents the path to the bean, property, parameter, cross-parameter, return value or container element hosting the constraint (see 6.2 for more information).

You can point it to a subpath of this default path by using the constraint violation builder fluent API.

If disableDefaultConstraintViolation() is called, no custom error is added (using the error builder) and if the constraint is not valid, a ValidationException is raised.

Constraint validators for temporal constraints (either the built-in constraints @Past, @PastOrPresent, @Future and @FutureOrPresent or custom temporal constraints) can obtain the current instant from the ClockProvider object exposed by ConstraintValidatorContext#getClockProvider().

The getClock() method returns a java.time.Clock object which represents the current instant, date and time using a time zone. A conforming Bean Validation implementation provides a default clock provider which returns a clock representing the current system time and default time zone.

The default ConstraintValidatorFactory provided by the Bean Validation provider implementation uses the public no-arg constructor of the ConstraintValidator class.

If an exception occurs in the factory while retrieving the ConstraintValidator instance, the runtime exception is wrapped in a ValidationException.

If the instance returned by the factory is null, a ValidationException is raised.

The validation engine passes the container instance and a value receiver object to the extractValues() method.

The value extractor is only invoked if the container is not null.

Value(), the given value will be passed to the validation engine

iterableValue(), the given value will be passed to the validation engine and the corresponding property path node (see 6.2) will be marked as iterable, i.e. Node#isInIterable() returns true

indexedValue(), the given value will be passed to the validation engine and the corresponding property path node will be marked as iterable and it will have set the given index, i.e. Node#getIndex() returns the given index value

keyedValue(), the given value will be passed to the validation engine and the corresponding property path node will be marked as iterable and it will have set the given key, i.e. Node#getKey() returns the given key value

When passing a non-null node name to any of the receiver methods, this node name will be used when adding a node of kind CONTAINER_ELEMENT to the property path (see 6.2 for the property path construction rules).

If null is passed as node name, no node will be appended to the property path. The resulting property path will then be the same as if the constraint had been given on the container instead of a container element. That is desirable for single-element wrapper types such as Optional, OptionalInt etc.

If an exception occurs during invocation of the extractValues() method, this exception is wrapped into a ValidationException by the Bean Validation engine.

When validating the @NotNull constraint, the map as returned by the getter will be passed to the map key extractor in order to obtain the map keys.

When validating the @RetailOrder constraint and performing cascaded validation, the map as obtained directly from the field will be passed to the map value extractor in order to obtain the map values.

The @ExtractedValue annotation is used to denote the element extracted by a given value extractor

The @ExtractedValue annotation must be specified exactly once for a value extractor type.

For generic container types (e.g. java.util.List), @ExtractedValue is to be specified on a type argument of the container type as used in the extractor definition.

For non-generic container types (e.g. java.util.OptionalInt), @ExtractedValue is to be specified on the container type as used in the extractor definition. The type of the wrapped element(s) must be specified using @ExtractedValue#type() in this case.

In case an illegal value extractor definition is detected, a ValueExtractorDefinitionException is raised.

This causes constraints to be automatically applied to the wrapped value(s) if a constraint is found for an element of a type handled by that extractor

java.util.Iterable; iterableValue() must be invoked for each contained element, passing the string literal <iterable element> as node name

java.util.List; indexedValue() must be invoked for each contained element, passing the string literal <list element> as node name

java.util.Map; both map keys and map values are to be supported; keyedValue() must be invoked by the map key extractor for each contained key, passing the string literal <map key> as node name; keyedValue() must be invoked by the map value extractor for each contained value, passing the string literal <map value> as node name

java.util.Optional; value() must be invoked, passing null as node name and passing the contained object as value or null if none is present

java.util.OptionalInt, java.util.OptionalLong and java.util.OptionalDouble; the extracted value types must be java.lang.Integer, java.lang.Long and java.lang.Double, respectively. value() must be invoked, passing null as node name and passing the contained number as value or null if none is present. The extractors must be marked with @UnwrapByDefault.

javafx.beans.observable.ObservableValue; value() must be invoked with the observable value, passing null as node name; the extractor must be marked with @UnwrapByDefault

javafx.beans.property.ReadOnlyListProperty and javafx.beans.property.ListProperty; indexedValue() must be invoked for each contained element, passing the string literal <list element> as node name

javafx.beans.property.ReadOnlySetProperty and javafx.beans.property.SetProperty; iterableValue() must be invoked for each contained element, passing the string literal <iterable element> as node name

javafx.beans.property.ReadOnlyMapProperty and javafx.beans.property.MapProperty; both map keys and map values are to be supported; keyedValue() must be invoked by the map key extractor for each contained key, passing the string literal <map key> as node name; keyedValue() must be invoked by the map value extractor for each contained value, passing the string literal <map value> as node name

The following extractor definition is illegal as it specifies @ExtractedValue more than once

Properties to be validated must follow the method signature conventions for JavaBeans read properties, as defined by the JavaBeans specification. These properties are commonly referred as getters.

Constraints can be applied to interfaces and superclasses.

The JavaBeans specification specifies that a getter is a method whose name starts with get and has a return type but no parameter name starts with is, has no parameter and is returning boolean

The target of an annotation definition can be a type field or property constructor or method return value constructor or method parameter constructor or method cross-parameter container element provided that: the constraint definition supports the specified target (java.lang.annotation.Target) one of the ConstraintValidators declared on the constraint supports the declared type of the target or in the case of cross-parameter, one cross-parameter ConstraintValidator is present (see 5.7.4 to learn about ConstraintValidator resolution) in the case of container element constraints, a corresponding value extractor exists (see 5.7.5 for the details of value extractor resolution)

Constraint declarations can be applied to a class or an interface.

Applying a constraint to a class or interface expresses a validation over the state of the class or the class implementing the interface.

Constraint declarations can be applied on both fields and properties for the same object type.

The same constraint should however not be duplicated between a field and its associated property (the constraint validation would be applied twice).

When a field is annotated with a constraint declaration, field access strategy is used to access the state validated by such constraint.

When a property is annotated with a constraint declaration, property access strategy is used to access the state validated by such constraint.

The fields or methods visibility are not constrained.

Consider the situation where bean X contains a field of type Y. By annotating field Y with the @Valid annotation, the Validator will validate Y (and its properties) when X is validated.

The exact type Z of the value contained in the field declared of type Y (subclass, implementation) is determined at runtime. The constraint definitions of Z are used.

Any object implementing java.lang.Iterable is supported.

Arrays of objects

java.util.Collection

java.util.Set

java.util.List

java.util.Map

Each object provided by the iterator is validated.

For Map, the value (retrieved by getValue) of each Map.Entry is validated (the key is not validated).

Like regular references, its type is determined at runtime and the constraint definitions for this particular type are used.

As of Bean Validation 2.0, @Valid can be applied to the elements of any generic container by putting it to the type argument(s) when using such container (e.g. MultiMap<String, @Valid Address> addressesByType), provided a value extractor implementation (see 4) for that container type and the targeted type argument is present.

@Valid also allows the validation of the elements of nested generic containers. @Valid must be put to a type argument of that nested container type in order to trigger validation of the elements of all the nested containers.

The @Valid annotation is applied recursively.

When a constraint is defined on a class, the class instance being validated is passed to the ConstraintValidator. When a constraint is defined on a field, the value of the field is passed to the ConstraintValidator. When a constraint is defined on a getter, the result of the getter invocation is passed to the ConstraintValidator.

A constraint declaration can be placed on an interface.

For a given class, constraint declarations held on superclasses as well as interfaces are evaluated by the Bean Validation provider.

The effect of constraint declarations is cumulative. Constraints declared on a superclass getter will be validated along with any constraints defined on an overridden version of the getter according to the Java Language Specification visibility rules.

If no group is explicitly declared, a constraint belongs to the Default group.

Groups are represented by interfaces.

A constraint can belong to one or more groups.

During the validation call, one or more groups are validated. All the constraints belonging to this set of groups is evaluated on the object graph.

A group may inherit one or more groups by using interface inheritance.

For a given interface Z, constraints marked as belonging to the group Z (i.e. where the annotation element groups contains the interface Z) or any of the super interfaces of Z (inherited groups) are considered part of the group Z.

Each group in a group sequence must be processed sequentially in the order defined by @GroupSequence.value when the group defined as a sequence is requested.

Note that a group member of a sequence can itself be composed of several groups via inheritance or sequence definition. In this case, each composed group must respect the sequence order as well.

If one of the groups processed in the sequence generates one or more constraint violations, the groups following in the sequence must not be processed.

Groups defining a sequence and groups composing a sequence must not be involved in a cyclic dependency: either directly or indirectly either through cascaded sequence definitions or group inheritance

If a group containing such a circularity is evaluated, a GroupDefinitionException is raised.

To define a group as a sequence, the interface must be annotated with the @GroupSequence annotation.

A given constraint can belong to two or more groups ordered by a sequence. In this case, the constraint is evaluated as part of the first group and ignored in the subsequent group(s).

To redefine Default for a class, place a @GroupSequence annotation on the class; this sequence expresses the sequence of groups that does substitute Default for this class.

A sequence defined on a class A (i.e. redefining the Default groups for the class) must contain the group A.

If a @GroupSequence redefining the Default group for a class A does not contain the group A, a GroupDefinitionException is raised when the class is validated or when its metadata is requested.

Every constraint hosted on an interface Z and part of the Default group (implicitly or explicitly) belongs to the group Z.

@ConvertGroup and @ConvertGroup.List can be used everywhere @Valid can be used (associations, method/constructor parameters and return value). If these annotations are used without @Valid, a ConstraintDeclarationException is raised.

Groups are passed as is to the nested elements unless the @ConvertGroup annotation is used.

If the group expected to be passed to the nested element validation is defined as the from attribute of a @ConvertGroup annotation, the group used to effectively validate the nested element is the corresponding group defined in the to attribute.

If no value for the from attribute is specified, Default.class will be used as the source group of the conversion.

Rules are not executed recursively.

It is not legal to have more than one conversion rule containing the same from value. In this case, a ConstraintDeclarationException is raised.

Like regular constraint declarations, the from attribute cannot refer to a group sequence. A ConstraintDeclarationException is raised in this situation.

The to attribute can. The group sequence will then be expanded before validating the associated object.

@ConvertGroup and @ConvertGroup.List can only be placed where @Valid is present to ensure proper respect of the Liskov substitution principle

Likewise, if a sub type overrides/implements a method originally defined in several parallel types of the hierarchy (e.g. two interfaces not extending each other, or a class and an interface not implemented by said class) and if that method's return value has been marked for cascading validation in one of the parallel types, no group conversion rule may be declared for that method's return value in the parallel types of the hierarchy.

If any of these rules is violated, a ConstraintDeclarationException is raised by default as defined in 5.6.5.

Group conversions can also be applied during container element validation

If X has no @GroupSequence annotation, the group Default contains the following constraints: every constraint in the group X if X has a direct superclass Y, every constraint in the group Default of Y

If X does have a @GroupSequence annotation, the group Default contains every constraint belonging to every group declared by the @GroupSequence annotation.

If a group definition leads to a circular sequencing order between groups, a GroupDefinitionException is raised.

Constraints can be applied to the elements of generic containers, e.g. List, Map or Optional. This is done by putting constraint annotations to the type arguments of such containers.

Container element constraints can be used within the following declarations: fields, properties, method or constructor parameters or method return values.

When a field, property, executable parameter or method return value which is of a container type gets validated, then all values contained in the container will be validated provided that their container element type is constrained.

Any container element constraints of that element will be validated alongside any other constraints hosted by that element.

For container element constraints, the same rules for validation groups and group sequences apply as for any other constraint on the same element.

Container element constraints can be applied to nested container types

This is useful for applying a constraint given on a non-generic container to the container element if there is no value extractor marked with @UnwrapByDefault (by using Unwrap) the container itself in case there is a value extractor marked with @UnwrapByDefault (by using Skip)

If both Unwrap and Skip are present in the definition of a payload, a ConstraintDeclarationException is raised.

Parameter constraints are declared by putting constraint annotations on method or constructor parameters.

Cross-parameter constraints are declared by putting cross-parameter constraint annotations on methods or constructors

It is not legal to declare a cross-parameter constraint on a method or constructor which has no parameters. A ConstraintDeclarationException is raised in this case.

They are known to be both generic and cross-parameter constraints. When using such a constraint on an executable to target the parameters, one must set validationAppliesTo if there is an ambiguity.

A conforming Bean Validation implementation provides a default ParameterNameProvider implementation which returns parameter names as stored in the class file containing the validated executable, if present. A conforming implementation must either use the Java reflection API or ensure behavioral compatibility to using the reflection API in the following way: Obtain the method's or constructor's parameters via java.lang.reflect.Executable.getParameters() Obtain each parameter's name via java.lang.reflect.Parameter.getName()

If an exception occurs during invocation of the getParameterNames() methods, this exception is wrapped into a ValidationException by the Bean Validation engine.

Return value constraints are declared by putting constraint annotations directly on a method or constructor.

They are known to be both generic and cross-parameter constraints. When using such constraint on an executable to target the return value, one must set validationAppliesTo in case there is an ambiguity.

The @Valid annotation is used to declare that a cascaded validation of the given method/constructor parameters or return values is performed by the Bean Validation provider. When marked, the parameter or return value is considered a bean object to validate.

Null arguments and null return values are ignored

The validation is recursive; that is, if validated parameter or return value objects have references marked with @Valid themselves, these references will also be validated

In sub types (be it sub classes/interfaces or interface implementations), no parameter constraints may be declared on overridden or implemented methods, nor may parameters be marked for cascaded validation. This would pose a strengthening of preconditions to be fulfilled by the caller.

If a sub type overrides/implements a method originally defined in several parallel types of the hierarchy (e.g. two interfaces not extending each other, or a class and an interface not implemented by said class), no parameter constraints may be declared for that method at all nor parameters be marked for cascaded validation. This again is to avoid an unexpected strengthening of preconditions to be fulfilled by the caller.

In sub types (be it sub classes/interfaces or interface implementations), return value constraints may be declared on overridden or implemented methods and the return value may be marked for cascaded validation. Upon validation, all return value constraints of the method in question are validated, wherever they are declared in the hierarchy. This only poses possibly a strengthening but no weakening of the method's postconditions guaranteed to the caller.

One must not mark a method return value for cascaded validation more than once in a line of a class hierarchy. In other words, overriding methods on sub types (be it sub classes/interfaces or interface implementations) cannot mark the return value for cascaded validation if the return value has already been marked on the overridden method of the super type or interface.

Out of the box, a conforming Bean Validation provider must throw a ConstraintDeclarationException when discovering that any of these rules are violated.

The above rules do not apply when validating constructor constraints as constructors do not override one another. Parameter and return value constraints can be applied to any constructor in the type hierarchy, but only the constraints defined directly on the validated constructor are evaluated.

For a given group, the validation routine applied on a given bean instance is expected to execute the following constraint validations in no particular order: for all reachable fields, execute all field level validations (including the ones expressed on superclasses) matching the targeted group unless the given validation constraint has already been processed during this validation routine for a given navigation path (see 5.7.1) as part of a previous group match. for all reachable getters, execute all getter level validations (including the ones expressed on interfaces and superclasses) matching the targeted group unless the given validation constraint has already been processed during this validation routine for a given navigation path (see 5.7.1) as part of a previous group match. execute all class level validations (including the ones expressed on interfaces and superclasses) matching the targeted group unless the given validation constraint has already been processed during this validation routine for a given navigation path (see 5.7.1) as part of a previous group match. for all reachable and cascadable associations, execute all cascading validations (see 5.7.1) including the ones expressed on interfaces and superclasses (see 5.4.6). Note that group conversion can apply (see 5.4.5).

The object validation routine is described as such. For each constraint declaration: determine for the constraint declaration, the appropriate ConstraintValidator to use (see 5.7.4). execute the isValid operation (from the constraint validation implementation) on the appropriate data (see 3.4) if isValid() returns true, continue to the next constraint, if isValid() returns false, the Bean Validation provider populates ConstraintViolation object(s) according to the rules defined in 3.4 and appends these objects to the list of constraint violations.

The @Valid annotation on a given association (i.e. object reference or collection, array, Iterable of objects), dictates the Bean Validator implementation to apply recursively the Bean Validation routine on (each of) the associated object(s).

This mechanism is recursive: an associated object can itself contain cascaded references.

Null references are ignored.

To prevent infinite loops, the Bean Validation implementation must ignore the cascading operation if the associated object instance has already been validated in the current navigation path (starting from the root object).

@Valid is an orthogonal concept to the notion of group. If two groups are in sequence, the first group must pass for all associated objects before the second group is evaluated.

For a given group, the validation routine applied to validate parameters of a method or constructor is expected to execute the following constraint validations in no particular order: execute all parameter validations (in case of overriding method validation, including the ones expressed on overridden methods of the interfaces and superclasses) matching the targeted group unless the given validation constraint has already been processed during this validation routine for a given navigation path (see 5.7.1) as part of a previous group match. execute all cross parameter validations (in case of overriding method validation, including the ones expressed on overridden methods of the interfaces and superclasses) matching the targeted group unless the given validation constraint has already been processed during this validation routine for a given navigation path (see 5.7.1) as part of a previous group match. for all parameters marked for cascaded validation, execute all cascading validations (see 5.7.1), in case of overriding method validation including the ones expressed on overridden methods of the interfaces and superclasses (see 5.4.6). Note that group conversion can apply (see 5.4.5).

For a given group, the validation routine applied to validate the return value of a method or constructor is expected to execute the following constraint validations in no particular order: execute all return value validations (including the ones expressed on interfaces and superclasses) matching the targeted group unless the given validation constraint has already been processed during this validation routine for a given navigation path (see 5.7.1) as part of a previous group match. if the return value is marked for cascaded validation, execute all cascading validations (see 5.7.1) including the ones expressed on interfaces and superclasses (see 5.4.6). Note that group conversion can apply (see 5.4.5).

isReachable() is called for every property about to be accessed either for validation or for cascading.

isCascadable() is called for every property about to be cascaded (i.e. marked as @Valid).

isCascadable() for a given property is only called if isReachable() returns true. In other words, isReachable() is always called before isCascadable() for a given property.

traversableObject is the object instance being evaluated. null if the check is triggered as part of a validateValue() call.

traversableProperty is the Node representing the property hosted by the traversableObject being considered for traversal. The name of a property is defined in 5.1.2.

rootBeanType is the class of the root being validated, i.e. either the type of the object passed to the validate method or the type declaring the validated method/constructor in case of method validation.

pathToTraversableObject is the Path from the rootBeanType down to the traversableObject. If the root object is traversableObject, pathToTraversableObject is composed of a single Node whose name is null. The path is described following the conventions described in 6.2 (getPropertyPath).

elementType is the java.lang.annotation.ElementType the annotation is placed on. It can be either FIELD or METHOD. Any other value is not expected.

The Bean Validation provider must not access the state of a property, nor validate its constraints if the property is not traversable. A property is traversable if TraversableResolver returns true for this property.

If an exception occurs when the TraversableResolver is called, the exception is wrapped into a ValidationException.

The following elements are not passed through the traversable resolver filter: the bean instance validated the method and constructor parameter values being validated the method and constructor return value being validated

But the properties of these elements (if validated) are. In this case the complete path is provided via pathToTraversableObject.

The list of ConstraintValidators can contain at most one which targets cross-parameter. If the constraint targets the parameters of an executable either implicitly or by the use of validationAppliesTo in the constraint - see 3.1.1.4, then the cross-parameter ConstraintValidator is used. If none is present, a ConstraintDefinitionException is raised. If more than one cross-parameter ConstraintValidator is present, a ConstraintDefinitionException is raised.

If the constraint declaration is hosted on a class or an interface, the targeted type is the class or the interface.

If the constraint is hosted on a class attribute, the type of the attribute is the targeted type.

If the constraint is hosted on a method (getter or non-getter) or constructor, the return type is the targeted type.

If the constraint is hosted on a method or constructor parameter, the parameter type is the targeted type.

If the constraint is hosted on a type argument of a parameterized type (i.e. a container element constraint, see 5.5), the type argument's type is the targeted type.

If the constraint is subject to implicit unwrapping (see 5.5.1) and the applicable value extractor is defined for a generic type (e.g. javafx.beans.value.ObservableValue), the targeted type is the type captured for the type parameter handled by the value extractor (e.g. String if the constraint is placed on a StringProperty).

If the constraint is subject to implicit unwrapping and the applicable value extractor is defined for a non-generic type, the targeted type is the type defined by the extractor via @ExtractedValue#type() (e.g. Integer if the constraint is placed on a java.util.OptionalInt).

The ConstraintValidator chosen to validate the generic constraint on a declared type T is the one where the ConstraintValidator targets the annotated element, where the type supported by the ConstraintValidator is a supertype of T and where there is no other ConstraintValidator whose supported type is a supertype of T and not a supertype of the chosen ConstraintValidator supported type.

Only ConstraintValidator implementations targeting annotated elements are considered.

Primitive types are considered equivalent to their respective primitive wrapper class.

If no ConstraintValidator compliant with T is found among the ConstraintValidators listed by the constraint A, an UnexpectedTypeException is raised.

A ConstraintValidator<A, U> compliant with T is considered strictly more specific than a ConstraintValidator<A, V> compliant with T if U is a strict subtype of V. U is a strict subtype of V if U is a subtype of V and U != V (according to the Java Language Specification).

If more than one maximally specific ConstraintValidator is found, an UnexpectedTypeException is raised.

Via the Java service loader mechanism; for this the file META-INF/services/javax.validation.valueextraction.ValueExtractor must be provided

By specifying the fully-qualified class name of one or several extractors in META-INF/validation.xml

By invoking the method Configuration#addValueExtractor(ValueExtractor<?>) (to apply it at the validator factory level).

By invoking the method ValidatorContext#addValueExtractor(ValueExtractor<?>) (to apply it for a single Validator instance).

A value extractor for a given type and type parameter specified at a higher priority overrides any other extractors for the same type and type parameter given at lower priorities.

A ValueExtractor<T> is said to be type-compliant with C, if C is a subtype of T (according to the Java Language Specification, Java SE 8 Edition, chapter 4.10, "Subtyping"). Note that C is a subtype of T if C = T.

A ValueExtractor implementation is said to be container-element-compliant with C, if C is a generic container type and the value extractor implementation handles a type parameter that maps to the constrained type argument.

If no ValueExtractor type-compliant and container-element-compliant with C is found among the available value extractors, a ConstraintDeclarationException is raised.

A ValueExtractor<U> type-compliant with C is considered strictly more specific than a ValueExtractor<V> compliant with C if U is a strict subtype of V.

If more than one maximally specific and container-element-compliant ValueExtractor is found, a ConstraintDeclarationException is raised.

A ValueExtractor<T> is said to be type-compliant with C', if C' is a subtype of T.

A ValueExtractor implementation is said to be container-element-compliant with C, if it handles a type parameter that maps to the type argument marked with @Valid.

If no ValueExtractor type-compliant with C' and container-element-compliant with C is found among the available value extractors, a ConstraintDeclarationException is raised.

A ValueExtractor<U> type-compliant with C' is considered strictly more specific than a ValueExtractor<V> compliant with C' if U is a strict subtype of V.

A ValueExtractor<U> type-compliant with C' is considered maximally specific if no other ValueExtractor<V> type-compliant with C' is strictly more specific than ValueExtractor<U>.

If more than one maximally specific and container-element-compliant ValueExtractor is found, a ConstraintDeclarationException is raised.

If the constraint carries the Unwrapping.Skip payload, no value extractor is applied.

If the constraint carries the Unwrapping.Unwrap payload and there is exactly one maximally-specific type-compliant value extractor, this extractor is applied;

If no type-compliant extractor or multiple maximally-specific type-compliant extractors exist, a ConstraintDeclarationException is raised.

If there is exactly one maximally-specific type-compliant value extractor and this extractor is marked with @UnwrapByDefault, this extractor is applied;

Otherwise, no value extractor is applied.

<T> Set<ConstraintViolation<T>> validate(T object, Class<?>... groups) is used to validate a given object.

An IllegalArgumentException is thrown when null is passed for the object parameter or the varargs groups parameter.

A Set containing all ConstraintViolation objects representing the failing constraints is returned, an empty Set is returned otherwise.

<T> Set<ConstraintViolation<T>> validateProperty(T object, String propertyName, Class<?>... groups) validates a given field or property of an object.

An IllegalArgumentException is thrown when validateProperty() is called and object is null or propertyName is null, empty or invalid or null is passed to the varargs groups parameter.

The property name is the JavaBeans property name (as defined by the JavaBeans Introspector class).

@Valid is not honored by this method.

<T> Set<ConstraintViolation<T>> validateValue(Class<T> beanType, String propertyName, Object value, Class<?>... groups) validates the property referenced by propertyName present on beanType or any of its superclasses, if the property value were value.

An IllegalArgumentException is thrown when validateValue() is called and beanType is null or propertyName is null, empty or invalid or null is passed to the varargs groups parameter.

@Valid is not honored by this method.

If some unrecoverable failure happens during validation, a ValidationException is raised.

<T> Set<ConstraintViolation<T>> validateParameters(T object, Method method, Object[] parameterValues, Class<?>... groups) validates the arguments (as given in parameterValues) for the parameters of a given method (identified by method). Cross-parameter constraints are also validated.

A set containing all ConstraintViolation objects representing the failing constraints is returned, an empty set is returned if no constraint violations occurred.

An IllegalArgumentException will be thrown if null is passed for any of the parameters or if the parameters don't match with each other (i.e. object and method don't match, parameterValues and method don't match).

<T> Set<ConstraintViolation<T>> validateReturnValue(T object, Method method, Object returnValue, Class<?>... groups) validates the return value (specified by returnValue) of a given method (identified by method).

A set containing all ConstraintViolation objects representing the failing constraints is returned, an empty set is returned if no constraint violations occurred.

An IllegalArgumentException will be thrown if null is passed for any of the parameters object, method and groups or if the parameters don't match with each other (i.e. object and method don't match, returnValue and method don't match).

<T> Set<ConstraintViolation<T>> validateConstructorParameters(Constructor<T> constructor, Object[] parameterValues, Class<?>... groups) validates the arguments (as given in parameterValues) for the parameters of a given constructor (identified by constructor). Cross-parameter constraints are also validated.

A set containing all ConstraintViolation objects representing the failing constraints is returned, an empty set is returned if no constraint violations occurred.

An IllegalArgumentException will be thrown if null is passed for any of the parameters or if the parameters don't match with each other (i.e. parameterValues and constructor don't match).

<T> Set<ConstraintViolation<T>> validateConstructorReturnValue(Constructor<T> constructor, T createdObject, Class<?>... groups) validates the object (specified by createdObject) of a given constructor (identified by constructor).

A set containing all ConstraintViolation objects representing the failing constraints is returned, an empty set is returned if no constraint violations occurred.

An IllegalArgumentException will be thrown if null is passed for any of the parameters or if the parameters don't match with each other (i.e. createdObject and constructor don't match).

None of those methods honor the XML configuration around executable validation nor the presence of @ValidateOnExecution. In other words, elements will be validated regardless of these settings when explicitly calling the validation methods.

All constraints belonging to the targeted group(s) are applied during the 5.7.

If no group is passed, the Default group is assumed.

The getMessage() method returns the interpolated (localized) message for the failing constraint

The getMessageTemplate() method returns the non-interpolated error message

The getRootBean() method returns the root object being validated that led to the failing constraint

For method validation, returns the object the method is executed on. For constructors or when Validator.validateValue() is used, returns null.

The getRootBeanClass() method returns the class of the root bean being validated. For method validation, this is the object class the method is executed on. For constructor validation, this is the class the constructor is declared on.

The getLeafBean() method returns the following object: If a bean constraint, the bean instance the constraint is applied on. If a property constraint, the bean instance hosting the property the constraint is applied on. If a property constraint, null when the ConstraintViolation is returned after calling Validator.validateValue(). If a method parameter, cross-parameter or return value constraint, the object the method is executed on. If a constructor parameter or cross-parameter constraint, null. If a constructor return value constraint, the object the constructor has created.

The getExecutableParameters() returns the parameters provided to the method or constructor invocation or null if not validating a method or constructor parameters.

The getExecutableReturnValue() returns the return value of the method or constructor invocation or null if the method has no return value or if not validating a method or constructor return value.

The getInvalidValue() method returns the value (field, property, method/constructor parameter, method/constructor return value, container element or validated object) being passed to isValid().

For a cross-parameter constraint failure, an Object[] representing the method/constructor invocation arguments is returned.

In case a constraint given on a container is subject to implicit application to the container element(s) (see 5.5.1), getInvalidValue() returns the invalid container element value.

getConstraintDescriptor() provides access to the failing constraint metadata

The getPropertyPath() method returns the Path object representing the navigation path from the root object to the failing object.

getName() returns the name of the element which the node represents

isInIterable() returns true if the node represents an object contained in an array or in a multi-valued container such as Iterable or Map, false otherwise.

getIndex() returns the index of the node if it is contained in an array, List or any other container supporting indexed access. Returns null otherwise.

getKey() returns the key of the node if it is contained in a Map or any other container supporting keyed access. Returns null otherwise.

getKind() returns the ElementKind corresponding to the actual node type. This can be used in conjunction with the method as() to narrow the type and access node specific methods

as(Class<? extends Node>) returns the node instance narrowed to the type passed as a parameter or throws a ClassCastException if the type and node don't match.

In particular, MethodNode and ConstructorNode host getParameterTypes() which return the method or constructor parameter list.

Likewise ParameterNode hosts getParameterIndex() which returns the parameter index in the method or constructor parameter list.

BeanNode, PropertyNode and ContainerElementNode host getContainerClass() and getTypeArgumentIndex(). If the node represents an element that is contained in a container such as Optional, List or Map, the former returns the declared type of the container and, if the container is of a generic type, the latter returns the index of the affected type argument.

The runtime type is considered, not the static type. For example if a property is declared Collection<String> but its runtime type is ArrayList<String>, the property is considered an ArrayList<String>.

If the failing object is the root object, a BeanNode with name set to null is added to the Path. The ElementKind of the node is ElementKind.BEAN.

A PropertyNode object whose name equals the name of the association property (field name or Java Bean property name) is added to Path. The ElementKind of the node is ElementKind.PROPERTY.

If the association is an array, a List or any other container whose value extractor invokes ValueReceiver#indexedValue() (see 4), the following Node object added contains the index value in getIndex()

If the association is a Map or any other container whose value extractor invokes ValueReceiver#keyedValue(), the following Node object added (representing a given map entry) contains the key value in getKey()

For all Iterable, Map or other container whose value extractor invokes ValueReceiver#indexedValue(), ValueReceiver#keyedValue() or ValueReceiver#iterableValue(), the following Node object added is marked as inIterable (isInIterable())

If the traversed object is of a container type (e.g. a List or Map), the following Node object added returns the declared type of the traversed container via getContainerClass() and the index of the affected type argument via getTypeArgumentIndex()

If the value extractor of the outer container has provided a non-null node name, a ContainerElementNode object whose name equals that name is added to Path. The ElementKind of the node is ElementKind.CONTAINER_ELEMENT

If the container is a List or any other container whose value extractor invokes ValueReceiver#indexedValue(), the following Node object added contains the index value in getIndex()

If the container is a Map or any other container whose value extractor invokes ValueReceiver#keyedValue(), the following Node object added (representing a given map entry) contains the key value in getKey()

For all Iterable, Map or other container whose value extractor invokes ValueReceiver#indexedValue(), ValueReceiver#keyedValue() or ValueReceiver#iterableValue(), the following Node object added is marked as inIterable (isInIterable())

The following Node object added returns the declared type of the traversed container via getContainerClass() and the index of the affected type argument via getTypeArgumentIndex()

For a property level constraint (field and getter) a PropertyNode object is added to Path whose name equals the name of the property (field name or Java Bean property name). The ElementKind of the node is ElementKind.PROPERTY. the property path is considered complete

For a class level constraint: a BeanNode object is added to Path whose name is null. The ElementKind of the node is ElementKind.BEAN. the property path is considered complete

A MethodNode respectively a ConstructorNode object is added to the Path which represents the validated method respectively constructor. The name of the node equals the validated method name or the validated constructor's unqualified class name, the ElementKind of the node is ElementKind.METHOD respectively ElementKind.CONSTRUCTOR.

If the constraint is on a parameter, a ParameterNode object is added to the Path which represents the validated parameter. The name of the node equals the parameter name as determined by the current parameter name provider (see 5.6.2.2). The ElementKind of the node is ElementKind.PARAMETER.

If the constraint is a cross-parameter constraint, a CrossParameterNode object is added to the Path which represents the validated cross-parameter element. The name of the node has the constant value <cross-parameter>. The ElementKind of the node is ElementKind.CROSS_PARAMETER.

If the constraint is on the return value, a ReturnValueNode object is added to the Path which represents the validated return value. The name of the node has the constant value <return value>. The ElementKind of the node is ElementKind.RETURN_VALUE.

The property path is considered complete

A MethodNode respectively ConstructorNode object is added to the Path which represents the concerned method respectively constructor. The name of the node equals the concerned method name or the constructor's unqualified class name, the ElementKind of the node is ElementKind.METHOD or ElementKind.CONSTRUCTOR, respectively.

If a parameter is traversed, a ParameterNode object is added to the Path which represents the traversed parameter. The name of the node equals the parameter name as determined by the current parameter name provider. The ElementKind of the node is ElementKind.PARAMETER.

If a return value is traversed, a ReturnValueNode object is added to the Path which represents the traversed return value. The name of the node has the constant value <return value>. The ElementKind of the node is ElementKind.RETURN_VALUE.

If the parameter/return value is a List or an array, the following Node object added contains the index value in getIndex().

If the parameter/return value is a Map, the following Node object added (representing a given map entry) contains the key value in getKey().

For all Iterable or Map, the following Node object added is marked as inIterable (isInIterable()).

For a container element constraint: if the corresponding value extractor (see 4) has specified a node name when calling one of the receiver methods, a ContainerElementNode object with that name is added to the Path. The ElementKind of the node is ElementKind.CONTAINER_ELEMENT. getContainerClass() returns the declared type of the container hosting the constraint. getTypeArgumentIndex() returns the index of the type argument hosting the constraint. If the constraint is given on a container and is subject to implicit application to the container's element(s) (see 5.5.1) and the applied value extractor is not tied to a type parameter, getTypeArgumentIndex() returns null. if the corresponding value extractor has passed no node name to the called receiver method, no node is appended. the property path is considered complete

If additional path nodes are added in a constraint validator implementation using the node builder API (see 3.4), the following rules apply: if the default path ends with a BeanNode, this node is removed and the first added node (a PropertyNode) inherits its inIterable, key and index values. inIterable, key and index value must not be specified directly on this first node by the user. if the default path ends with a CrossParameterNode, this node is removed. then the additional nodes are appended to the (possibly amended) path generated by the Bean Validation engine as previously described

A PropertyNode is appended in case addPropertyNode(String) is invoked. The node name is equal to the name provided. The ElementKind of the node is ElementKind.PROPERTY.

A BeanNode is appended in case addBeanNode() is invoked. The node name is null. The ElementKind of the node is ElementKind.BEAN.

A ParameterNode is appended in case addParameterNode(int) is invoked. The node name is equal to the parameter name at the provided index. The name is determined by the current parameter name provider. The ElementKind of the node is ElementKind.PARAMETER. The previous node (removed) must be a CrossParameterNode.

A ContainerElementNode is appended in case addContainerElementNode(String, Class, Integer) is invoked. The name, container type and type argument index of the node are equal to the values provided. The ElementKind of the node is ElementKind.CONTAINER_ELEMENT.

If inIterable() is invoked, the node returns true for isInIterable(), false otherwise.

If inContainer(Class, Integer) is invoked, the node returns the passed container type and type argument index from getContainerClass() and getTypeArgumentIndex(), respectively.

If atIndex(Integer) is invoked, the node returns the provided integer for getIndex(), null otherwise.

If atKey(Object) is invoked, the node returns the provided object for getKey(), null otherwise.

Every conforming Bean Validation implementation includes a default message interpolator which has to comply with the algorithm defined here to interpolate message descriptors.

Each constraint defines a message descriptor via its message property.

Every constraint definition defines a default message descriptor for that constraint.

Messages can be overridden at constraint declaration time by setting the message property on the constraint.

The message descriptor is a string literal and may contain one or more message parameters or expressions. Message parameters and expressions are string literals enclosed in {} or ${} respectively.

\{ is considered as the literal { instead of being considered as the beginning of a message parameter

\} is considered as the literal } instead of being considered as the end of a message parameter

\\ is considered as the literal \ instead of being considered as the escaping character

\$ is considered as the literal $ instead of being considered as the beginning of a message expression

Message parameters are extracted from the message string and used as keys to search the ResourceBundle named ValidationMessages

Step 1 is applied recursively until no replacement is performed

Message parameters are extracted from the message string and used as keys to search the Bean Validation provider's built-in ResourceBundle using the defined locale (see 6.3.1.2). If a property is found, the message parameter is replaced with the property value in the message string.

Message parameters are extracted from the message string. Those matching the name of an attribute of the constraint are replaced by the value of that attribute in the constraint declaration. Parameter interpolation has precedence over message expressions. For example for the message descriptor ${value}, trying to evaluate {value} as message parameter has precedence over evaluating ${value} as message expression.

Message expressions are extracted from the message string and evaluated using Expression Language. See also 6.3.1.3.

If the locale is passed explicitly to the interpolator method via interpolate(String, Context, Locale), this provided instance is used.

Otherwise, the default Locale as provided by Locale.getDefault() is used.

The default message interpolation allows the use of Expression Language (EL) as defined in JSR 341.

Expressions to be evaluated by EL need to be enclosed in ${} within the message descriptor

The attribute values of the constraint declaration mapped to their attribute name

The validated value mapped under the name validatedValue.

A bean mapped to the name formatter exposing the vararg method format(String format, Object... args). This method must behave like java.util.Formatter.format(String format, Object... args). The locale used for formatting is defined by 6.3.1.2. The formatter bean allows to format property values, for example in the case of the validated value being 98.12345678, ${formatter.format('%1$.2f', validatedValue)} would format it to 98.12 (two digits after the decimal point, where the use of '.' vs ',' would be locale specific).

If an exception occurs during message interpolation, e.g. due to invalid expressions or references to an unknown property, the message expression stays unchanged.

messageTemplate is the value of the message attribute of the constraint declaration or provided to the ConstraintValidatorContext methods.

getConstraintDescriptor() returns the ConstraintDescriptor object representing the metadata of the failing constraint (see 7).

getValidatedValue() returns the value being validated.

It is possible to override the MessageInterpolator implementation for a given Validator instance by invoking ValidatorFactory.usingContext().messageInterpolator(messageInterpolator).getValidator().

The default implementation is accessible through Configuration.getDefaultMessageInterpolator().

If the interpolation process leads to an exception, the exception is wrapped into a ValidationException.

The validation of method / constructor constraints comprises the following steps: Intercept the method call to be validated Validate the parameter values provided by the method caller using ExecutableValidator.validateParameters() or ExecutableValidator.validateConstructorParameters(). If this validation yields a non-empty set of constraint violations, throw a ConstraintViolationException wrapping the violations. Otherwise proceed with the actual method invocation. Validate the result returned by the invoked method using ExecutableValidator.validateReturnValue() or ExecutableValidator.validateConstructorReturnValue(). If this validation yields a non-empty set of constraint violations, throw a ConstraintViolationException wrapping the violations. Otherwise return the invocation result to the method caller.

The Default group is used for validation out of the box.

A bootstrap implementation must be able to bootstrap any Bean Validation provider implementation.

getMessageInterpolator() returns the MessageInterpolator instance configured during the initialization of the ValidatorFactory.

getTraversableResolver() returns the TraversableResolver instance configured during the initialization of the ValidatorFactory.

getConstraintValidatorFactory() returns the ConstraintValidatorFactory instance configured during the initialization of the ValidatorFactory.

getParameterNameProvider() returns the ParameterNameProvider instance configured during the initialization of the ValidatorFactory.

getClockProvider() returns the ClockProvider instance configured during the initialization of the ValidatorFactory.

The MessageInterpolator, the TraversableResolver, the ConstraintValidatorFactory, the ParameterNameProvider or the ClockProvider passed to the ValidatorContext are used instead of the ValidatorFactory's MessageInterpolator, TraversableResolver, ConstraintValidatorFactory, ParameterNameProvider or ClockProvider instances.

A ValueExtractorDeclarationException is raised if more than one extractor for the same type and type parameter is added via addValueExtractor().

Configuration does provide a MessageInterpolator implementation following the default Bean Validation MessageInterpolator rules as defined in 6.3.1. You can access it by calling getDefaultMessageInterpolator().

Configuration does provide a TraversableResolver implementation following the default Bean Validation TraversableResolver rules as defined in 5.7.3. You can access it by calling getDefaultTraversableResolver().

Configuration does provide a ConstraintValidatorFactory implementation following the default Bean Validation ConstraintValidatorFactory rules as defined in 3.5. You can access it by calling getDefaultConstraintValidatorFactory().

Configuration does provide a ParameterNameProvider implementation following the default Bean Validation ParameterNameProvider rules as defined in 5.6.2.2. You can access it by calling getDefaultParameterNameProvider().

Configuration does provide a ClockProvider implementation following the default Bean Validation ClockProvider rules as defined in 3.4.1. You can access it by calling getDefaultClockProvider().

Via getBootstrapConfiguration(), Configuration also exposes data stored in META-INF/validation.xml

Via addValueExtractor(), additional value extractor implementations can be added to the configuration. A value extractor for a given type and type parameter takes precedence over any extractor for the same type and type parameter detected through the service loader or given in the XML configuration.

A ValueExtractorDeclarationException is raised if more than one extractor for the same type and type parameter is added.

Using addMapping(), additional constraint mapping XML descriptors can be added to the configuration

Streams not supporting the mark() and reset() methods will be wrapped with an InputStream implementation supporting these methods by the Bean Validation provider in order to allow the streams to be read several times.

It is legal to invoke buildValidatorFactory() several times, e.g. in order to retrieve several ValidatorFactory instances with a slightly different configuration (see ).

A Bean Validation provider must define a sub interface of Configuration uniquely identifying the provider.

The requested provider implementation is resolved according to the following rules in the following order: Use the provider implementation requested if Configuration has been created from Validation.byProvider(Class). Use the provider implementation described in the XML configuration (under validation-config.default-provider see 6.5.6) if defined: the value of this element is the fully qualified class name of the ValidationProvider implementation uniquely identifying the provider. Use the first provider implementation returned by validationProviderResolver.getValidationProviders().

ValidationProviderResolver returns the list of Bean Validation providers available at runtime and more specifically a ValidationProvider instance for each provider available in the context.

A client can request a specific Bean Validation provider by using <T extends Configuration<T>, U extends ValidationProvider<T>> Validation.byProvider(Class<U>) or by defining the provider in the XML configuration file.

The provider discovery mechanism uses the following algorithm: Retrieve available providers using ValidationProviderResolver.getValidationProviders(). The first ValidationProvider matching the requested provider is returned. Providers are evaluated in the order they are returned by ValidationProviderResolver. A provider instance is considered matching if it is assignable to the requested provider class.

When the default Bean Validation provider is requested, the first ValidationProvider returned by the ValidationProviderResolver strategy is returned.

Every Bean Validation provider must provide a ValidationProvider implementation containing a public no-arg constructor

If a problem occurs while building the ValidatorFactory, a ValidationException is raised.

The first entry point, buildDefaultValidatorFactory(), is considered to be the default ValidatorFactory and is equivalent to the ValidatorFactory returned by Validation.byDefaultProvider().configure().buildValidatorFactory().

The second entry point lets the client provide a custom ValidationProviderResolver instance. This instance is passed to GenericBootstrap. GenericBootstrap builds a generic Configuration using the first ValidationProvider returned by ValidationProviderResolution and calling ValidationProvider.createGenericConfiguration(BootstrapState state).

The last entry point lets the client define the specific Bean Validation provider requested as well as a custom ValidationProviderResolver implementation if needed. The entry point method, Validation.byProvider(Class<U> providerType), takes the provider specific ValidationProvider implementation type and returns a ProviderSpecificBootstrap object that guarantees to return an instance of the specific Configuration sub interface.

The Validation implementation must not contain any non private attribute or method aside from the three public static bootstrap methods

The bootstrap implementation must ensure it can bootstrap third party providers.

When bootstrapping a Bean Validation provider, if the ValidationProviderResolver either fails or if the expected provider is not found, a ValidationException is raised.

Unless explicitly ignored by calling Configuration.ignoreXMLConfiguration(), a Configuration takes into account the configuration available in META-INF/validation.xml.