[hibernate-commits] Hibernate SVN: r16619 - beanvalidation/trunk/validation-tck/src/main/resources.
hibernate-commits at lists.jboss.org
hibernate-commits at lists.jboss.org
Mon May 25 12:17:26 EDT 2009
Author: hardy.ferentschik
Date: 2009-05-25 12:17:26 -0400 (Mon, 25 May 2009)
New Revision: 16619
Modified:
beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml
Log:
Added more assertions
Modified: beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml
===================================================================
--- beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml 2009-05-25 14:42:39 UTC (rev 16618)
+++ beanvalidation/trunk/validation-tck/src/main/resources/tck-audit.xml 2009-05-25 16:17:26 UTC (rev 16619)
@@ -630,11 +630,596 @@
root object)</text>
</assertion>
</section>
-
- <!--
- <assertion id="">
- <text></text>
- </assertion>
- -->
-
+ <section id="4.3.1" title="Default message interpolation">
+ <assertion id="a">
+ <text>A conforming implementation includes a default message interpolator</text>
+ </assertion>
+ <assertion id="b">
+ <text>Each constraint defines a message descriptor via its message property</text>
+ </assertion>
+ <assertion id="c">
+ <text>Every constraint definition shall define a de- fault message descriptor for that
+ constraint.</text>
+ </assertion>
+ <assertion id="d">
+ <text>Messages can be overridden at declaration time in constraints by setting the
+ property on the constraint.</text>
+ </assertion>
+ <assertion id="e">
+ <text>The message descriptor is a string literal and may contain one or more message
+ parameters. Message parameters are string literals enclosed in braces</text>
+ </assertion>
+ <assertion id="f">
+ <text>\{ is considered as the literal { instead of being considered as the beginning of
+ a message parameter</text>
+ </assertion>
+ <assertion id="g">
+ <text>\} is considered as the literal } instead of being considered as the end of a
+ message parameter</text>
+ </assertion>
+ <assertion id="h">
+ <text>\\ is considered as the literal \ instead of being considered as the escaping
+ character</text>
+ </assertion>
+ </section>
+ <section id="4.3.1.1" title="Default message interpolation algorithm">
+ <assertion id="a">
+ <text>Message parameters are extracted from the message string and used as keys to
+ search the ResourceBundle named ValidationMessages (often materialized as the
+ property file /ValidationMessages.properties and its locale variations) using the
+ defined locale (see below). If a property is found, the message parameter is re-
+ placed with the property value in the message string</text>
+ </assertion>
+ <assertion id="b">
+ <text>Step 1 is applied recursively until no replacement is per- formed</text>
+ </assertion>
+ <assertion id="c">
+ <text>Message parameters are extracted from the message string and used as keys to
+ search the Bean Validation pro- vider's built-in ResourceBundle using the defined
+ locale (see below). If a property is found, the message para- meter is replaced with
+ the property value in the message string</text>
+ </assertion>
+ <assertion id="e">
+ <text>Contrary to step 1, step 2 is not processed re- cursively</text>
+ </assertion>
+ <assertion id="f">
+ <text>If step 2 triggers a replacement, then step 1 is applied again. Otherwise step 4
+ is performed</text>
+ </assertion>
+ <assertion id="g">
+ <text>Message parameters are extracted from the message string. Those matching the name
+ of an attribute of the constraint declaration are replaced by the value of that
+ attribute.</text>
+ </assertion>
+ <assertion id="h">
+ <text>if the locale is passed to the interpolator method interpolate(String,
+ CosntraintDescriptor, Object, Locale), this Locale instance is used</text>
+ </assertion>
+ <assertion id="i">
+ <text>otherwise, the default Locale as provided by Locale.getDefault() is used.</text>
+ </assertion>
+ </section>
+ <section id="4.3.2" title="Custom message interpolation">
+ <assertion id="a">
+ <text>A message interpolator implementation shall be thread-safe</text>
+ </assertion>
+ <assertion id="b">
+ <text>It is possible to override the MessageInterpolator implementation for a given
+ Validator instance by invoking
+ ValidatorFactory.usingContext().messageInterpolator(messageInterpolator).getValidator()</text>
+ </assertion>
+ </section>
+ <section id="4.4" title="Bootstrapping">
+ <assertion id="a">
+ <text>a bootstrap implementation must be able to bootstrap any Bean Validation provider
+ implementation</text>
+ </assertion>
+ </section>
+ <section id="4.4.1" title="Examples">
+ <assertion id="">
+ <text>The ValidatorFactory object is thread-safe</text>
+ </assertion>
+ </section>
+ <section id="4.4.2" title="ValidatorFactory">
+ <assertion id="a">
+ <text>The MessageInterpolator or the TraversableResolver passed to the ValidatorContext
+ are used instead of the ValidatorFactory's MessageInterpolator or
+ TraversableResolver instances</text>
+ </assertion>
+ <assertion id="b">
+ <text>getMessageInterpolator() returns the MessageInterpolator instance configured
+ during the initialization of the ValidatorFactory</text>
+ </assertion>
+ </section>
+ <section id="4.4.3" title="Configuration">
+ <assertion id="a">
+ <text>A Bean Validation provider must define a sub interface of Configuration uniquely
+ identifying the provider.</text>
+ </assertion>
+ <assertion id="b">
+ <text>The isSuitable() method of its ValidationProvider implementation must return true
+ when this sub interface type is passed as a parameter, false otherwise</text>
+ </assertion>
+ <assertion id="c">
+ <text>Streams represented in the XML configuration and opened by the Configuration
+ implementation must be closed by the Configuration implementation after the
+ ValidatorFactory creation (or if an exception occurs)</text>
+ </assertion>
+ <assertion id="d">
+ <text>Use the provider implementation requested if Configuration has been created from
+ Validation.byProvider(Class)</text>
+ </assertion>
+ <assertion id="e">
+ <text>Use the provider implementation associated with the Configuration implementation
+ described in the XML configuration (under validation-config.default-provider see
+ Section 4.4.6) if defined: the value of this element is the fully qualified class
+ name of the Configuration sub interface uniquely identifying the provider.</text>
+ </assertion>
+ <assertion id="f">
+ <text>Use the first provider implementation returned by
+ validationProviderResolver.getValidationProviders()</text>
+ </assertion>
+ <assertion id="g">
+ <text>If no ValidationProviderResolver instance has been specified, the default
+ ValidationProviderResolv- er is used</text>
+ </assertion>
+ <assertion id="h">
+ <text>If a problem occurs while building the ValidationFactory, a ValidationException is
+ raised</text>
+ </assertion>
+ </section>
+ <section id="4.4.4.1" title="">
+ <assertion id="a">
+ <text>ValidationProviderResolver returns the list of Bean Validation providers available
+ at runtime and more specific- ally a ValidationProvider instance for each provider
+ available in the context</text>
+ </assertion>
+ <assertion id="b">
+ <text>Implementations must be thread-safe</text>
+ </assertion>
+ <assertion id="c">
+ <text>Bean Validation providers must supply a service provider configuration file by
+ creating a text file javax.validation.spi.ValidationProvider and placing it in the
+ META-INF/services directory of one of its jar files</text>
+ </assertion>
+ </section>
+ <section id="4.4.4.2" title="ValidationProviderResolver">
+ <assertion id="a">
+ <text>A client can request a specific Bean Validation provider by using
+ Validation.byProvider(Class) or by defining the provider in the XML configuration
+ file</text>
+ </assertion>
+ <assertion id="b">
+ <text>The key uniquely identifying a Bean Validation provider is a provider specific sub
+ interface of Configuration</text>
+ </assertion>
+ <assertion id="c">
+ <text>Retrieve available providers using
+ ValidationProviderResolver.getValidationProviders(). • The first
+ ValidationProvider matching the requested provider is returned</text>
+ </assertion>
+ <assertion id="d">
+ <text>Providers are evaluated in the order they are returned by
+ ValidationProviderResolver</text>
+ </assertion>
+ <assertion id="e">
+ <text>When the default Bean Validation provider is requested, the first
+ ValidationProvider returned by the Valida- tionProviderResolver strategy is
+ returned</text>
+ </assertion>
+ <assertion id="f">
+ <text>Every Bean Validation provider must provide a ValidationProvider implementation
+ containing a public no-arg constructor and add the corresponding
+ META-INF/services/javax.validation.spi.ValidationProvider file descriptor in one of
+ its jars.</text>
+ </assertion>
+ <assertion id="g">
+ <text>If a problem occurs while building the ValidationFactory, a ValidationException is
+ raised</text>
+ </assertion>
+ </section>
+ <section id="4.4.5" title="Validation">
+ <assertion id="a">
+ <text>The Validation implementation provided by the Bean Validation provider must not
+ contain any non private attrib- ute or method aside from the three public static
+ bootstrap methods</text>
+ </assertion>
+ <assertion id="b">
+ <text>The bootstrap implementation must ensure it can bootstrap third party
+ providers</text>
+ </assertion>
+ <assertion id="c">
+ <text>When building the Configuration object, if the ValidationProviderResolver either
+ fail or if the expected pro- vider is not found, a ValidationException is
+ raised</text>
+ </assertion>
+ </section>
+ <section id="4.4.6" title="XML Configuration">
+ <assertion id="a">
+ <text>Unless explicitly ignored by calling Configuration.ignoreXMLConfiguration(), a
+ Configuration takes into ac- count the configuration available in
+ META-INF/validation.xml</text>
+ </assertion>
+ <assertion id="b">
+ <text>This configuration file is optional but can be used by application to refine some
+ of the Bean Validation behavior</text>
+ </assertion>
+ <assertion id="c">
+ <text>If more than one META-INF/validation.xml file is found in the classpath, a is
+ raised</text>
+ </assertion>
+ <assertion id="d">
+ <text>Unless stated otherwise, XML based configuration settings are overridden by values
+ explicitly set via the Config- uration API</text>
+ </assertion>
+ <assertion id="e">
+ <text>default-provider: represents the class name of the provider specific Configuration
+ sub-interface. If defined, the provider suitable for this interface is used</text>
+ </assertion>
+ <assertion id="f">
+ <text>message-interpolator: represents the fully qualified class name of the
+ MessageInterpolator implementation. When defined in XML, the implementation must
+ have a public no-arg constructor. This element is optional</text>
+ </assertion>
+ <assertion id="g">
+ <text>traversable-resolver: represents the fully qualified class name of the
+ TraversableResolver implementation. When defined in XML, the implementation must
+ have a public no-arg constructor. This element is optional</text>
+ </assertion>
+ <assertion id="h">
+ <text>constraint-validator-factory: represents the fully qualified class name of the
+ ConstraintValidatorFactory implementation. When defined in XML, the implementation
+ must have a public no-arg constructor. This element is optional.</text>
+ </assertion>
+ <assertion id="i">
+ <text>constraint-mapping: represents the resource path of an XML mapping file</text>
+ </assertion>
+ <assertion id="j">
+ <text>More than one constraint-mapping element can be present</text>
+ </assertion>
+ <assertion id="k">
+ <text>Mappings provided via Configuration.addMapping(InputString) are added to the list
+ of mappings described via constraint-mapping</text>
+ </assertion>
+ <assertion id="l">
+ <text>The namespace javax.validation is reserved for use by this specification</text>
+ </assertion>
+ <assertion id="m">
+ <text>Properties defined via Configura- tion.addProperty(String, String) are added to
+ the properties defined via property</text>
+ </assertion>
+ <assertion id="n">
+ <text>If a property with the same name are defined in both XML and via the programmatic
+ API, the value provided via programmatic API has prior- ity</text>
+ </assertion>
+ <assertion id="o">
+ <text>If a public no-arg constructor is missing, a ValidationException is raised during
+ the Configura- tion.buildValidatorFactory() call</text>
+ </assertion>
+ </section>
+ <section id="4.4.7" title="Usage">
+ <assertion id="a">
+ <text>ValidatorFactory is a thread-safe object that should be built once per deployment
+ unit</text>
+ </assertion>
+ <assertion id="b">
+ <text>Validator is thread-safe too and should be considered a lightweight object</text>
+ </assertion>
+ </section>
+ <section id="5.1" title="Validator">
+ <assertion id="a">
+ <text>If a constraint definition or declaration hosted by the requested class (or any of
+ it's superclasses and interfaces ac- cording to the constraint propagation rules) is
+ invalid, a ValidationException is raised</text>
+ </assertion>
+ </section>
+ <section id="5.3" title="BeanDescriptor">
+ <assertion id="a">
+ <text>isBeanConstrained returns true if the given class (and superclasses and
+ interfaces) host at least one validation de- claration (either constraint or @Valid
+ annotation)</text>
+ </assertion>
+ <assertion id="b">
+ <text>getConstraintsForProperty returns a PropertyDescriptor object describing the
+ property level constraints (See Section 3.1.2). The property is uniquely identified
+ by its name as per the JavaBeans convention: field level and get- ter level
+ constraints of the given name are all returned</text>
+ </assertion>
+ </section>
+ <section id="5.4" title="PropertyDescriptor">
+ <assertion id="a">
+ <text>The isCascaded method returns true if the property is marked with @Valid</text>
+ </assertion>
+ </section>
+ <section id="5.5" title="ConstraintDescriptor">
+ <assertion id="a">
+ <text>If ConstraintDescriptor represents a composing annotation (see Section 2.3), the
+ returned annotation must reflect parameter overriding</text>
+ </assertion>
+ <assertion id="b">
+ <text>getAttributes returns a map containing the annotation attribute names as a key,
+ and the annotation attribute val- ues as a value</text>
+ </assertion>
+ <assertion id="c">
+ <text>If ConstraintDescriptor represents a composing annotation (see Section 2.3), the
+ returned Map must reflect attribute overriding</text>
+ </assertion>
+ <assertion id="d">
+ <text>getGroups returns the groups the constraint is supposed to be applied upon</text>
+ </assertion>
+ <assertion id="e">
+ <text>If no group is set on the constraint de- claration, the Default group is
+ returned</text>
+ </assertion>
+ <assertion id="f">
+ <text>The groups of a composing constraint are the groups of the composed con-
+ straint</text>
+ </assertion>
+ </section>
+ <section id="6" title="Built-in Constraint definitions">
+ <assertion id="a">
+ <text>Each Bean Validation provider must recognize built-in constraint annotations as
+ valid constraint definitions and provide compliant constraint implementations for
+ each</text>
+ </assertion>
+ <assertion id="b">
+ <text>The built-in constraint validation implementation is having a lower priority than
+ an XML mapping definition</text>
+ </assertion>
+ <assertion id="c">
+ <text>@Null constraint</text>
+ </assertion>
+ <assertion id="d">
+ <text>@NotNull constraint</text>
+ </assertion>
+ <assertion id="e">
+ <text>@AssertTrue constraint</text>
+ </assertion>
+ <assertion id="f">
+ <text>@AssertFalse constraint</text>
+ </assertion>
+ <assertion id="g">
+ <text>@Min constraint</text>
+ </assertion>
+ <assertion id="h">
+ <text>@Max constraint</text>
+ </assertion>
+ <assertion id="i">
+ <text>@DecimalMin constraint</text>
+ </assertion>
+ <assertion id="j">
+ <text>@DecimalMax constraint</text>
+ </assertion>
+ <assertion id="k">
+ <text>@Size constraint</text>
+ </assertion>
+ <assertion id="l">
+ <text>@Digits constraint</text>
+ </assertion>
+ <assertion id="i">
+ <text>@Past constraint</text>
+ </assertion>
+ <assertion id="j">
+ <text>@Future constraint</text>
+ </assertion>
+ <assertion id="l">
+ <text>@Pattern constraint</text>
+ </assertion>
+ </section>
+ <section id="7.1" title="Constraint definition and declaration">
+ <assertion id="a">
+ <text>Specifically when exploring metadata, the Bean Validation provider must ensure
+ that an annotation instance corres- ponding to the XML declaration is provided via
+ ConstraintDescriptor.getAnnnotation()</text>
+ </assertion>
+ <assertion id="b">
+ <text>A given class must not be described more than once amongst all the XML mapping
+ descriptors</text>
+ </assertion>
+ <assertion id="c">
+ <text>A given field or getter must not be described more than once on a given class
+ description</text>
+ </assertion>
+ <assertion id="d">
+ <text>A given constraint definition must not be overridden more than once amongst all
+ the XML mapping descriptors</text>
+ </assertion>
+ <assertion id="e">
+ <text>If any of these rule is violated in a given validation deployment, a
+ ValidationException is raised during the creation of the ValidatorFactory</text>
+ </assertion>
+ </section>
+ <section id="7.1.1" title="Constraint declaration in XML">
+ <assertion id="a">
+ <text>If default-package is set, all unqualified class names (including annotations) are
+ considered part of the package described by default-package.</text>
+ </assertion>
+ <assertion id="b">
+ <text>A given JavaBean is described by the bean element. The name of the class is
+ mandatory</text>
+ </assertion>
+ <assertion id="c">
+ <text>By default, all constraint declarations expressed via annotation are ignored for
+ classes described in XML</text>
+ </assertion>
+ <assertion id="d">
+ <text>You can force Bean Validation to consider both annotations and XML constraint
+ declarations by using ignore-annotation="false" on bean</text>
+ </assertion>
+ <assertion id="e">
+ <text>If the name of the class does refer to a class not present in in the classpath, a
+ ValidationException is raised</text>
+ </assertion>
+ </section>
+ <section id="7.1.1.1" title="Class-level overriding">
+ <assertion id="a">
+ <text>If ignore-annotations is declared, Bean Validation must honor the explicit value
+ for this element</text>
+ </assertion>
+ <assertion id="b">
+ <text>If not declared, the default value defined in the encapsulating bean element is
+ considered</text>
+ </assertion>
+ <assertion id="c">
+ <text>When ignore-annotations is true, class-level Bean Validation annotations are
+ ignored for this class</text>
+ </assertion>
+ <assertion id="d">
+ <text>When ignore-annotations is false, constraints declared in XML and constraints
+ declared in annotations are added and form the list of class-level declared
+ constraints</text>
+ </assertion>
+ <assertion id="e">
+ <text>@GroupSequence is considered unless group-sequence element is explicitly
+ used</text>
+ </assertion>
+ </section>
+ <section id="7.1.1.2" title="Field-level overriding">
+ <assertion id="a">
+ <text>If ignore-annotations is declared, Bean Validation must honor the explicit value
+ for this element</text>
+ </assertion>
+ <assertion id="b">
+ <text>If not declared, the default value defined in the encapsulating bean element is
+ considered</text>
+ </assertion>
+ <assertion id="c">
+ <text>When ignore-annotations is true, field-level Bean Validation annotations on the
+ targeted field are ignored</text>
+ </assertion>
+ <assertion id="d">
+ <text>When ignore-annotations is false, constraints declared in XML and constraints
+ declared in annotations are added and form the list of field-level declared
+ constraints</text>
+ </assertion>
+ <assertion id="e">
+ <text>@Valid is considered unless the valid element is explicitly used</text>
+ </assertion>
+ <assertion id="f">
+ <text>Note that the only way to disable cascading on a field marked as @Valid is to use
+ ignore-validation=true</text>
+ </assertion>
+ <assertion id="g">
+ <text>If the name of the field does not correspond to a field in the given bean a
+ ValidationException is raised</text>
+ </assertion>
+ </section>
+ <section id="7.1.1.3" title="Property-level overriding">
+ <assertion id="a">
+ <text>The name attribute correspond to the name of the property considered as defined in
+ Section 3.1.2. If ignore-annotations is declared, Bean Validation must honor the
+ explicit value for this element</text>
+ </assertion>
+ <assertion id="b">
+ <text>If not declared, the default value defined in the encapsulating bean element is
+ con- sidered</text>
+ </assertion>
+ <assertion id="c">
+ <text>When ignore-annotations is true, property-level Bean Validation annotations on the
+ targeted property are ig- nored (including the @Valid)</text>
+ </assertion>
+ <assertion id="d">
+ <text>When ignore-annotations is false, constraints declared in XML and constraints
+ declared in annotations are added and form the list of property- level declared
+ constraints.</text>
+ </assertion>
+ <assertion id="e">
+ <text>@Valid is considered unless the valid element is explicitly used</text>
+ </assertion>
+ <assertion id="f">
+ <text>Note that the only way to disable cascading on a property marked as @Valid is to
+ use ignore-validation=true</text>
+ </assertion>
+ <assertion id="g">
+ <text>If the name of the property does not correspond to a property in the given bean a
+ ValidationException is raised</text>
+ </assertion>
+ </section>
+ <section id="7.1.1.4" title="Constraint declaration">
+ <assertion id="a">
+ <text>The name attribute is mandatory and repres- ents the name of the element in the
+ constraint declaration</text>
+ </assertion>
+ <assertion id="b">
+ <text>“message”, “groups” are not permitted names, use the message or groups
+ elements instead. Otherwise a ValidationException is raised</text>
+ </assertion>
+ <assertion id="c">
+ <text>If the element represents a primitive type, a class or an enum, the string
+ representation of its value is placed in the element itself</text>
+ </assertion>
+ <assertion id="d">
+ <text>If the element represents a primitive type array, a class array or an enum array,
+ the string representation of each value is placed in a element placed under the
+ element itself</text>
+ </assertion>
+ <assertion id="e">
+ <text>If the element represents an annotation, the annotation element is used to
+ represent the annotation and placed un- der element</text>
+ </assertion>
+ <assertion id="f">
+ <text>If the element represents an array of annotations, one or more annotation elements
+ are placed under element</text>
+ </assertion>
+ <assertion id="g">
+ <text>Elements with default values in the annotation definition do not have to be
+ represented in XML: the default value will be used in this case</text>
+ </assertion>
+ <assertion id="h">
+ <text>If an XML constraint declaration is missing mandatory elements, or if it contains
+ elements not part of the constraint definition, a ValidationException is
+ raised</text>
+ </assertion>
+ </section>
+ <section id="7.1.2" title="Overriding constraint definitions in XML">
+ <assertion id="a">
+ <text>A constraint definition is represented by a constraint-definition element</text>
+ </assertion>
+ <assertion id="b">
+ <text>If include-existing-validator is set to false, ConstraintValidator defined on the
+ constraint annotation are ig- nored</text>
+ </assertion>
+ <assertion id="c">
+ <text>If set to true, the list of ConstraintValidators described in XML are concatenated
+ to the list of Con- straintValidator described on the annotation to form a new array
+ of ConstraintValidator evaluated</text>
+ </assertion>
+ <assertion id="d">
+ <text>Annota- tion based ConstraintValidator come before XML based ConstraintValidatot
+ in the array</text>
+ </assertion>
+ <assertion id="e">
+ <text>The new list is re- turned by
+ ConstraintDescriptor.getConstraintValidatorClasses()</text>
+ </assertion>
+ </section>
+ <section id="8" title="Exception model">
+ <assertion id="a">
+ <text>Every (runtime) exception raised either at initialization time or execution time
+ by any of the extension interfaces (ConstraintValidator, ConstraintValidatorFactory,
+ MessageInterpolator, TraversableResolver, Valida- tionProviderResolver) is wrapped
+ in a ValidationException</text>
+ </assertion>
+ </section>
+ <section id="8.2" title="ConstraintDefinitionException">
+ <assertion id="a">
+ <text>If a constraint definition does not respect the Bean Validation rules or is
+ inconsistent, a ConstraintDefinitionEx- ception is raised</text>
+ </assertion>
+ </section>
+ <section id="8.3" title="ConstraintDeclarationException and UnexpectedTypeException">
+ <assertion id="a">
+ <text>When a constraint declaration is illegal, ConstraintDeclarationException is
+ raised</text>
+ </assertion>
+ <assertion id="b">
+ <text>When the return type of a property cannot be processed for a given constraint, an
+ UnexpectedTypeException is raised</text>
+ </assertion>
+ </section>
+ <section id="8.4" title="GroupDefinitionException">
+ <assertion id="a">
+ <text>When a group definition is illegal, GroupDefinitionException is raised</text>
+ </assertion>
+ </section>
</specification>
More information about the hibernate-commits
mailing list