6:54 a.m.
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>