[webbeans-commits] Webbeans SVN: r2768 - tck/trunk/impl/src/main/resources.
webbeans-commits at lists.jboss.org
webbeans-commits at lists.jboss.org
Fri Jun 5 05:42:47 EDT 2009
Author: shane.bryzak at jboss.com
Date: 2009-06-05 05:42:47 -0400 (Fri, 05 Jun 2009)
New Revision: 2768
Modified:
tck/trunk/impl/src/main/resources/tck-audit.xml
Log:
updated section 9 assertions
Modified: tck/trunk/impl/src/main/resources/tck-audit.xml
===================================================================
--- tck/trunk/impl/src/main/resources/tck-audit.xml 2009-06-05 02:37:14 UTC (rev 2767)
+++ tck/trunk/impl/src/main/resources/tck-audit.xml 2009-06-05 09:42:47 UTC (rev 2768)
@@ -3500,15 +3500,170 @@
</assertion>
</section>
+ <section id="9" title="Interceptor bindings">
+
+ </section>
+ <section id="9.1" title="Interceptor binding types">
+ <assertion id="a">
+ <text>An interceptor binding type is a Java annotation defined as |@Target({TYPE, METHOD})| or |@Target(TYPE)| and |@Retention(RUNTIME)|./text>
+ </assertion>
+
+ <assertion id="b">
+ <text>An interceptor binding type may be declared by specifying the |@javax.interceptor.InterceptorBindingType| metaannotation.</text>
+ </assertion>
+
+ <assertion id="c">
+ <text>Multiple interceptors may be bound to the same interceptor binding type or types.</text>
+ </assertion>
+ </section>
+ <section id="9.1.1" title="Interceptor binding types with additional interceptor bindings">
+ <assertion id="a">
+ <text>An interceptor binding type may declare other interceptor bindings.</text>
+ </assertion>
+
+ <assertion id="b">
+ <text>Interceptor bindings are transitive—an interceptor binding declared by an interceptor binding type is inherited by all beans and other interceptor binding types that declare that interceptor binding type.</text>
+ </assertion>
+
+ <assertion id="c">
+ <text>Interceptor binding types declared |@Target(TYPE)| may not be applied to interceptor binding types declared |@Target({TYPE, METHOD})|.</text>
+ </assertion>
+ </section>
+ <section id="9.1.2" title="Interceptor bindings for stereotypes">
+ <assertion id="a">
+ <text>Interceptor bindings may be applied to a stereotype by annotating the stereotype annotation</text>
+ </assertion>
+
+ <assertion id="b">
+ <text>An interceptor binding declared by a stereotype are inherited by any bean that declares that stereotype.</text>
+ </assertion>
+
+ <assertion id="c">
+ <text>If a stereotype declares interceptor bindings, it must be defined as |@Target(TYPE)|.</text>
+ </assertion>
+ </section>
+ <section id="9.2" title="Declaring the interceptor bindings of an interceptor">
+ <assertion id="a">
+ <text>The interceptor bindings of an interceptor are specified by annotating the interceptor bean class with the binding types and the |@javax.interceptor.Interceptor| annotation.</text>
+ </assertion>
+
+ <assertion id="b">
+ <text>If an interceptor does not declare an |@Interceptor| annotation, it must be bound to beans using |@Interceptors| or |ejb-jar.xml|.</text>
+ </assertion>
+
+ <assertion id="c">
+ <text>All interceptors declared using |@Interceptor| must specify at least one interceptor binding. If an interceptor declared using |@Interceptor| does not declare any interceptor binding, the container automatically detects the problem and treats it as a definition error, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ </assertion>
+
+ <assertion id="d">
+ <text>An interceptor for lifecycle callbacks may only declare interceptor binding types that are defined as |@Target(TYPE)|. If an
+interceptor for lifecycle callbacks declares an interceptor binding type that is defined |@Target({TYPE, METHOD})|, the containerautomatically detects the problem and treats it as a definition error, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ </assertion>
+ </section>
- <section id="7" title="Events">
+ <section id="9.3" title="Binding an interceptor to a bean">
+ <assertion id="a">
+ <text>An interceptor binding may be declared by annotating the bean class, or a method of the bean class, with the interceptor binding type.</text>
+ </assertion>
+
+ <assertion id="b">
+ <text>Interceptors may be enabled or disabled at deployment time.</text>
+ </assertion>
+
+ <assertion id="c">
+ <text>Disabled interceptors are never called at runtime.</text>
+ </assertion>
+ </section>
+ <section id="9.4" title="Interceptor enablement and ordering">
+ <assertion id="a">
+ <text>By default, interceptors bound via interceptor bindings are not enabled. An interceptor must be explicitly enabled by listing
+its bean class under the |<Interceptors>| element in |beans.xml|.</text>
+ </assertion>
+
+ <assertion id="b">
+ <text>The order of the interceptor declarations determines the interceptor ordering. Interceptors which occur earlier in the list are
+called first.</text>
+ </assertion>
+
+ <assertion id="c">
+ <text>If a class listed under the |<Interceptors>| element is not the bean class of at least one interceptor, the container automatically detects the problem and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ </assertion>
+
+ <assertion id="d">
+ <text>If the bean class of an interceptor with a disabled deployment type is listed under the |<Interceptors>| element, the container automatically detects the problem and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ </assertion>
+
+ <assertion id="e">
+ <text>If the |<Interceptors>| element is specified in more than one |beans.xml| document, the container automatically detects the
+problem and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ </assertion>
+
+ <assertion id="f">
+ <text>Interceptors declared using |@Interceptors| or in |ejb-jar.xml| are called before interceptors declared using interceptor
+bindings.</text>
+ </assertion>
+
+ <assertion id="g">
+ <text>Interceptors are called before decorators.</text>
+ </assertion>
</section>
+ <section id="9.5" title="Interceptor resolution">
+ <assertion id="a">
+ <text>For a lifecycle callback, the bean interceptor bindings include the interceptor bindings declared by the bean at the class
+level, including interceptor bindings declared as meta-annotations of other interceptor bindings, recursively, and of stereotypes.
+ </text>
+ </assertion>
+
+ <assertion id="b">
+ <text>For a method, the bean interceptor bindings include the interceptor bindings declared by the bean at the class level, including
+interceptor bindings declared as meta-annotations of other interceptor bindings, recursively, and of stereotypes, together with all interceptor bindings declared at the method level, including interceptor bindings declared as meta-annotations of other interceptor bindings, recursively./text>
+ </assertion>
+
+ <assertion id="c">
+ <text>First, the container identifies the set of matching enabled interceptors where for each declared interceptor binding, there exists an interceptor binding in the set of bean interceptor bindings with (a) the same type and (b) the same annotation member value for each member which is not annotated |@javax.enterprise.inject.NonBinding| (see Section
+9.5.2, "Interceptor binding types with members").</text>
+ </assertion>
+
+ <assertion id="d">
+ <text>Next, the container narrows the set of matching interceptors according to whether the interceptor intercepts the given kind of lifecycle callback or business method.</text>
+ </assertion>
+
+ <assertion id="e">
+ <text>Next, the container orders the matching interceptors according to the interceptor ordering specified in Section 9.4, "Interceptor enablement and ordering" and returns the resulting list of interceptors. If no matching interceptors exist in the set, an empty list is returned.</text>
+ </assertion>
+ </section>
+
+ <section id="9.5.1" title="Interceptors with multiple bindings">
+ <assertion id="a">
+ <text>An interceptor class may specify multiple interceptor bindings, in which case the interceptor will be applied only to beans
+that declare all the bindings at the class level, and to methods of beans for which every binding appears at either the method or class level.</text>
+ </assertion>
+ </section>
+
+ <section id="9.5.2" title="Interceptor binding types with members">
+ <assertion id="a">
+ <text>Interceptor binding types may have annotation members.</text>
+ </assertion>
+
+ <assertion id="b">
+ <text>An annotation member may be excluded from consideration using the @NonBinding annotation.</text>
+ </assertion>
+
+ <assertion id="c">
+ <text>Array-valued or annotation-valued members of an interceptor binding type must be annotated |@NonBinding|. If an array-valued or annotation-valued member of an interceptor binding type is not annotated |@NonBinding|, the container automatically detects the problem and treats it as a definition error, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ </assertion>
+ </section>
+
+ <section id="10" title="Events">
+
+ </section>
+
<section id="7.1" title="Event types and binding types">
<assertion id="a">
More information about the weld-commits
mailing list