Author: hardy.ferentschik Date: 2009-05-19 09:45:23 -0400 (Tue, 19 May 2009) New Revision: 16601 Modified: beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml Log: Completed assertions for chapter 2 Modified: beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml =================================================================== --- beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml 2009-05-19 13:44:49 UTC (rev 16600) +++ beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml 2009-05-19 13:45:23 UTC (rev 16601) @@ -61,24 +61,184 @@ group is considered declared. </text> </assertion> </section> - + <section id="2.2" title="Applying multiple constraints of the same type"> - <assertion id=""> - <text></text> + <assertion id="a"> + <text>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.</text> </assertion> - <assertion id=""> - <text/> + <assertion id="b"> + <text>The annotation must have retention RUNTIME and can be applied on a type, field, + property or an other annotation</text> </assertion> - </section> + </section> + <section id="2.3" title="Constraint composition"> + <assertion id="a"> + <text>Each constraint annotation hosted on a constraint an- notation is applied to the + target element and this recursively</text> + </assertion> + <assertion id="b"> + <text>Note that the main annotation and its constraint valid- ation implementation is + also applied</text> + </assertion> + <assertion id="c"> + <text>By default, each failing constraint generates an error report</text> + </assertion> + <assertion id="d"> + <text>Groups from the main constraint annotation are inherited by the composing + annotations</text> + </assertion> + <assertion id="e"> + <text>Any groups definition on a composing an- notation is ignored</text> + </assertion> + <assertion id="f"> + <text>The property type a composed constraint is placed on must be compatible with all + constraints (composing and com- posed)</text> + </assertion> + <assertion id="g"> + <text> If a composed constraint is marked as @ReportAsSingleViolation, and if any of its + composing constraint reports one or more violations, all reports from composing + constraints are ignored and the error report corresponding to the composed + constraint is generated</text> + </assertion> + <assertion id="h"> + <text>Composing annotations can define the value of message and custom attributes + (excluding groups) but these are fixed in the composed constraint definition</text> + </assertion> + <assertion id="i"> + <text>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</text> + </assertion> + <assertion id="j"> + <text> The types of the overridden and overriding attributes must be identical</text> + </assertion> + <assertion id="k"> + <text>A composing constraint can itself be a composed constraint. In this case, + attribute values are overridden re- cursively according to the described + rules</text> + </assertion> + <assertion id="l"> + <text>If a constraint is used more than once as a composing constraint, the multi value + constraints model as described in Section 2.2 is used</text> + </assertion> + <assertion id="m"> + <text>To select the appropriate composing constraint targeted, OverridesAttrib- + ute.constraintIndex is used. It represents the constraint index in the value + array</text> + </assertion> + <assertion id="n"> + <text>If index is undefined, the single constraint declaration is targeted</text> + </assertion> + <assertion id="o"> + <text>If the composition is invalid (infinite composition, wrong attribute overriding, a + single attribute mapped to more than one source attribute etc), a + ConstraintDefinitionException is raised either at validation time or when the + metadata is requested</text> + </assertion> + </section> + <section id="2.4" title="Constraint validation implementation"> + <assertion id="a"> + <text>A constraint validation implementation performs the validation of a given + constraint annotation for a given type</text> + </assertion> + <assertion id="b"> + <text>The implementation classes are specified by the validatedBy element of the + @Contraint annotation that decorates the constraint definition</text> + </assertion> + <assertion id="c"> + <text>The constraint validation implementation implements the ConstraintValidator + interface</text> + </assertion> + <assertion id="d"> + <text>T must resolve in a non parameterized type or generic parameters of T must be + unbounded wildcard types</text> + </assertion> + <assertion id="e"> + <text>The initialize method is called by the Bean validation provider prior to any use + of the constraint implementation.</text> + </assertion> + <assertion id="f"> + <text>The isValid method is evaluated by the Bean Validation provider each time a given + value is validated</text> + </assertion> + <assertion id="g"> + <text>It returns false if the value is not valid, true otherwise</text> + </assertion> + <assertion id="h"> + <text>isValid implementations must be thread-safe</text> + </assertion> + <assertion id="i"> + <text>If the property is of an unanticipated type, an UnexpectedTypeException is + raised</text> + </assertion> + <assertion id="j"> + <text>If an exception occurs either in the initialize or isValid method, the runtime + exception is wrapped into a Valid- ationException by the Bean Validation engine + </text> + </assertion> + <assertion id="k"> + <text>The constraint validation implementation is not allowed to change the state of the + value passed to isValid. </text> + </assertion> + <assertion id="l"> + <text>By default, each invalid constraint leads to the generation of one error object + represented by a ConstraintViolation object. This object is build from the default + error message as defined by the constraint de- claration and the context in which + the constraint declaration is placed on (bean, property, attribute)</text> + </assertion> + <assertion id="m"> + <text>The ConstraintValidatorContext methods let the constraint implementation disable + the default error object gen- eration and create one or more custom ones</text> + </assertion> + <assertion id="n"> + <text>The non-interpolated message passed as a parameter is used to build the + ConstraintViolation object (the message interpolation operation is applied to + it)</text> + </assertion> + <assertion id="o"> + <text>By default, the propertyPath exposed on the ConstraintViolation represents the + path to the bean or property hosting the constraint</text> + </assertion> + <assertion id="q"> + <text>The leaf of the propertyPath can be adjusted by use of ConstraintValidatorCon- + text.addError(String, String). In this case, propertyPath is the concatenation of + the default propertyPath value . (dot) if propertyPath is not an empty string (ie + not representing the root object) and the property string passed to the addError + method </text> + </assertion> + </section> + <section id="2.5" title="The ConstraintValidatorFactory"> + <assertion id="a"> + <text>Constraint validation implementation instances are created by a + ConstraintValidatorFactory</text> + </assertion> + <assertion id="b"> + <text>The default ConstraintValidatorFactory provided by the Bean Validation provider + implementation uses the pub- lic constraint no-arg constructor</text> + </assertion> + <assertion id="c"> + <text>ConstraintValidatorFactory should not cache instances as the state of each + instance can be altered in the ini- tialize method</text> + </assertion> + <assertion id="d"> + <text>If an exception occurs in the factory while retrieving the ConstraintValidator + instance, the runtime exception is wrapped in a ValidationException</text> + </assertion> + <assertion id="e"> + <text>If the instance returned by the factory is null, a ValidationException is + raised</text> + </assertion> + </section> - - <!-- <assertion id=""> <text></text> </assertion> --> - - - + </specification>