Author: hardy.ferentschik Date: 2009-05-22 07:54:33 -0400 (Fri, 22 May 2009) New Revision: 16613 Modified: beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml Log: adding assertions Modified: beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml =================================================================== --- beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml 2009-05-22 06:45:23 UTC (rev 16612) +++ beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml 2009-05-22 11:54:33 UTC (rev 16613) @@ -356,6 +356,179 @@ </assertion> </section> + + <section id="3.4.2" title=""> + <assertion id="a"> + <text>By default, constraints are evaluated in no particular order and this regardless + of which groups they belong to</text> + </assertion> + <assertion id="b"> + <text>Each group in a group sequence must be processed sequentially in the order defined + by @GroupSequence.value when the group defined as a se- quence is requested</text> + </assertion> + <assertion id="c"> + <text>Note that a group member of a sequence can itself be composed of several groups + via inherit- ance or sequence definition. In this case, each composed group must + respect the sequence order as well.</text> + </assertion> + <assertion id="d"> + <text>if one of the groups processed in the sequence generates one or more constraint + violation, the groups following in the sequence must not be processed</text> + </assertion> + <assertion id="e"> + <text>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 + definition or group inheritance</text> + </assertion> + <assertion id="f"> + <text>If a group containing such a circularity is evaluated, a GroupDefinitionException + is raised.</text> + </assertion> + <assertion id="g"> + <text>Groups defining a sequence should not directly inherit other groups</text> + </assertion> + <assertion id="h"> + <text>Groups defining a sequence should not be used directly in constraint + declarations</text> + </assertion> + <assertion id="i"> + <text>To define a group as a sequence, the interface must be annotated with the + @GroupSequence annotation</text> + </assertion> + <assertion id="j"> + <text>A given constraint can belong to two 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)</text> + </assertion> + </section> + <section id="3.4.3" title=""> + <assertion id="a"> + <text>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.</text> + </assertion> + <assertion id="b"> + <text>Constraints hosted on a class A and belonging to the Default group (by default or + explicitly) implicitly belong to the group A</text> + </assertion> + <assertion id="c"> + <text>A sequence defined on a class A (ie. redefining the Default groups for the class) + must contain the group A</text> + </assertion> + <assertion id="d"> + <text>If a @GroupSequence rede- fining 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</text> + </assertion> + </section> + <section id="3.4.4" title=""> + <assertion id="a"> + <text>Every constraint hosted on an interface Z and part of the Default group + (implicitly or expli- citly) belongs to the group Z</text> + </assertion> + </section> + <section id="3.5" title=""> + <assertion id="a"> + <text>For a given group to validate, the validation routine applied on a given bean + instance is expected to execute the constraint validations in no particular + order</text> + </assertion> + <assertion id="b"> + <text>Note that this implies that a given validation constraint will not be processed + more than once per validation</text> + </assertion> + <assertion id="c"> + <text>Unless ordered by group sequences, groups can be validated in no particular + order</text> + </assertion> + </section> + <section id="3.5.1" title=""> + <assertion id="a"> + <text>The @Valid annotation on a given association (i.e. object reference or collection, + array, Iterable of objects), dic- tates the Bean Validator implementation to apply + recursively the bean validation routine on (each of) the associated object(s)</text> + </assertion> + <assertion id="b"> + <text>This mechanism is recursive</text> + </assertion> + <assertion id="c"> + <text>Null references are ignored</text> + </assertion> + <assertion id="d"> + <text>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)</text> + </assertion> + </section> + <section id="3.5.2" title=""> + <assertion id="a"> + <text>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</text> + </assertion> + <assertion id="b"> + <text>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</text> + </assertion> + <assertion id="c"> + <text>If an exception occurs when the TraversableResolver is called, the exception is + wrapped into a ValidationEx- ception</text> + </assertion> + <assertion id="d"> + <text>if Java Persistence is available in the runtime environment, a property is + considered reachable if Java Persist- ence considers the property as loaded</text> + </assertion> + <assertion id="d"> + <text>if Java Persistence is not available in the runtime environment, all properties + are considered reachable</text> + </assertion> + <assertion id="e"> + <text>all properties are considered cascadable</text> + </assertion> + </section> + <section id="3.5.3" title=""> + <assertion id="a"> + <text>A constraint is associated to one or more ConstraintValidator + implementations</text> + </assertion> + <assertion id="b"> + <text>The ConstraintValidator executed depends on the type hosting the constraint</text> + </assertion> + <assertion id="c"> + <text>For a given constraint evaluation, a single ConstraintValidator is + considered</text> + </assertion> + <assertion id="d"> + <text>If the constraint declaration is hosted on a class or an interface, the targeted + type is the class or the interface</text> + </assertion> + <assertion id="e"> + <text>If the constraint is hosted on a class attribute, the type of the attribute is the + targeted type</text> + </assertion> + <assertion id="f"> + <text>If the constraint is hosted on a getter, the return type of the getter is the + targeted type</text> + </assertion> + <assertion id="g"> + <text>the ConstraintValidator chosen to validate a declared type T is the one 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</text> + </assertion> + <assertion id="h"> + <text>If no ConstraintValidator compliant with T is found amongst the + ConstraintValidators listed by the con- straint A, a UnexpectedTypeException is + raised</text> + </assertion> + <assertion id="i"> + <text>If more than one maximally specific ConstraintValidator is found, a + UnexpectedTypeException is raised</text> + </assertion> + </section> + + <!-- <assertion id=""> <text></text>