[webbeans-commits] Webbeans SVN: r2802 - tck/trunk/impl/src/main/resources.
webbeans-commits at lists.jboss.org
webbeans-commits at lists.jboss.org
Tue Jun 9 21:47:01 EDT 2009
Author: shane.bryzak at jboss.com
Date: 2009-06-09 21:47:00 -0400 (Tue, 09 Jun 2009)
New Revision: 2802
Modified:
tck/trunk/impl/src/main/resources/tck-audit.xml
Log:
updated section 12 assertions
Modified: tck/trunk/impl/src/main/resources/tck-audit.xml
===================================================================
--- tck/trunk/impl/src/main/resources/tck-audit.xml 2009-06-09 23:47:01 UTC (rev 2801)
+++ tck/trunk/impl/src/main/resources/tck-audit.xml 2009-06-10 01:47:00 UTC (rev 2802)
@@ -4774,290 +4774,134 @@
<text>A bean registered with an activity is only available to Unified EL expressions that are evaluated when that activity or one of its children is the current activity.</text>
</assertion>
</section>
-
-
-
-
-
-
-
-
- <section id="11" title="Packaging and Deployment">
+ <section id="12" title="Packaging and Deployment">
</section>
- <section id="11.1" title="Deployment lifecycle">
+ <section id="12.1" title="Bean deployment archives">
<assertion id="a">
- <text>First, the container performs bean discovery and registers |Bean| and |Observer| objects for the discovered beans. The container detects definition errors by validating the bean classes and metadata, throwing a |DeploymentException| and aborting deployment of the application if any definition errors exist, as defined in Section 10.1, "Definition errors".</text>
- <note>Test that beans and observers are registered and definition exceptions occur before @Initialized, and that this causes the app deployment to fail</note>
+ <text>Bean classes must be deployed in any EAR, JAR, WAR, EJB-JAR or RAR archive or directory in the application classpath that has a file named |beans.xml| in the metadata directory (META-INF, or WEB-INF in the case of a WAR). Any such archive or directory is called a bean deployment archive.</text>
</assertion>
<assertion id="b">
- <text>Next, the container raises an event of type |@Initialized Manager|, allowing the application or third-party frameworks to register additional |Bean| and |Observer| objects.</text>
- <note>Test that the @Initialized event is called, and that beans are registered</note>
+ <text>When searching for beans, the container considers any Java class in any bean deployment archive, and any |ejb-jar.xml| file in any bean deployment archive.</text>
</assertion>
<assertion id="c">
- <text>Next, the container detects deployment problems by validating bean dependencies and specialization, throwing a |DeploymentException| and aborting deployment of the application if any deployment problems exist, as defined in Section 10.2, "Deployment problems".</text>
- <note>Test that validation happens after @Initialized and before @Deployed and that deployment problems cause deployment to fail</note>
- </assertion>
-
- <assertion id="d">
- <text>Next, the container raises an event of type |@Deployed Manager|.</text>
- <note>Test that the @Deployed event is called</note>
- </assertion>
-
- <assertion id="e">
- <text>Finally, the container begins directing requests to the application.</text>
- <note>Test that the app is usable</note>
- </assertion>
-
+ <text>If a bean is deployed to a location that is not in the application classpath, or does not contain a file named |beans.xml| in the metadata directory, it will not be discovered by the container.</text>
+ </assertion>
</section>
-
- <section id="11.2" title="Bean discovery">
- <assertion id="a" implied="true">
- <text>When bean discovery occurs, the container considers any |beans.xml| file in any metadata directory of the application classpath (standalone WAR)</text>
+
+ <section id="12.2" title="Application initialization lifecycle">
+ <assertion id="a">
+ <text>When an application is started, the container performs the following steps.</text>
</assertion>
- <assertion id="b" implied="true">
- <text>When bean discovery occurs, the container considers any |beans.xml| file in any metadata directory of the application classpath (jar in |WEB-INF/lib| of standalone WAR)</text>
+ <assertion id="b">
+ <text>First, the container must search for service providers for the service |javax.enterprise.inject.spi.Extension| defined in Section 11.5, "Container lifecycle events", instantiate a single instance of each service provider, and search the service provider class for observer methods of initialization events.</text>
</assertion>
- <assertion id="c" implied="true">
- <text>When bean discovery occurs, the container considers any |beans.xml| file in any metadata directory of the application classpath (WAR in EAR)</text>
+ <assertion id="c">
+ <text>Next, the container must fire an event of type |BeforeBeanDiscovery|, as defined in Section 11.5.1, "BeforeBeanDiscovery event".</text>
</assertion>
- <assertion id="d" implied="true">
- <text>When bean discovery occurs, the container considers any |beans.xml| file in any metadata directory of the application classpath (jar in |WEB-INF/lib| of WAR in EAR)</text>
+ <assertion id="d">
+ <text>Next, the container must perform bean discovery, and abort initialization of the application if any definition errors exist, as defined in Section 12.4, "Problems detected automatically by the container".</text>
</assertion>
- <assertion id="e" implied="true">
- <text>When bean discovery occurs, the container considers any |beans.xml| file in any metadata directory of the application classpath (ejb-jar)</text>
+ <assertion id="e">
+ <text>Next, the container must fire an event of type |AfterBeanDiscovery|, as defined in Section 11.5.2, "AfterBeanDiscovery event", and abort initialization of the application if any observer registers a definition error.</text>
</assertion>
-
- <assertion id="f" implied="true">
- <text>When bean discovery occurs, the container considers any |beans.xml| file in any metadata directory of the application classpath (jar in EAR lib directory)</text>
+
+ <assertion id="f">
+ <text>Next, the container must detect deployment problems by validating bean dependencies and specialization and abort initialization of the application if any deployment problems exist, as defined in Section 12.4, "Problems detected automatically by the container".</text>
</assertion>
<assertion id="g">
- <text>When bean discovery occurs, the container considers any |ejb-jar.xml| file in any metadata directory of the application classpath that also contains a |beans.xml| file</text>
- <note>What does this mean?</note>
+ <text>Next, the container must fire an event of type |AfterDeploymentValidation|, as defined in Section 11.5.3, "AfterDeploymentValidation event", and abort initialization of the application if any observer registers a deployment problem.</text>
</assertion>
- <assertion id="h" implied="true">
- <text>When bean discovery occurs, the container considers any Java class in any archive or directory in the classpath that has a |beans.xml| file in the metadata directory (standalone WAR)</text>
+ <assertion id="h">
+ <text>Finally, the container begins directing requests to the application.</text>
+ </assertion>
+ </section>
+
+ <section id="12.3" title="Bean discovery">
+ <assertion id="a">
+ <text>The container automatically discovers managed beans (according to the rules of Section 3.2.1, "Which Java classes are managed beans?") and session beans in bean deployment archives and searches the bean classes for producer methods, producer fields, disposal methods and observer methods.</text>
</assertion>
- <assertion id="i" implied="true">
- <text>When bean discovery occurs, the container considers any Java class in any archive or directory in the classpath that has a |beans.xml| file in the metadata directory (jar in |WEB-INF/lib| of standalone WAR)</text>
+ <assertion id="b">
+ <text>For each Java class in any bean deployment archive, the container must create an |AnnotatedType| representing the class and fire an event of type |ProcessAnnotatedType|, as defined in Section
+11.5.5, "ProcessAnnotatedType event".</text>
</assertion>
- <assertion id="j" implied="true">
- <text>When bean discovery occurs, the container considers any Java class in any archive or directory in the classpath that has a |beans.xml| file in the metadata directory (WAR in EAR)</text>
+ <assertion id="c">
+ <text>For each Java class in any bean deployment archive, the container must inspect the class metadata to determine if it is a bean or other Java EE component class supporting injection.</text>
</assertion>
- <assertion id="k" implied="true">
- <text>When bean discovery occurs, the container considers any Java class in any archive or directory in the classpath that has a |beans.xml| file in the metadata directory (jar in |WEB-INF/lib| of WAR in EAR)</text>
+ <assertion id="d">
+ <text>For each Java class in any bean deployment archive, the container must detect definition errors by validating the class and its metadata.</text>
</assertion>
- <assertion id="l" implied="true">
- <text>When bean discovery occurs, the container considers any Java class in any archive or directory in the classpath that has a |beans.xml| file in the metadata directory (ejb-jar)</text>
+ <assertion id="e">
+ <text>For each Java class in any bean deployment archive, the container must, if the class is a managed bean, session bean, producer method or field, or other Java EE component class supporting injection, create an |InjectionTarget| for the class, as defined in Section 11.4.1, "The InjectionTarget interface", and fire an event of type |ProcessInjectionTarget|, as defined in Section 11.5.6, "ProcessInjectionTarget event"</text>
</assertion>
-
- <assertion id="m" implied="true">
- <text>When bean discovery occurs, the container considers any Java class in any archive or directory in the classpath that has a |beans.xml| file in the metadata directory (jar in EAR lib dir)</text>
- </assertion>
-
- <assertion id="n">
- <text>First, the container discovers all binding types~, stereotypes and interceptor binding types~ declared in XML, according to the rules of Section 9.4, "Stereotype, binding type and interceptor binding type declarations".</text>
- </assertion>
- <assertion id="o">
- <text>First, the container discovers all ~binding types~, stereotypes ~and interceptor binding types~ declared in XML, according to the rules of Section 9.4, "Stereotype, binding type and interceptor binding type declarations".</text>
+ <assertion id="f">
+ <text>For each Java class in any bean deployment archive, the container must, if the class is a bean, create a |Bean| object that implements the rules defined in Chapter 7, "Bean lifecycle", and fire an event of type |ProcessBean|, as defined in Section 11.5.7, "ProcessBean event".</text>
</assertion>
-
- <assertion id="p">
- <text>First, the container discovers all ~binding types, stereotypes and~ interceptor binding types declared in XML, according to the rules of Section 9.4, "Stereotype, binding type and interceptor binding type declarations".</text>
- </assertion>
-
- <assertion id="q">
- <text>The container automatically discovers simple beans (according to the rules of Section 3.2.1, "Which Java classes are beans?") ~and session beans (according to the rules of Section 3.3.2, "Which EJBs are beans?") deployed and/or declared in these locations and searches the bean classes for producer methods, producer fields, disposal methods and observer methods declared using annotations.~</text>
- <note>Check all archive types enumerated above</note>
- </assertion>
-
- <assertion id="r">
- <text>The container automatically discovers ~simple beans (according to the rules of Section 3.2.1, "Which Java classes are beans?") and~ session beans (according to the rules of Section 3.3.2, "Which EJBs are beans?")~ deployed and/or declared in these locations and searches the bean classes for producer methods, producer fields, disposal methods and observer methods declared using annotations.~</text>
- <note>Check all archive types enumerated above</note>
- </assertion>
-
- <assertion id="s">
- <text>The container automatically discovers ~simple beans (according to the rules of Section 3.2.1, "Which Java classes are beans?") and session beans (according to the rules of Section 3.3.2, "Which EJBs are beans?") deployed and/or declared in these locations and searches the bean classes for~ producer methods, ~producer fields, disposal methods and observer methods~ declared using annotations.</text>
- <note>Check all archive types enumerated above, and session beans and simple beans</note>
- </assertion>
-
- <assertion id="t">
- <text>The container automatically discovers ~simple beans (according to the rules of Section 3.2.1, "Which Java classes are beans?") and session beans (according to the rules of Section 3.3.2, "Which EJBs are beans?") deployed and/or declared in these locations and searches the bean classes for producer methods~, producer fields~, disposal methods and observer methods~ declared using annotations.</text>
- <note>Check all archive types enumerated above, and session beans and simple beans</note>
- </assertion>
-
- <assertion id="u">
- <text>The container automatically discovers ~simple beans (according to the rules of Section 3.2.1, "Which Java classes are beans?") and session beans (according to the rules of Section 3.3.2, "Which EJBs are beans?") deployed and/or declared in these locations and searches the bean classes for producer methods, producer fields,~ disposal methods~ and observer methods~ declared using annotations.</text>
- <note>Check all archive types enumerated above, and session beans and simple beans</note>
- </assertion>
-
- <assertion id="v">
- <text>The container automatically discovers~ simple beans (according to the rules of Section 3.2.1, "Which Java classes are beans?") and session beans (according to the rules of Section 3.3.2, "Which EJBs are beans?") deployed and/or declared in these locations and searches the bean classes for producer methods, producer fields, disposal methods and~ observer methods declared using annotations.</text>
- <note>Check all archive types enumerated above, and session beans and simple beans</note>
- </assertion>
- <assertion id="z">
- <text>Next, the container determines which beans~, interceptors and decorators are enabled,~ according to the rules defined in Section 2.5.6, "Enabled deployment types", Section A.3.7, "Interceptor enablement and ordering" and Section A.5.5, "Decorator enablement and ordering", taking into account any |<Deploy>|, ~|<Interceptors>| and |<Decorators>|~ declarations in the |beans.xml| files.</text>
+ <assertion id="g">
+ <text>If the class is a bean, the container must search the class for producer methods and fields, and for each producer method or field create an InjectionTarget, as defined in Section 11.4.1, "The InjectionTarget interface", for the producer method or field and fire an event of type |ProcessInjectionTarget|, as defined in Section 11.5.6, "ProcessInjectionTarget event".</text>
</assertion>
- <assertion id="ac">
- <text>For each enabled bean that is not an interceptor or decorator, the container creates an instance of |Bean|, and registers it by calling |Manager.addBean()|</text>
- <note>Check that interceptors aren't registered as beans, decorators aren't registered as beans, that disabled beans aren't registered and that simple beans, session beans, producer methods and producer fields are registered</note>
+ <assertion id="h">
+ <text>If the class is a bean, the container must search the class for producer methods and fields, and for each producer method or field create a Bean object that implements the rules defined in Chapter 7, Bean lifecycle and fire an event of type |ProcessBean|, as defined in Section 11.5.7, "ProcessBean event".</text>
</assertion>
- <assertion id="af">
- <text>For each observer method of an enabled bean, the container creates an instance of |Observer| that implements the rules of Section 7.5.8, "Observer object for an observer method" and registers it by calling |Manager.addObserver()|</text>
+ <assertion id="i">
+ <text>If the class is a bean, the container must search the class for observer methods, and for each observer method create an Observer, as defined in Section 10.6.1, “Observer method notification”, for the observer method and fire an event of type ProcessObserver, as defined in Section 11.5.8, “ProcessObserver event”.</text>
</assertion>
- </section>
- <section id="11.5" title="Initialization and Deployment Events">
- <assertion id="a">
- <text>Container fires event of type Manager with binding type @Initialized after bean discovery but before deployment problems are detected.</text>
- </assertion>
-
- <assertion id="b">
- <text>The container must fire a second event of type Manager with binding type @Deployed after it has validated that there are no deployment problems and before the deployment begins processing requests.</text>
- </assertion>
-
- <assertion id="c">
- <text>The container must not allow any request to be processed by the deployment until all observers of this event return.</text>
- </assertion>
-
- <assertion id="d">
- <text>The request and application contexts are active when these events are fired.</text>
- </assertion>
-
- <assertion id="aa">
- <text>If any observer method of the @Initialized event throws an exception, the exception is treated as a definition error by the container.</text>
- </assertion>
-
- <assertion id="ba">
- <text> f any observer method of the @Deployed event throws an exception, the exception is treated as a deployment problem by the container.</text>
- </assertion>
- </section>
-
- <section id="11.6" title="Activities">
-
- <assertion id="a" testable="false">
- <text>The method |createActivity()| creates a new child activity of an activity:</text>
- <note>A statement of intent</note>
- </assertion>
-
- <assertion id="b">
- <text>Every bean belonging to a parent activity also belongs to the child activity~, is eligible for injection into other beans belonging to the child activity and may be obtained by dynamic lookup via the child activity~</text>
- </assertion>
-
- <assertion id="c">
- <text>Every bean belonging to a parent activity ~also belongs to the child activity,~ is eligible for injection into other beans belonging to the child activity~ and may be obtained by dynamic lookup via the child activity~</text>
- </assertion>
-
- <assertion id="d">
- <text>Every bean belonging to a parent activity ~also belongs to the child activity, is eligible for injection into other beans belonging to the child activity and~ may be obtained by dynamic lookup via the child activity</text>
- </assertion>
-
<assertion id="j">
- <text>Every observer belonging to a parent activity also belongs to the child activity ~and receives events fired via the child activity~</text>
+ <text>For each session bean declared in |ejb-jar.xml| in any bean deployment archive the container must create a |Bean| object that implements the rules defined in Chapter 7, "Bean lifecycle" and fire an event of type ProcessBean.</text>
</assertion>
<assertion id="k">
- <text>Every observer belonging to a parent activity ~also belongs to the child activity and~ receives events fired via the child activity</text>
+ <text>The container determines which beans, interceptors and decorators are enabled, according to the rules defined in Section 2.5.5, "Enabled deployment types", Section 9.4, "Interceptor enablement and ordering" and Section 8.2, "Decorator enablement and ordering", taking into account any <Deploy>, <Interceptors> and <Decorators> declarations in the |beans.xml| files, and registers the |Bean| and |Observer| objects.</text>
</assertion>
-
+
<assertion id="l">
- <text>Every context object belonging to the parent activity also belongs to the child activity</text>
+ <text>For each enabled bean that is not an interceptor or decorator, the container creates and registers an instance of |Bean| that implements the rules of Chapter 7, "Bean lifecycle".</text>
</assertion>
<assertion id="m">
- <text>|Beans| ~and observers~ may be registered with an activity by calling |addBean()| ~or |addObserver()|~ on the |Manager| object that represents the activity.</text>
+ <text>For each enabled interceptor, the container creates and registers an instance of |Interceptor|, as defined in Section 11.1.2, "The Interceptor interface".</text>
</assertion>
<assertion id="n">
- <text>~|Beans| and~ observers may be registered with an activity by calling ~|addBean()| or~ |addObserver()| on the |Manager| object that represents the activity.</text>
- </assertion>
-
- <assertion id="o">
- <text>A bean registered with the child activity is not available for injection into any bean registered with a parent activity</text>
+ <text>For each enabled decorator, the container creates and registers an instance of |Decorator|, as defined in Section 11.1.1, "The Decorator interface".</text>
</assertion>
- <assertion id="p">
- <text>A bean registered with a child activity is not available for injection into a ~servlet or~ EJB</text>
+ <assertion id="o">
+ <text>For each observer method of an enabled bean, the container creates and registers an instance of |Observer| that implements the rules of Section 10.6.1, "Observer method notification".</text>
</assertion>
-
- <assertion id="q">
- <text>A bean registered with a child activity is not available for injection into a servlet ~or EJB~</text>
- </assertion>
-
- <assertion id="r">
- <text>A bean registered with a child activity may not be obtained by dynamic lookup via the parent activity</text>
- </assertion>
-
- <assertion id="s">
- <text>An observer registered with the child activity does not receive events fired via a parent activity</text>
- </assertion>
-
- <assertion id="t">
- <text>If a bean registered with a child activity has the bean type and all bindings of some injection point of some bean registered with a direct ~or indirect~ parent activity, a |DeploymentException| is throw by the container at deployment time.</text>
- </assertion>
-
- <assertion id="u">
- <text>If a bean registered with a child activity has the bean type and all bindings of some injection point of some bean registered with a~ direct or~ indirect parent activity, a |DeploymentException| is throw by the container at deployment time.</text>
- </assertion>
-
</section>
- <section id="11.6.1" title="Current Activity">
- <assertion id="a" testable="false">
- <text>An activity may be associated with the current context for a normal scope by calling |setCurrent()|, passing the normal scope type</text>
- <note>A statement of intent</note>
+ <section id="12.4" title="Problems detected automatically by the container">
+ <assertion id="a">
+ <text>Definition errors may be detected by tooling at development time, and are also detected by the container at initialization time. If a definition error exists in a deployment, initialization will be aborted by the container.</text>
</assertion>
<assertion id="b">
- <text>If the given scope is inactive when |setCurrent()| is called, a |ContextNotActiveException| is thrown.</text>
+ <text>Deployment problems are detected by the container at initialization time. If a deployment problem exists in a deployment, initialization will be aborted by the container.</text>
</assertion>
<assertion id="c">
- <text>If the given scope type is not a normal scope, an |IllegalArgumentException| is thrown.</text>
+ <text>Execution errors are represented by instances of |javax.enterprise.inject.InjectionException| and its subclasses.</text>
</assertion>
-
- <assertion id="d">
- <text>All EL evaluations (as defined Section 5.10, "EL name resolution")~, all calls to any injected |Manager| object or |Manager| object obtained via JNDI lookup (as defined by Section 5.7, "The Manager object"), all calls to any injected |Event| object (as defined in Section 7.6, "The Event interface") and all calls to any injected |Instance| object (as defined by Section 5.8, "Dynamic lookup")~ are processed by the current activity</text>
- </assertion>
-
- <assertion id="e">
- <text>~All EL evaluations (as defined Section 5.10, "EL name resolution"),~ all calls to any injected |Manager| object ~or |Manager| object obtained via JNDI lookup (as defined by Section 5.7, "The Manager object"), all calls to any injected |Event| object (as defined in Section 7.6, "The Event interface") and all calls to any injected |Instance| object (as defined by Section 5.8, "Dynamic lookup")~ are processed by the current activity</text>
- </assertion>
-
- <assertion id="f">
- <text>~All EL evaluations (as defined Section 5.10, "EL name resolution"),~ all calls to any ~injected |Manager| object or~ |Manager| object obtained via JNDI lookup~ (as defined by Section 5.7, "The Manager object"), all calls to any injected |Event| object (as defined in Section 7.6, "The Event interface") and all calls to any injected |Instance| object (as defined by Section 5.8, "Dynamic lookup")~ are processed by the current activity</text>
- </assertion>
-
- <assertion id="g">
- <text>~All EL evaluations (as defined Section 5.10, "EL name resolution"), all calls to any injected |Manager| object or |Manager| object obtained via JNDI lookup (as defined by Section 5.7, "The Manager object"),~ all calls to any injected |Event| object (as defined in Section 7.6, "The Event interface") ~and all calls to any injected |Instance| object (as defined by Section 5.8, "Dynamic lookup")~ are processed by the current activity</text>
- </assertion>
-
- <assertion id="h">
- <text>~All EL evaluations (as defined Section 5.10, "EL name resolution"), all calls to any injected |Manager| object or |Manager| object obtained via JNDI lookup (as defined by Section 5.7, "The Manager object"), all calls to any injected |Event| object (as defined in Section 7.6, "The Event interface") and ~all calls to any injected |Instance| object (as defined by Section 5.8, "Dynamic lookup") are processed by the current activity</text>
- </assertion>
-
- <assertion id="m">
- <text>A bean registered with an activity is only available to Unified EL expressions that are evaluated when that activity or one of its children is the current activity.</text>
- <note>This is a statement of intent</note>
- </assertion>
</section>
</specification>
More information about the weld-commits
mailing list