Chapter | Assertions | Testable | Total Tested | Total Tests | Tested (problematic) |
Tested (working) |
Coverage % |
---|---|---|---|---|---|---|---|
1 Introduction | 0 | 0 | 0 | 0 | 0 | 0 | |
2 What's new in 1.1 | 0 | 0 | 0 | 0 | 0 | 0 | |
3 Constraint Definition | 66 | 58 | 45 | 71 | 0 | 45 | 77.59% |
4 Constraint declaration and validation process | 100 | 89 | 86 | 203 | 0 | 86 | 96.63% |
5 Validation APIs | 141 | 125 | 104 | 346 | 0 | 104 | 83.20% |
6 Constraint metadata request APIs | 46 | 46 | 42 | 177 | 0 | 42 | 91.30% |
7 Built-in Constraint definitions | 15 | 15 | 15 | 0 | 0 | 15 | 100.00% |
8 XML deployment descriptor | 85 | 85 | 45 | 74 | 0 | 45 | 52.94% |
9 Exception model | 5 | 4 | 4 | 12 | 0 | 4 | 100.00% |
10 Integration | 13 | 11 | 0 | 0 | 0 | 0 | 0.00% |
Total | 471 | 433 | 341 | 883 | 0 | 341 | 78.75% |
Colour Key |
---|
Assertion is covered |
Assertion is not covered |
Assertion test is unimplemented |
Assertion is untestable |
An annotation is considered a constraint definition if its retention policy contains RUNTIME and if the annotation itself is annotated with javax.validation.Constraint
Generic constraint annotations can target any of the following ElementTypes: FIELD for constrained attributes METHOD for constrained getters and constrained method return values CONSTRUCTOR for constrained constructor return values PARAMETER for constrained method and constructor parameters TYPE for constrained beans ANNOTATION_TYPE for constraints composing other constraints
Cross-parameter constraint annotations can target any of the following ElementTypes: METHOD CONSTRUCTOR ANNOTATION_TYPE for cross-parameter constraints composing other cross-parameter constraints
A constraint annotation that is both can target the union of the generic and cross-parameter constraint annotations targets.
Coverage
No tests exist for this assertion
Applying a constraint annotation to an incompatible type will raise an UnexpectedTypeException.
Coverage
At most one ConstraintValidator supporting cross-parameter validation must be present for a given constraint. A UnexpectedTypeException is raised otherwise.
Coverage
No tests exist for this assertion
If a constraint definition is not valid, a ConstraintDefinitionException is raised either at validation time or when the metadata is requested.
Coverage
A constraint definition may have attributes that are specified at the time the constraint is applied to a JavaBean.
Coverage
Annotation elements starting with valid are not allowed
Coverage
Every constraint annotation must define a message element of type String.
Coverage
Every constraint annotation must define a groups element that specifies the processing groups with which the constraint declaration is associated.
Coverage
The type of the groups parameter is Class<?>[].
Coverage
The default value must be an empty array.
Coverage
If no group is specified when declaring the constraint on an element, the Default group is considered declared.
Coverage
Constraint annotations must define a payload element that specifies the payload with which the the constraint declaration is associated.
Coverage
The default value must be an empty array.
Coverage
Each attachable payload extends Payload.
Coverage
If a ConstraintTarget is used in an illegal situation, a ConstraintDeclarationException is raised either at validation time or when the metadata is requested.
Coverage
No tests exist for this assertion
Using IMPLICIT in a situation that cannot be inferred (see the JavaDoc for the detailed rules),
Coverage
No tests exist for this assertion
Using PARAMETERS on a constructor or method that has no parameter,
Coverage
No tests exist for this assertion
Using RETURN_VALUE on a method with no return value,
Coverage
No tests exist for this assertion
Using PARAMETERS or RETURN_VALUE on a type - class or interface - or on a field.
Coverage
No tests exist for this assertion
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.
Coverage
More formally, each constraint annotation hosted on a constraint annotation is applied to the target element and this is done recursively.
Coverage
Note that the main annotation and its constraint validation implementation is also applied.
Coverage
By default, each failing constraint generates an error report.
Coverage
Groups from the main constraint annotation are inherited by the composing annotations.
Coverage
Any groups definition on a composing annotation is ignored.
Coverage
Payload from the main constraint annotation is inherited by the composing annotations.
Coverage
No tests exist for this assertion
Any payload definition on a composing annotation is ignored.
Coverage
The constraint target from the main constraint annotation is inherited by the composing annotations.
Coverage
No tests exist for this assertion
Any validationAppliesTo definition on a composing annotation is ignored.
Coverage
No tests exist for this assertion
The type upon which composed constraint is placed must be compatible with all constraints (composing and composed).
Coverage
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.
Coverage
Composing annotations can define the value of message and custom attributes (excluding groups and payload) but these are fixed in the composed constraint definition.
Coverage
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 the @OverridesAttribute annotation or its multivalued equivalent @OverridesAttribute.List.
Coverage
The types of the overridden and overriding attributes must be identical.
Coverage
A composing constraint can itself be a composed constraint. In this case, attribute values are overridden recursively according to the described rules.
Coverage
If a constraint is used more than once as a composing constraint, the multi value constraints model as described in 3.2 is used.
Coverage
To select a specific composing constraint, OverridesAttribute.constraintIndex is used. It represents the constraint index in the value array.
Coverage
If index is undefined, the single constraint declaration is targeted.
Coverage
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.
Coverage
A constraint validation implementation performs the validation of a given constraint annotation for a given type.
Coverage
The implementation classes are specified by the validatedBy element of the @Constraint annotation that decorates the constraint definition.
Coverage
The constraint validation implementation implements the ConstraintValidator interface.
Some restrictions apply on the generic type T (used in the isValid() method). T must resolve to a non parameterized type (i.e. because the type is not using generics or because the raw type is used instead of the generic version) or generic parameters of T must be unbounded wildcard types (i.e. <?>).
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.
Coverage
No tests exist for this assertion
A ConstraintValidator implementation can target both annotated elements and array of parameters.
Coverage
No tests exist for this assertion
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.
Coverage
The initialize() method is called by the Bean validation provider prior to any use of the constraint implementation.
Coverage
The isValid() method is evaluated by the Bean Validation provider each time a given value is validated.
Coverage
It returns false if the value is not valid, true otherwise.
isValid() implementations must be thread-safe.
If the property is of an unanticipated type, an UnexpectedTypeException is raised.
Coverage
If an exception occurs either in the initialize() or isValid() method, the runtime exception is wrapped into a ValidationException by the Bean Validation engine.
Coverage
The constraint validation implementation is not allowed to change the state of the value passed to isValid().
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 or executable return value).
Coverage
The ConstraintValidatorContext methods let the constraint implementation disable the default ConstraintViolation generation and create one or more custom ones.
Coverage
The non-interpolated message passed as a parameter is used to build the ConstraintViolation message (the message interpolation operation is applied to it).
Coverage
By default, the Path exposed on the ConstraintViolation represents the path to the bean, property, parameter, cross-parameter or return value hosting the constraint (see 5.2 for more information).
Coverage
You can point it to a subpath of this default path by using the constraint violation builder fluent API.
Coverage
If disableDefaultConstraintViolation() is called, no custom error is added (using the error builder) and if the constraint is not valid, a ValidationException is raised.
Coverage
Bean Validation providers must release each instance retrieved. The ConstraintValidatorFactory instance that has created a ConstraintValidator instance must be the one that releases it. In other words, passing an instance of ConstraintValidator to a ConstraintValidatorFactory that has not created it is an error.
Coverage
No tests exist for this assertion
The default ConstraintValidatorFactory provided by the Bean Validation provider implementation uses the public no-arg constructor of the ConstraintValidator class.
Coverage
If an exception occurs in the factory while retrieving the ConstraintValidator instance, the runtime exception is wrapped in a ValidationException.
Coverage
If the instance returned by the factory is null, a ValidationException is raised.
Coverage
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.
Coverage
Static fields and static methods are excluded from validation.
Constraints can be applied to interfaces and superclasses.
Coverage
What is a getter? 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
Coverage
No tests exist for this assertion
The target of an annotation definition can be a field, property, type, constructor or method return value, constructor or method parameter or constructor or method cross-parameter 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 4.6.4 to learn about ConstraintValidator resolution).
Coverage
Constraint declarations can be applied to a class or an interface.
Coverage
Constraint declarations can be applied on both fields and properties for the same object type.
Coverage
The same constraint should however not be duplicated between a field and its associated property (the constraint validation would be applied twice).
Coverage
When a field is annotated with a constraint declaration, field access strategy is used to access the state validated by such constraint.
Coverage
When a property is annotated with a constraint declaration, property access strategy is used to access the state validated by such constraint.
Coverage
The fields or methods visibility are not constrained.
Coverage
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.
Coverage
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.
Coverage
Any object implementing java.lang.Iterable is supported.
Coverage
Arrays of objects
Coverage
java.util.Collection
Coverage
java.util.Set
Coverage
java.util.List
Coverage
java.util.Map
Coverage
For Map, the value (retrieved by getValue) of each Map.Entry is validated (the key is not validated).
Coverage
Like regular references, its type is determined at runtime and the constraint definitions for this particular type are used.
Coverage
The @Valid annotation is applied recursively.
Coverage
A constraint declaration can be placed on an interface.
Coverage
For a given class, constraint declarations held on superclasses as well as interfaces are evaluated by the Bean Validation provider.
Coverage
If no group is explicitly declared, a constraint belongs to the Default group.
Coverage
Groups are represented by interfaces.
Coverage
A constraint can belong to one or more groups.
Coverage
During the validation call, one or more groups are validated. All the constraints belonging to this set of group is evaluated on the object graph.
Coverage
A group may inherit one or more groups by using interface inheritance.
Coverage
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.
Coverage
By default, constraints are evaluated in no particular order regardless of which groups they belong to.
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.
Coverage
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.
Coverage
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.
Coverage
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
Coverage
If a group containing such a circularity is evaluated, a GroupDefinitionException is raised.
Coverage
Groups defining a sequence should not directly inherit other groups. In other words, the interface hosting the group sequence should not have any super interface.
Groups defining a sequence should not be used directly in constraint declarations.
To define a group as a sequence, the interface must be annotated with the @GroupSequence annotation.
Coverage
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).
Coverage
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.
Coverage
Constraints hosted on a class A and belonging to the Default group (by default or explicitly) implicitly belong to the group A.
A sequence defined on a class A (i.e. redefining the Default groups for the class) must contain the group A.
Coverage
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.
Coverage
Every constraint hosted on an interface Z and part of the Default group (implicitly or explicitly) belongs to the group Z.
Coverage
@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.
Coverage
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.
Coverage
Rules are not executed recursively.
Coverage
It is not legal to have more than one conversion rule containing the same from value. In this case, a ConstraintDeclarationException is raised.
Coverage
Like regular constraint declarations, the from attribute cannot refer to a group sequence. A ConstraintDeclarationException is raised in this situation.
Coverage
The to attribute can. The group sequence will then be expanded before validating the associated object.
Coverage
@ConvertGroup and @ConvertGroup.List can only be placed where @Valid is present to ensure proper respect of the Liskov substitution principle
Coverage
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.
Coverage
If any of these rules is violated, a ConstraintDeclarationException is raised by default as defined in 4.5.5.
Coverage
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
Coverage
If X does have a @GroupSequence annotation, the group Default contains every constraint belonging to every group declared by the @GroupSequence annotation.
Coverage
Static methods are ignored by validation. Putting constraints on a static method is not portable.
Parameter constraints are declared by putting constraint annotations on method or constructor parameters.
Coverage
Cross-parameter constraints are declared by putting cross-parameter constraint annotations on methods or constructors
Coverage
Cross-parameter constraints are validated at the same time as parameter constraints.
Coverage
A conforming Bean Validation implementation provides a default ParameterNameProvider implementation which returns parameter names in the form argPARAMETERINDEX, where PARAMETERINDEX starts at 0 for the first parameter, e.g. arg0, arg1 etc.
Coverage
If an exception occurs during invocation of the getParameterNames() methods, this exception is wrapped into a ValidationException by the Bean Validation engine.
Coverage
Return value constraints are declared by putting constraint annotations directly on a method or constructor.
Coverage
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.
Coverage
Null arguments and null return values are ignored
Coverage
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
Coverage
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.
Coverage
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.
Coverage
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.
Coverage
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.
Coverage
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.
Coverage
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
Unless ordered by group sequences, groups can be validated in no particular order.
A test exists for this untestable assertion!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).
Coverage
This mechanism is recursive: an associated object can itself contain cascaded references.
Coverage
Null references are ignored.
Coverage
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).
Coverage
@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.
Coverage
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
Coverage
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
Coverage
Unless ordered by group sequences, groups can be validated in no particular order.
Coverage
isReachable() is called for every property about to be accessed either for validation or for cascading.
Coverage
isCascadable() is called for every property about to be cascaded (i.e. marked as @Valid).
Coverage
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.
Coverage
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.
Coverage
If an exception occurs when the TraversableResolver is called, the exception is wrapped into a ValidationException.
Coverage
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
Coverage
But the properties of these elements (if validated) are. In this case the complete path is provided via pathToTraversableObject.
Coverage
If Java Persistence is available in the runtime environment, a property is considered reachable if Java Persistence considers the property as loaded.
If Java Persistence is not available in the runtime environment, all properties are considered reachable.
All properties are considered cascadable.
If the constraint is a generic constraint, the following rules apply. If the constraint declaration is hosted on a class or an interface, the targeted type is the class or the interface.
Coverage
If the constraint is hosted on a class attribute, the type of the attribute is the targeted type.
Coverage
If the constraint is hosted on a getter, the return type of the getter is the targeted type.
Coverage
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.
Coverage
Only ConstraintValidator implementations targeting annotated elements are considered.
Coverage
No tests exist for this assertion
Primitive types are considered equivalent to their respective primitive wrapper class. Likewise, arrays of primitive types are considered equivalent to arrays of their wrapper classes.
Coverage
No tests exist for this assertion
If no ConstraintValidator compliant with T is found amongst the ConstraintValidators listed by the constraint A, an UnexpectedTypeException is raised.
Coverage
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 3rd edition chapter 4.10 Subtyping).
Coverage
No tests exist for this assertion
If more than one maximally specific ConstraintValidator is found, an UnexpectedTypeException is raised.
Coverage
Validator implementations are thread-safe.
<T> Set<ConstraintViolation<T>> validate(T object, Class<?>... groups) is used to validate a given object.
Coverage
An IllegalArgumentException is thrown when null is passed for the object parameter or the varargs groups parameter.
Coverage
A Set containing all ConstraintViolation objects representing the failing constraints is returned, an empty Set is returned otherwise.
Coverage
<T> Set<ConstraintViolation<T>> validateProperty(T object, String propertyName, Class<?>... groups) validates a given field or property of an object.
Coverage
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.
Coverage
The property name is the JavaBeans property name (as defined by the JavaBeans Introspector class).
Coverage
@Valid is not honored by this method.
Coverage
<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.
Coverage
An IllegalArgumentException is thrown when validateValue() is called and object is null or propertyName is null empty or invalid or null is passed to the varargs groups parameter.
Coverage
@Valid is not honored by this method.
Coverage
If some unrecoverable failure happens during validation, a ValidationException is raised.
Coverage
<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).
Coverage
A set containing all ConstraintViolation objects representing the failing constraints is returned, an empty set is returned if no constraint violation occurred.
Coverage
An IllegalArgumentException will be thrown if null is passed for any of the parameters.
Coverage
<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).
Coverage
A set containing all ConstraintViolation objects representing the failing constraints is returned, an empty set is returned if no constraint violation occurred.
Coverage
An IllegalArgumentException will be thrown if null is passed for any of the parameters object, method and groups.
Coverage
<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).
Coverage
A set containing all ConstraintViolation objects representing the failing constraints is returned, an empty set is returned if no constraint violation occurred.
Coverage
An IllegalArgumentException will be thrown if null is passed for any of the parameters.
Coverage
<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).
Coverage
A set containing all ConstraintViolation objects representing the failing constraints is returned, an empty set is returned if no constraint violation occurred.
Coverage
An IllegalArgumentException will be thrown if null is passed for any of the parameters.
Coverage
None of those methods honor the XML configuration <validated-executables/> nor the presence of @ValidateExecutable. In other words, elements will be validated regardless of these settings when explicitly calling the validation methods.
Coverage
All constraints belonging to the targeted group are applied during the 4.6.
Coverage
If no group is passed, the Default group is assumed.
Coverage
When more than one group is evaluated and passed to the various validate methods, order is not constrained.
The getMessage() method returns the interpolated (localized) message for the failing constraint
Coverage
The getMessageTemplate() method returns the non-interpolated error message
Coverage
The getRootBean() method returns the root object being validated that led to the failing constraint
Coverage
For method validation, returns the object the method is executed on. For constructors or when Validator.validateValue() is used, returns null.
Coverage
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.
Coverage
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 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.
Coverage
No tests exist for this assertion
The getExecutableParameters() returns the parameters provided to the method or constructor invocation or null if not validating the method or constructor parameters.
Coverage
No tests exist for this assertion
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 the method or constructor return value.
Coverage
No tests exist for this assertion
The getInvalidValue() method returns the value (field, property, method/constructor parameter, method/constructor return value or validated object) being passed to isValid().
Coverage
For a cross-parameter constraint failure, an Object[] representing the method/constructor invocation arguments is returned.
Coverage
getConstraintDescriptor() provides access to the failing constraint metadata
Coverage
The getPropertyPath() method returns the Path object representing the navigation path from the root object to the failing object.
Coverage
getName() returns the name of the element which the node represents: null if it is a leaf node which represents an entity / bean. In particular, the node representing the root object. The property name for a property. The method name for a method. The unqualified name of the type declaring the constructor for a constructor. The parameter named as defined by the ParameterNameProvider (see 4.5.2.2) for a method or constructor parameter. The literal <cross-parameter> for a method or constructor cross-parameter. The literal <return value> for a method or constructor return value.
Coverage
No tests exist for this assertion
isInIterable() returns true if the node represents an object contained in an Iterable or in a Map, false otherwise.
Coverage
No tests exist for this assertion
getIndex() returns the index of the node if it is contained in an array or List. Returns null otherwise.
Coverage
No tests exist for this assertion
getKey() returns the key of the node if it is contained in a Map. Returns null otherwise.
Coverage
No tests exist for this assertion
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
Coverage
No tests exist for this assertion
as(Class<? extends Node>) returns the node instance narrowed to the type passed as a parameter.
Coverage
No tests exist for this assertion
In particular, MethodNode and ConstructorNode host getParameterTypes() which return the method or constructor parameter list.
Coverage
No tests exist for this assertion
Likewise ParameterNode hosts getParameterIndex() which returns the parameter index in the method or constructor parameter list.
Coverage
No tests exist for this assertion
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>.
Coverage
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.
Coverage
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.
Coverage
If the association is a List or an array, the following Node object added contains the index value in getIndex().
Coverage
If the association is a Map, the following Node object added (representing a given map entry) contains the key value in getKey()
Coverage
For all Iterable or Map, the following Node object added is marked as inIterable (isInIterable())
Coverage
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 is ElementKind.PROPERTY. the property path is considered complete
Coverage
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
Coverage
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.
Coverage
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 4.5.2.2). The ElementKind of the node is elementKind.PARAMETER.
Coverage
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.
Coverage
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.
Coverage
The property path is considered complete
Coverage
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.
Coverage
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.
Coverage
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.
Coverage
If the parameter/return value is a List or an array, the following Node object added contains the index value in getIndex().
Coverage
If the parameter/return value is a Map, the following Node object added (representing a given map entry) contains the key value in getKey().
Coverage
For all Iterable or Map, the following Node object added is marked as inIterable (isInIterable()).
Coverage
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. if inIterable() is invoked, the node returns true for isInIterable(), false otherwise. 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.
Coverage
No tests exist for this assertion
Bean Validation implementations should ensure that a ConstraintViolation implementation is Serializable provided that the root bean, the leaf bean, the invalid value and keys in the Path object are Serializable objects.
Every conforming Bean Validation implementation includes a default message interpolator which has to comply with
Coverage
Each constraint defines a message descriptor via its message property.
Coverage
Every constraint definition defines a default message descriptor for that constraint.
Coverage
Messages can be overridden at constraint declaration time by setting the message property on the constraint.
Coverage
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.
Coverage
\{ is considered as the literal { instead of being considered as the beginning of a message parameter
Coverage
\} is considered as the literal } instead of being considered as the end of a message parameter
Coverage
\\ is considered as the literal \ instead of being considered as the escaping character
Coverage
\$ is considered as the literal $ instead of being considered as the beginning of a message expression
Coverage
No tests exist for this assertion
Message parameters are extracted from the message string and used as keys to search the ResourceBundle named ValidationMessages
Coverage
Step 1 is applied recursively until no replacement is performed
Coverage
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 5.3.1.2). If a property is found, the message parameter is replaced with the property value in the message string.
Coverage
Contrary to step 1, step 2 is not processed recursively.
If step 2 triggers a replacement, then step 1 is applied again.
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.
Coverage
Message expressions are extracted from the message string and evaluated using Expression Language. See also .
Coverage
No tests exist for this assertion
If the locale is passed explicitly to the interpolator method via interpolate(String, Context, Locale), this provided instance is used.
Coverage
Otherwise, the default Locale as provided by Locale.getDefault() is used.
Coverage
The default message interpolation allows the use of Expression Language (EL) as defined in JSR 341.
Coverage
No tests exist for this assertion
Expressions to be evaluated by EL need to be enclosed in ${} within the message descriptor
Coverage
No tests exist for this assertion
The attribute values of the constraint declaration mapped to their attribute name
Coverage
No tests exist for this assertion
The validated value mapped under the name validatedValue.
Coverage
No tests exist for this assertion
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 5.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).
Coverage
No tests exist for this assertion
A message interpolator implementation must be thread-safe.
It is possible to override the MessageInterpolator implementation for a given Validator instance by invoking ValidatorFactory.usingContext().messageInterpolator(messageInterpolator).getValidator().
Coverage
A bootstrap implementation must be able to bootstrap any Bean Validation provider implementation.
Coverage
The ValidatorFactory object is thread-safe.
getMessageInterpolator() returns the MessageInterpolator instance configured during the initialization of the ValidatorFactory.
Coverage
getParameterNameProvider() returns the ParameterNameProvider instance configured during the initialization of the ValidatorFactory.
Coverage
The MessageInterpolator, the TraversableResolver, the ConstraintValidatorFactory or the ParameterNameProvider passed to the ValidatorContext are used instead of the ValidatorFactory's MessageInterpolator, TraversableResolver, ConstraintValidatorFactory or ParameterNameProvider instances.
Coverage
Configuration does provide a ParameterNameProvider implementation following the default Bean Validation ParameterNameProvider rules as defined in 4.5.2.2. You can access it by calling getDefaultParameterNameProvider()
Coverage
Via getBootstrapConfiguration(), Configuration also exposes data stored in META-INF/validation.xml
Coverage
Using addMapping(), additional constraint mapping XML descriptors can be added to the configuration
Coverage
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.
Coverage
It is legal to invoke buildValidatorFactory() several times, e.g. in order to retrieval several ValidatorFactory instances with a slightly different configuration (see ).
Coverage
A Bean Validation provider must define a sub interface of Configuration uniquely identifying the provider.
Coverage
Streams represented in the XML configuration and opened by the Configuration implementation must be closed by the Configuration implementation after the ValidatorFactory creation (or if an exception occurs).
If no ValidationProviderResolver instance has been specified, the default ValidationProviderResolver is used.
ValidationProviderResolver returns the list of Bean Validation providers available at runtime and more specifically a ValidationProvider instance for each provider available in the context.
Coverage
Implementations must be thread-safe.
Bean Validation providers must supply a service provider configuration file by creating a text file javax.validation.spi.ValidationProvider and placing it in the META-INF/services directory of one of its jar files.
Coverage
No tests exist for this assertion
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.
Coverage
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.
Coverage
When the default Bean Validation provider is requested, the first ValidationProvider returned by the ValidationProviderResolver strategy is returned.
Coverage
Every Bean Validation provider must provide a ValidationProvider implementation containing a public no-arg constructor
Coverage
If a problem occurs while building the ValidatorFactory, a ValidationException is raised.
Coverage
The first entry point, buildDefaultValidatorFactory(), is considered to be the default ValidatorFactory and is equivalent to the ValidatorFactory returned by Validation.byDefaultProvider().configure().buildValidatorFactory().
Coverage
The second entry point lets the client provide a custom ValidationProviderResolution 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).
Coverage
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.
Coverage
The Validation implementation must not contain any non private attribute or method aside from the three public static bootstrap methods
Coverage
The bootstrap implementation must ensure it can bootstrap third party providers.
Coverage
When bootstrapping a Bean Validation provider, if the ValidationProviderResolver either fails or if the expected provider is not found, a ValidationException is raised.
Coverage
Unless explicitly ignored by calling Configuration.ignoreXMLConfiguration(), a Configuration takes into account the configuration available in META-INF/validation.xml.
Coverage
This configuration file is optional
Coverage
If more than one META-INF/validation.xml file is found in the classpath, a ValidationException is raised.
Unless stated otherwise, XML based configuration settings are overridden by values explicitly set via the Configuration API.
Coverage
default-provider: represents the class name of the provider specific ValidationProvider implementation class. If defined, the specific provider is used
Coverage
message-interpolator: represents the fully qualified class name of the MessageInterpolator implementation. When defined in XML, the implementation must have a public no-arg constructor.
Coverage
traversable-resolver: represents the fully qualified class name of the TraversableResolver implementation. When defined in XML, the implementation must have a public no-arg constructor.
Coverage
constraint-validator-factory: represents the fully qualified class name of the ConstraintValidatorFactory implementation. When defined in XML, the implementation must have a public no-arg constructor.
Coverage
parameter-name-provider: represents the fully qualified class name of the ParameterNameProvider implementation. When defined in XML, the implementation must have a public no-arg constructor.
Coverage
validated-executables: contains the list of executable-type that are considered by default by the integration technology validating executables upon execution.
Coverage
No tests exist for this assertion
message-interpolator, traversable-resolver, constraint-validator-factory, parameter-name-provider and validated-executables are optional.
Coverage
constraint-mapping: represents the resource path of an XML mapping file.
Coverage
More than one constraint-mapping element can be present.
Coverage
Mappings provided via Configuration.addMapping(InputStream) are added to the list of mappings described via constraint-mapping.
Coverage
The namespace javax.validation is reserved for use by this specification.
Properties defined via Configuration.addProperty(String, String) are added to the properties defined via property.
If a property with the same name are defined in both XML and via the programmatic API, the value provided via programmatic API has priority.
If a public no-arg constructor is missing, a ValidationException is raised during the Configuration.buildValidatorFactory() call.
Coverage
ValidatorFactory is a thread-safe object that should be built once per deployment unit
Validator is a thread-safe and lightweight object which can be cached by the ValidatorFactory instance.
getConstraintsForClass() returns a BeanDescriptor object describing the bean level constraints (see 4.1.1) and providing access to the property level constraints metadata.
Coverage
An IllegalArgumentException is raised if the clazz parameter is null.
Coverage
If a constraint definition or declaration hosted by the requested class (or any of it's superclasses and interfaces according to the constraint propagation rules) is invalid, a ValidationException is raised.
Coverage
getElementClass() returns the object type when invoked on BeanDescriptor, the type of a property or parameter when invoked on PropertyDescriptor or ParameterDescriptor respectively, Object[].class when invoked on CrossParameterDescriptor, the return type when invoked on ConstructorDescriptor, MethodDescriptor or ReturnValueDescriptor.
Coverage
getConstraintDescriptors() returns all the ConstraintDescriptors (see 6.11) hosted on the given element in the class hierarchy, each ConstraintDescriptor describing one of the constraints declared on the given element.
Coverage
hasConstraints() returns true if the given element in the class hierarchy holds at least one constraint declaration.
Coverage
If you need to query the metadata API in a more fine grained way for example by restricting the constraints to the one described on fields or on getters or by restricting to a given set of groups, you can use the ConstraintFinder fluent API by calling findConstraints().
Coverage
No tests exist for this assertion
unorderedAndMatchingGroups() restricts the results to the ConstraintDescriptors (see 6.11) matching the given groups. Order is not respected but group inheritance and inheritance via sequence (including the Default group overriding at the class level) are honored.
Coverage
declaredOn() lets you restrict the list of element types constraints are hosted on.
Coverage
lookingAt() lets you restrict which constraints are considered. Either constraints belonging to the element but hosted on the class represented by the given descriptor (Scope.LOCAL_ELEMENT), or constraints belonging to the element but hosted anywhere in the class hierarchy (Scope.HIERARCHY).
Coverage
isBeanConstrained() returns true if the given class (and superclasses and interfaces) has at least one class-level or property-level constraint or validation cascade.
Coverage
hasConstrainedExecutables() returns true if the given class (and superclasses and interfaces) has at least one constrained method or constructor.
Coverage
No tests exist for this assertion
getConstraintsForProperty() returns a PropertyDescriptor object describing the property level constraints (See 4.1.2). The property is uniquely identified by its name as per the JavaBeans convention: field level and getter level constraints of the given name are all returned.
Coverage
An IllegalArgumentException is raised if the propertyName parameter is null.
Coverage
getConstraintsForMethod() returns a MethodDescriptor object describing the method constraints of the given method. The method is uniquely identified by its name and the types of its parameters.
Coverage
getConstrainedMethods() returns the MethodDescriptors of the methods having at least one constraint or cascaded parameter or return value.
Coverage
getConstraintsForConstructor() returns a ConstructorDescriptor object describing the method constraints of the given constructor. The constructor is uniquely identified by its name and the types of its parameters.
Coverage
getConstrainedConstructors() returns the ConstructorDescriptors of the constructors having at least one constraint or cascaded parameter or return value.
Coverage
The isCascaded() method returns true if the element is marked for cascaded validation.
Coverage
The method getGroupConversions() returns a set with the group conversions declared for the cascadable element. An empty set will be returned if no group conversions are configured.
Coverage
The getFrom() method returns the source of a group conversion rule.
Coverage
The getTo() method returns the target of a group conversion rule.
Coverage
getPropertyName() returns the property name as described in 5.2.
Coverage
getName() returns the name of the represented method (e.g. "placeOrder") respectively the non-qualified name of the declaring class of the represented constructor (e.g. "OrderService").
Coverage
getParameterDescriptors() returns a list of ParameterDescriptors representing the method's or constructor's parameters in order of their declaration, including synthetic parameters. An empty list will be returned in case the method or constructor has no parameters.
Coverage
getCrossParameterDescriptor() returns a descriptor containing cross-parameter constraints of the method or constructor. If no cross-parameter constraint is present, the descriptor will return an empty set of constraint descriptors.
Coverage
getReturnValueDescriptor() returns a descriptor for the method's or constructor's return value. A descriptor representing the special class void, without any constraint descriptors, will be returned for executables which have no return value.
Coverage
isConstrainedOnParameters() returns true if any of the parameters is constrained or cascaded or if the represented executable has at least one cross-parameter constraint. Returns false if there is no parameter.
Coverage
isConstrainedOnReturnValue() returns true if the return value is constrained or cascaded. Returns false if there is no return value.
Coverage
The methods hasConstraints(), getConstraintDescriptors() and findConstraints() defined on ElementDescriptor are redefined to clarify that executables do not host constraints directly and thus will always return false or an empty set of constraints, respectively. Constraint descriptors for individual parameters can be obtained from the corresponding ParameterDescriptor object, constraint descriptors for cross-parameter constraints can be obtained from the corresponding CrossParameterDescriptor object and constraint descriptors for the return value can be obtained from ReturnValueDescriptor.
Coverage
None of the metadata API methods honor the XML configuration <validated-executables/> nor the presence of @ValidateExecutable. In other words, all constrained methods and constructors will be returned by the metadata API regardless of these settings.
Coverage
getIndex() returns the index of the represented parameter within the parameter array of the method or constructor holding it.
Coverage
getName() returns the name of the represented parameter.
Coverage
If ConstraintDescriptor represents a composing annotation (see 3.3), the returned annotation must reflect parameter overriding.
Coverage
getAttributes() returns a map containing the annotation attribute names as a key, and the annotation attribute values as a value
Coverage
If ConstraintDescriptor() represents a composing annotation (see 3.3), the returned Map must reflect attribute overriding.
Coverage
getMessageTemplate() returns the non-interpolated error message.
Coverage
No tests exist for this assertion
getGroups() returns the groups the constraint is supposed to be applied upon.
Coverage
If no group is set on the constraint declaration, the Default group is returned.
Coverage
The groups of a composing constraint are the groups of the composed constraint.
Coverage
getPayload() returns the payloads associated to the constraint or an empty set if none.
Coverage
The payload from the main constraint annotation is inherited by the composing annotations.
Coverage
Any payload definition on a composing annotation is ignored.
Coverage
getValidationAppliesTo() returns the ConstraintTarget returned by validationAppliesTo if the constraint hosts the attribute or null otherwise. The constraint target from the main constraint annotation is inherited by the composing annotation. Any constraint target definition on a composing annotation is ignored.
Coverage
No tests exist for this assertion
isReportAsSingleViolation() returns true if the constraint is annotated with @ReportAsSingleViolation.
Coverage
getComposingConstraints() return a set of composing ConstraintDescriptors where each descriptor describes a composing constraint.
Coverage
Each Bean Validation provider must recognize built-in constraint annotations as valid constraint definitions and provide compliant constraint implementations for each.
Coverage
The built-in constraint validation implementation is having a lower priority than an XML mapping definition.
Coverage
@Null constraint
Coverage
@NotNull constraint
Coverage
@AssertTrue constraint
Coverage
@AssertFalse constraint
Coverage
@Min constraint
Coverage
@Max constraint
Coverage
@DecimalMin constraint
Coverage
@DecimalMax constraint
Coverage
@Size constraint
Coverage
@Digits constraint
Coverage
@Past constraint
Coverage
@Future constraint
Coverage
@Pattern constraint
Coverage
If an XML descriptor does not validate against the corresponding XSD file, a ValidationException is raised.
Coverage
Specifically when exploring metadata, the Bean Validation provider must ensure that an annotation instance corresponding to the XML declaration is provided via ConstraintDescriptor.getAnnnotation().
Coverage
A given class must not be described more than once amongst all the XML mapping descriptors.
Coverage
A given field or getter must not be described more than once on a given class description.
Coverage
A given constraint definition must not be overridden more than once amongst all the XML mapping descriptors.
Coverage
If any of these rule is violated in a given validation deployment, a ValidationException is raised during the creation of the ValidatorFactory.
Coverage
If default-package is set, all unqualified class names (including annotations) are considered part of the package described by default-package.
Coverage
A given JavaBean is described by the bean element.
Coverage
The name of the class is mandatory.
Coverage
By default, all constraint declarations expressed via annotation are ignored for classes described in XML.
Coverage
You can force Bean Validation to consider both annotations and XML constraint declarations by using ignore-annotation="false" on bean.
Coverage
If the name of the class does refer to a class not present in the classpath, a ValidationException is raised.
Coverage
If ignore-annotations is declared, Bean Validation must honor the explicit value for this element.
Coverage
If not declared, the default value defined in the encapsulating bean element is considered.
Coverage
When ignore-annotations is true, class-level Bean Validation annotations are ignored for this class (including the @GroupSequence).
Coverage
Constraints declared in XML and constraints declared in annotations are added and form the list of class-level declared constraints.
Coverage
@GroupSequence is considered unless group-sequence element is explicitly used.
Coverage
If ignore-annotations is declared, Bean Validation must honor the explicit value for this element.
Coverage
If not declared, the default value defined in the encapsulating bean element is considered.
Coverage
When ignore-annotations is true, field-level Bean Validation annotations on the targeted field are ignored (including @Valid and @ConvertGroup).
Coverage
Constraints declared in XML and constraints declared in annotations are added and form the list of field-level declared constraints.
Coverage
Note that the only way to disable cascading on a field marked as @Valid is to use ignore-annotations=true.
Coverage
Group conversions declared in XML and via the @ConvertGroup annotation are added and form the list of applied conversions. Note that the rules for the declaration of group conversions as outlined in 4.4.5 apply, in particular it is not legal to declare several conversions for the same source group.
Coverage
No tests exist for this assertion
If the name of the field does not correspond to a field in the given bean a ValidationException is raised.
Coverage
The name attribute corresponds to the name of the property considered as defined in 4.1.2 (for example a getter String getAge() would have <getter name="age"/> as a corresponding descriptor). If ignore-annotations is declared, Bean Validation must honor the explicit value for this element.
Coverage
If not declared, the default value defined in the encapsulating bean element is considered.
Coverage
When ignore-annotations is true, property-level Bean Validation annotations on the targeted property are ignored (including @Valid and @ConvertGroup).
Coverage
Constraints declared in XML and constraints declared in annotations are added and form the list of property-level declared constraints.
Coverage
Note that the only way to disable cascading on a property marked as @Valid is to use ignore-annotations=true.
Coverage
Group conversions declared in XML and via the @ConvertGroup annotation are added and form the list of applied conversions. Note that the rules for the declaration of group conversions as outlined in 4.4.5 apply, in particular it is not legal to declare several conversions for the same source group.
Coverage
No tests exist for this assertion
If the name of the property does not correspond to a property in the given bean a ValidationException is raised.
Coverage
To identify a constructor to be configured, zero or more parameter elements are used, matching the number and types of parameters of the configured constructor. When configuring the default constructor, no parameter element is to be used. The parameter types are specified using their fully qualified name using the syntax described in the documentation of java.lang.Class.getName().
Coverage
No tests exist for this assertion
Varargs parameters are specified using the corresponding array type, e.g. a parameter String... must be specified as "[Ljava.lang.String;".
Coverage
No tests exist for this assertion
If the default-package element is configured for the mapping file, any unqualified class names will be resolved using the given default package.
Coverage
No tests exist for this assertion
If no constructor with the specified parameter types exists in the given bean a ValidationException is raised.
Coverage
No tests exist for this assertion
The optional return-value element is used to change the configuration of a constructor's return value if required.
Coverage
No tests exist for this assertion
The optional cross-parameter element is used to change the configuration of a constructor's cross-parameter constraints if required.
Coverage
No tests exist for this assertion
The constraints applying for a constructor's parameters and its return value are specified by adding constraint elements to the parameter and return-value elements respectively.
Coverage
No tests exist for this assertion
Whether or not to perform cascaded validation is controlled using the valid element
Coverage
No tests exist for this assertion
Group conversion rules for cascaded validation are specified using the convert-group element.
Coverage
No tests exist for this assertion
The cross-parameter constraints applied on a constructor parameter list are specified by adding constraint elements to the cross-parameter element.
Coverage
No tests exist for this assertion
If ignore-annotations is declared on the parameter, cross-parameter element or return value level, Bean Validation must honor the explicit value for this element. Otherwise, if ignore-annotations is declared for the constructor element, Bean Validation must honor this value. Otherwise, the default value declared in the encapsulating bean element is considered.
Coverage
No tests exist for this assertion
When ignore-annotations is true, Bean Validation annotations on the targeted constructor or parameter are ignored (including @Valid and @ConvertGroup).
Coverage
No tests exist for this assertion
Constraints declared in XML and constraints declared in annotations are added and form the list of declared parameter, cross-parameter or return value constraints respectively.
Coverage
No tests exist for this assertion
@Valid is considered unless the valid element is explicitly used.
Coverage
No tests exist for this assertion
Note that the only way to disable cascading on a constructor parameter or return value marked as @Valid is to use ignore-annotations=true. This does not apply to cross-parameter elements as cascading does not make sense in this situation.
Coverage
No tests exist for this assertion
Group conversions declared in XML and via the @ConvertGroup annotation are added and form the list of applied conversions. Note that the rules for the declaration of group conversions as outlined in 4.4.5 apply, in particular it is not legal to declare several conversions for the same source group. This does not apply to cross-parameter elements as cascading does not make sense in this situation.
Coverage
No tests exist for this assertion
To identify a method to be configured, zero or more parameter elements are used, matching the number and types of parameters of the configured method. The parameter types are specified using their fully qualified name using the syntax described in the documentation of java.lang.Class.getName().
Coverage
No tests exist for this assertion
Varargs parameters are specified using the corresponding array type, e.g. a parameter String... must be specified as "[Ljava.lang.String;".
Coverage
No tests exist for this assertion
If the default-package element is configured for the mapping file, any unqualified class names will be resolved using the given default package.
Coverage
No tests exist for this assertion
A given getter method representing a JavaBeans property may either be configured using the getter or the method element, but not both. If a getter element and a method element referring to the same method are detected by the Bean Validation provider, a ValidationException is raised.
Coverage
No tests exist for this assertion
If no method with the specified name and parameter types exists in the given bean a ValidationException is raised.
Coverage
No tests exist for this assertion
The optional return-value element is used to change the configuration of a method's return value if required.
Coverage
No tests exist for this assertion
The optional cross-parameter element is used to change the configuration of a method's cross-parameter constraints if required.
Coverage
No tests exist for this assertion
The constraints applying for a method's parameters and its return value are specified by adding constraint elements to the parameter and return-value elements respectively.
Coverage
No tests exist for this assertion
Whether or not to perform cascaded validation is controlled using the valid element.
Coverage
No tests exist for this assertion
Group conversion rules for cascaded validation are specified using the convert-group element.
Coverage
No tests exist for this assertion
The cross-parameter constraints applied on a method parameter list are specified by adding constraint elements to the cross-parameter element.
Coverage
No tests exist for this assertion
If ignore-annotations is declared on the parameter, cross-parameter element or return value level, Bean Validation must honor the explicit value for this element. Otherwise, if ignore-annotations is declared for the method element, Bean Validation must honor this value. Otherwise, the default value declared in the encapsulating bean element is considered.
Coverage
No tests exist for this assertion
When ignore-annotations is true, Bean Validation annotations on the targeted method or parameter are ignored (including @Valid and @ConvertGroup).
Coverage
No tests exist for this assertion
Constraints declared in XML and constraints declared in annotations are added and form the list of declared parameter, cross-parameter or return value constraints respectively.
Coverage
No tests exist for this assertion
@Valid is considered unless the valid element is explicitly used.
Coverage
No tests exist for this assertion
Note that the only way to disable cascading on a method parameter or return value marked as @Valid is to use ignore-annotations=true. This does not apply to cross-parameter elements as cascading does not make sense in this situation.
Coverage
No tests exist for this assertion
Group conversions declared in XML and via the @ConvertGroup annotation are added and form the list of applied conversions. Note that the rules for the declaration of group conversions as outlined in 4.4.5 apply, in particular it is not legal to declare several conversions for the same source group. This does not apply to cross-parameter elements as cascading does not make sense in this situation.
Coverage
No tests exist for this assertion
The name attribute is mandatory and represents the name of the element in the constraint declaration.
Coverage
Message, groups and payload are not permitted names, use the message, groups or payload elements instead. Otherwise a ValidationException is raised.
Coverage
If the element represents a primitive type, a class or an enum, the string representation of its value is placed in the element itself.
Coverage
If the element represents a primitive type array, a class array or an enum array, the string representation of each value is placed in a value element placed under the element itself.
Coverage
If the element represents an annotation, the annotation element is used to represent the annotation and placed under element.
Coverage
If the element represents an array of annotations, one or more annotation elements are placed under element.
Coverage
Elements with default values in the annotation definition do not have to be represented in XML: the default value will be used in this case.
Coverage
If an XML constraint declaration is missing mandatory elements, or if it contains elements not part of the constraint definition, a ValidationException is raised.
Coverage
Group conversion rules are declared by specifying one or more convert-group elements within the field, getter, parameter and return-value elements.
Coverage
No tests exist for this assertion
Source and target group of a conversion rule are given by specifying their fully-qualified names within the from and to attribute respectively. If the default-package element is configured for the mapping file, any unqualified class names will be resolved using the given default package.
Coverage
No tests exist for this assertion
A constraint definition is represented by a constraint-definition element.
Coverage
If include-existing-validator is set to false, ConstraintValidator defined on the constraint annotation are ignored.
Coverage
If set to true, the list of ConstraintValidators described in XML are concatenated to the list of ConstraintValidator described on the annotation to form a new array of ConstraintValidator evaluated.
Coverage
Annotation based ConstraintValidator come before XML based ConstraintValidators in the array.
Coverage
The new validator list is returned by ConstraintDescriptor.getConstraintValidatorClasses().
Coverage
Implementations supporting Bean Validation 1.1 must properly parse mapping descriptors of Bean Validation 1.0 and 1.1.
Coverage
No tests exist for this assertion
If the version attribute attribute is not given, schema version 1.0 is to be assumed by the Bean Validation Provider.
Coverage
In case an unknown version is given (e.g. if a mapping descriptor adhering to a future schema version is parsed by a Bean Validation 1.1 provider) a ValidationException is raised.
Coverage
Implementations supporting Bean Validation 1.1 must properly parse configuration descriptors of Bean Validation 1.0 and 1.1.
Coverage
No tests exist for this assertion
If the version attribute attribute is not given, schema version 1.0 is to be assumed by the Bean Validation Provider.
Coverage
No tests exist for this assertion
In case an unknown version is given a ValidationException is raised.
Coverage
Every (runtime) exception raised either at initialization time or execution time by any of the extension interfaces (ConstraintValidator, ConstraintValidatorFactory, MessageInterpolator, TraversableResolver, ValidationProviderResolver, ParameterNameProvider) is wrapped in a ValidationException.
Coverage
If a constraint definition does not respect the Bean Validation rules or is inconsistent, a ConstraintDefinitionException is raised.
Coverage
When a constraint declaration is illegal, ConstraintDeclarationException is raised.
When the return type of a property cannot be processed for a given constraint or when a cross-parameter constraint usage is illegal an UnexpectedTypeException is raised.
Coverage
When a group definition is illegal, GroupDefinitionException is raised.
Coverage
By default, method validation is applied to all constrained methods or constructors provided the integration technology can intercept the call. By default, getters (as defined in 4.1) are not considered constrained methods.
Coverage
No tests exist for this assertion
Static methods are ignored by validation. Putting constraints on a static method is not portable.
If it is annotated with @ValidateExecutable and the value attribute contains the executable type. If the value attribute does not contain the executable type, the executable is not validated.
Coverage
No tests exist for this assertion
Otherwise if the type (class, interface) on which the executable is defined is annotated with @ValidateExecutable and the value attribute contains the executable type. If the value attribute does not contain the executable type, the executable is not validated.
Coverage
No tests exist for this assertion
Otherwise if the global configuration of validated executables contains the executable type. If the global setting does not contain the executable type, the executable is not validated.
Coverage
No tests exist for this assertion
The rules above do not apply to methods overriding a superclass method or implementing an interface method. In this case, the method inherits the behavior of the method it overrides / implements.
Coverage
No tests exist for this assertion
CONSTRUCTORS: parameters and return values are validated provided the executable is a constructor.
Coverage
No tests exist for this assertion
NONGETTERMETHODS: parameters and return values are validated provided the executable is a method but not a getter.
Coverage
No tests exist for this assertion
GETTER_METHODS: parameters and return values are validated provided the executable is a getter method.
Coverage
No tests exist for this assertion
ALL: parameters and return values are validated for all executables (getters, non getters and constructors). This option is equivalent to a list of all executable types and is present to improve readability. A list containing ALL and other types of executables is equivalent to a list containing only ALL.
Coverage
No tests exist for this assertion
Similar to the Java EE integration via @Resource (see 10.2), a CDI container must support injection of built-in default ValidatorFactory and Validator beans via @Inject. These default beans are injectable via the @Default qualifier.
Coverage
No tests exist for this assertion
Using directly or indirectly a JPA EntityManager that might call back Bean Validation for validation is not allowed in the Bean Validation extension points and in ConstraintValidator instances. This would lead to infinite flush or unexpected behavior.
Bean Validation requires that CDI beans support constructor and method validation as defined in 10.1.2. Validation must happen at the equivalent time an interceptor occurs when having priority Interceptor.Priority.PLATFORM_AFTER+800, in other words priority of 4800.
Coverage
No tests exist for this assertion
The following 8 tests do not match any known assertions:
Section | Assertion | Test Class | Test Method |
---|---|---|---|
6.2 | x | org.hibernate.beanvalidation.tck.tests.metadata CrossParameterDescriptorTest | testFindConstraintsForConstructor() |
6.2 | x | org.hibernate.beanvalidation.tck.tests.metadata CrossParameterDescriptorTest | testFindConstraintsForConstructorWithoutCrossParameterConstraints() |
6.2 | x | org.hibernate.beanvalidation.tck.tests.metadata CrossParameterDescriptorTest | testFindConstraintsForMethod() |
6.2 | x | org.hibernate.beanvalidation.tck.tests.metadata CrossParameterDescriptorTest | testFindConstraintsForMethodWithoutCrossParameterConstraints() |
4.6.2 | x | org.hibernate.beanvalidation.tck.tests.methodvalidation MethodValidationTest | constructorParameterValidationValidatesEachConstraintOnlyOnce() |
4.6.2 | x | org.hibernate.beanvalidation.tck.tests.methodvalidation MethodValidationTest | constructorReturnValueValidationValidatesEachConstraintOnlyOnce() |
4.6.2 | x | org.hibernate.beanvalidation.tck.tests.methodvalidation MethodValidationTest | methodParameterValidationValidatesEachConstraintOnlyOnce() |
4.6.2 | x | org.hibernate.beanvalidation.tck.tests.methodvalidation MethodValidationTest | methodReturnValueValidationValidatesEachConstraintOnlyOnce() |