From c20b22a0111a336ed473313c14efa9b419e8fa8a Mon Sep 17 00:00:00 2001 From: Phillip Webb Date: Tue, 20 Nov 2012 16:39:54 -0800 Subject: [PATCH] Consistent spelling for US/UK words Replaced behaviour and summarised with US variants that seem to be more prevalent in the rest of the document. --- src/reference/docbook/aop.xml | 4 ++-- src/reference/docbook/cache.xml | 12 ++++++------ src/reference/docbook/dtd.xml | 2 +- src/reference/docbook/jdbc.xml | 4 ++-- 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/reference/docbook/aop.xml b/src/reference/docbook/aop.xml index 89c0224ff0..a555d91f7b 100644 --- a/src/reference/docbook/aop.xml +++ b/src/reference/docbook/aop.xml @@ -3565,7 +3565,7 @@ http://www.springframework.org/schema/context LoadTimeWeaver: the exact type of LoadTimeWeaver that will be 'automatically detected' is dependent upon your runtime environment - (summarised in the following table). + (summarized in the following table). <classname>DefaultContextLoadTimeWeaver</classname> @@ -3689,7 +3689,7 @@ http://www.springframework.org/schema/context the '<literal>aspectjWeaving</literal>' attribute (or '<literal>aspectj-weaving</literal>' if you are using XML). This is a simple attribute that controls whether LTW is enabled or not, it is as simple - as that. It accepts one of three possible values, summarised below, + as that. It accepts one of three possible values, summarized below, with the default value if the attribute is not present being '<literal>autodetect</literal>'</para> diff --git a/src/reference/docbook/cache.xml b/src/reference/docbook/cache.xml index 85b7beff65..7070103306 100644 --- a/src/reference/docbook/cache.xml +++ b/src/reference/docbook/cache.xml @@ -33,7 +33,7 @@ <para>At its core, the abstraction applies caching to Java methods, reducing thus the number of executions based on the information available in the cache. That is, each time a <emphasis>targeted</emphasis> method is invoked, the abstraction - will apply a caching behaviour checking whether the method has been already executed for the given arguments. If it has, + will apply a caching behavior checking whether the method has been already executed for the given arguments. If it has, then the cached result is returned without having to execute the actual method; if it has not, then method is executed, the result cached and returned to the user so that, the next time the method is invoked, the cached result is returned. This way, expensive methods (whether CPU or IO bound) can be executed only once for a given set of parameters and the result @@ -227,8 +227,8 @@ public Book findBook(String name)]]></programlisting> be executed and its result placed into the cache (according to the <literal>@CachePut</literal> options). It supports the same options as <literal>@Cacheable</literal> and should be used for cache population rather then method flow optimization.</para> - <para>Note that using <literal>@CachePut</literal> and <literal>@Cacheable</literal> annotations on the same method is generally discouraged because they have different behaviours. While the latter - causes the method execution to be skipped by using the cache, the former forces the execution in order to execute a cache update. This leads to unexpected behaviour and with the exception of specific + <para>Note that using <literal>@CachePut</literal> and <literal>@Cacheable</literal> annotations on the same method is generally discouraged because they have different behaviors. While the latter + causes the method execution to be skipped by using the cache, the former forces the execution in order to execute a cache update. This leads to unexpected behavior and with the exception of specific corner-cases (such as annotations having conditions that exclude them from each other), such declarations should be avoided.</para> </section> @@ -293,7 +293,7 @@ public class AppConfig { <![CDATA[</beans>]]></programlisting> <para>Both the <literal>cache:annotation-driven</literal> element and <interfacename>@EnableCaching</interfacename> annotation allow various options to be specified that influence the way the - caching behaviour is added to the application through AOP. The configuration is intentionally similar + caching behavior is added to the application through AOP. The configuration is intentionally similar with that of <link linkend="tx-annotation-driven-settings"><interfacename>@Transactional</interfacename></link>: </para> @@ -462,7 +462,7 @@ public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)]]>< public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)]]></programlisting> <para>Even though <literal>@SlowService</literal> is not a Spring annotation, the container automatically picks up its declaration at runtime and understands its meaning. Note that as - mentioned <link linkend="cache-annotation-enable">above</link>, the annotation-driven behaviour needs to be enabled.</para> + mentioned <link linkend="cache-annotation-enable">above</link>, the annotation-driven behavior needs to be enabled.</para> </section> </section> @@ -484,7 +484,7 @@ public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)]]>< </cache:caching> </cache:advice> -<!-- apply the cacheable behaviour to all BookService interfaces --> +<!-- apply the cacheable behavior to all BookService interfaces --> <aop:config> <aop:advisor advice-ref="cacheAdvice" pointcut="execution(* x.y.BookService.*(..))"/> </aop:config> diff --git a/src/reference/docbook/dtd.xml b/src/reference/docbook/dtd.xml index 9976d4f8e5..79bbae2628 100644 --- a/src/reference/docbook/dtd.xml +++ b/src/reference/docbook/dtd.xml @@ -250,7 +250,7 @@ The latter two are similar to PicoContainer and make bean factories simple to configure for small namespaces, but doesn't work as well as standard Spring - behaviour for bigger applications. + behavior for bigger applications. Note that explicit dependencies, i.e. "property" and "constructor-arg" elements, always override autowiring. Autowire behavior can be combined with dependency diff --git a/src/reference/docbook/jdbc.xml b/src/reference/docbook/jdbc.xml index 95dde0d808..89c591b642 100644 --- a/src/reference/docbook/jdbc.xml +++ b/src/reference/docbook/jdbc.xml @@ -2950,7 +2950,7 @@ public class DataAccessUnitTestTemplate { used the scripts are executed in lexical order of their URL or filename.</para> - <para>The default behaviour of the database initializer is to + <para>The default behavior of the database initializer is to unconditionally execute the scripts provided. This will not always be what you want, for instance if running against an existing database that already has test data in it. The likelihood of accidentally deleting @@ -3049,7 +3049,7 @@ public class DataAccessUnitTestTemplate { <para>The second option can also be easy. Some suggestions on how to implement this are<itemizedlist> <listitem> - <para>Rely on Spring BeanFactory default behaviour, which is + <para>Rely on Spring BeanFactory default behavior, which is that beans are initialized in registration order. You can easily arrange that by adopting the common practice of a set of <import/> elements that order your application modules,