Use unconstrained quotes in reference manual

Prior to this commit, there were numerous places in the reference
manual, where we see output similar to the following:

    BeanDefinition`s with the `ApplicationContext

This commit addresses this issue by using unconstrained quotes
(e.g., ++XYZ++s) instead of backticks (e.g., `XYZ`s) when the formatted
text is immediately followed by an "s".

This commit also corrects a few typos and corrects natural English
pluralization of Java code elements in the reference manual where
appropriate -- for example, "@Controllers" becomes "@Controller classes,
etc.

Issue: SPR-11650
(cherry picked from commit 0eba1f818f)

src/asciidoc/index.adoc

@@ -4308,7 +4308,7 @@ dependency type:
 
 | `BootstrapContextAware`
 | Resource adapter `BootstrapContext` the container runs in. Typically available only in
-  JCA aware `ApplicationContext`s
+  JCA aware ++ApplicationContext++s
 | <<cci>>
 
 | `LoadTimeWeaverAware`
@@ -4460,7 +4460,7 @@ after the Spring container finishes instantiating, configuring, and initializing
 you can plug in one or more `BeanPostProcessor` implementations.
 
 You can configure multiple `BeanPostProcessor` instances, and you can control the order
-in which these `BeanPostProcessor`s execute by setting the `order` property. You can
+in which these ++BeanPostProcessor++s execute by setting the `order` property. You can
 set this property only if the `BeanPostProcessor` implements the `Ordered` interface; if
 you write your own `BeanPostProcessor` you should consider implementing the `Ordered`
 interface too. For further details, consult the javadocs of the `BeanPostProcessor` and
@@ -4470,11 +4470,11 @@ registration of `BeanPostProcessors`>>
 
 [NOTE]
 ====
-`BeanPostProcessor`s operate on bean (or object) __instances__; that is to say, the
-Spring IoC container instantiates a bean instance and __then__ `BeanPostProcessor`s do
+++BeanPostProcessor++s operate on bean (or object) __instances__; that is to say, the
+Spring IoC container instantiates a bean instance and __then__ ++BeanPostProcessor++s do
 their work.
 
-`BeanPostProcessor`s are scoped __per-container__. This is only relevant if you are
+++BeanPostProcessor++s are scoped __per-container__. This is only relevant if you are
 using container hierarchies. If you define a `BeanPostProcessor` in one container, it
 will __only__ post-process the beans in that container. In other words, beans that are
 defined in one container are not post-processed by a `BeanPostProcessor` defined in
@@ -4709,8 +4709,8 @@ you would any other bean.
 
 [NOTE]
 ====
-As with `BeanPostProcessor`s , you typically do not want to configure
-`BeanFactoryPostProcessor`s for lazy initialization. If no other bean references a
+As with ++BeanPostProcessor++s , you typically do not want to configure
+++BeanFactoryPostProcessor++s for lazy initialization. If no other bean references a
 `Bean(Factory)PostProcessor`, that post-processor will not get instantiated at all.
 Thus, marking it for lazy initialization will be ignored, and the
 `Bean(Factory)PostProcessor` will be instantiated eagerly even if you set the
@@ -5028,7 +5028,7 @@ example:
 This annotation simply indicates that the affected bean property must be populated at
 configuration time, through an explicit property value in a bean definition or through
 autowiring. The container throws an exception if the affected bean property has not been
-populated; this allows for eager and explicit failure, avoiding `NullPointerException`s
+populated; this allows for eager and explicit failure, avoiding ++NullPointerException++s
 or the like later on. It is still recommended that you put assertions into the bean
 class itself, for example, into an init method. Doing so enforces those required
 references and values even when you use the class outside of a container.
@@ -5912,7 +5912,7 @@ of the `proxyMode`.
 [[beans-scanning-autodetection]]
 ==== Automatically detecting classes and registering bean definitions
 Spring can automatically detect stereotyped classes and register corresponding
-`BeanDefinition`s with the `ApplicationContext`. For example, the following two classes
+++BeanDefinition++s with the `ApplicationContext`. For example, the following two classes
 are eligible for such autodetection:
 
 [source,java,indent=0]
@@ -6147,10 +6147,11 @@ resolving expression text.
 The `@Bean` methods in a Spring component are processed differently than their
 counterparts inside a Spring `@Configuration` class. The difference is that `@Component`
 classes are not enhanced with CGLIB to intercept the invocation of methods and fields.
-CGLIB proxying is the means by which invoking methods or fields within `@Configuration`
-classes `@Bean` methods create bean metadata references to collaborating objects.
-Methods are __not__ invoked with normal Java semantics. In contrast, calling a method or
-field within a `@Component` classes `@Bean` method __has__ standard Java semantics.
+CGLIB proxying is the means by which invoking methods or fields within `@Bean` methods 
+in `@Configuration` classes creates bean metadata references to collaborating objects;
+such methods are __not__ invoked with normal Java semantics. In contrast, invoking a
+method or field in an `@Bean` method within a `@Component` class __has__ standard Java
+semantics.
 
 
 
@@ -7021,7 +7022,7 @@ inter-bean dependencies. See <<beans-java-basic-concepts>> for a general introdu
 
 [[beans-java-injecting-dependencies]]
 ===== Injecting inter-bean dependencies
-When `@Bean`s have dependencies on one another, expressing that dependency is as simple
+When ++@Bean++s have dependencies on one another, expressing that dependency is as simple
 as having one bean method call another:
 
 [source,java,indent=0]
@@ -8107,7 +8108,7 @@ For optimal usage and understanding of application contexts, users should genera
 familiarize themselves with Spring's `Resource` abstraction, as described in the chapter
 <<resources>>.
 
-An application context is a `ResourceLoader`, which can be used to load `Resource`s. A
+An application context is a `ResourceLoader`, which can be used to load ++Resource++s. A
 `Resource` is essentially a more feature rich version of the JDK class `java.net.URL`,
 in fact, the implementations of the `Resource` wrap an instance of `java.net.URL` where
 appropriate. A `Resource` can obtain low-level resources from almost any location in a
@@ -8203,7 +8204,7 @@ class for the configuration details involved in RAR deployment.
 __For a simple deployment of a Spring ApplicationContext as a J2EE RAR file:__ package
 all application classes into a RAR file, which is a standard JAR file with a different
 file extension. Add all required library JARs into the root of the RAR archive. Add a
-"META-INF/ra.xml" deployment descriptor (as shown in `SpringContextResourceAdapter`s
+"META-INF/ra.xml" deployment descriptor (as shown in ++SpringContextResourceAdapter++'s
 JavaDoc) and the corresponding Spring XML bean definition file(s) (typically
 "META-INF/applicationContext.xml"), and drop the resulting RAR file into your
 application server's deployment directory.
@@ -8616,7 +8617,7 @@ Similarly, one can force a `UrlResource` to be used by specifying any of the sta
 	Resource template = ctx.getResource("http://myhost.com/resource/path/myTemplate.txt");
 ----
 
-The following table summarizes the strategy for converting `String`s to `Resource`s:
+The following table summarizes the strategy for converting ++String++s to ++Resource++s:
 
 [[resources-resource-strings]]
 .Resource strings
@@ -10520,7 +10521,7 @@ For XML you should use the `'conversion-service'` attribute of the
 Spring 3 introduces several enhancements to its validation support. First, the JSR-303
 Bean Validation API is now fully supported. Second, when used programmatically, Spring's
 DataBinder can now validate objects as well as bind to them. Third, Spring MVC now has
-support for declaratively validating @Controller inputs.
+support for declaratively validating `@Controller` inputs.
 
 
 
@@ -10739,14 +10740,14 @@ locally on a DataBinder instance. See <<validation-mvc-configuring>>.
 [[validation-mvc]]
 ==== Spring MVC 3 Validation
 Beginning with Spring 3, Spring MVC has the ability to automatically validate
-@Controller inputs. In previous versions it was up to the developer to manually invoke
+`@Controller` inputs. In previous versions it was up to the developer to manually invoke
 validation logic.
 
 
 [[validation-mvc-triggering]]
 ===== Triggering @Controller Input Validation
-To trigger validation of a @Controller input, simply annotate the input argument as
-@Valid:
+To trigger validation of a `@Controller` input, simply annotate the input argument as
+++@Valid++:
 
 [source,java,indent=0]
 [subs="verbatim,quotes"]
@@ -10770,10 +10771,10 @@ Spring-specific construct.
 
 [[validation-mvc-configuring]]
 ===== Configuring a Validator for use by Spring MVC
-The Validator instance invoked when a @Valid method argument is encountered may be
-configured in two ways. First, you may call binder.setValidator(Validator) within a
-@Controller's @InitBinder callback. This allows you to configure a Validator instance
-per @Controller class:
+The `Validator` instance invoked when a `@Valid` method argument is encountered may be
+configured in two ways. First, you may call `binder.setValidator(Validator)` within a
+++@Controller++'s `@InitBinder` callback. This allows you to configure a `Validator`
+instance per `@Controller` class:
 
 [source,java,indent=0]
 [subs="verbatim,quotes"]
@@ -10792,8 +10793,8 @@ per @Controller class:
 	}
 ----
 
-Second, you may call setValidator(Validator) on the global WebBindingInitializer. This
-allows you to configure a Validator instance across all @Controllers. This can be
+Second, you may call `setValidator(Validator)` on the global `WebBindingInitializer`. This
+allows you to configure a `Validator` instance across all `@Controller` classes. This can be
 achieved easily by using the Spring MVC namespace:
 
 [source,xml,indent=0]
@@ -10861,10 +10862,10 @@ The Spring MVC configuration required to enable Bean Validation support is shown
 	</beans>
 ----
 
-With this minimal configuration, anytime a @Valid @Controller input is encountered, it
+With this minimal configuration, anytime a `@Valid` `@Controller` input is encountered, it
 will be validated by the Bean Validation provider. That provider, in turn, will enforce
-any constraints declared against the input. Any ConstraintViolations will automatically
-be exposed as errors in the BindingResult renderable by standard Spring MVC form tags.
+any constraints declared against the input. Any ++ConstraintViolation++s will automatically
+be exposed as errors in the `BindingResult` renderable by standard Spring MVC form tags.
 
 
 
@@ -11118,7 +11119,7 @@ expression using the methods `setVariable()` and `registerFunction()`. The use o
 variables and functions are described in the language reference sections
 <<expressions-ref-variables,Variables>> and <<expressions-ref-functions,Functions>>. The
 `StandardEvaluationContext` is also where you can register custom
-`ConstructorResolver`s, `MethodResolver`s, and `PropertyAccessor`s to extend how SpEL
+++ConstructorResolver++s, ++MethodResolver++s, and ++PropertyAccessor++s to extend how SpEL
 evaluates expressions. Please refer to the JavaDoc of these classes for more details.
 
 
@@ -11163,15 +11164,15 @@ being placed in it. A simple example:
 
 [[expressions-beandef]]
 === Expression support for defining bean definitions
-SpEL expressions can be used with XML or annotation based configuration metadata for
-defining BeanDefinitions. In both cases the syntax to define the expression is of the
+SpEL expressions can be used with XML or annotation-based configuration metadata for
+defining ++BeanDefinition++s. In both cases the syntax to define the expression is of the
 form `#{ <expression string> }`.
 
 
 
 [[expressions-beandef-xml-based]]
 ==== XML based configuration
-A property or constructor-arg value can be set using expressions as shown below
+A property or constructor-arg value can be set using expressions as shown below.
 
 [source,xml,indent=0]
 [subs="verbatim,quotes"]
@@ -11183,8 +11184,8 @@ A property or constructor-arg value can be set using expressions as shown below
 	</bean>
 ----
 
-The variable 'systemProperties' is predefined, so you can use it in your expressions as
-shown below. Note that you do not have to prefix the predefined variable with the '#'
+The variable `systemProperties` is predefined, so you can use it in your expressions as
+shown below. Note that you do not have to prefix the predefined variable with the `#`
 symbol in this context.
 
 [source,xml,indent=0]
@@ -11347,8 +11348,8 @@ By default real numbers are parsed using Double.parseDouble().
 
 [[expressions-properties-arrays]]
 ==== Properties, Arrays, Lists, Maps, Indexers
-Navigating with property references is easy, just use a period to indicate a nested
-property value. The instances of Inventor class, pupin and tesla, were populated with
+Navigating with property references is easy: just use a period to indicate a nested
+property value. The instances of the `Inventor` class, pupin, and tesla, were populated with
 data listed in the section <<expressions-example-classes,Classes used in the examples>>.
 To navigate "down" and get Tesla's year of birth and Pupin's city of birth the following
 expressions are used.
@@ -11415,7 +11416,7 @@ string literals.
 
 [[expressions-inline-lists]]
 ==== Inline lists
-Lists can be expressed directly in an expression using {} notation.
+Lists can be expressed directly in an expression using `{}` notation.
 
 [source,java,indent=0]
 [subs="verbatim,quotes"]
@@ -11426,7 +11427,7 @@ Lists can be expressed directly in an expression using {} notation.
 	List listOfLists = (List) parser.parseExpression("{{'a','b'},{'x','y'}}").getValue(context);
 ----
 
-{} by itself means an empty list. For performance reasons, if the list is itself
+`{}` by itself means an empty list. For performance reasons, if the list is itself
 entirely composed of fixed literals then a constant list is created to represent the
 expression, rather than building a new list on each evaluation.
 
@@ -11494,8 +11495,8 @@ and greater than or equal are supported using standard operator notation.
 	boolean trueValue = parser.parseExpression("'black' < 'block'").getValue(Boolean.class);
 ----
 
-In addition to standard relational operators SpEL supports the 'instanceof' and regular
-expression based 'matches' operator.
+In addition to standard relational operators SpEL supports the `instanceof` and regular
+expression based `matches` operator.
 
 [source,java,indent=0]
 [subs="none"]
@@ -11516,8 +11517,8 @@ expression based 'matches' operator.
 Each symbolic operator can also be specified as a purely alphabetic equivalent. This
 avoids problems where the symbols used have special meaning for the document type in
 which the expression is embedded (eg. an XML document). The textual equivalents are
-shown here: lt ('<'), gt ('>'), le ('<='), ge ('>='), eq ('=='), ne ('!='), div ('/'),
-mod ('%'), not ('!'). These are case insensitive.
+shown here: `lt` (`<`), `gt` (`>`), `le` (`<=`), `ge` (`>=`), `eq` (`==`),
+`ne` (`!=`), `div` (`/`), `mod` (`%`), `not` (`!`). These are case insensitive.
 
 
 [[expressions-operators-logical]]
@@ -11622,8 +11623,8 @@ done within a call to `setValue` but can also be done inside a call to `getValue
 
 [[expressions-types]]
 ==== Types
-The special 'T' operator can be used to specify an instance of java.lang.Class (the
-'type'). Static methods are invoked using this operator as well. The
+The special `T` operator can be used to specify an instance of java.lang.Class (the
+_type_). Static methods are invoked using this operator as well. The
 `StandardEvaluationContext` uses a `TypeLocator` to find types and the
 `StandardTypeLocator` (which can be replaced) is built with an understanding of the
 java.lang package. This means T() references to types within java.lang do not need to be
@@ -11666,8 +11667,8 @@ used).
 
 [[expressions-ref-variables]]
 ==== Variables
-Variables can be referenced in the expression using the syntax #variableName. Variables
-are set using the method setVariable on the StandardEvaluationContext.
+Variables can be referenced in the expression using the syntax `#variableName`. Variables
+are set using the method setVariable on the `StandardEvaluationContext`.
 
 [source,java,indent=0]
 [subs="verbatim,quotes"]
@@ -12577,10 +12578,10 @@ releases to support more of the AspectJ pointcut designators.
 Because Spring AOP limits matching to only method execution join points, the discussion
 of the pointcut designators above gives a narrower definition than you will find in the
 AspectJ programming guide. In addition, AspectJ itself has type-based semantics and at
-an execution join point both ' `this`' and ' `target`' refer to the same object - the
+an execution join point both '++this++' and '++target++' refer to the same object - the
 object executing the method. Spring AOP is a proxy-based system and differentiates
-between the proxy object itself (bound to ' `this`') and the target object behind the
-proxy (bound to ' `target`').
+between the proxy object itself (bound to '++this++') and the target object behind the
+proxy (bound to '++target++').
 
 [NOTE]
 ====
@@ -12597,9 +12598,9 @@ different characteristics, so be sure to make yourself familiar with weaving fir
 before making a decision.
 ====
 
-Spring AOP also supports an additional PCD named ' `bean`'. This PCD allows you to limit
+Spring AOP also supports an additional PCD named '++bean++'. This PCD allows you to limit
 the matching of join points to a particular named Spring bean, or to a set of named
-Spring beans (when using wildcards). The ' `bean`' PCD has the following form:
+Spring beans (when using wildcards). The '++bean++' PCD has the following form:
 
 [source,java,indent=0]
 [subs="verbatim,quotes"]
@@ -12607,19 +12608,19 @@ Spring beans (when using wildcards). The ' `bean`' PCD has the following form:
 	bean(idOrNameOfBean)
 ----
 
-The ' `idOrNameOfBean`' token can be the name of any Spring bean: limited wildcard
-support using the ' `*`' character is provided, so if you establish some naming
-conventions for your Spring beans you can quite easily write a ' `bean`' PCD expression
-to pick them out. As is the case with other pointcut designators, the ' `bean`' PCD can
+The '++idOrNameOfBean++' token can be the name of any Spring bean: limited wildcard
+support using the '++*++' character is provided, so if you establish some naming
+conventions for your Spring beans you can quite easily write a '++bean++' PCD expression
+to pick them out. As is the case with other pointcut designators, the '++bean++' PCD can
 be &&'ed, ||'ed, and ! (negated) too.
 
 [NOTE]
 ====
-Please note that the ' `bean`' PCD is __only__ supported in Spring AOP - and __not__ in
+Please note that the '++bean++' PCD is __only__ supported in Spring AOP - and __not__ in
 native AspectJ weaving. It is a Spring-specific extension to the standard PCDs that
 AspectJ defines.
 
-The ' `bean`' PCD operates at the __instance__ level (building on the Spring bean name
+The '++bean++' PCD operates at the __instance__ level (building on the Spring bean name
 concept) rather than at the type level only (which is what weaving-based AOP is limited
 to). Instance-based pointcut designators are a special capability of Spring's
 proxy-based AOP framework and its close integration with the Spring bean factory, where
@@ -12945,8 +12946,8 @@ for how to make the annotation object available in the advice body.
 how to make the annotation object(s) available in the advice body.
 ====
 
-* any join point (method execution only in Spring AOP) on a Spring bean named '
-  `tradeService`':
+* any join point (method execution only in Spring AOP) on a Spring bean named
+  '++tradeService++':
 
 [source,java,indent=0]
 [subs="verbatim,quotes"]
@@ -12955,7 +12956,7 @@ how to make the annotation object(s) available in the advice body.
 ----
 
 * any join point (method execution only in Spring AOP) on Spring beans having names that
-  match the wildcard expression ' `*Service`':
+  match the wildcard expression '++*Service++':
 
 [source,java,indent=0]
 [subs="verbatim,quotes"]
@@ -14567,8 +14568,8 @@ In the XML style I can declare the first two pointcuts:
 			expression="execution(org.xyz.Account+ *(..))"/>
 ----
 
-The downside of the XML approach is that you cannot define the '
-`accountPropertyAccess`' pointcut by combining these definitions.
+The downside of the XML approach is that you cannot define the
+'++accountPropertyAccess++' pointcut by combining these definitions.
 
 The @AspectJ style supports additional instantiation models, and richer pointcut
 composition. It has the advantage of keeping the aspect as a modular unit. It also has
@@ -14647,7 +14648,7 @@ at runtime, which applies the __strongest__ proxy settings that any of the
 This also applies to the `<tx:annotation-driven/>` and `<aop:aspectj-autoproxy/>`
 elements.
 
-To be clear: using ' `proxy-target-class="true"`' on `<tx:annotation-driven/>`,
+To be clear: using '++proxy-target-class="true"++' on `<tx:annotation-driven/>`,
 `<aop:aspectj-autoproxy/>` or `<aop:config/>` elements will force the use of CGLIB
 proxies __for all three of them__.
 ====
@@ -14900,7 +14901,7 @@ Spring will now look for a bean definition named " `account`" and use that as th
 definition to configure new `Account` instances.
 
 You can also use autowiring to avoid having to specify a dedicated bean definition at
-all. To have Spring apply autowiring use the ' `autowire`' property of the
+all. To have Spring apply autowiring use the '++autowire++' property of the
 `@Configurable` annotation: specify either `@Configurable(autowire=Autowire.BY_TYPE)` or
 `@Configurable(autowire=Autowire.BY_NAME` for autowiring by type or by name
 respectively. As an alternative, as of Spring 2.5 it is preferable to specify explicit,
@@ -14920,7 +14921,7 @@ the annotation. In essence the aspect says "after returning from the initializat
 new object of a type annotated with `@Configurable`, configure the newly created object
 using Spring in accordance with the properties of the annotation". In this context,
 __initialization__ refers to newly instantiated objects (e.g., objects instantiated with
-the ' `new`' operator) as well as to `Serializable` objects that are undergoing
+the '++new++' operator) as well as to `Serializable` objects that are undergoing
 deserialization (e.g., via
 http://docs.oracle.com/javase/6/docs/api/java/io/Serializable.html[readResolve()]).
 
@@ -15103,7 +15104,7 @@ fully-qualified class names:
 When using AspectJ aspects with Spring applications, it is natural to both want and
 expect to be able to configure such aspects using Spring. The AspectJ runtime itself is
 responsible for aspect creation, and the means of configuring the AspectJ created
-aspects via Spring depends on the AspectJ instantiation model (the ' `per-xxx`' clause)
+aspects via Spring depends on the AspectJ instantiation model (the '++per-xxx++' clause)
 used by the aspect.
 
 The majority of AspectJ aspects are __singleton__ aspects. Configuration of these
@@ -15241,10 +15242,10 @@ profiler, using the @AspectJ-style of aspect declaration.
 	}
 ----
 
-We will also need to create an ' `META-INF/aop.xml`' file, to inform the AspectJ weaver
+We will also need to create an '++META-INF/aop.xml++' file, to inform the AspectJ weaver
 that we want to weave our `ProfilingAspect` into our classes. This file convention,
-namely the presence of a file (or files) on the Java classpath called '
-`META-INF/aop.xml`' is standard AspectJ.
+namely the presence of a file (or files) on the Java classpath called
+'++META-INF/aop.xml++' is standard AspectJ.
 
 [source,xml,indent=0]
 [subs="verbatim,quotes"]
@@ -15268,7 +15269,7 @@ namely the presence of a file (or files) on the Java classpath called '
 Now to the Spring-specific portion of the configuration. We need to configure a
 `LoadTimeWeaver` (all explained later, just take it on trust for now). This load-time
 weaver is the essential component responsible for weaving the aspect configuration in
-one or more ' `META-INF/aop.xml`' files into the classes in your application. The good
+one or more '++META-INF/aop.xml++' files into the classes in your application. The good
 thing is that it does not require a lot of configuration, as can be seen below (there
 are some more options that you can specify, but these are detailed later).
 
@@ -15294,7 +15295,7 @@ are some more options that you can specify, but these are detailed later).
 	</beans>
 ----
 
-Now that all the required artifacts are in place - the aspect, the ' `META-INF/aop.xml`'
+Now that all the required artifacts are in place - the aspect, the '++META-INF/aop.xml++'
 file, and the Spring configuration -, let us create a simple driver class with a
 `main(..)` method to demonstrate the LTW in action.
 
@@ -15331,7 +15332,7 @@ to switch on the LTW. This is the command line we will use to run the above `Mai
 java -javaagent:C:/projects/foo/lib/global/spring-instrument.jar foo.Main
 ----
 
-The ' `-javaagent`' is a flag for specifying and enabling
+The '++-javaagent++' is a flag for specifying and enabling
 http://docs.oracle.com/javase/6/docs/api/java/lang/instrument/package-summary.html[agents
 to instrument programs running on the JVM]. The Spring Framework ships with such an
 agent, the `InstrumentationSavingAgent`, which is packaged in the
@@ -15407,15 +15408,15 @@ Furthermore, the compiled aspect classes need to be available on the classpath.
 
 
 [[aop-aj-ltw-aop_dot_xml]]
-===== ' META-INF/aop.xml'
+===== 'META-INF/aop.xml'
 
-The AspectJ LTW infrastructure is configured using one or more ' `META-INF/aop.xml`'
+The AspectJ LTW infrastructure is configured using one or more '++META-INF/aop.xml++'
 files, that are on the Java classpath (either directly, or more typically in jar files).
 
 The structure and contents of this file is detailed in the main AspectJ reference
 documentation, and the interested reader is
 http://www.eclipse.org/aspectj/doc/released/devguide/ltw-configuration.html[referred to
-that resource]. (I appreciate that this section is brief, but the ' `aop.xml`' file is
+that resource]. (I appreciate that this section is brief, but the '++aop.xml++' file is
 100% AspectJ - there is no Spring-specific information or semantics that apply to it,
 and so there is no extra value that I can contribute either as a result), so rather than
 rehash the quite satisfactory section that the AspectJ developers wrote, I am just
@@ -15474,8 +15475,8 @@ which typically is done using the `@EnableLoadTimeWeaving` annotation.
 ----
 
 Alternatively, if you prefer XML based configuration, use the
-`<context:load-time-weaver/>` element. Note that the element is defined in the '
-`context`' namespace.
+`<context:load-time-weaver/>` element. Note that the element is defined in the
+'++context++' namespace.
 
 [source,xml,indent=0]
 [subs="verbatim,quotes"]
@@ -15553,7 +15554,7 @@ To specify a specific `LoadTimeWeaver` with Java configuration implement the
 ----
 
 If you are using XML based configuration you can specify the fully-qualified classname
-as the value of the ' `weaver-class`' attribute on the `<context:load-time-weaver/>`
+as the value of the '++weaver-class++' attribute on the `<context:load-time-weaver/>`
 element:
 
 [source,xml,indent=0]
@@ -15576,7 +15577,7 @@ element:
 ----
 
 The `LoadTimeWeaver` that is defined and registered by the configuration can be later
-retrieved from the Spring container using the well-known name ' `loadTimeWeaver`'.
+retrieved from the Spring container using the well-known name '++loadTimeWeaver++'.
 Remember that the `LoadTimeWeaver` exists just as a mechanism for Spring's LTW
 infrastructure to add one or more `ClassFileTransformers`. The actual
 `ClassFileTransformer` that does the LTW is the `ClassPreProcessorAgentAdapter` (from
@@ -15584,11 +15585,11 @@ the `org.aspectj.weaver.loadtime` package) class. See the class-level javadocs o
 `ClassPreProcessorAgentAdapter` class for further details, because the specifics of how
 the weaving is actually effected is beyond the scope of this section.
 
-There is one final attribute of the configuration left to discuss: 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, summarized below, with the default value if the
-attribute is not present being ' `autodetect`'
+There is one final attribute of the configuration left to discuss: 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, summarized below, with the default value being
+'++autodetect++' if the attribute is not present.
 
 [[aop-aj-ltw-ltw-tag-attrs]]
 .AspectJ weaving attribute values
@@ -15605,7 +15606,7 @@ attribute is not present being ' `autodetect`'
 
 | `AUTODETECT`
 | `autodetect`
-| If the Spring LTW infrastructure can find at least one ' `META-INF/aop.xml`' file,
+| If the Spring LTW infrastructure can find at least one '++META-INF/aop.xml++' file,
   then AspectJ weaving is on, else it is off. This is the default value.
 |===
 
@@ -17581,7 +17582,7 @@ depends on environment-specific properties.
 ===== JNDI
 The `org.springframework.mock.jndi` package contains an implementation of the JNDI SPI,
 which you can use to set up a simple JNDI environment for test suites or stand-alone
-applications. If, for example, JDBC `DataSource`s get bound to the same JNDI names in
+applications. If, for example, JDBC ++DataSource++s get bound to the same JNDI names in
 test code as within a Java EE container, you can reuse both application code and
 configuration in testing scenarios without modification.
 
@@ -17630,7 +17631,7 @@ dealing with Spring MVC `ModelAndView` objects.
 [TIP]
 ====
 
-To test your Spring MVC `Controller`s, use `ModelAndViewAssert` combined with
+To test your Spring MVC ++Controller++s, use `ModelAndViewAssert` combined with
 `MockHttpServletRequest`, `MockHttpSession`, and so on from the <<mock-objects-servlet,
 `org.springframework.mock.web`>> package.
 
@@ -17691,7 +17692,7 @@ configuration details.
 [[testing-ctx-management]]
 ===== Context management and caching
 The Spring TestContext Framework provides consistent loading of Spring
-`ApplicationContext`s and `WebApplicationContext`s as well as caching of those
+++ApplicationContext++s and ++WebApplicationContext++s as well as caching of those
 contexts. Support for the caching of loaded contexts is important, because startup time
 can become an issue -- not because of the overhead of Spring itself, but because the
 objects instantiated by the Spring container take time to instantiate. For example, a
@@ -17724,7 +17725,7 @@ configure instances of your test classes via Dependency Injection. This provides
 convenient mechanism for setting up test fixtures using preconfigured beans from your
 application context. A strong benefit here is that you can reuse application contexts
 across various testing scenarios (e.g., for configuring Spring-managed object graphs,
-transactional proxies, `DataSource`s, etc.), thus avoiding the need to duplicate
+transactional proxies, ++DataSource++s, etc.), thus avoiding the need to duplicate
 complex test fixture setup for individual test cases.
 
 As an example, consider the scenario where we have a class, `HibernateTitleRepository`,
@@ -17957,7 +17958,7 @@ hierarchy. See the `@WebAppConfiguration` javadocs for further details.
 
 +
 
-A class-level annotation that is used to define a hierarchy of `ApplicationContext`s
+A class-level annotation that is used to define a hierarchy of ++ApplicationContext++s
 for integration tests. `@ContextHierarchy` should be declared with a list of one or more
 `@ContextConfiguration` instances, each of which defines a level in the context
 hierarchy. The following examples demonstrate the use of `@ContextHierarchy` within a
@@ -18129,7 +18130,7 @@ hierarchy via `@ContextHierarchy`, the `hierarchyMode` flag can be used to contr
 the context cache is cleared. By default an __exhaustive__ algorithm will be used that
 clears the context cache including not only the current level but also all other context
 hierarchies that share an ancestor context common to the current test; all
-`ApplicationContext`s that reside in a sub-hierarchy of the common ancestor context
+++ApplicationContext++s that reside in a sub-hierarchy of the common ancestor context
 will be removed from the context cache and closed. If the __exhaustive__ algorithm is
 overkill for a particular use case, the simpler __current level__ algorithm can be
 specified instead, as seen below.
@@ -18166,7 +18167,7 @@ For further details regarding the `EXHAUSTIVE` and `CURRENT_LEVEL` algorithms se
 
 +
 
-Defines class-level metadata for configuring which `TestExecutionListener`s should be
+Defines class-level metadata for configuring which ++TestExecutionListener++s should be
 registered with the `TestContextManager`. Typically, `@TestExecutionListeners` is used
 in conjunction with `@ContextConfiguration`.
 
@@ -18551,7 +18552,7 @@ and the `TestExecutionListener`, `ContextLoader`, and `SmartContextLoader` inter
 `TestContextManager` is created on a per-test basis (e.g., for the execution of a single
 test method in JUnit). The `TestContextManager` in turn manages a `TestContext` that
 holds the context of the current test. The `TestContextManager` also updates the state
-of the `TestContext` as the test progresses and delegates to `TestExecutionListener`s,
+of the `TestContext` as the test progresses and delegates to ++TestExecutionListener++s,
 which instrument the actual test execution by providing dependency injection, managing
 transactions, and so on. A `ContextLoader` (or `SmartContextLoader`) is responsible for
 loading an `ApplicationContext` for a given test class. Consult the javadocs and the
@@ -18564,7 +18565,7 @@ Spring test suite for further information and examples of various implementation
   requested.
 * `TestContextManager`: The main entry point into the __Spring TestContext Framework__,
   which manages a single `TestContext` and signals events to all registered
-  `TestExecutionListener`s at well-defined test execution points:
+  ++TestExecutionListener++s at well-defined test execution points:
 ** prior to any __before class methods__ of a particular testing framework
 ** test instance preparation
 ** prior to any __before methods__ of a particular testing framework
@@ -19543,7 +19544,7 @@ default.
 
 When writing integration tests that rely on a loaded Spring `ApplicationContext`, it is
 often sufficient to test against a single context; however, there are times when it is
-beneficial or even necessary to test against a hierarchy of `ApplicationContext`s. For
+beneficial or even necessary to test against a hierarchy of ++ApplicationContext++s. For
 example, if you are developing a Spring MVC web application you will typically have a
 root `WebApplicationContext` loaded via Spring's `ContextLoaderListener` and a child
 `WebApplicationContext` loaded via Spring's `DispatcherServlet`. This results in a
@@ -19663,7 +19664,7 @@ set as the parent context for the contexts loaded from `"/user-config.xml"` and
 --
 In contrast to the previous example, this example demonstrates how to __override__ the
 configuration for a given named level in a context hierarchy by setting
-`ContextConfiguration`'s `inheritLocations` flag to `false`. Consequently, the
+++ContextConfiguration++'s `inheritLocations` flag to `false`. Consequently, the
 application context for `ExtendedTests` will be loaded only from
 `"/test-user-config.xml"` and will have its parent set to the context loaded from
 `"/app-config.xml"`.
@@ -21631,7 +21632,7 @@ the call stack, and make a determination whether to mark the transaction for rol
 In its default configuration, the Spring Framework's transaction infrastructure code
 __only__ marks a transaction for rollback in the case of runtime, unchecked exceptions;
 that is, when the thrown exception is an instance or subclass of `RuntimeException`. (
-`Error`s will also - by default - result in a rollback). Checked exceptions that are
+++Error++s will also - by default - result in a rollback). Checked exceptions that are
 thrown from a transactional method do __not__ result in rollback in the default
 configuration.
 
@@ -23124,7 +23125,7 @@ creation and release of resources, which helps you avoid common errors such as
 forgetting to close the connection. It performs the basic tasks of the core JDBC
 workflow such as statement creation and execution, leaving application code to provide
 SQL and extract results. The `JdbcTemplate` class executes SQL queries, update
-statements and stored procedure calls, performs iteration over `ResultSet`s and
+statements and stored procedure calls, performs iteration over ++ResultSet++s and
 extraction of returned parameter values. It also catches JDBC exceptions and translates
 them to the generic, more informative, exception hierarchy defined in the
 `org.springframework.dao` package.
@@ -23397,7 +23398,7 @@ The corresponding XML configuration file would look like the following:
 			http://www.springframework.org/schema/context
 			http://www.springframework.org/schema/context/spring-context.xsd">
 
-		<!-- Scans within the base package of the application for @Components to configure as beans -->
+		<!-- Scans within the base package of the application for @Component classes to configure as beans -->
 		<context:component-scan base-package="org.springframework.docs.test" />
 
 		<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
@@ -25332,8 +25333,8 @@ declaration of an `SqlOutParameter`.
 You use the `SqlTypeValue` to pass in the value of a Java object like `TestItem` into a
 stored procedure. The `SqlTypeValue` interface has a single method named
 `createTypeValue` that you must implement. The active connection is passed in, and you
-can use it to create database-specific objects such as `StructDescriptor`s, as shown in
-the following example, or `ArrayDescriptor`s.
+can use it to create database-specific objects such as ++StructDescriptor++s, as shown in
+the following example, or ++ArrayDescriptor++s.
 
 [source,java,indent=0]
 [subs="verbatim,quotes"]
@@ -27809,7 +27810,7 @@ set using the `targetClass` property. Optionally, you can set the binding name u
 ----
 
 A `JibxMarshaller` is configured for a single class. If you want to marshal multiple
-classes, you have to configure multiple `JibxMarshaller`s with different `targetClass`
+classes, you have to configure multiple ++JibxMarshaller++s with different `targetClass`
 property values.
 
 
@@ -28534,7 +28535,7 @@ application shows a multi-action controller using `@RequestMapping`:
 ----
 
 [[mvc-ann-requestmapping-proxying]]
-===== `@Controller`'s and AOP Proxying
+===== ++@Controller++'s and AOP Proxying
 
 In some cases a controller may need to be decorated with an AOP proxy at runtime.
 One example is if you choose to have `@Transactional` annotations directly on the
@@ -28992,7 +28993,7 @@ The following are the supported method arguments:
 [NOTE]
 ====
 Session access may not be thread-safe, in particular in a Servlet environment. Consider
-setting the `RequestMappingHandlerAdapter`'s "synchronizeOnSession" flag to "true" if
+setting the ++RequestMappingHandlerAdapter++'s "synchronizeOnSession" flag to "true" if
 multiple requests are allowed to access a session concurrently.
 ====
 
@@ -29020,13 +29021,13 @@ multiple requests are allowed to access a session concurrently.
   headers. Parameter values are converted to the declared method argument type.
 * `@RequestBody` annotated parameters for access to the HTTP request body. Parameter
   values are converted to the declared method argument type using
-  `HttpMessageConverter`s. See <<mvc-ann-requestbody>>.
+  ++HttpMessageConverter++s. See <<mvc-ann-requestbody>>.
 * `@RequestPart` annotated parameters for access to the content of a
   "multipart/form-data" request part. See <<mvc-multipart-forms-non-browsers>> and
   <<mvc-multipart>>.
 * `HttpEntity<?>` parameters for access to the Servlet request HTTP headers and
   contents. The request stream will be converted to the entity body using
-  `HttpMessageConverter`s. See <<mvc-ann-httpentity>>.
+  ++HttpMessageConverter++s. See <<mvc-ann-httpentity>>.
 * `java.util.Map` / `org.springframework.ui.Model` / `org.springframework.ui.ModelMap`
   for enriching the implicit model that is exposed to the web view.
 * `org.springframework.web.servlet.mvc.support.RedirectAttributes` to specify the exact
@@ -29102,10 +29103,10 @@ The following are the supported return types:
   signature).
 * If the method is annotated with `@ResponseBody`, the return type is written to the
   response HTTP body. The return value will be converted to the declared method argument
-  type using `HttpMessageConverter`s. See <<mvc-ann-responsebody>>.
+  type using ++HttpMessageConverter++s. See <<mvc-ann-responsebody>>.
 * An `HttpEntity<?>` or `ResponseEntity<?>` object to provide access to the Servlet
   response HTTP headers and contents. The entity body will be converted to the response
-  stream using `HttpMessageConverter`s. See <<mvc-ann-httpentity>>.
+  stream using ++HttpMessageConverter++s. See <<mvc-ann-httpentity>>.
 * An `HttpHeaders` object to return a response with no body.
 * A `Callable<?>` can be returned when the application wants to produce the return value
   asynchronously in a thread managed by Spring MVC.
@@ -29149,7 +29150,7 @@ The following code snippet shows the usage:
 ----
 
 Parameters using this annotation are required by default, but you can specify that a
-parameter is optional by setting `@RequestParam`'s `required` attribute to `false`
+parameter is optional by setting ++@RequestParam++'s `required` attribute to `false`
 (e.g., `@RequestParam(value="id", required=false)`).
 
 Type conversion is applied automatically if the target method parameter type is not
@@ -29270,7 +29271,7 @@ is a stereotype annotation that combines `@ResponseBody` and `@Controller`. More
 that, it gives more meaning to your Controller and also may carry additional semantics
 in future releases of the framework.
 
-As with regular `@Controllers`, a `@RestController` may be assisted by a
+As with regular ++@Controller++s, a `@RestController` may be assisted by a
 `@ControllerAdvice` Bean. See the <<mvc-ann-controller-advice>> section for more details.
 
 [[mvc-ann-httpentity]]
@@ -29353,7 +29354,7 @@ depending on your needs.
 A controller can have any number of `@ModelAttribute` methods. All such methods are
 invoked before `@RequestMapping` methods of the same controller.
 
-`@ModelAttribute` methods can also be defined in an `@ControllerAdvice`-annotated class
+`@ModelAttribute` methods can also be defined in an ++@ControllerAdvice++-annotated class
 and such methods apply to many controllers. See the <<mvc-ann-controller-advice>> section
 for more details.
 
@@ -29747,7 +29748,7 @@ PropertyEditors required by several of the PetClinic controllers.
 	</bean>
 ----
 
-`@InitBinder` methods can also be defined in an `@ControllerAdvice`-annotated class in
+`@InitBinder` methods can also be defined in an ++@ControllerAdvice++-annotated class in
 which case they apply to matching controllers. This provides an alternative to using a
 `WebBindingInitializer`. See the <<mvc-ann-controller-advice>> section for more details.
 
@@ -29786,14 +29787,14 @@ The latter, in combination with the former, causes Spring MVC to do no further
 processing of the request.
 
 [[mvc-ann-controller-advice]]
-===== Assisting Controllers with the @ControllerAdvice annotation
+===== Advising controllers with the `@ControllerAdvice` annotation
 The `@ControllerAdvice` annotation is a component annotation allowing implementation
-classes to be autodetected through classpath scanning. It is automatically enabled when
+classes to be auto-detected through classpath scanning. It is automatically enabled when
 using the MVC namespace or the MVC Java config.
 
 Classes annotated with `@ControllerAdvice` can contain `@ExceptionHandler`,
-`@InitBinder`, and `@ModelAttribute` annotated methods and those will apply to
-`@RequestMapping` methods across controller hierarchies as opposed to the controller
+`@InitBinder`, and `@ModelAttribute` annotated methods, and these methods will apply to
+`@RequestMapping` methods across all controller hierarchies as opposed to the controller
 hierarchy within which they are declared.
 
 The `@ControllerAdvice` annotation can also target a subset of controllers with its
@@ -30069,7 +30070,7 @@ don't need to do that because the `RequestMappingHandlerMapping` automatically l
 all `HandlerMapping` classes extending from `AbstractHandlerMapping` have the following
 properties that you can use to customize their behavior:
 
-* `interceptors` List of interceptors to use. `HandlerInterceptor`s are discussed in
+* `interceptors` List of interceptors to use. ++HandlerInterceptor++s are discussed in
   <<mvc-handlermapping-interceptor>>.
 * `defaultHandler` Default handler to use, when this handler mapping does not result in
   a matching handler.
@@ -31920,7 +31921,7 @@ in addition to the JavaBeans PropertyEditors used for Data Binding.
 through the `ConversionService`.
 . Support for <<format,formatting>> Date, Calendar, Long, and Joda Time fields using the
 `@DateTimeFormat` annotation.
-. Support for <<validation-mvc-jsr303,validating>> @Controller inputs with `@Valid`, if
+. Support for <<validation-mvc-jsr303,validating>> `@Controller` inputs with `@Valid`, if
 a JSR-303 Provider is present on the classpath.
 . HttpMessageConverter support for `@RequestBody` method parameters and `@ResponseBody`
 method return values from `@RequestMapping` or `@ExceptionHandler` methods.
@@ -33388,7 +33389,7 @@ web.xml:
 	</filter-mapping>
 ----
 
-The corresponding @Controller method is shown below:
+The corresponding `@Controller` method is shown below:
 
 [source,java,indent=0]
 [subs="verbatim,quotes"]
@@ -35549,7 +35550,7 @@ action request, handling a render request, and returning a model and a view.
 ==== AbstractController and PortletContentGenerator
 
 Of course, just a `Controller` interface isn't enough. To provide a basic
-infrastructure, all of Spring Portlet MVC's `Controller`s inherit from
+infrastructure, all of Spring Portlet MVC's ++Controller++s inherit from
 `AbstractController`, a class offering access to Spring's `ApplicationContext` and
 control over caching.
 
@@ -35758,7 +35759,7 @@ The rest of this section describes three of Spring Portlet MVC's most commonly u
 handler mappings. They all extend `AbstractHandlerMapping` and share the following
 properties:
 
-* `interceptors`: The list of interceptors to use. `HandlerInterceptor`s are discussed
+* `interceptors`: The list of interceptors to use. ++HandlerInterceptor++s are discussed
   in <<portlet-handlermapping-interceptor>>.
 * `defaultHandler`: The default handler to use, when this handler mapping does not
   result in a matching handler.
@@ -36222,7 +36223,7 @@ register any custom property editor because there is no type conversion to be pe
 
 [[portlet-exceptionresolver]]
 === Handling exceptions
-Just like Servlet MVC, Portlet MVC provides `HandlerExceptionResolver`s to ease the
+Just like Servlet MVC, Portlet MVC provides ++HandlerExceptionResolver++s to ease the
 pain of unexpected exceptions that occur while your request is being processed by a
 handler that matched the request. Portlet MVC also provides a portlet-specific, concrete
 `SimpleMappingExceptionResolver` that enables you to take the class name of any
@@ -38014,13 +38015,13 @@ This connection is used for messages originating from the server-side applicatio
 only, not for receiving messages. You can configure the STOMP credentials
 for this connection, i.e. the STOMP frame `login` and `passcode` headers. This
 is exposed in both the XML namespace and the Java config as the
-`systemLogin`/`systemPasscode` properties with default values `guest`/`guest`.
+++systemLogin++/++systemPasscode++ properties with default values ++guest++/++guest++.
 
 The STOMP broker relay also creates a separate TCP connection for every connected
 WebSocket client. You can configure the STOMP credentials to use for all TCP
 connections created on behalf of clients. This is exposed in both the XML namespace
 and the Java config as the `clientLogin`/`clientPasscode` properties with default
-values `guest`/`guest`.
+values ++guest++/++guest++.
 
 [NOTE]
 ====
@@ -38167,7 +38168,7 @@ properties work and understand the various queuing strategies.
 On the `"clientOutboundChannel"` side it is all about sending messages to WebSocket
 clients. If clients are on a fast network then the number of threads should
 remain close to the number of available processors. If they are slow or on
-low bandwith they will take longer to consume messages and put a burden on the
+low bandwidth they will take longer to consume messages and put a burden on the
 thread pool. Therefore increasing the thread pool size will be necessary.
 
 While the workload for the "clientInboundChannel" is possible to predict --
@@ -39630,7 +39631,7 @@ Concrete implementations for the main media (mime) types are provided in the fra
 and are registered by default with the `RestTemplate` on the client-side and with
 `AnnotationMethodHandlerAdapter` on the server-side.
 
-The implementations of `HttpMessageConverter`s are described in the following sections.
+The implementations of ++HttpMessageConverter++s are described in the following sections.
 For all converters a default media type is used but can be overridden by setting the
 `supportedMediaTypes` bean property
 
@@ -41856,7 +41857,7 @@ lists of method names.
 === Controlling the ObjectNames for your beans
 
 Behind the scenes, the `MBeanExporter` delegates to an implementation of the
-`ObjectNamingStrategy` to obtain `ObjectName`s for each of the beans it is registering.
+`ObjectNamingStrategy` to obtain ++ObjectName++s for each of the beans it is registering.
 The default implementation, `KeyNamingStrategy`, will, by default, use the key of the
 `beans` `Map` as the `ObjectName`. In addition, the `KeyNamingStrategy` can map the key
 of the `beans` `Map` to an entry in a `Properties` file (or files) to resolve the
@@ -41871,7 +41872,7 @@ uses source level metadata to obtain the `ObjectName`.
 ==== Reading ObjectNames from Properties
 
 You can configure your own `KeyNamingStrategy` instance and configure it to read
-`ObjectName`s from a `Properties` instance rather than use bean key. The
+++ObjectName++s from a `Properties` instance rather than use bean key. The
 `KeyNamingStrategy` will attempt to locate an entry in the `Properties` with a key
 corresponding to the bean key. If no entry is found or if the `Properties` instance is
 `null` then the bean key itself is used.
@@ -46654,7 +46655,7 @@ we did in the example above by defining the target cache through the `cache:defi
 Out of the box, the cache abstraction provides integration with two storages - one on
 top of the JDK `ConcurrentMap` and one for http://ehcache.org/[EhCache] library. To use
 them, one needs to simply declare an appropriate `CacheManager` - an entity that
-controls and manages `Cache`s and can be used to retrieve these for storage.
+controls and manages ++Cache++s and can be used to retrieve these for storage.
 
 
 
@@ -46746,7 +46747,7 @@ performs no caching - that is, forces the cached methods to be executed every ti
 	</bean>
 ----
 
-The `CompositeCacheManager` above chains multiple `CacheManager`s and additionally,
+The `CompositeCacheManager` above chains multiple ++CacheManager++s and additionally,
 through the `fallbackToNoOpCache` flag, adds a __no op__ cache that for all the
 definitions not handled by the configured cache managers. That is, every cache
 definition not found in either `jdkCache` or `gemfireCache` (configured above) will be