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).
DefaultContextLoadTimeWeaver
@@ -3689,7 +3689,7 @@ http://www.springframework.org/schema/context
the 'aspectjWeaving' attribute
(or 'aspectj-weaving' 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
'autodetect'
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 @@
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 targeted 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)]]>
be executed and its result placed into the cache (according to the @CachePut options). It supports the same options as @Cacheable and should be used
for cache population rather then method flow optimization.
- Note that using @CachePut and @Cacheable 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
+ Note that using @CachePut and @Cacheable 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.
@@ -293,7 +293,7 @@ public class AppConfig {
]]>
Both the cache:annotation-driven element and @EnableCaching 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 @Transactional:
@@ -462,7 +462,7 @@ public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)]]><
public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)]]>
Even though @SlowService is not a Spring annotation, the container automatically picks up its declaration at runtime and understands its meaning. Note that as
- mentioned above, the annotation-driven behaviour needs to be enabled.
+ mentioned above, the annotation-driven behavior needs to be enabled.
@@ -484,7 +484,7 @@ public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)]]><
-
+
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.
- The default behaviour of the database initializer is to
+ 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 {
The second option can also be easy. Some suggestions on how to
implement this are
- Rely on Spring BeanFactory default behaviour, which is
+ 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,