Author: gavin.king(a)jboss.com Date: 2009-11-03 12:25:20 -0500 (Tue, 03 Nov 2009) New Revision: 4619 Modified: doc/trunk/reference/en-US/intro.xml Log: minor fixes Modified: doc/trunk/reference/en-US/intro.xml =================================================================== --- doc/trunk/reference/en-US/intro.xml 2009-11-03 16:45:56 UTC (rev 4618) +++ doc/trunk/reference/en-US/intro.xml 2009-11-03 17:25:20 UTC (rev 4619) @@ -38,7 +38,7 @@ 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&mdash;you won't need any additional special metadata. There's just little one thing you + they're already beans&#8212;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 such as a war or EJB jar) that contains a special marker file: <literal>META-INF/beans.xml</literal>. </para> @@ -46,9 +46,9 @@ <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&mdash;allowing the container to create and destroy instances of your beans and associate them with a + CDI&#8212;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&mdash;without modifying your + qualifier annotations, even adding interceptors and decorators to them&#8212;without modifying your existing code. At most, you'll need to add some annotations. </para> @@ -541,23 +541,25 @@ <para> 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 + the deployment environment. For example, we 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> - 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. + We normally annotate a bean <literal>@Alternative</literal> only when there is some other + implementation of some interface it implements. We can choose between alternatives at deployment time + by <emphasis>selecting</emphasis> an alternative using the CDI deployment descriptor + <literal>META-INF/beans.xml</literal> of the jar or Java EE module that uses it. Different modules + can specify that they use different alternatives. </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="3"/>. + 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="3"/>. </para> </section> @@ -619,7 +621,7 @@ </section> <section> - <title>What kinds of classes can be beans?</title> + <title>What kinds of classes are beans?</title> <para> We've already seen that JavaBeans and EJBs can be (CDI) beans. Is that the whole story? Let's start from what