[weld-commits] Weld SVN: r4643 - doc/trunk/reference/en-US.
weld-commits at lists.jboss.org
weld-commits at lists.jboss.org
Wed Nov 4 04:00:21 EST 2009
Author: nickarls
Date: 2009-11-04 04:00:20 -0500 (Wed, 04 Nov 2009)
New Revision: 4643
Modified:
doc/trunk/reference/en-US/ee.xml
doc/trunk/reference/en-US/extend.xml
doc/trunk/reference/en-US/gettingstarted.xml
doc/trunk/reference/en-US/injection.xml
doc/trunk/reference/en-US/interceptors.xml
doc/trunk/reference/en-US/intro.xml
doc/trunk/reference/en-US/part1.xml
doc/trunk/reference/en-US/part4.xml
doc/trunk/reference/en-US/ri-spi.xml
doc/trunk/reference/en-US/scopescontexts.xml
doc/trunk/reference/en-US/specialization.xml
doc/trunk/reference/en-US/stereotypes.xml
Log:
typos
Modified: doc/trunk/reference/en-US/ee.xml
===================================================================
--- doc/trunk/reference/en-US/ee.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/ee.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -219,7 +219,7 @@
<para>
For Java SE execution, beans may be deployed in any location in which EJBs may be deployed for execution by the
embeddable EJB Lite container. Again, each location must contain a <literal>beans.xml</literal> file. (That
- doesn't rule out the possibility of having an extention which provides support for normal Java SE execution,
+ doesn't rule out the possibility of having an extension which provides support for normal Java SE execution,
like the Weld Java SE module).
</para>
Modified: doc/trunk/reference/en-US/extend.xml
===================================================================
--- doc/trunk/reference/en-US/extend.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/extend.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -57,7 +57,7 @@
<para>
The <literal>BeanManager</literal> interface lets us register and obtain beans, interceptors, decorators,
- observers and contexts programatically.
+ observers and contexts programmatically.
</para>
<programlisting role="JAVA"><![CDATA[public interface Manager {
Modified: doc/trunk/reference/en-US/gettingstarted.xml
===================================================================
--- doc/trunk/reference/en-US/gettingstarted.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/gettingstarted.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -43,7 +43,7 @@
<para>a supported runtime environment (minimum versions shown)</para>
<itemizedlist>
<listitem>
- <para>JBoss AS 5.2.0 (currenly only nightly builds of JBoss AS 5.2.0.Beta1 are available), or</para>
+ <para>JBoss AS 5.2.0 (currently only nightly builds of JBoss AS 5.2.0.Beta1 are available), or</para>
</listitem>
<listitem>
<para>GlassFish 3.0, or</para>
@@ -98,7 +98,7 @@
<para>
After you have downloaded JBoss AS, extract it. (We recommended renaming the folder to include the
<literal>as</literal> qualifier so it's clear that it's the application server). You can move the extracted
- folder anywhere you like. Whereever it lays to rest, that's what we'll call the JBoss AS installation
+ folder anywhere you like. Wherever it lays to rest, that's what we'll call the JBoss AS installation
directory, or <literal>JBOSS_HOME</literal>.
</para>
@@ -324,7 +324,7 @@
<para>
In order for Ant to push the artifact to the Tomcat hot deploy directory, it needs to know where the Tomcat
- installation is located. Again, we need to setup a propery in the local.build.properties file in the
+ installation is located. Again, we need to setup a property in the local.build.properties file in the
examples directory of the Weld distribution. If you haven't yet created this file, do so now. Then assign
the path of your Tomcat installation to the property key tomcat.home.
</para>
@@ -410,7 +410,7 @@
The Maven plugin communicates with Tomcat over HTTP, so it doesn't care where you have installed Tomcat.
However, the plugin configuration assumes you are running Tomcat in its default configuration, with a hostname
of localhost and port 8080. The readme.txt file in the example directory has information about how to modify
- the Maven settings to accomodate a different setup.
+ the Maven settings to accommodate a different setup.
</para>
<para>
@@ -730,7 +730,7 @@
<callout arearefs="instructions">
<para>
As the user guesses, the range of numbers they can guess gets
- smaller - this sentance changes to make sure they know the
+ smaller - this sentence changes to make sure they know the
number range of a valid guess.
</para>
</callout>
@@ -920,7 +920,7 @@
<tip>
<para>
You must also include the JARs for JSF, EL, and the common annotations
- (<literal>jsr250-api.jar</literal>), all of which are provided by the Java EE platorm (a Java EE
+ (<literal>jsr250-api.jar</literal>), all of which are provided by the Java EE platform (a Java EE
application server). Are you starting to appreciate why a Java EE platform is worth using?
</para>
</tip>
@@ -969,7 +969,7 @@
<note>
<para>
We'll also be using the Eclipse IDE in these examples. Instructions are provided later for running the
- example from the commandline, but since you'll likely need to do more than just deploy examples, we'll get
+ example from the command line, but since you'll likely need to do more than just deploy examples, we'll get
setup in this full development environment.
</para>
</note>
@@ -988,7 +988,7 @@
<para>
If you have m2eclipse installed, you can open any Maven project directly. From within Eclipse, select
<emphasis>File -> Import... -> Maven Projects</emphasis>. Then, browse to the location of the Wicket
- numberguess example. You should see that Eclipse recognizes the existance of a Maven project.
+ numberguess example. You should see that Eclipse recognizes the existence of a Maven project.
</para>
<mediaobject>
@@ -1652,7 +1652,7 @@
<note>
<para>
- Jave EE 6, which bundles EJB 3.1, allows you to package EJBs in a WAR, which will make this structure much
+ Java EE 6, which bundles EJB 3.1, allows you to package EJBs in a WAR, which will make this structure much
simpler! Still, there are other advantages of using an EAR.
</para>
</note>
@@ -1716,7 +1716,7 @@
</para>
<para>
- More intersting is the JSF view used to translate text. Just as in the numberguess example we have a template,
+ More interesting is the JSF view used to translate text. Just as in the numberguess example we have a template,
which surrounds the form (ommitted here for brevity):
</para>
Modified: doc/trunk/reference/en-US/injection.xml
===================================================================
--- doc/trunk/reference/en-US/injection.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/injection.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -235,7 +235,7 @@
this.asyncPaymentProcessor = asyncPaymentProcessor;
}]]></programlisting>
- <para>Using using constructor injection:</para>
+ <para>Using constructor injection:</para>
<programlisting role="JAVA"><![CDATA[@Inject
public Checkout(@Synchronous PaymentProcessor syncPaymentProcessor,
@@ -275,7 +275,7 @@
<title>Qualifiers with members</title>
<para>
- Annotations can have members (i.e., fields) just like regular classes. You can use these fields to furthur
+ Annotations can have members (i.e., fields) just like regular classes. You can use these fields to further
discriminate the qualifier. This simply prevents an explosion of annotations that you have to introduce.
For instance, if you wanted to create several qualifiers representing different payment methods, you could
aggregate them under a single annotation using a member:
@@ -375,7 +375,7 @@
</para>
<para>
- During the course of your development, your going to encounter these errors. Let's learn how to resolve them.
+ During the course of your development, you're going to encounter these errors. Let's learn how to resolve them.
It's usually pretty easy, and a decent IDE can really help out here.
</para>
@@ -437,7 +437,7 @@
If you recall, Seam also boasted the ability to reference the current instance of a component. However, Seam
went about it differently. In Seam, the references are established prior to the method call and cleared
afterword using an interceptor—a process known as bijection. This model was not very friendly to multiple
- threads sharing instances and thefore the client proxy approach was adopted in CDI instead.
+ threads sharing instances and therefore the client proxy approach was adopted in CDI instead.
</para>
</note>
@@ -535,7 +535,7 @@
.select(new AnnotationLiteral<Asynchronous>() {});]]></programlisting>
<para>
- You can choose to create a concreate type for all of your annotation literals, such as:
+ You can choose to create a concrete type for all of your annotation literals, such as:
</para>
<programlisting role="JAVA"><![CDATA[abstract class AsynchronousQualifier
@@ -543,7 +543,7 @@
<note>
<para>
- The concrete is required if your qualifier has members, since an anonymous subclass cannot define members.
+ The concrete type is required if your qualifier has members, since an anonymous subclass cannot define members.
</para>
</note>
@@ -567,7 +567,7 @@
<para>
You won't always be able to take advantage of the type safety that CDI provides. One of those places is the JSF
- view. To accomodate that environment, CDI must learn to speak the binding language that view templates
+ view. To accommodate that environment, CDI must learn to speak the binding language that view templates
understand. That language is the Unified EL.
</para>
Modified: doc/trunk/reference/en-US/interceptors.xml
===================================================================
--- doc/trunk/reference/en-US/interceptors.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/interceptors.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -5,7 +5,7 @@
<title>Interceptors</title>
<para>
- Thanks to the managed bean specification, intereceptors are now part of the core functionality of a bean. That
+ Thanks to the managed bean specification, interceptors are now part of the core functionality of a bean. That
means that you no longer need to make your class an EJB just to use interceptors!
</para>
@@ -253,7 +253,7 @@
@Transactional public void checkout() { ... }
}]]></programlisting>
- <programlisting role="JAVA"><![CDATA[@Transactionl
+ <programlisting role="JAVA"><![CDATA[@Transactional
public class ShoppingCart {
@Secure public void checkout() { ... }
}]]></programlisting>
Modified: doc/trunk/reference/en-US/intro.xml
===================================================================
--- doc/trunk/reference/en-US/intro.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/intro.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -182,8 +182,8 @@
</tip>
<para>
- Alternatively, we may obtain an instance of <literal>TextTranslator</literal> programatically from an injected
- instance of <literal>Instance</literal>, paramaterized with the bean type:
+ Alternatively, we may obtain an instance of <literal>TextTranslator</literal> programmatically from an injected
+ instance of <literal>Instance</literal>, parameterized with the bean type:
</para>
<programlisting role="JAVA"><![CDATA[@Inject Instance<TextTranslator> textTranslatorSource;
@@ -265,7 +265,7 @@
<para>
One great advantage of the contextual model is that it allows stateful beans to be treated like services! The
client need not concern itself with managing the lifecycle of the bean it's using, <emphasis>nor does it even
- need to know what that lifecyle is.</emphasis> Beans interact by passing messages, and the bean implementations
+ need to know what that lifecycle is.</emphasis> Beans interact by passing messages, and the bean implementations
define the lifecycle of their own state. The beans are loosely coupled because:
</para>
@@ -373,8 +373,8 @@
The bean types alone often do not provide enough information for the container to know which bean to inject.
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
+ field of type <literal>PaymentProcessor</literal> introduces an ambiguous condition. In these cases, the
+ container must rely on some client-visible semantic that is satisfied by one implementation of the bean
type, but not by others. That semantic is called a qualifier.
</para>
@@ -540,7 +540,7 @@
<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
+ development time. But sometimes we have an interface whose implementation varies depending upon
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.
@@ -581,7 +581,7 @@
well just put the interceptor code <emphasis>in</emphasis> the implementation. Second, the order in which
the interceptors are applied is taken from the order in which they are declared in the annotation or the XML
descriptor. Perhaps this isn't so bad if you're applying the interceptors to a single bean. But, if you are
- applying them repeatly, then there is a chance that you'll inadvertly define a different order for different
+ applying them repeatedly, then there is a chance that you'll inadvertently define a different order for different
beans. Now that is a problem.
</para>
@@ -685,7 +685,7 @@
<para>
EJB 3 session beans belong to the EJB specification. That is, the basic lifecycle and semantics. Beyond
that, they get to participate in CDI just like any other bean. There are some restrictions about which
- scopes can be assigned to a session bean, but other than that, they are interchangable with regular managed
+ scopes can be assigned to a session bean, but other than that, they are interchangeable with regular managed
beans. That means you can inject one session bean into another, a managed bean into a session bean, a
session bean into a managed bean, have a managed bean observe an event raised by a session bean, and so on.
</para>
@@ -952,7 +952,7 @@
<para>
Naturally, there remained some mismatch with the new style of dependency injection in CDI. Most notably,
- resource injections rely on string-based names to qualify ambigious types, and there is no real consistency
+ resource injections rely on string-based names to qualify ambiguous types, and there is no real consistency
as to how a resource obtains its name (sometimes JNDI, other times from an XML descriptor or even a default
name). Producer fields turned out to be an elegant adapter to rein them in and get them to participate in
the CDI system just like any other injectable bean.
Modified: doc/trunk/reference/en-US/part1.xml
===================================================================
--- doc/trunk/reference/en-US/part1.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/part1.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -138,7 +138,7 @@
</itemizedlist>
<para>
- The main theme of CDI, which is instrumental in removing these complexities, is <emphasis>loose-couping with
+ The main theme of CDI, which is instrumental in removing these complexities, is <emphasis>loose-coupling with
strong typing</emphasis>. Let's study what that phrase means.
</para>
Modified: doc/trunk/reference/en-US/part4.xml
===================================================================
--- doc/trunk/reference/en-US/part4.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/part4.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -14,7 +14,7 @@
into the Java EE platform via an SPI. This SPI positions CDI as the foundation for a new ecosystem of
<emphasis>portable</emphasis> extensions and integration with existing frameworks and technologies. The CDI
services will be able to reach a diverse collection of technologies, such as business process management (BPM)
- engines, existing web frameworks and defacto standard component models. Of course, The Java EE platform will never
+ engines, existing web frameworks and de facto standard component models. Of course, The Java EE platform will never
be able to standardize all the interesting technologies that are used in the world of Java application
development, but CDI makes it easier to use the technologies which are not yet part of the platform seamlessly
within the Java EE environment.
Modified: doc/trunk/reference/en-US/ri-spi.xml
===================================================================
--- doc/trunk/reference/en-US/ri-spi.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/ri-spi.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -114,7 +114,7 @@
<para>
BDA X may also reference another BDA Y whose beans can be resolved by, and injected into, any bean in BDA X.
These are the accessible BDAs, and every BDA that is directly accessible by BDA X should be returned. A BDA
- will also have BDAs which are accessible transtivively, and the transitive closure of the sub-graph of BDA X
+ will also have BDAs which are accessible transitively, and the transitive closure of the sub-graph of BDA X
describes all the beans resolvable by BDA X.
</para>
@@ -291,7 +291,7 @@
<para>
<literal>InjectionServices</literal> provides a very simple contract, the
<literal>InjectionServices.aroundInject(InjectionContext ic);</literal> intercepter will be called for every
- instance that CDI injects, whether it is a contextual instance, or a non-contexutal instance injected by
+ instance that CDI injects, whether it is a contextual instance, or a non-contextual instance injected by
<literal>InjectionTarget.inject()</literal>.
</para>
@@ -491,7 +491,7 @@
<para>
If you are integrating Weld into a JSF environment you must register
- <literal>org.jboss.weld.el.WeldELContextListener</literal> as as an EL Context listener.
+ <literal>org.jboss.weld.el.WeldELContextListener</literal> as an EL Context listener.
</para>
<para>
@@ -537,7 +537,7 @@
<para>
If you are integrating Weld into a JSP environment you must register
- <literal>org.jboss.weld.el.WeldELContextListener</literal> as as an EL Context listener.
+ <literal>org.jboss.weld.el.WeldELContextListener</literal> as an EL Context listener.
</para>
<para>
Modified: doc/trunk/reference/en-US/scopescontexts.xml
===================================================================
--- doc/trunk/reference/en-US/scopescontexts.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/scopescontexts.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -54,7 +54,7 @@
<para>
Of course, that's the easy part of the job. For this scope type to be useful, we will also need to define a
<literal>Context</literal> object that implements the scope! Implementing a <literal>Context</literal> is
- usually a very technical task, intended for framework development only. You can expect an implemention of the
+ usually a very technical task, intended for framework development only. You can expect an implementation of the
business scope, for instance, in a future version of Seam.
</para>
@@ -172,7 +172,7 @@
<title>Conversation demarcation</title>
<para>
- CDI provides a built-in bean for controlling the lifecyle of conversations in a JSF application. This bean
+ CDI provides a built-in bean for controlling the lifecycle of conversations in a JSF application. This bean
may be obtained by injection:
</para>
Modified: doc/trunk/reference/en-US/specialization.xml
===================================================================
--- doc/trunk/reference/en-US/specialization.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/specialization.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -7,9 +7,9 @@
<para>
When you first start developing with CDI, you'll likely be dealing only with a single bean implementation for each
bean type. In this case, it's easy to understand how beans get selected for injection. As the complexity of your
- application grows, multiple occurances of the same bean type start appearing, either because you have multiple
+ application grows, multiple occurrences of the same bean type start appearing, either because you have multiple
implementations or two beans share a common (Java) inheritance. That's when you have to begin studying the
- specialization, inheritance and alternative rules to work through unsatisified or ambiguous dependencies or to
+ specialization, inheritance and alternative rules to work through unsatisfied or ambiguous dependencies or to
avoid certain beans from being called.
</para>
Modified: doc/trunk/reference/en-US/stereotypes.xml
===================================================================
--- doc/trunk/reference/en-US/stereotypes.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/stereotypes.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -145,7 +145,7 @@
<title>Alternatives as stereotypes</title>
<para>
- A stereotype can inicate that all beans to which it is applied are <literal>@Alternative</literal> beans. If
+ A stereotype can indicate that all beans to which it is applied are <literal>@Alternative</literal> beans. If
you can remember back to the early days of the specification, this is the closest match to a deployment type.
Whole sets of beans can be enabled or left disabled by activating a single stereotype.
</para>
More information about the weld-commits
mailing list