[hibernate-commits] Hibernate SVN: r16601 - beanvalidation/trunk/validation-tck/src/main/resources.
hibernate-commits at lists.jboss.org
hibernate-commits at lists.jboss.org
Tue May 19 09:45:23 EDT 2009
Author: hardy.ferentschik
Date: 2009-05-19 09:45:23 -0400 (Tue, 19 May 2009)
New Revision: 16601
Modified:
beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml
Log:
Completed assertions for chapter 2
Modified: beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml
===================================================================
--- beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml 2009-05-19 13:44:49 UTC (rev 16600)
+++ beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml 2009-05-19 13:45:23 UTC (rev 16601)
@@ -61,24 +61,184 @@
group is considered declared. </text>
</assertion>
</section>
-
+
<section id="2.2" title="Applying multiple constraints of the same type">
- <assertion id="">
- <text></text>
+ <assertion id="a">
+ <text>The bean validation provider treats regular annotations (annotations not annotated
+ by @Constraint) whose value element has a return type of an array of constraint
+ annotations in a special way. Each element in the value array are processed by the
+ Bean Validation implementation as regular constraint annotations.</text>
</assertion>
- <assertion id="">
- <text/>
+ <assertion id="b">
+ <text>The annotation must have retention RUNTIME and can be applied on a type, field,
+ property or an other annotation</text>
</assertion>
- </section>
+ </section>
+ <section id="2.3" title="Constraint composition">
+ <assertion id="a">
+ <text>Each constraint annotation hosted on a constraint an- notation is applied to the
+ target element and this recursively</text>
+ </assertion>
+ <assertion id="b">
+ <text>Note that the main annotation and its constraint valid- ation implementation is
+ also applied</text>
+ </assertion>
+ <assertion id="c">
+ <text>By default, each failing constraint generates an error report</text>
+ </assertion>
+ <assertion id="d">
+ <text>Groups from the main constraint annotation are inherited by the composing
+ annotations</text>
+ </assertion>
+ <assertion id="e">
+ <text>Any groups definition on a composing an- notation is ignored</text>
+ </assertion>
+ <assertion id="f">
+ <text>The property type a composed constraint is placed on must be compatible with all
+ constraints (composing and com- posed)</text>
+ </assertion>
+ <assertion id="g">
+ <text> If a composed constraint is marked as @ReportAsSingleViolation, and if any of its
+ composing constraint reports one or more violations, all reports from composing
+ constraints are ignored and the error report corresponding to the composed
+ constraint is generated</text>
+ </assertion>
+ <assertion id="h">
+ <text>Composing annotations can define the value of message and custom attributes
+ (excluding groups) but these are fixed in the composed constraint definition</text>
+ </assertion>
+ <assertion id="i">
+ <text>It is possible to override attributes and messages defined on a composing
+ annotation. An attribute from the main annotation is used to override one or more
+ attributes of the composing annotations. Such an attribute is annotated with the
+ @OverridesAttribute annotation or its multivalued equivalent
+ @OverridesAttribute.List</text>
+ </assertion>
+ <assertion id="j">
+ <text> The types of the overridden and overriding attributes must be identical</text>
+ </assertion>
+ <assertion id="k">
+ <text>A composing constraint can itself be a composed constraint. In this case,
+ attribute values are overridden re- cursively according to the described
+ rules</text>
+ </assertion>
+ <assertion id="l">
+ <text>If a constraint is used more than once as a composing constraint, the multi value
+ constraints model as described in Section 2.2 is used</text>
+ </assertion>
+ <assertion id="m">
+ <text>To select the appropriate composing constraint targeted, OverridesAttrib-
+ ute.constraintIndex is used. It represents the constraint index in the value
+ array</text>
+ </assertion>
+ <assertion id="n">
+ <text>If index is undefined, the single constraint declaration is targeted</text>
+ </assertion>
+ <assertion id="o">
+ <text>If the composition is invalid (infinite composition, wrong attribute overriding, a
+ single attribute mapped to more than one source attribute etc), a
+ ConstraintDefinitionException is raised either at validation time or when the
+ metadata is requested</text>
+ </assertion>
+ </section>
+ <section id="2.4" title="Constraint validation implementation">
+ <assertion id="a">
+ <text>A constraint validation implementation performs the validation of a given
+ constraint annotation for a given type</text>
+ </assertion>
+ <assertion id="b">
+ <text>The implementation classes are specified by the validatedBy element of the
+ @Contraint annotation that decorates the constraint definition</text>
+ </assertion>
+ <assertion id="c">
+ <text>The constraint validation implementation implements the ConstraintValidator
+ interface</text>
+ </assertion>
+ <assertion id="d">
+ <text>T must resolve in a non parameterized type or generic parameters of T must be
+ unbounded wildcard types</text>
+ </assertion>
+ <assertion id="e">
+ <text>The initialize method is called by the Bean validation provider prior to any use
+ of the constraint implementation.</text>
+ </assertion>
+ <assertion id="f">
+ <text>The isValid method is evaluated by the Bean Validation provider each time a given
+ value is validated</text>
+ </assertion>
+ <assertion id="g">
+ <text>It returns false if the value is not valid, true otherwise</text>
+ </assertion>
+ <assertion id="h">
+ <text>isValid implementations must be thread-safe</text>
+ </assertion>
+ <assertion id="i">
+ <text>If the property is of an unanticipated type, an UnexpectedTypeException is
+ raised</text>
+ </assertion>
+ <assertion id="j">
+ <text>If an exception occurs either in the initialize or isValid method, the runtime
+ exception is wrapped into a Valid- ationException by the Bean Validation engine
+ </text>
+ </assertion>
+ <assertion id="k">
+ <text>The constraint validation implementation is not allowed to change the state of the
+ value passed to isValid. </text>
+ </assertion>
+ <assertion id="l">
+ <text>By default, each invalid constraint leads to the generation of one error object
+ represented by a ConstraintViolation object. This object is build from the default
+ error message as defined by the constraint de- claration and the context in which
+ the constraint declaration is placed on (bean, property, attribute)</text>
+ </assertion>
+ <assertion id="m">
+ <text>The ConstraintValidatorContext methods let the constraint implementation disable
+ the default error object gen- eration and create one or more custom ones</text>
+ </assertion>
+ <assertion id="n">
+ <text>The non-interpolated message passed as a parameter is used to build the
+ ConstraintViolation object (the message interpolation operation is applied to
+ it)</text>
+ </assertion>
+ <assertion id="o">
+ <text>By default, the propertyPath exposed on the ConstraintViolation represents the
+ path to the bean or property hosting the constraint</text>
+ </assertion>
+ <assertion id="q">
+ <text>The leaf of the propertyPath can be adjusted by use of ConstraintValidatorCon-
+ text.addError(String, String). In this case, propertyPath is the concatenation of
+ the default propertyPath value . (dot) if propertyPath is not an empty string (ie
+ not representing the root object) and the property string passed to the addError
+ method </text>
+ </assertion>
+ </section>
+ <section id="2.5" title="The ConstraintValidatorFactory">
+ <assertion id="a">
+ <text>Constraint validation implementation instances are created by a
+ ConstraintValidatorFactory</text>
+ </assertion>
+ <assertion id="b">
+ <text>The default ConstraintValidatorFactory provided by the Bean Validation provider
+ implementation uses the pub- lic constraint no-arg constructor</text>
+ </assertion>
+ <assertion id="c">
+ <text>ConstraintValidatorFactory should not cache instances as the state of each
+ instance can be altered in the ini- tialize method</text>
+ </assertion>
+ <assertion id="d">
+ <text>If an exception occurs in the factory while retrieving the ConstraintValidator
+ instance, the runtime exception is wrapped in a ValidationException</text>
+ </assertion>
+ <assertion id="e">
+ <text>If the instance returned by the factory is null, a ValidationException is
+ raised</text>
+ </assertion>
+ </section>
-
-
<!--
<assertion id="">
<text></text>
</assertion>
-->
-
-
-
+
</specification>
More information about the hibernate-commits
mailing list