[webbeans-commits] Webbeans SVN: r2767 - tck/trunk/impl/src/main/resources.

webbeans-commits at lists.jboss.org webbeans-commits at lists.jboss.org
Thu Jun 4 22:37:14 EDT 2009


Author: shane.bryzak at jboss.com
Date: 2009-06-04 22:37:14 -0400 (Thu, 04 Jun 2009)
New Revision: 2767

Modified:
   tck/trunk/impl/src/main/resources/tck-audit.xml
Log:
updated section 8 assertions

Modified: tck/trunk/impl/src/main/resources/tck-audit.xml
===================================================================
--- tck/trunk/impl/src/main/resources/tck-audit.xml	2009-06-04 23:59:36 UTC (rev 2766)
+++ tck/trunk/impl/src/main/resources/tck-audit.xml	2009-06-05 02:37:14 UTC (rev 2767)
@@ -3354,6 +3354,157 @@
     
   </section>
   
+  <section id="8" title="Decorators">
+    <assertion id="a">
+      <text>Decorators may be bound to any managed bean that is not itself an interceptor or decorator or to any EJB session or message-driven bean.</text>
+    </assertion>
+  </section>
+  
+  <section id="8.1" title="Decorator beans">
+    <assertion id="a">
+      <text>A decorator is a managed bean.</text>
+    </assertion>
+    
+    <assertion id="b">
+      <text>The set of decorated types of a decorator includes all interfaces implemented directly or indirectly by the bean class, except for |java.io.Serializable|.</text>
+    </assertion>
+    
+    <assertion id="c">
+      <text>The decorator bean class and its superclasses are not decorated types of the decorator.</text>
+    </assertion>
+    
+    <assertion id="d">
+      <text>The decorator class may be abstract.</text>
+    </assertion>
+  </section>
+  
+  <section id="8.1.1" title="Declaring a decorator">
+    <assertion id="a">
+      <text>A decorator is declared by annotating the bean class with the |@javax.decorator.Decorator| stereotype.</text>
+    </assertion>
+  </section>
+  
+  <section id="8.1.2" title="Decorator delegate injection points">
+    <assertion id="a">
+      <text>All decorators have a delegate injection point.  A delegate injection point is an injection point of the bean class. The type and bindings of the injection point are called the delegate type and delegate bindings. The delegate injection point must be be declared by annotating the field with the @javax.decorator.Decorates annotation.</text>
+    </assertion>
+    
+    <assertion id="b">
+      <text>The decorator applies to any bean that is eligible for injection to the delegate injection point, according to the rules defined
+in Section 5.1, "Typesafe resolution algorithm".</text>
+    </assertion>
+    
+    <assertion id="c">
+      <text>A decorator must have exactly one delegate injection point. If a decorator has more than one delegate injection point, or does not have a delegate injection point, 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>If a decorator applies to a managed bean, and the bean class is declared final, 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="e">
+      <text>If a decorator applies to a managed bean with a non-static, non-private, final method, and the decorator also implements that method, 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="f">
+      <text>When the container must inject a delegate object to the delegate injection point, the delegate object implements the delegate
+type and delegates method invocations along the decorator stack.</text>
+    </assertion>
+  </section>
+  
+  <section id="8.1.3" title="Decorated types of a decorator">
+    <assertion id="a">
+      <text>The delegate type of a decorator must implement or extend every decorated type. If the delegate type does not implement or extend a decorated type of the decorator, 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="b">
+      <text>A decorator is not required to implement the delegate type.</text>
+    </assertion>
+    
+    <assertion id="c">
+      <text>A decorator may be an abstract Java class, and is not required to implement every method of every decorated type.</text>
+    </assertion>
+    
+    <assertion id="d">
+      <text>The decorator intercepts every method declared by a decorated type of the decorator, and that is implemented by the bean class of the decorator.</text>
+    </assertion>
+  </section>
+  
+  <section id="8.2" title="Decorator enablement and ordering">
+    <assertion id="a">
+      <text>By default, decorators are not enabled. A decorator must be explicitly enabled by listing its bean class under the
+|&lt;Decorators&gt;| element in |beans.xml|.</text>
+    </assertion>
+    
+    <assertion id="b">
+      <text>The order of the decorator declarations determines the decorator ordering. Decorators which occur earlier in the list are called first.</text>
+    </assertion>
+    
+    <assertion id="c">
+      <text>If a class listed under the |&lt;Decorators&gt;| element is not the bean class of at least one decorator, 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 a decorator with a disabled deployment type is listed under the |&lt;Decorators&gt;| 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 |&lt;Decorators&gt;| 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>Decorators are called after interceptors.</text>
+    </assertion>
+  </section>
+  
+  <section id="8.3" title="Decorator resolution">
+    <assertion id="a">
+      <text>The following algorithm must be used by the container when resolving decorators for a certain bean - First, the container identifies the set of matching enabled decorators such that the bean is eligible for injection to the delegate injection point according to the rules defined in Section 5.1, "Typesafe resolution algorithm". Next, the container orders the matching decorators according to the decorator ordering specified in Section 8.2, "Decorator enablement and ordering".</text>
+    </assertion>
+  </section>
+  
+  <section id="8.4" title="Decorator stack creation">
+    <assertion id="a">
+      <text>When a bean with decorators is created, the container must
+identify the decorators for the bean according to Section 8.3, "Decorator resolution", and for each decorator, obtain a contextual reference, as defined in Section 6.5.3, "Contextual reference for a bean", and build an ordered list of the decorator instances.</text>
+    </assertion>
+  </section>
+  
+  <section id="8.5" title="Decorator invocation">
+    <assertion id="a">
+      <text>Whenever a business method is invoked on an instance of a bean with decorators, the container intercepts the business method invocation and, after processing the interceptor stack, invokes decorators of the bean. The container searches for the first decorator in the decorator stack for the instance that implements the method that is being
+invoked as a business method.</text>
+    </assertion>
+    
+    <assertion id="b">
+      <text>If no such decorator exists, the container invokes the business method of the intercepted instance.</text>
+    </assertion>
+    
+    <assertion id="c">
+      <text>Otherwise, the container calls the method of the decorator.</text>
+    </assertion>
+        
+    <assertion id="d">
+      <text>When any decorator is invoked by the container, it may in turn invoke a method of the delegate. The container intercepts the delegate invocation and searches for the first decorator in the decorator stack for the instance such that the decorator implements the method that is being invoked upon the delegate, and the decorator has not previously been invoked during this business method invocation.</text>
+    </assertion>
+    
+    <assertion id="e">
+      <text>If no such decorator exists, the container invokes the business method of the intercepted instance.</text>
+    </assertion>
+    
+    <assertion id="f">
+      <text>Otherwise, the container calls the method of the decorator.</text>
+    </assertion>
+  </section>
+  
+  
+  
+  
+  
+  
   <section id="7" title="Events">
   
   </section>




More information about the weld-commits mailing list