root
/
spring-framework
mirror of https://github.com/spring-projects/spring-framework.git
1
0
Fork 0
Code Issues Actions 6 Packages Projects Releases Wiki Activity

Migrate to Asciidoctor 1.5 syntax 

Issue: SPR-14355
This commit is contained in:
Sam Brannen 2016-06-11 12:51:38 +02:00
parent d60028caf1
commit 0815560c85
13 changed files with 112 additions and 112 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
src/asciidoc/core-aop.adoc
View File

@ -398,10 +398,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]
====
@ -418,9 +418,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"]
@ -428,19 +428,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 and therefore not available for aspects declared in the `@Aspect` model.
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
@ -769,7 +769,7 @@ 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++':
`tradeService`:
[source,java,indent=0]
[subs="verbatim,quotes"]
@ -778,7 +778,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"]
@ -2391,7 +2391,7 @@ In the XML style I can declare the first two pointcuts:
----
The downside of the XML approach is that you cannot define the
'++accountPropertyAccess++' pointcut by combining these definitions.
`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
@ -2467,7 +2467,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__.
====
@ -2720,7 +2720,7 @@ Spring will now look for a bean definition named "account" and use that as the
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,
@ -2740,7 +2740,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()]).
@ -2929,7 +2929,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
@ -3067,10 +3067,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.
`META-INF/aop.xml` is standard AspectJ.
[source,xml,indent=0]
[subs="verbatim,quotes"]
@ -3094,7 +3094,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).
@ -3120,7 +3120,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.
@ -3157,7 +3157,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
@ -3235,13 +3235,13 @@ Furthermore, the compiled aspect classes need to be available on the classpath.
[[aop-aj-ltw-aop_dot_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
@ -3301,7 +3301,7 @@ 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` namespace.
[source,xml,indent=0]
[subs="verbatim,quotes"]
@ -3380,7 +3380,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]
@ -3403,7 +3403,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
@ -3412,10 +3412,10 @@ the `org.aspectj.weaver.loadtime` package) class. See the class-level javadocs o
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
`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.
`autodetect` if the attribute is not present.
[[aop-aj-ltw-ltw-tag-attrs]]
.AspectJ weaving attribute values
@ -3432,7 +3432,7 @@ It accepts one of three possible values, summarized below, with the default valu
| `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.
|===

54
src/asciidoc/core-beans.adoc
View File

@ -3485,7 +3485,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`
@ -3637,21 +3637,21 @@ 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
`Ordered` interfaces. See also the note below on
<<beans-factory-programmatically-registering-beanpostprocessors, programmatic
registration of `BeanPostProcessors`>>.
registration of ``BeanPostProcessor``s>>.
[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
@ -3679,12 +3679,12 @@ configuration metadata which implement the `BeanPostProcessor` interface. The
later upon bean creation. Bean post-processors can be deployed in the container just
like any other beans.
Note that when declaring a ++BeanPostProcessor++ using an `@Bean` factory method on a
Note that when declaring a `BeanPostProcessor` using an `@Bean` factory method on a
configuration class, the return type of the factory method should be the implementation
class itself or at least the `org.springframework.beans.factory.config.BeanPostProcessor`
interface, clearly indicating the post-processor nature of that bean. Otherwise, the
`ApplicationContext` won't be able to autodetect it by type before fully creating it.
Since a ++BeanPostProcessor++ needs to be instantiated early in order to apply to the
Since a `BeanPostProcessor` needs to be instantiated early in order to apply to the
initialization of other beans in the context, this early type detection is critical.
@ -3697,9 +3697,9 @@ While the recommended approach for `BeanPostProcessor` registration is through
register them __programmatically__ against a `ConfigurableBeanFactory` using the
`addBeanPostProcessor` method. This can be useful when needing to evaluate conditional
logic before registration, or even for copying bean post processors across contexts in a
hierarchy. Note however that `BeanPostProcessors` added programmatically __do not
hierarchy. Note however that ``BeanPostProcessor``s added programmatically __do not
respect the `Ordered` interface__. Here it is the __order of registration__ that
dictates the order of execution. Note also that `BeanPostProcessors` registered
dictates the order of execution. Note also that ``BeanPostProcessor``s registered
programmatically are always processed before those registered through auto-detection,
regardless of any explicit ordering.
====
@ -3708,11 +3708,11 @@ regardless of any explicit ordering.
[NOTE]
====
Classes that implement the `BeanPostProcessor` interface are __special__ and are treated
differently by the container. All `BeanPostProcessors` __and beans that they reference
differently by the container. All ``BeanPostProcessor``s __and beans that they reference
directly__ are instantiated on startup, as part of the special startup phase of the
`ApplicationContext`. Next, all `BeanPostProcessors` are registered in a sorted fashion
`ApplicationContext`. Next, all ``BeanPostProcessor``s are registered in a sorted fashion
and applied to all further beans in the container. Because AOP auto-proxying is
implemented as a `BeanPostProcessor` itself, neither `BeanPostProcessors` nor the beans
implemented as a `BeanPostProcessor` itself, neither ``BeanPostProcessor``s nor the beans
they reference directly are eligible for auto-proxying, and thus do not have aspects
woven into them.
@ -3729,7 +3729,7 @@ directly correspond to the declared name of a bean and no name attribute is used
Spring will access other beans for matching them by type.
====
The following examples show how to write, register, and use `BeanPostProcessors` in an
The following examples show how to write, register, and use ``BeanPostProcessor``s in an
`ApplicationContext`.
@ -3850,10 +3850,10 @@ this interface are similar to those of the `BeanPostProcessor`, with one major
difference: `BeanFactoryPostProcessor` operates on the __bean configuration metadata__;
that is, the Spring IoC container allows a `BeanFactoryPostProcessor` to read the
configuration metadata and potentially change it __before__ the container instantiates
any beans other than `BeanFactoryPostProcessors`.
any beans other than ``BeanFactoryPostProcessor``s.
You can configure multiple `BeanFactoryPostProcessors`, and you can control the order in
which these `BeanFactoryPostProcessors` execute by setting the `order` property.
You can configure multiple ``BeanFactoryPostProcessor``s, and you can control the order in
which these ``BeanFactoryPostProcessor``s execute by setting the `order` property.
However, you can only set this property if the `BeanFactoryPostProcessor` implements the
`Ordered` interface. If you write your own `BeanFactoryPostProcessor`, you should
consider implementing the `Ordered` interface too. Consult the javadocs of the
@ -3869,10 +3869,10 @@ to work with bean instances within a `BeanFactoryPostProcessor` (e.g., using
standard container lifecycle. This may cause negative side effects such as bypassing
bean post processing.
Also, `BeanFactoryPostProcessors` are scoped __per-container__. This is only relevant if
Also, ``BeanFactoryPostProcessor``s are scoped __per-container__. This is only relevant if
you are using container hierarchies. If you define a `BeanFactoryPostProcessor` in one
container, it will __only__ be applied to the bean definitions in that container. Bean
definitions in one container will not be post-processed by `BeanFactoryPostProcessors`
definitions in one container will not be post-processed by ``BeanFactoryPostProcessor``s
in another container, even if both containers are part of the same hierarchy.
====
@ -3892,8 +3892,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
@ -4211,7 +4211,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.
@ -5231,7 +5231,7 @@ For further details, consult the <<annotation-programming-model,Spring Annotatio
=== 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]
@ -6561,7 +6561,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]
@ -8385,7 +8385,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
@ -8471,7 +8471,7 @@ class for the configuration details involved in RAR deployment.
__For a simple deployment of a Spring ApplicationContext as a Java EE 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.
@ -8589,7 +8589,7 @@ implementation, you must write code like this:
In both cases, the explicit registration step is inconvenient, which is one reason why
the various `ApplicationContext` implementations are preferred above plain `BeanFactory`
implementations in the vast majority of Spring-backed applications, especially when
using `BeanFactoryPostProcessors` and `BeanPostProcessors`. These mechanisms implement
using ``BeanFactoryPostProcessor``s and ``BeanPostProcessor``s. These mechanisms implement
important functionality such as property placeholder replacement and AOP.

4
src/asciidoc/core-expressions.adoc
View File

@ -247,7 +247,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.
@ -432,7 +432,7 @@ More and more types of expression will be compilable in the future.
[[expressions-beandef]]
== Expression support for defining bean definitions
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
defining ``BeanDefinition``s. In both cases the syntax to define the expression is of the
form `#{ <expression string> }`.

2
src/asciidoc/core-resources.adoc
View File

@ -253,7 +253,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

10
src/asciidoc/data-access.adoc
View File

@ -801,7 +801,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.
@ -2330,7 +2330,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.
@ -4543,8 +4543,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"]
@ -7105,7 +7105,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.

10
src/asciidoc/integration.adoc
View File

@ -1292,7 +1292,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
@ -3894,7 +3894,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
@ -3909,7 +3909,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.
@ -9013,7 +9013,7 @@ we did in the example above by defining the target cache through the `cache:defi
=== Configuring the cache storage
Out of the box, the cache abstraction provides several storage integration. 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.
[[cache-store-configuration-jdk]]
@ -9192,7 +9192,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

2
src/asciidoc/overview.adoc
View File

@ -238,7 +238,7 @@ of the `spring-webmvc` module.
The `spring-test` module supports the <<unit-testing,unit testing>> and
<<integration-testing,integration testing>> of Spring components with JUnit or TestNG. It
provides consistent <<testcontext-ctx-management,loading>> of Spring
++ApplicationContext++s and <<testcontext-ctx-management-caching,caching>> of those
``ApplicationContext``s and <<testcontext-ctx-management-caching,caching>> of those
contexts. It also provides <<mock-objects,mock objects>> that you can use to test your
code in isolation.

36
src/asciidoc/testing.adoc
View File

@ -64,7 +64,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.
@ -79,7 +79,7 @@ alternative Servlet API mock objects such as http://www.mockobjects.com[MockObje
Spring Framework 4.0, the set of mocks in the `org.springframework.mock.web` package is
based on the Servlet 3.0 API.
For thorough integration testing of your Spring MVC and REST ++Controller++s in
For thorough integration testing of your Spring MVC and REST ``Controller``s in
conjunction with your `WebApplicationContext` configuration for Spring MVC, see the
<<spring-mvc-test-framework,_Spring MVC Test Framework_>>.
@ -132,10 +132,10 @@ dealing with Spring MVC `ModelAndView` objects.
.Unit testing Spring MVC Controllers
[TIP]
====
To unit test your Spring MVC ++Controller++s as POJOs, use `ModelAndViewAssert` combined
To unit test your Spring MVC ``Controller``s as POJOs, use `ModelAndViewAssert` combined
with `MockHttpServletRequest`, `MockHttpSession`, and so on from Spring's
<<mock-objects-servlet, Servlet API mocks>>. For thorough integration testing of your
Spring MVC and REST ++Controller++s in conjunction with your `WebApplicationContext`
Spring MVC and REST ``Controller``s in conjunction with your `WebApplicationContext`
configuration for Spring MVC, use the <<spring-mvc-test-framework,_Spring MVC Test
Framework_>> instead.
====
@ -193,7 +193,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
@ -227,7 +227,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`,
@ -442,7 +442,7 @@ hierarchy. See the `@WebAppConfiguration` javadocs for further details.
===== @ContextHierarchy
`@ContextHierarchy` is a class-level annotation that is used to define a hierarchy of
++ApplicationContext++s for integration tests. `@ContextHierarchy` should be declared
``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 single test class; however, `@ContextHierarchy` can also be
@ -670,7 +670,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.
@ -1207,7 +1207,7 @@ by default, exactly in this order.
[[testcontext-tel-config-registering-tels]]
===== Registering custom TestExecutionListeners
Custom ++TestExecutionListener++s can be registered for a test class and its subclasses
Custom ``TestExecutionListener``s can be registered for a test class and its subclasses
via the `@TestExecutionListeners` annotation. See
<<integration-testing-annotations,annotation support>> and the javadocs for
`@TestExecutionListeners` for details and examples.
@ -1215,31 +1215,31 @@ via the `@TestExecutionListeners` annotation. See
[[testcontext-tel-config-automatic-discovery]]
===== Automatic discovery of default TestExecutionListeners
Registering custom ++TestExecutionListener++s via `@TestExecutionListeners` is suitable
Registering custom ``TestExecutionListener``s via `@TestExecutionListeners` is suitable
for custom listeners that are used in limited testing scenarios; however, it can become
cumbersome if a custom listener needs to be used across a test suite. Since Spring
Framework 4.1, this issue is addressed via support for automatic discovery of _default_
`TestExecutionListener` implementations via the `SpringFactoriesLoader` mechanism.
Specifically, the `spring-test` module declares all core default
++TestExecutionListener++s under the
``TestExecutionListener``s under the
`org.springframework.test.context.TestExecutionListener` key in its
`META-INF/spring.factories` properties file. Third-party frameworks and developers can
contribute their own ++TestExecutionListener++s to the list of default listeners in the
contribute their own ``TestExecutionListener``s to the list of default listeners in the
same manner via their own `META-INF/spring.factories` properties file.
[[testcontext-tel-config-ordering]]
===== Ordering TestExecutionListeners
When the TestContext framework discovers default ++TestExecutionListener++s via the
When the TestContext framework discovers default ``TestExecutionListener``s via the
aforementioned `SpringFactoriesLoader` mechanism, the instantiated listeners are sorted
using Spring's `AnnotationAwareOrderComparator` which honors Spring's `Ordered` interface
and `@Order` annotation for ordering. `AbstractTestExecutionListener` and all default
++TestExecutionListener++s provided by Spring implement `Ordered` with appropriate
``TestExecutionListener``s provided by Spring implement `Ordered` with appropriate
values. Third-party frameworks and developers should therefore make sure that their
_default_ ++TestExecutionListener++s are registered in the proper order by implementing
_default_ ``TestExecutionListener``s are registered in the proper order by implementing
`Ordered` or declaring `@Order`. Consult the javadocs for the `getOrder()` methods of the
core default ++TestExecutionListener++s for details on what values are assigned to each
core default ``TestExecutionListener``s for details on what values are assigned to each
core listener.
[[testcontext-tel-config-merging]]
@ -1273,7 +1273,7 @@ which listeners are registered by default. Moreover, the set of default listener
change from release to release -- for example, `SqlScriptsTestExecutionListener` was
introduced in Spring Framework 4.1, and `DirtiesContextBeforeModesTestExecutionListener`
was introduced in Spring Framework 4.2. Furthermore, third-party frameworks like Spring
Security register their own default ++TestExecutionListener++s via the aforementioned
Security register their own default ``TestExecutionListener``s via the aforementioned
<<testcontext-tel-config-automatic-discovery, automatic discovery mechanism>>.
To avoid having to be aware of and re-declare **all** _default_ listeners, the
@ -2486,7 +2486,7 @@ annotation is provided by the `DirtiesContextBeforeModesTestExecutionListener` a
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

2
src/asciidoc/web-cors.adoc
View File

@ -17,7 +17,7 @@ and less powerful hacks like IFRAME or JSONP.
As of Spring Framework 4.2, CORS is supported out of the box. CORS requests
(https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/FrameworkServlet.java#L906[including preflight ones with an `OPTIONS` method])
are automatically dispatched to the various registered ++HandlerMapping++s. They handle
are automatically dispatched to the various registered ``HandlerMapping``s. They handle
CORS preflight requests and intercept CORS simple and actual requests thanks to a
{api-spring-framework}/web/cors/CorsProcessor.html[CorsProcessor]
implementation (https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/cors/DefaultCorsProcessor.java[DefaultCorsProcessor]

20
src/asciidoc/web-mvc.adoc
View File

@ -1302,7 +1302,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.
====
@ -1333,7 +1333,7 @@ multiple requests are allowed to access a session concurrently.
See <<mvc-ann-requestheader>>.
* `@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>>.
@ -1344,7 +1344,7 @@ multiple requests are allowed to access a session concurrently.
* `@RequestAttribute` annotated parameters for access to request attributes.
* `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
@ -1427,10 +1427,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.
@ -1482,7 +1482,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(path="id", required=false)`).
Type conversion is applied automatically if the target method parameter type is not
@ -1607,7 +1607,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 ++@Controller++s, a `@RestController` may be assisted by
As with regular ``@Controller``s, a `@RestController` may be assisted by
`@ControllerAdvice` or `@RestControllerAdvice` beans. See the <<mvc-ann-controller-advice>>
section for more details.
@ -1691,7 +1691,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.
@ -2151,7 +2151,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.
@ -2626,7 +2626,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.

6
src/asciidoc/web-portlet.adoc
View File

@ -333,7 +333,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.
@ -542,7 +542,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.
@ -1006,7 +1006,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

6
src/asciidoc/web-websocket.adoc
View File

@ -1530,13 +1530,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++.
and the Java config as the ``clientLogin``/``clientPasscode`` properties with default
values ``guest``/``guest``.
[NOTE]
====

10
src/asciidoc/whats-new.adoc
View File

@ -368,9 +368,9 @@ method has been added.
* Test property sources which automatically override system and application property
sources can be configured via the new `@TestPropertySource` annotation.
** See <<testcontext-ctx-management-property-sources>> for details.
* Default ++TestExecutionListener++s can now be automatically discovered.
* Default ``TestExecutionListener``s can now be automatically discovered.
** See <<testcontext-tel-config-automatic-discovery>> for details.
* Custom ++TestExecutionListener++s can now be automatically merged with the default
* Custom ``TestExecutionListener``s can now be automatically merged with the default
listeners.
** See <<testcontext-tel-config-merging>> for details.
* The documentation for transactional testing support in the TestContext framework has
@ -597,13 +597,13 @@ public @interface MyTestConfig {
subsequent release.
* `@Sql` now supports execution of _inlined SQL statements_ via a new
`statements` attribute.
* The `ContextCache` that is used for caching ++ApplicationContext++s
* The `ContextCache` that is used for caching ``ApplicationContext``s
between tests is now a public API with a default implementation that
can be replaced for custom caching needs.
* `DefaultTestContext`, `DefaultBootstrapContext`, and
`DefaultCacheAwareContextLoaderDelegate` are now public classes in the
`support` subpackage, allowing for custom extensions.
* ++TestContextBootstrapper++s are now responsible for building the
* ``TestContextBootstrapper``s are now responsible for building the
`TestContext`.
* In the Spring MVC Test framework, `MvcResult` details can now be logged
at `DEBUG` level or written to a custom `OutputStream` or `Writer`. See
@ -616,7 +616,7 @@ public @interface MyTestConfig {
definition profiles.
* Embedded databases can now be automatically assigned a unique name,
allowing common test database configuration to be reused in different
++ApplicationContext++s within a test suite.
``ApplicationContext``s within a test suite.
** See <<jdbc-embedded-database-unique-names>> for details.
* `MockHttpServletRequest` and `MockHttpServletResponse` now provide better
support for date header formatting via the `getDateHeader` and `setDateHeader`