Author: hardy.ferentschik Date: 2009-05-20 07:58:04 -0400 (Wed, 20 May 2009) New Revision: 16606 Modified: beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml Log: Further work on the TCK assertions. Modified: beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml =================================================================== --- beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml 2009-05-20 09:42:21 UTC (rev 16605) +++ beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml 2009-05-20 11:58:04 UTC (rev 16606) @@ -234,11 +234,132 @@ raised</text> </assertion> </section> + <section id="3.1" title="Requirements on classes to be validated"> + <assertion id="a"> + <text>Properties to be validated must follow the method signature conventions for + JavaBeans read properties, as defined by the JavaBeans specification</text> + </assertion> + <assertion id="b"> + <text>Static fields and static methods are excluded from validation</text> + </assertion> + <assertion id="c"> + <text>Constraints can be applied to interfaces and superclasses</text> + </assertion> + <assertion id="d"> + <text>The target of an annotation definition can be a field, property, or type, provided + that the constraint definition supports the specified target and the constraint + supports the declared type of the target. </text> + </assertion> + </section> + <section id="3.1.1" title="Object validation"> + <assertion id="a"> + <text>Constraint declarations can be applied to a class or an interface</text> + </assertion> + </section> + <section id="3.1.2" title="Field and property validation"> + <assertion id="a"> + <text>Constraint declarations can be applied on both fields and properties for the same + object type</text> + </assertion> + <assertion id="b"> + <text>The same constraint should however not be duplicated between a field and its + associated property (the constraint validation would be applied twice)</text> + </assertion> + <assertion id="c"> + <text>When a field is annotated with a constraint declaration, field access strategy is + used to access the state validated by such constraint</text> + </assertion> + <assertion id="d"> + <text>When a property is annotated with a constraint declaration, property access + strategy is used to access the state val- idated by such constraint</text> + </assertion> + <assertion id="e"> + <text>When using field access strategy, the bean validation provider accesses the + instance variable directly</text> + </assertion> + <assertion id="f"> + <text>When using the property access strategy, the bean validation provider accesses the + state via the property accessor method.</text> + </assertion> + <assertion id="g"> + <text>The fields or methods visibility are not constrained</text> + </assertion> + <assertion id="h"> + <text>Constraints on non getter methods are not supported</text> + </assertion> + </section> + <section id="3.1.3" title="Graph validation"> + <assertion id="a"> + <text>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.</text> + </assertion> + <assertion id="b"> + <text> 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</text> + </assertion> + <assertion id="c"> + <text>Collection-valued, array-valued or Iterable fields and properties may also be + decorated with the @Valid annota- tion. This causes the contents of the collection, + array or iterator to be validated</text> + </assertion> + <assertion id="d"> + <text>The following types are supported, any array of objects, java.util.Collection, + java.util.Set, java.util.List, java.util.Map and any object implementing + java.lang.Iterable </text> + </assertion> + <assertion id="e"> + <text>For Map, the value of each entry is validated (the key is not validated)</text> + </assertion> + <assertion id="f"> + <text>Like regular references, its type is determined at runtime and the constraint + definitions for this particular type are used</text> + </assertion> + <assertion id="g"> + <text>The @Valid annotation is applied recursively</text> + </assertion> + </section> + <section id="3.3" title="Inheritance"> + <assertion id="a"> + <text>A constraint declaration can be placed on an interface</text> + </assertion> + <assertion id="b"> + <text>For a given class, constraint declarations held on super- classes as well as + interfaces are evaluated by the Bean Validation provider</text> + </assertion> + </section> + <section id="3.4" title="Group and group sequence"> + <assertion id="a"> + <text>If no group is explicitly declared, a constraint belongs to the Default + group</text> + </assertion> + <assertion id="b"> + <text>Groups are represented by interfaces</text> + </assertion> + <assertion id="c"> + <text>A constraint can belong to one or more groups</text> + </assertion> + <assertion id="d"> + <text>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</text> + </assertion> + </section> + <section id="3.4.1" title="Group inheritance"> + <assertion id="a"> + <text>A group can inherit one or more groups by using interface inheritance</text> + </assertion> + <assertion id="b"> + <text>For a given interface Z, constraints marked as belonging to the group Z (ie where + the annotation groups property contains the interface Z) or any of the super + interfaces of Z (inherited groups) are considered part of the group Z</text> + </assertion> + </section> <!-- <assertion id=""> <text></text> </assertion> --> - + </specification>