[hibernate-commits] Hibernate SVN: r16613 - beanvalidation/trunk/validation-tck/src/main/resources.
hibernate-commits at lists.jboss.org
hibernate-commits at lists.jboss.org
Fri May 22 07:54:34 EDT 2009
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>
More information about the hibernate-commits
mailing list