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.
This commit is contained in:
parent
d70762baaf
commit
c20b22a011
|
@ -3565,7 +3565,7 @@ http://www.springframework.org/schema/context
|
|||
<interfacename>LoadTimeWeaver</interfacename>: the exact type of
|
||||
<interfacename>LoadTimeWeaver</interfacename> that will be
|
||||
'automatically detected' is dependent upon your runtime environment
|
||||
(summarised in the following table).</para>
|
||||
(summarized in the following table).</para>
|
||||
|
||||
<table id="aop-aj-ltw-spring-env-impls" pgwide="1">
|
||||
<title><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>
|
||||
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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,
|
||||
|
|
Loading…
Reference in New Issue