Weld SVN: r4597 - build/tags.
by weld-commits＠lists.jboss.org
Author: pete.muir(a)jboss.org
Date: 2009-11-03 07:38:34 -0500 (Tue, 03 Nov 2009)
New Revision: 4597
Added:
build/tags/weld-parent-5/
Log:
[maven-scm] copy for tag weld-parent-5
Copied: build/tags/weld-parent-5 (from rev 4596, build/trunk/parent)
16 years, 5 months
- 1
- 0
Weld SVN: r4596 - build/trunk/parent.
by weld-commits＠lists.jboss.org
Author: pete.muir(a)jboss.org
Date: 2009-11-03 07:38:17 -0500 (Tue, 03 Nov 2009)
New Revision: 4596
Modified:
build/trunk/parent/pom.xml
Log:
[maven-release-plugin] prepare release weld-parent-5
Modified: build/trunk/parent/pom.xml
===================================================================
--- build/trunk/parent/pom.xml 2009-11-03 12:31:17 UTC (rev 4595)
+++ build/trunk/parent/pom.xml 2009-11-03 12:38:17 UTC (rev 4596)
@@ -3,7 +3,7 @@
<groupId>org.jboss.weld</groupId>
<artifactId>weld-parent</artifactId>
<packaging>pom</packaging>
- <version>5-SNAPSHOT</version>
+ <version>5</version>
<name>Weld Parent</name>
@@ -454,6 +454,19 @@
</execution>
</executions>
</plugin>
+ <plugin>
+ <groupId>org.sonatype.plugins</groupId>
+ <artifactId>nexus-maven-plugin</artifactId>
+ <executions>
+ <execution>
+ <id>staging-close</id>
+ <phase>deploy</phase>
+ <goals>
+ <goal>staging-close</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
</plugins>
</build>
</profile>
@@ -462,9 +475,9 @@
<!-- SCM and Distribution Management -->
<scm>
- <connection>scm:svn:http://anonsvn.jboss.org/repos/weld/build/trunk/parent</connection>
- <developerConnection>scm:svn:https://svn.jboss.org/repos/weld/build/trunk/parent</developerConnection>
- <url>http://fisheye.jboss.org/browse/Weld/build/trunk/parent</url>
+ <connection>scm:svn:http://anonsvn.jboss.org/repos/weld/build/tags/weld-parent-5</connection>
+ <developerConnection>scm:svn:https://svn.jboss.org/repos/weld/build/tags/weld-parent-5</developerConnection>
+ <url>http://fisheye.jboss.org/browse/Weld/build/tags/weld-parent-5</url>
</scm>
<distributionManagement>
16 years, 5 months
- 1
- 0
Weld SVN: r4595 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: gavin.king(a)jboss.com
Date: 2009-11-03 07:31:17 -0500 (Tue, 03 Nov 2009)
New Revision: 4595
Modified:
doc/trunk/reference/en-US/intro.xml
Log:
minor
Modified: doc/trunk/reference/en-US/intro.xml
===================================================================
--- doc/trunk/reference/en-US/intro.xml 2009-11-03 10:34:47 UTC (rev 4594)
+++ doc/trunk/reference/en-US/intro.xml 2009-11-03 12:31:17 UTC (rev 4595)
@@ -40,7 +40,7 @@
JavaBean and every EJB session bean. If you've already got some JavaBeans or session beans lying around,
they're already beans—you won't need any additional special metadata. There's just little one thing you
need to do before you can start injecting them into stuff: you need to put them in an archive (a jar, or a
- Java EE module like a war or ejb-jar) that contains a special marker file: <literal>META-INF/beans.xml</literal>.
+ Java EE module such as a war or EJB jar) that contains a special marker file: <literal>META-INF/beans.xml</literal>.
</para>
<para>
16 years, 5 months
- 1
- 0
Weld SVN: r4594 - api/trunk/cdi/src/main/java/javax/enterprise/inject.
by weld-commits＠lists.jboss.org
Author: gavin.king(a)jboss.com
Date: 2009-11-03 05:34:47 -0500 (Tue, 03 Nov 2009)
New Revision: 4594
Modified:
api/trunk/cdi/src/main/java/javax/enterprise/inject/package-info.java
Log:
minor
Modified: api/trunk/cdi/src/main/java/javax/enterprise/inject/package-info.java
===================================================================
--- api/trunk/cdi/src/main/java/javax/enterprise/inject/package-info.java 2009-11-03 10:26:28 UTC (rev 4593)
+++ api/trunk/cdi/src/main/java/javax/enterprise/inject/package-info.java 2009-11-03 10:34:47 UTC (rev 4594)
@@ -410,7 +410,7 @@
* resolves to a bean if:</p>
*
* <ul>
- * <li>The bean has the given EL name.</li>
+ * <li>the bean has the given EL name, and</li>
* <li>the bean is available for injection in the war containing the JSP or JSF
* page with the EL expression.</li>
* </ul>
16 years, 5 months
- 1
- 0
Weld SVN: r4593 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: gavin.king(a)jboss.com
Date: 2009-11-03 05:26:28 -0500 (Tue, 03 Nov 2009)
New Revision: 4593
Modified:
doc/trunk/reference/en-US/specialization.xml
Log:
id
Modified: doc/trunk/reference/en-US/specialization.xml
===================================================================
--- doc/trunk/reference/en-US/specialization.xml 2009-11-03 10:26:17 UTC (rev 4592)
+++ doc/trunk/reference/en-US/specialization.xml 2009-11-03 10:26:28 UTC (rev 4593)
@@ -43,7 +43,7 @@
alternatives and then show the guarantees that specialization adds.
</para>
- <section>
+ <section id="alternatives">
<title>Bean alternatives</title>
<para>
16 years, 5 months
- 1
- 0
Weld SVN: r4592 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: gavin.king(a)jboss.com
Date: 2009-11-03 05:26:17 -0500 (Tue, 03 Nov 2009)
New Revision: 4592
Modified:
doc/trunk/reference/en-US/intro.xml
doc/trunk/reference/en-US/part1.xml
Log:
various revisions
Modified: doc/trunk/reference/en-US/intro.xml
===================================================================
--- doc/trunk/reference/en-US/intro.xml 2009-11-03 10:24:58 UTC (rev 4591)
+++ doc/trunk/reference/en-US/intro.xml 2009-11-03 10:26:17 UTC (rev 4592)
@@ -1,12 +1,12 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [ ]>
<chapter id="intro">
- <title>Getting started with JSR-299 (CDI)</title>
+ <title>Getting started with CDI</title>
<para>
So you're keen to get started writing your first bean? Or perhaps you're skeptical, wondering what kinds of hoops
the CDI specification will make you jump through! The good news is that you've probably already written and used
- hundreds, perhaps thousands of beans. CDI just helps you make use them in your web or enterprise application.
+ hundreds, perhaps thousands of beans. CDI just makes it easier to actually use them to build an application!
</para>
<section id="bean-definition">
@@ -14,41 +14,42 @@
<para>
In this section, you'll learn that a bean is exactly what you think it is. Only now, it has a true identity in
- Java EE.
+ the container environment.
</para>
<para>
- Prior to Java EE 6, there existed no clear definition of a bean in the platform. Of course, we've been calling
- Java classes used in web and enterprise applications beans for years. Third-party frameworks, such as Spring,
- even have facilities for defining and creating beans; and there are a couple of bean variants in the platform
- itself, including EJB session beans and JSF managed beans. What was missing was a common definition.
+ Prior to Java EE 6, there was no clear definition of the term "bean" in the Java EE platform. Of course,
+ we've been calling Java classes used in web and enterprise applications "beans" for years. There were even a
+ couple of different kinds of things called "beans" in EE specifications, including EJB session beans and JSF
+ managed beans. Meanwhile, other third-party frameworks such as Spring and Seam introduced their own ideas of
+ what it meant to be a "bean". What we've been missing is a common definition.
</para>
<para>
- Java EE 6 finally lays down the definition of a bean in the Managed Bean specification. Managed Beans are
- defined as container-managed objects with minimal requirements, otherwise known by their acronym, POJOs (Plain
- Old Java Objects). They support a small set of basic services, such as resource injection, lifecycle callbacks
- and interceptors. Companion specifications, such as EJB and CDI, build on this basic model. But, <emphasis>at
- last</emphasis>, there is a universally accepted concept of a bean and a lightweight component model that's
+ Java EE 6 finally lays down that common definition in the Managed Beans specification. Managed Beans are
+ defined as container-managed objects with minimal programming restrictions, otherwise known by the acronym
+ POJO (Plain Old Java Object). They support a small set of basic services, such as resource injection, lifecycle
+ callbacks and interceptors. Companion specifications, such as EJB and CDI, build on this basic model. But,
+ <emphasis>at last</emphasis>, there is a uniform concept of a bean and a lightweight component model that's
aligned across the Java EE platform.
</para>
<para>
- With certain, unique exceptions, every Java class that has a constructor with no parameters (or an alternate
- constructor designated with the annotation <literal>@Inject</literal>) is a candidate for becoming a bean. Any
- EJB session bean is also a candidate. They become beans, specifically CDI beans, if they reside in a Java EE
- module that contains a special marker file (META-INF/beans.xml) and if instances of those classes are managed
- by the Java EE container. Just know that, for simple JavaBean classes, there's no special metadata you need to
- add to make them beans. They just are.
+ With very few exceptions, almost every concrete Java class that has a constructor with no parameters (or a
+ constructor designated with the annotation <literal>@Inject</literal>) is a bean. This includes every
+ JavaBean and every EJB session bean. If you've already got some JavaBeans or session beans lying around,
+ they're already beans—you won't need any additional special metadata. There's just little one thing you
+ need to do before you can start injecting them into stuff: you need to put them in an archive (a jar, or a
+ Java EE module like a war or ejb-jar) that contains a special marker file: <literal>META-INF/beans.xml</literal>.
</para>
<para>
- The JavaBeans and EJBs you've been writing every day, up until now, have not been able to take advantage of the
- new services defined by the CDI specification. But you'll be able to use every one of them with CDI --
- allowing the container to create and destroy instances of your beans and associate them with a designed context
- (or scope), injecting them into other beans, using them in EL expressions, specializing them with qualifier
- annotations, even adding interceptors and decorators to them—from this point forward without modifying
- your code. At most, you'll have to add some annotations.
+ The JavaBeans and EJBs you've been writing every day, up until now, have not been able to take advantage
+ of the new services defined by the CDI specification. But you'll be able to use every one of them with
+ CDI—allowing the container to create and destroy instances of your beans and associate them with a
+ designed context, injecting them into other beans, using them in EL expressions, specializing them with
+ qualifier annotations, even adding interceptors and decorators to them—without modifying your
+ existing code. At most, you'll need to add some annotations.
</para>
<para>
@@ -117,16 +118,16 @@
<para>
As you've guessed, the <literal>@Inject</literal> annotation has something to do with dependency injection!
- <literal>@Inject</literal> may be applied to a constructor or method of a bean, and tells the container to call
- that constructor or method when instantiating the bean. The container will inject other beans it finds into the
- parameters of the constructor or method.
+ <literal>@Inject</literal> may be applied to a constructor or method of a bean, and tells the container to
+ call that constructor or method when instantiating the bean. The container will inject other beans it finds
+ into the parameters of the constructor or method.
</para>
<para>
We may obtain an instance of <literal>TextTranslator</literal> by injecting it into a constructor, bean
- "setter" method, producer method, observer method or field of a JavaBean or EJB session, or a field of a
- Servlet. The injection is based on the type of the injection point, not the name of the field, method or
- argument.
+ "setter" method, producer method, observer method or field of a JavaBean or EJB session bean, or a field
+ of a servlet. The injection is based on the type of the injection point, not the name of the field, method
+ or parameter.
</para>
<para>
@@ -209,7 +210,8 @@
<para>
Now we are starting to venture off into the details, so let's pause and examine a bean's anatomy. What aspects
- of the bean are significant, and what gives it its identity?
+ of the bean are significant, and what gives it its identity? Instead of giving examples of beans, we're going
+ to define what <emphasis>makes</emphasis> something a bean.
</para>
</section>
@@ -218,8 +220,8 @@
<title>The anatomy of a bean</title>
<para>
- A bean is an application class that contains business logic. It may be called directly from Java code, or it
- may be invoked via Unified EL. A bean may access transactional resources. Dependencies between beans are
+ A bean is usually an application class that contains business logic. It may be called directly from Java code,
+ or it may be invoked via Unified EL. A bean may access transactional resources. Dependencies between beans are
managed automatically by the container. Most beans are <emphasis>stateful</emphasis> and
<emphasis>contextual</emphasis>. The lifecycle of a bean is always managed by the container.
</para>
@@ -279,12 +281,12 @@
<para>
We can replace one bean with another different bean that implements the same interface and has a different lifecycle
(a different scope) without affecting the other bean implementation. In fact, CDI defines a simple facility for
- overriding bean implementations at deployment time, as we will see in <xref linkend="alternatives"/> (FIXREF).
+ overriding bean implementations at deployment time, as we will see in <xref linkend="alternatives"/>.
</para>
<para>
- Note that not all clients of a bean are beans themselves. Other objects such as Servlets or Message-Driven
- Beans—which are by nature not injectable, contextual objects—may also obtain references to beans by
+ Note that not all clients of a bean are beans themselves. Other objects such as servlets or message-driven
+ beans—which are by nature not injectable, contextual objects—may also obtain references to beans by
injection.
</para>
@@ -292,17 +294,18 @@
<blockquote>
- <para>A bean comprises of the following attributes:</para>
+ <para>A bean comprises the following attributes:</para>
<itemizedlist>
<listitem><para>A (nonempty) set of bean types</para></listitem>
<listitem><para>A (nonempty) set of qualifiers</para></listitem>
<listitem><para>A scope</para></listitem>
- <listitem><para>A deployment type</para></listitem>
<listitem><para>Optionally, a bean EL name</para></listitem>
<listitem><para>A set of interceptor bindings</para></listitem>
<listitem><para>A bean implementation</para></listitem>
</itemizedlist>
+
+ <para>Furthermore, a bean may or may not be an alternative.</para>
</blockquote>
@@ -334,10 +337,14 @@
<para>
The bean types are <literal>BookShop</literal>, <literal>Business</literal> and
<literal>Shop<Book></literal>, as well as the implicit type <literal>java.lang.Object</literal>.
- (Notice that a parameterized type is a legal bean type). Meanwhile, this session bean has only the local
- interfaces <literal>BookShop</literal>, <literal>Auditable</literal> and <literal>java.lang.Object</literal>
- as bean types, since the bean class, <literal>BookShopBean</literal> is not a client-visible type.
+ (Notice that a parameterized type is a legal bean type).
</para>
+
+ <para>
+ Meanwhile, this session bean has only the local interfaces <literal>BookShop</literal>,
+ <literal>Auditable</literal> and <literal>java.lang.Object</literal> as bean types, since the bean class,
+ <literal>BookShopBean</literal> is not a client-visible type.
+ </para>
<programlisting role="JAVA"><![CDATA[@Stateful
public class BookShopBean extends Business implements BookShop, Auditable {
@@ -354,7 +361,7 @@
<para>
Bean types may be restricted to an explicit set by annotating the bean with the <literal>@Typed</literal>
annotation and listing the bean types in the value of the annotation. For instance, this bean has been
- restricted to a single bean type, <literal>Shop</literal>:
+ restricted to a single bean type, <literal>Shop<Book></literal>:
</para>
<programlisting role="JAVA"><![CDATA[(a)Typed(Shop.class)
@@ -364,7 +371,7 @@
<para>
The bean types alone often do not provide enough information for the container to know which bean to inject.
- For instance, say you have two implementations of the <literal>PaymentProcessor</literal> interface:
+ For instance, suppose we have two implementations of the <literal>PaymentProcessor</literal> interface:
<literal>CreditCardPaymentProcessor</literal> and <literal>DebitPaymentProcessor</literal>. Injecting into a
field of type <literal>PaymentProcessor</literal> introduces an ambigious condition. In these cases, the
container must rely on some client-visible semantic that is satisified by one implementation of the bean
@@ -374,7 +381,7 @@
<para>
Qualifiers are represented by user-defined annotations that are themselves annotated with
<literal>@Qualifer</literal>. These annotations extend the type system in Java to let you further qualify
- the type without having to fall back to string-based names as many dependency injection frameworks use.
+ the type without having to fall back to string-based names as in many other dependency injection solutions.
Here's an example of a qualifier annotation:
</para>
@@ -385,14 +392,15 @@
<para>
You may not be used to seeing the definition of an annotation. In fact, this might be the first time you
- have encountered one. With CDI, they will become very familiar artifact as you will be creating them often.
- Pay attention to the names of the built-in annotations in CDI and EJB.
+ have encountered one. With CDI, they will become very familiar artifact as you will be creating them from
+ time to time.
</para>
<tip>
<para>
- You'll notice that they are all adjectives. You are encouraged to follow this convention when creating
- your custom annotations, since they serve to describe the behaviors and roles of the class.
+ Pay attention to the names of the built-in annotations in CDI and EJB. You'll notice that they are
+ often adjectives. We encourage you to follow this convention when creating your custom annotations,
+ since they serve to describe the behaviors and roles of the class.
</para>
</tip>
@@ -411,12 +419,13 @@
</note>
<para>
- For each injection point, the container searches for a bean which satisfies the contract, meaning it matches
- the bean time and all the qualifiers. It then injects that instance.
+ For each injection point, the container searches for a bean which satisfies the contract, one which has
+ the bean type and all the qualifiers. If it find exactly one matching bean, it injects an instance of
+ that bean.
</para>
<para>
- We've seen how to indicate that you want to inject qualified bean. But how do you actually qualify the bean?
+ We've seen how to indicate that you want to inject a qualified bean. But how do you actually qualify the bean?
By using the annotation, of course! The following bean has the qualifier <literal>@CreditCard</literal>
and implements the bean type <literal>PaymentProcessor</literal>. Therefore, it satisfies our qualified
injection point:
@@ -434,9 +443,9 @@
</note>
<para>
- CDI defines a sophisticated, yet intuitive <emphasis>resolution algorithm</emphasis> that helps the
- container decide what to do if there is more than one bean that satisfies a particular contract. We'll get
- into the details in <xref linkend="injection"/>.
+ CDI defines a simple <emphasis>resolution rule</emphasis> that helps the container decide what to do if there
+ is more than one bean that satisfies a particular contract. We'll get into the details in
+ <xref linkend="alternatives"/>. TBD: write a section about "fixing ambiguous dependencies"!
</para>
</section>
@@ -446,9 +455,9 @@
<!-- I wonder whether the explaination of contextual above would fit better here -->
<para>
- The <emphasis>scope</emphasis> of a bean defines the lifecycle and visibility of instances created from it.
+ The <emphasis>scope</emphasis> of a bean defines the lifecycle and visibility of its instances.
The CDI context model is extensible, accommodating arbitrary scopes. However, certain important scopes are
- built-in to the specification, and provided by the container. Each scope is represented by an annotation
+ built into the specification, and provided by the container. Each scope is represented by an annotation
type.
</para>
@@ -484,13 +493,12 @@
<title>EL name</title>
<para>
- If you want to reference a bean outside of Java, such as in JavaServer Faces (JSF) view, you must assign the
- bean a <emphasis>name</emphasis>. The name is used as the EL name of the bean, allowing the bean to be used
- in a Unified EL expression.
+ If you want to reference a bean in non-Java code that supports Unified EL expressions, for example, in a
+ JSP or JSF page, you must assign the bean an <emphasis>EL name</emphasis>.
</para>
<para>
- The name is specified using the <literal>@Named</literal> annotation, as shown here:
+ The EL name is specified using the <literal>@Named</literal> annotation, as shown here:
</para>
<programlisting role="JAVA"><![CDATA[@SessionScoped @Named("cart")
@@ -531,31 +539,25 @@
<title>Alternatives</title>
<para>
- There are cases when you want to replace one bean implementation with another at deployment time. For
- instance, you may want to use a mock implementation in a testing environment. An
- <emphasis>alternative</emphasis> may be declared by annotating the bean class or producer method or field
- with the <literal>@Alternative</literal> annotation.
+ We've already seen how qualifiers let us choose between multiple implementations of an interface at
+ development time. But sometimes we have an interface whose implementation varies dependending upon
+ the deployment environment. For example, you may want to use a mock implementation in a testing
+ environment. An <emphasis>alternative</emphasis> may be declared by annotating the bean class or
+ producer method or field with the <literal>@Alternative</literal> annotation.
</para>
<programlisting role="JAVA"><![CDATA[@Alternative
public class MockPaymentProcessor extends PaymentProcessorImpl { ... }]]></programlisting>
<para>
- An alternative can also be declared by annotating a bean, producer method or producer fields with a
- stereotype that has the <literal>@Alternative</literal> annotation. Stereotypes are explained in <xref
- linkend="stereotypes"/>.
+ You can choose between alternatives at deployment time by selecting an alternative using the CDI
+ deployment descriptor <literal>META-INF/beans.xml</literal> of the jar or Java EE module that
+ uses it.
</para>
<para>
- You then enable the alternative using the CDI deployment descriptor, META-INF/beans.xml, in the classpath
- entry in which you intent to use it. An alternative must be explicitly selected in every bean deployment
- archive in which the alternative should be available for injection, lookup and EL resolution.
- </para>
-
- <para>
Details on how to enable alternative beans, and how you can use them to specialize (override) beans and
- producer methods is covered in <xref linkend="specialization"/>. CDI is very flexible when it comes
- alternatives that are selected at deployment time.
+ producer methods is covered in <xref linkend="3"/>.
</para>
</section>
@@ -564,8 +566,8 @@
<title>Interceptor binding types</title>
<para>
- Since the introduction of the Managed Bean specification in Java EE 6, interceptors are available on
- JavaBeans in additionn to EJB session beans. That's right, you no longer have to create an EJB just to
+ Since the introduction of the managed bean specification in Java EE 6, interceptors are available on
+ JavaBeans in addition to EJB session beans. That's right, you no longer have to create an EJB just to
intercept method calls. Holler. So what does CDI have to offer? Well, a lot actually. Let's cover some
background.
</para>
Modified: doc/trunk/reference/en-US/part1.xml
===================================================================
--- doc/trunk/reference/en-US/part1.xml 2009-11-03 10:24:58 UTC (rev 4591)
+++ doc/trunk/reference/en-US/part1.xml 2009-11-03 10:26:17 UTC (rev 4592)
@@ -12,16 +12,16 @@
<!-- NOTE synchronize this intro with the intro on http://seamframework.org/Weld -->
<para>
- The <ulink src="http://jcp.org/en/jsr/detail?id=299">JSR-299</ulink> specification (CDI) defines a set of services
- for the Java EE environment that make applications much easier to develop. CDI layers an enhanced lifecycle and
- interaction model over existing Java component types, including Managed Beans (JavaBeans) and Enterprise JavaBeans
- (EJB session beans). As a complement to the traditional Java EE programming model, the CDI services provide:
+ The <ulink src="http://jcp.org/en/jsr/detail?id=299">JSR-299</ulink> specification (CDI) defines a set of
+ complementary services that help improve the structure of application code. CDI layers an enhanced lifecycle
+ and interaction model over existing Java component types, including managed beans (JavaBeans) and Enterprise
+ Java Beans. The CDI services provide:
</para>
<itemizedlist>
<listitem>
<para>
- an improved lifecycle for stateful components, bound to well-defined <emphasis>contexts</emphasis>,
+ an improved lifecycle for stateful objects, bound to well-defined <emphasis>contexts</emphasis>,
</para>
</listitem>
<listitem>
@@ -31,48 +31,76 @@
</listitem>
<listitem>
<para>
- component interaction via an <emphasis>event notification facility</emphasis>,
+ object interaction via an <emphasis>event notification facility</emphasis>,
</para>
</listitem>
<listitem>
<para>
- a better approach to binding <emphasis>interceptors</emphasis> to components, along with a new kind of
- interceptor, called a <emphasis>decorator</emphasis>, that is more appropriate for use in solving business problems, and
+ a better approach to binding <emphasis>interceptors</emphasis> to objects, along with a new kind of
+ interceptor, called a <emphasis>decorator</emphasis>, that is more appropriate for use in solving
+ business problems, and
</para>
</listitem>
<listitem>
<para>
- an <emphasis>SPI</emphasis> for developing portable extensions for the Java EE platform.
+ an <emphasis>SPI</emphasis> for developing portable extensions to the container.
</para>
</listitem>
</itemizedlist>
<para>
- A component that receives CDI services is referred to, generally, as a bean. The CDI services are a core aspect of
- the Java EE platform and apply to the following types of components that exist in the platform:
+ The CDI services are a core aspect of the Java EE platform and include full support for Java EE modularity
+ and the Java EE component architecture. But the specification does not limit the use of CDI to the Java EE
+ environment. In the Java SE environment, the services might be provided by a standalone CDI implementation
+ like Weld (see <xref linkend="weld-se"/>), or even by a container that also implements the subset of EJB
+ defined for embedded usage by the EJB 3.1 specification. CDI is especially useful in the context of web
+ application development, but the problems it solves are general development concerns and it is therefore
+ applicable to a wide variety of application.
</para>
+ <para>
+ An object bound to a lifecycle context is called a bean. CDI includes built-in support for several different
+ kinds of bean, including the following Java EE component types:
+ </para>
+
<itemizedlist>
<listitem>
- <para>all Managed Beans (JavaBeans), including JavaServer Faces (JSF) managed beans,</para>
+ <para>managed beans</para>
</listitem>
<listitem>
- <para>all Enterprise JavaBeans (EJBs), and</para>
+ <para>EJB session beans, and</para>
</listitem>
<listitem>
- <para>all Servlets.</para>
+ <para>JAX-RS resources.</para>
</listitem>
</itemizedlist>
-
+
<para>
- CDI is especially useful in the context of web applications, but is applicable to a wide variety of applications.
- It may even be used in the Java SE context, in conjunction with an embeddable EJB Lite container, as defined in
- the EJB 3.1 specification, or through an extension (see <xref linkend="weld-se"/>).
+ Both managed beans and EJB session beans may inject other beans. But some other objects, which are not
+ themselves beans, can also make use of CDI by injecting beans. In the Java EE platform, the following
+ kinds of component may inject beans:
</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>message-driven beans,</para>
+ </listitem>
+ <listitem>
+ <para>interceptors,</para>
+ </listitem>
+ <listitem>
+ <para>servlets, servlet filters and servlet event listeners,</para>
+ </listitem>
+ <listitem>
+ <para>JAX-WS service endpoints and handlers, and</para>
+ </listitem>
+ <listitem>
+ <para>JSP tag handlers and tag library event listeners.</para>
+ </listitem>
+ </itemizedlist>
<para>
- The concerns handled by CDI save the user who is unfamiliar with an API from having to answer the following
- questions:
+ CDI relieves the user of an unfamiliar API of the need to answer the following questions:
</para>
<itemizedlist>
@@ -86,7 +114,7 @@
<para>Is it multithreaded?</para>
</listitem>
<listitem>
- <para>How do I retrieve it?</para>
+ <para>How do I get access to it from a client?</para>
</listitem>
<listitem>
<para>Do I need to explicitly destroy it?</para>
@@ -98,7 +126,8 @@
</listitem>
<listitem>
<para>
- How can I define alternatives, so that the implementation of this object can vary at deployment time?
+ How can I define alternative an implementation, so that the implementation can vary
+ at deployment time?
</para>
</listitem>
<listitem>
@@ -146,28 +175,26 @@
objects fit together. (XML is rarely used, reserved only to activate alternatives and define ordering at
deployment time). Instead, CDI uses the typing information that is already available in the Java object model,
then extends it with a new typing pattern, called <emphasis>qualifier annotations</emphasis>, to wire together
- beans, their dependencies, their interceptors and decorators and their event consumers.
+ beans, their dependencies, their interceptors and decorators, and their event consumers.
</para>
<para>
- CDI even provides the necessary integration points, through a comprehensive SPI, so that other kinds of components
- defined by future Java EE specifications or by non-standard frameworks may be cleanly integrated with CDI, take
- advantage of the CDI services, and interact with any other kind of platform component.
+ CDI even provides the necessary integration points, through a comprehensive SPI, so that other kinds of object
+ defined by future Java EE specifications or by third-party frameworks may be cleanly integrated with CDI, take
+ advantage of the CDI services, and interact with any other kind of bean.
</para>
<para>
- CDI was influenced by a number of existing Java frameworks, including Seam, Guice and Spring. However, CDI has its
- own, very distinct, character: more typesafe than Seam, more stateful and less XML-centric than Spring, more web and
- enterprise-application capable than Guice. But it couldn't have been any of these without inspiration from the
- frameworks mentioned and <emphasis>lots</emphasis> of collaboration and hard work by the JSR-299 Expert Group
+ CDI was influenced by a number of existing Java frameworks, including Seam, Guice and Spring. However, CDI has
+ its own, very distinct, character: more typesafe than Seam, more stateful and less XML-centric than Spring, more
+ web and enterprise-application capable than Guice. But it couldn't have been any of these without inspiration from
+ the frameworks mentioned and <emphasis>lots</emphasis> of collaboration and hard work by the JSR-299 Expert Group
(EG).
</para>
<para>
- Finally, JSR-299 is a <ulink src="http://jcp.org">Java Community Process</ulink> (JCP) standard that integrates
- cleanly with the Java EE platform, and with any Java SE environment where embeddable EJB Lite is available. In
- fact, Java EE 6 requires that all compliant application servers provide support for JSR-299 (even in the web
- profile).
+ Finally, CDI is a <ulink src="http://jcp.org">Java Community Process</ulink> (JCP) standard. Java EE 6 requires
+ that all compliant application servers provide support for JSR-299 (even in the web profile).
</para>
<!--
16 years, 5 months
- 1
- 0
Weld SVN: r4591 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: gavin.king(a)jboss.com
Date: 2009-11-03 05:24:58 -0500 (Tue, 03 Nov 2009)
New Revision: 4591
Modified:
doc/trunk/reference/en-US/master.xml
Log:
ids
Modified: doc/trunk/reference/en-US/master.xml
===================================================================
--- doc/trunk/reference/en-US/master.xml 2009-11-03 10:24:43 UTC (rev 4590)
+++ doc/trunk/reference/en-US/master.xml 2009-11-03 10:24:58 UTC (rev 4591)
@@ -32,7 +32,7 @@
<toc/>
- <part>
+ <part id="1">
<title>Loosely-coupled, contextual components with strong typing</title>
<xi:include href="part1.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
@@ -47,7 +47,7 @@
</part>
- <part>
+ <part id="2">
<title>Developing loosely-coupled code</title>
<xi:include href="part2.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
@@ -58,7 +58,7 @@
</part>
- <part>
+ <part id="3">
<title>Making the most of strong typing</title>
<xi:include href="part3.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
@@ -68,7 +68,7 @@
</part>
- <part>
+ <part id="4">
<title>CDI and the Java EE ecosystem</title>
<xi:include href="part4.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
@@ -80,7 +80,7 @@
<xi:include href="next.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <part>
+ <part id="5">
<title>Weld reference</title>
<xi:include href="part5.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
16 years, 5 months
- 1
- 0
Weld SVN: r4590 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: gavin.king(a)jboss.com
Date: 2009-11-03 05:24:43 -0500 (Tue, 03 Nov 2009)
New Revision: 4590
Modified:
doc/trunk/reference/en-US/injection.xml
Log:
minor
Modified: doc/trunk/reference/en-US/injection.xml
===================================================================
--- doc/trunk/reference/en-US/injection.xml 2009-11-03 07:43:28 UTC (rev 4589)
+++ doc/trunk/reference/en-US/injection.xml 2009-11-03 10:24:43 UTC (rev 4590)
@@ -356,7 +356,7 @@
<para>
<!-- this is a really vague point -->
The most common circumstance when it's necessary to explicitly specify <literal>@Default</literal> is on a bean
- which as another qualifier in addition to the default one.
+ which has another qualifier in addition to the default one.
</para>
</section>
16 years, 5 months
- 1
- 0
Weld SVN: r4589 - cdi-tck/trunk/impl/src/main/resources.
by weld-commits＠lists.jboss.org
Author: nickarls
Date: 2009-11-03 02:43:28 -0500 (Tue, 03 Nov 2009)
New Revision: 4589
Modified:
cdi-tck/trunk/impl/src/main/resources/tck-audit-cdi.xml
Log:
minor: missing </group>
Modified: cdi-tck/trunk/impl/src/main/resources/tck-audit-cdi.xml
===================================================================
--- cdi-tck/trunk/impl/src/main/resources/tck-audit-cdi.xml 2009-11-03 07:21:39 UTC (rev 4588)
+++ cdi-tck/trunk/impl/src/main/resources/tck-audit-cdi.xml 2009-11-03 07:43:28 UTC (rev 4589)
@@ -2322,13 +2322,14 @@
<group>
<text>All unresolvable ambiguous EL names are detected by the container when the application is initialized. Suppose two beans are both accessible to classes in a certain war, according to the class loading requirements of the Java EE platform and Java Servlet specifications. If each bean is either not an alternative, or is a selected alternative of the war, and either the two beans have the same EL name and the name is not resolvable, or the EL name of one bean is of the form |x.y|, where |y| is a valid bean EL name, and |x| is the EL name of the other bean, the container automatically detects the problem and treats it as a deployment problem.</text>
- <assertion id="da">
- <text>Test with two beans with the same EL name.</text>
- </assertion>
+ <assertion id="da">
+ <text>Test with two beans with the same EL name.</text>
+ </assertion>
- <assertion id="db">
- <text>Test with with an EL name in the form |x.y|.</text>
- </assertion>
+ <assertion id="db">
+ <text>Test with with an EL name in the form |x.y|.</text>
+ </assertion>
+ </group>
</section>
<section id="5.4" title="Client proxies">
16 years, 5 months
- 1
- 0
Weld SVN: r4588 - cdi-tck/trunk/impl/src/main/resources.
by weld-commits＠lists.jboss.org
Author: shane.bryzak(a)jboss.com
Date: 2009-11-03 02:21:39 -0500 (Tue, 03 Nov 2009)
New Revision: 4588
Modified:
cdi-tck/trunk/impl/src/main/resources/tck-audit-cdi.xml
Log:
updated chapter 5 assertions
Modified: cdi-tck/trunk/impl/src/main/resources/tck-audit-cdi.xml
===================================================================
--- cdi-tck/trunk/impl/src/main/resources/tck-audit-cdi.xml 2009-11-03 00:19:36 UTC (rev 4587)
+++ cdi-tck/trunk/impl/src/main/resources/tck-audit-cdi.xml 2009-11-03 07:21:39 UTC (rev 4588)
@@ -2030,7 +2030,7 @@
</assertion>
</section>
- <section id="5.1" title="Inter-module accessibility in Java EE">
+ <section id="5.1" title="Modularity">
<group>
<text>Beans packaged in a certain Java EE module or library are available for injection, lookup and EL resolution to classes and JSP/JSF pages packaged in some other Java EE module or library if and only if the first module or library is required to be accessible to the other module or library by the Java EE platform specification.</text>
@@ -2046,32 +2046,17 @@
<text>Test with EL resolution.</text>
</assertion>
</group>
-
- <assertion id="b">
- <text>For a custom implementation of the |Bean| interface defined in Section 11.1, "The Bean interface", the container calls |getBeanClass()| to determine the bean class of the bean.</text>
- </assertion>
- <assertion id="c">
- <text>For a custom implementation of |Bean|, defined in Section 11.2, "The Producer and InjectionTarget interfaces", the container calls |InjectionPoint.getMember()| and then |Member.getDeclaringClass()| to determine the class that declares an injection point.</text>
- </assertion>
-
<assertion id="d">
- <text>For a custom implementation of |InjectionTarget|, defined in Section 11.2, "The Producer and InjectionTarget interfaces", the container calls |InjectionPoint.getMember()| and then |Member.getDeclaringClass()| to determine the class that declares an injection point.</text>
+ <text>An alternative is never available for injection, lookup or EL resolution in a Java EE module or library that is not a bean deployment archive (a module or library with no beans.xml| file.</text>
</assertion>
-
- </section>
-
- <section id="5.2" title="Alternative selection">
- <assertion id="a">
- <text>An alternative is never available for injection, lookup or EL resolution in a Java EE module or library that is not a bean deployment archive (a module or library with no |beans.xml| file).</text>
- </assertion>
- <assertion id="b">
+ <assertion id="e">
<text>Nor is an alternative available for injection, lookup or EL resolution in every bean deployment archive. An alternative must be explicitly selected in every bean deployment archive in which the alternative should be available for injection, lookup and EL resolution.</text>
</assertion>
</section>
- <section id="5.2.1" title="Declaring selected alternatives for a bean deployment archive">
+ <section id="5.1.1" title="Declaring selected alternatives for a bean deployment archive">
<assertion id="c">
<text>By default, a bean deployment archive has no selected alternatives. An alternative must be explicitly declared using the <alternatives> element of the |beans.xml| file of the bean deployment archive.</text>
</assertion>
@@ -2125,37 +2110,35 @@
</assertion>
</section>
- <section id="5.2.2" title="Enabled and disabled beans">
+ <section id="5.1.2" title="Enabled and disabled beans">
<assertion id="a">
- <text>A bean is said to be enabled if it is not a producer method or field of a disabled bean, and it is not specialized by any other enabled bean, and either it is not an alternative, or it is a selected alternative of at least one bean deployment archive. Otherwise, the bean is said to be disabled.</text>
+ <text>A bean is said to be enabled if it is deployed in a bean deployment archive, as defined by Section 12.1, "Bean deployment archives", and it is not a producer method or field of a disabled bean, and it is not specialized by any other enabled bean, as defined in Section 4.3, "Specialization", and either it is not an alternative, or it is a selected alternative of at least one bean deployment archive. Otherwise, the bean is said to be disabled.</text>
</assertion>
+
+ <assertion id="b">
+ <text>Section 3.12, "@New qualified beans" defines a special rule that determines whether a |@New| qualified bean is enabled or disabled. This rule applies as only to |@New| qualified beans, as an exception to the normal rule defined here.</text>
+ </assertion>
</section>
- <section id="5.2.3" title="Inconsistent specialization">
+ <section id="5.1.3" title="Inconsistent specialization">
<assertion id="a">
<text>Suppose an enabled bean X specializes a second bean Y. If there is another enabled bean that specializes Y we say that inconsistent specialization exists. The container automatically detects inconsistent specialization and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
</assertion>
</section>
-
- <section id="5.3" title="Typesafe resolution">
+
+ <section id="5.1.4" title="Inter-module injection">
<assertion id="a">
- <text>A bean is eligible for injection into a given class if the bean is enabled, and the bean is either not an alternative, or is a selected alternative of the bean deployment archive of the given class, and in a Java EE or servlet container, the bean class is required to be accessible to the given class, according to the class loading requirements of the Java EE platform and Java Servlet specifications.</text>
+ <text>A bean is available for injection in a certain Java EE module or library if the bean is enabled, the bean is either not an alternative, or the module or library is a bean deployment archive and the bean is a selected alternative of the bean deployment archive, and the bean class is required to be accessible to classes in the module or library, according to the class loading requirements of the Java EE platform and Java Servlet specifications.</text>
</assertion>
-
- <assertion id="hq">
- <text>When determining the set of beans that are eligible for injection to an injection point, the container identifies the set of matching beans which are not _interceptors_ or decorators and which have a bean type that matches the required type.</text>
- </assertion>
- <assertion id="hb">
- <text>When determining the set of beans that are eligible for injection to an injection point, the container identifies the set of matching beans which are not interceptors or _decorators_ and which have a bean type that matches the required type.</text>
+ <assertion id="b">
+ <text>For a custom implementation of the |Bean| interface defined in Section 11.1, "The Bean interface, the container calls |getBeanClass()| to determine the bean class of the bean and |InjectionPoint.getMember()| and then |Member.getDeclaringClass()| to determine the class that declares an injection point.</text>
</assertion>
-
- <assertion id="hc">
- <text>When determining the set of beans that are eligible for injection to an injection point, the container identifies the set of matching beans which are not interceptors or decorators and which have a _bean type that matches the required type_.</text>
- </assertion>
-
+ </section>
+
+ <section id="5.2" title="Typesafe resolution">
<group>
- <text>When determining the set of beans that are eligible for injection to an injection point, the container identifies the set of matching beans which are not interceptors or decorators and which have a bean type that matches the required type. For this purpose, primitive types are considered to match their corresponding wrapper types in |java.lang| and array types are considered to match only if their element types are identical. Parameterized and raw types are considered to match if they are identical or if the bean type is assignable to the required type, as defined in Section 5.3.3, "Assignability of raw and parameterized types".</text>
+ <text>A bean is assignable to a given injection point if the bean has a bean type that matches the required type. For this purpose, primitive types are considered to match their corresponding wrapper types in |java.lang| and array types are considered to match only if their element types are identical. Parameterized and raw types are considered to match if they are identical or if the bean type is assignable to the required type, as defined in Section 5.2.3, "Assignability of raw and parameterized types".</text>
<assertion id="i">
<text>Test with a primitive type.</text>
@@ -2179,7 +2162,7 @@
</group>
<group>
- <text>When determining the set of beans that are eligible for injection to an injection point, the container identifies the set of matching beans which are not interceptors or decorators and which have the required qualifiers. If no required qualifiers were explicitly specified, the container assumes the required binding |@Default|. The container narrows the set of matching beans to just those where for each required qualifier, the bean declares a matching qualifier with (a) the same type and (b) the same annotation member value for each member which is not annotated |(a)javax.enterprise.inject.NonBinding| (see Section 5.3.5, "Qualifier annotations with members").</text>
+ <text>A bean is assignable to a given injection point if the bean has all the required qualifiers. If no required qualifiers were explicitly specified, the container assumes the required qualifier |@Default|. A bean has the required qualifier if it has a qualifier with (a) the same type and (b) the same annotation member value for each member which is not annotated |(a)javax.enterprise.inject.NonBinding|.</text>
<assertion id="la">
<text>Test with beans with required qualifiers.</text>
@@ -2199,11 +2182,11 @@
</group>
<assertion id="n">
- <text>When determining the set of beans that are eligible for injection to an injection point, the container identifies the set of matching beans which are eligible for injection into the class that declares the injection point.</text>
+ <text>A bean is eligible for injection to a certain injection point if it is available for injection in the Java EE module or library that contains the class that declares the injection point, and it is assignable to the injection point.</text>
</assertion>
<group>
- <text>For a custom implementation of the |Bean| interface defined in Section 11.1, "The Bean interface", the container calls |getTypes()| and |getQualifiers()| to determine the bean types and bindings.</text>
+ <text>For a custom implementation of the |Bean| interface defined in Section 11.1, "The Bean interface", the container calls |getTypes()| and |getQualifiers()| to determine the bean types and qualifiers.</text>
<assertion id="na">
<text>Test |getTypes()| determines bean types.</text>
@@ -2215,18 +2198,18 @@
</group>
</section>
- <section id="5.3.1" title="Unsatisfied and ambiguous dependencies">
+ <section id="5.2.1" title="Unsatisfied and ambiguous dependencies">
<assertion id="aa">
<text>The container must validate all injection points of all enabled beans when the application is initialized to ensure that there are no unsatisfied or ambiguous dependencies. If an unsatisfied or ambiguous dependency exists, 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>
<note>These need expanding out - one for each assertion that results in an exception in 5.7.1</note>
</assertion>
<assertion id="b">
- <text>For a custom implementation of the Bean interface defined in Section 11.1, "The Bean interface", the container calls |getInjectionPoints()| to determine the injection points of the bean.</text>
+ <text>For a custom implementation of the |Bean| interface defined in Section 11.1, "The Bean interface", the container calls |getInjectionPoints()| to determine the set of injection points.</text>
</assertion>
</section>
- <section id="5.3.2" title="Legal injection point types">
+ <section id="5.2.2" title="Legal injection point types">
<assertion id="a">
<text>Any legal bean type, as defined in Section 2.2.1, "Legal bean types" may be the required type of an injection point.</text>
</assertion>
@@ -2236,11 +2219,11 @@
</assertion>
<assertion id="c">
- <text>If an injection point type is a type variable, 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>
+ <text>If an injection point type is a type variable, the container automatically detects the problem and treats it as a definition error.</text>
</assertion>
</section>
- <section id="5.3.3" title="Assignability of raw and parameterized types">
+ <section id="5.2.3" title="Assignability of raw and parameterized types">
<assertion id="a">
<text>A parameterized bean type is considered assignable to a raw required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or |java.lang.Object|.</text>
</assertion>
@@ -2266,7 +2249,7 @@
</assertion>
</section>
- <section id="5.3.4" title="Primitive types and null values">
+ <section id="5.2.4" title="Primitive types and null values">
<group>
<text>If necessary, the container performs boxing or unboxing when it injects a value to a field or parameter of primitive or wrapper type.</text>
@@ -2288,7 +2271,7 @@
</assertion>
</section>
- <section id="5.3.5" title="Qualifier annotations with members">
+ <section id="5.2.5" title="Qualifier annotations with members">
<assertion id="a" testable="false">
<text>Qualifier types with members are supported</text>
<note>A statement of intent</note>
@@ -2303,7 +2286,7 @@
</assertion>
</section>
- <section id="5.3.6" title="Multiple qualifiers">
+ <section id="5.2.6" title="Multiple qualifiers">
<assertion id="a">
<text>A bean class may declare multiple qualifiers.</text>
</assertion>
@@ -2321,32 +2304,34 @@
</assertion>
</section>
- <section id="5.4" title="EL Name resolution">
-
- <assertion id="baa">
- <text>When resolving a bean by name, the container identifies the set of matching beans which have the given EL name, and are enabled, and are either not an alternative, or is a selected alternative of the war containing the JSP or JSF page with the EL expression, and are accessible to classes in the war containing the JSP or JSF page with the EL expression, according to the class loading requirements of the Java EE platform and Java Servlet specifications, and which are not a policy or an enabled policy of the war containing the JSP or JSF page with the EL expression.</text>
+ <section id="5.3" title="EL Name resolution">
+ <assertion id="d">
+ <text>An EL name resolves to a bean if the bean has the given EL name, and the bean is available for injection in the war containing the JSP or JSF page with the EL expression.</text>
</assertion>
<assertion id="e">
- <text>For a custom implementation of the Bean interface defined in Section 11.1, "The Bean interface", the container calls |getName()| to determine the bean EL name.</text>
+ <text>For a custom implementation of the |Bean| interface defined in Section 11.1, "The Bean interface", the container calls |getName()| to determine the bean EL name.</text>
</assertion>
</section>
- <section id="5.4.1" title="Ambiguous EL names">
+ <section id="5.3.1" title="Ambiguous EL names">
<assertion id="ca">
- <text>An ambiguous EL name exists in an EL expression when there are multiple beans which match the given EL name. When an ambiguous EL name exists, the container attempts to resolve the ambiguity - if any matching beans are alternatives, the container eliminates all matching beans that are not alternatives.If there is exactly one bean remaining, the container will select this bean, and the ambiguous name is called resolvable.</text>
+ <text>An ambiguous EL name exists in an EL expression when there are multiple beans which match the given EL name. When an ambiguous EL name exists, the container attempts to resolve the ambiguity. If any of the beans are alternatives, the container eliminates all beans that are not alternatives. If there is exactly one bean remaining, the container will select this bean, and the ambiguous EL name is called resolvable.</text>
</assertion>
+ <group>
+ <text>All unresolvable ambiguous EL names are detected by the container when the application is initialized. Suppose two beans are both accessible to classes in a certain war, according to the class loading requirements of the Java EE platform and Java Servlet specifications. If each bean is either not an alternative, or is a selected alternative of the war, and either the two beans have the same EL name and the name is not resolvable, or the EL name of one bean is of the form |x.y|, where |y| is a valid bean EL name, and |x| is the EL name of the other bean, the container automatically detects the problem and treats it as a deployment problem.</text>
+
<assertion id="da">
- <text>All unresolvable ambiguous EL names are detected by the container when the application is initialized. Suppose two beans are both accessible to classes in a certain war, according to the class loading requirements of the Java EE platform and Java Servlet specifications. If each bean is either not an alternative, or is a selected alternative of the war, and either _the two beans have the same EL name and the name is not resolvable_, or the EL name of one bean is of the form x.y, where y is a valid bean EL name, and x is the EL name of the other bean, 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>
+ <text>Test with two beans with the same EL name.</text>
</assertion>
<assertion id="db">
- <text>All unresolvable ambiguous EL names are detected by the container when the application is initialized. Suppose two beans are both accessible to classes in a certain war, according to the class loading requirements of the Java EE platform and Java Servlet specifications. If each bean is either not an alternative, or is a selected alternative of the war, and either the two beans have the same EL name and the name is not resolvable, _or the EL name of one bean is of the form x.y, where y is a valid bean EL name, and x is the EL name of the other bean_, 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>
+ <text>Test with with an EL name in the form |x.y|.</text>
</assertion>
</section>
- <section id="5.5" title="Client proxies">
+ <section id="5.4" title="Client proxies">
<assertion id="a" testable="false">
<text>Client proxies are never required for a bean whose scope is a pseudo-scope such as |@Dependent|</text>
</assertion>
@@ -2365,29 +2350,34 @@
</assertion>
</section>
- <section id="5.5.1" title="Unproxyable bean types">
+ <section id="5.4.1" title="Unproxyable bean types">
<assertion id="aa">
- <text>Classes which don't have a non-private constructor with no parameters cannot be proxied by the container. If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, 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>
+ <text>Classes which don't have a non-private constructor with no parameters cannot be proxied by the container. If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, the container automatically detects the problem and treats it as a deployment problem.</text>
</assertion>
- <assertion id="baa">
- <text>Classes which are declared final ~or have final methods~ cannot be proxied by the container. If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, 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>
+ <group>
+ <text>Classes which are declared final or have final methods cannot be proxied by the container. If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, the container automatically detects the problem and treats it as a deployment problem.</text>
+
+ <assertion id="baa">
+ <text>Test with a final class.</text>
+ </assertion>
- <assertion id="bba">
- <text>Classes which ~are declared final or ~have final methods cannot be proxied by the container. If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, 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="bba">
+ <text>Test with a class that has final methods.</text>
+ </assertion>
+ </group>
<assertion id="ca">
- <text>Primitive types cannot be proxied by the container. If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, 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>
+ <text>Primitive types cannot be proxied by the container. If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, the container automatically detects the problem and treats it as a deployment problem.</text>
</assertion>
<assertion id="da">
- <text>Array types cannot be proxied by the container. If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, 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>
+ <text>Array types cannot be proxied by the container. If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, the container automatically detects the problem and treats it as a deployment problem.</text>
</assertion>
+
</section>
- <section id="5.5.2" title="Client proxy invocation">
+ <section id="5.4.2" title="Client proxy invocation">
<assertion id="aa">
<text>Every time a method of the bean is invoked upon a client proxy, the client proxy must obtain a contextual instance of the bean, as defined in Section 6.5.2, "Contextual instance of a bean", and invoke the method upon this instance.</text>
</assertion>
@@ -2397,12 +2387,12 @@
</assertion>
<assertion id="b" testable="false">
- <text>The behavior of all methods declared by |java.lang.Object|, except for |toString()|, is undefined for a client proxy</text>
+ <text>The behavior of all methods declared by |java.lang.Object|, except for |toString()|, is undefined for a client proxy.</text>
</assertion>
</section>
- <section id="5.6" title="Dependency injection">
+ <section id="5.5" title="Dependency injection">
<assertion id="a">
<text>The container is required to perform dependency injection whenever it creates a contextual instance of a session bean.</text>
</assertion>
@@ -2451,44 +2441,19 @@
<assertion id="g">
<text>The container interacts with instances of beans and other Java EE component classes supporting injection by calling methods and getting and setting the field values.</text>
</assertion>
- </section>
-
- <section id="5.6.1" title="Injectable references">
- <assertion id="aa">
- <text>To obtain an injectable reference for an injection point, the container must identify a bean according to the rules defined in Section 5.3, "Typesafe resolution" and resolving ambiguities according to Section 5.3.1, "Unsatisfied and ambiguous dependencies", then obtain a contextual reference for this bean and the type of the injection point according to Section 6.5.3, "Contextual reference for a bean".</text>
+
+ <assertion id="h">
+ <text>The object injected by the container may not be a direct reference to a contextual instance of the bean. Instead, it is an injectable reference, as defined by Section 6.5.5, "Injectable references".</text>
</assertion>
-
- <assertion id="g">
- <text>For certain combinations of scopes, the container is permitted to optimize the above procedure by directly injecting a contextual instance of the bean, as defined in Section 6.5.2, "Contextual instance of a bean". If an incompletely initialized instance of the bean is registered with the current |CreationalContext|, as defined in Section
-6.1, "The Contextual interface", the container is permitted to directly inject this instance. However, in performing these optimizations, the container must respect the rules of injected reference validity.</text>
- </assertion>
</section>
-
- <section id="5.6.2" title="Injected reference validity">
- <assertion id="d">
- <text>A reference to a bean injected into a field, bean constructor or initializer method is valid until the object into which it was injected is destroyed.</text>
- </assertion>
-
- <assertion id="e">
- <text>A reference to a bean injected into a producer method is valid until the producer method bean instance that is being produced is destroyed.</text>
- </assertion>
-
- <assertion id="f">
- <text>A reference to a bean injected into a disposer method or observer method is valid until the invocation of the method completes.</text>
- </assertion>
-
- <assertion id="g" testable="false">
- <text>The application should not invoke a method of an invalid reference. If the application invokes a method of an invalid injected reference, the behavior is undefined.</text>
- </assertion>
- </section>
-
- <section id="5.6.3" title="Injection using the bean constructor">
+
+ <section id="5.5.1" title="Injection using the bean constructor">
<assertion id="a">
<text>When the container instantiates a managed bean with a constructor annotated |@Inject|, the container calls this constructor, passing an injectable reference to each parameter. If there is no constructor annotated |@Inject|, the container calls the constructor with no parameters.</text>
</assertion>
</section>
- <section id="5.6.4" title="Injection of fields and initializer methods">
+ <section id="5.5.2" title="Injection of fields and initializer methods">
<group>
<text>When the container creates a new instance of a managed bean, session bean, or of any other Java EE component class supporting injection, the container must: Initialize the values of all injected fields. The container sets the value of each injected field to an injectable reference. Call all initializer methods, passing an injectable reference to each parameter.</text>
<assertion id="aa">
@@ -2618,13 +2583,13 @@
</group>
</section>
- <section id="5.6.5" title="Destruction of dependent objects">
+ <section id="5.5.3" title="Destruction of dependent objects">
<assertion id="a">
<text>When the container destroys an instance of a bean or of any Java EE component class supporting injection, the container destroys all dependent objects, as defined in Section 6.4.2, "Dependent object destruction", after the |@PreDestroy| callback completes and after the servlet |destroy()| method is called.</text>
</assertion>
</section>
- <section id="5.6.6" title="Invocation of producer or disposal methods">
+ <section id="5.5.4" title="Invocation of producer or disposal methods">
<assertion id="a">
<text>When the container calls a producer method, if the method is static, the container must invoke the method.</text>
</assertion>
@@ -2646,7 +2611,7 @@
</assertion>
</section>
- <section id="5.6.7" title="Access to producer field values">
+ <section id="5.5.5" title="Access to producer field values">
<assertion id="a">
<text>When the container accesses the value of a producer field, if the producer field is static, the container must access the field value.</text>
</assertion>
@@ -2656,7 +2621,7 @@
</assertion>
</section>
- <section id="5.6.8" title="Invocation of observer methods">
+ <section id="5.5.6" title="Invocation of observer methods">
<assertion id="a">
<text>When the container calls an observer method (defined in Section 10.4 "Observer methods"), if the observer method is static, the container must invoke the method.</text>
</assertion>
@@ -2674,7 +2639,7 @@
</assertion>
</section>
- <section id="5.6.9" title="Injection point metadata">
+ <section id="5.5.7" title="Injection point metadata">
<assertion id="aa">
<text>The |javax.enterprise.inject.spi.InjectionPoint.getBean()| method returns the Bean object representing the bean that defines the injection point. If the injection point does not belong to a bean, |getBean()| returns a null value.</text>
</assertion>
@@ -2720,15 +2685,15 @@
</assertion>
<assertion id="f">
- <text>If a bean that declares any scope other than |@Dependent| has an injection point of type |InjectionPoint| and binding |@Default|, 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>
+ <text>If a bean that declares any scope other than |@Dependent| has an injection point of type |InjectionPoint| and binding |@Default|, the container automatically detects the problem and treats it as a definition error.</text>
</assertion>
<assertion id="ga">
- <text>If a Java EE component class supporting injection that is not a bean has an injection point of type |InjectionPoint| and binding |@Default|, 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>
+ <text>If a Java EE component class supporting injection that is not a bean has an injection point of type |InjectionPoint| and binding |@Default|, the container automatically detects the problem and treats it as a definition error.</text>
</assertion>
</section>
- <section id="5.7" title="Programmatic lookup">
+ <section id="5.6" title="Programmatic lookup">
<assertion id="aa">
<text>An instance of the |javax.enterprise.inject.Instance| interface may be injected.</text>
</assertion>
@@ -2746,7 +2711,7 @@
</assertion>
</section>
- <section id="5.7.1" title="The Instance interface">
+ <section id="5.6.1" title="The Instance interface">
<assertion id="aa">
<text>The |Instance| interface provides a method for obtaining instances of beans with a specified combination of required type and qualifiers, and inherites the ability to iterate beans with that combination of required type and qualifiers from |java.lang.Iterable|.</text>
</assertion>
@@ -2805,7 +2770,7 @@
</assertion>
</section>
- <section id="5.7.2" title="The built-in Instance">
+ <section id="5.6.2" title="The built-in Instance">
<assertion id="a">
<text>The container must provide a built-in bean with |Instance<X>| and |Provider<X>| for every legal bean type |x| in its set of bean types.</text>
</assertion>
@@ -2831,30 +2796,10 @@
</assertion>
</section>
- <section id="5.7.3" title="Using AnnotationLiteral and TypeLiteral">
+ <section id="5.6.3" title="Using AnnotationLiteral and TypeLiteral">
</section>
- <section id="5.8" title="Integration with Unified EL">
- <assertion id="aaa">
- <text>The container must provide a Unified EL ELResolver to the servlet engine ~and JSF implementation~ that resolves bean EL names using the rules of name resolution algorithm defined in Section 5.4 "EL name resolution" and resolving ambiguities according to Section 5.4.1, "Ambiguous EL names".</text>
- <note>This is testable implicitly by trying to resolve using EL from a servlet</note>
- </assertion>
-
- <assertion id="aba">
- <text>The container must provide a Unified EL |ELResolver| to the ~servlet engine~ and JSF implementation that resolves bean EL names using the rules of name resolution algorithm defined in Section 5.4 "EL name resolution" and resolving ambiguities according to Section 5.4.1, "Ambiguous EL names".</text>
- <note>This is testable implicitly by trying to resolve using EL from a JSF view</note>
- </assertion>
-
- <assertion id="bb">
- <text>If a name used in an EL expression does not resolve to any bean, the |ELResolver| must return a null value.</text>
- </assertion>
-
- <assertion id="bc">
- <text>Otherwise, if a name used in an EL expression resolves to exactly one bean, the |ELResolver| must return a contextual instance of the bean, as defined in Section 6.5.2, "Contextual instance of a bean".</text>
- </assertion>
- </section>
-
<section id="6" title="Scopes and contexts">
</section>
16 years, 5 months
- 1
- 0