[hibernate-commits] Hibernate SVN: r16606 - beanvalidation/trunk/validation-tck/src/main/resources.
hibernate-commits at lists.jboss.org
hibernate-commits at lists.jboss.org
Wed May 20 07:58:04 EDT 2009
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>
More information about the hibernate-commits
mailing list