Fix "One sentence per line" in docs

Author: artembilan

src/reference/asciidoc/aggregator.adoc

@@ -188,7 +188,8 @@ However if, for some reason, you need to access the full `MessageGroup`, you sho
 When handling potentially large groups, you should understand how these methods are invoked, because the release strategy may be invoked multiple times before the group is released.
 The most efficient is an implementation of `ReleaseStrategy`, because the aggregator can invoke it directly.
 The second most efficient is a POJO method with a `Collection<Message<?>>` parameter type.
-The least efficient is a POJO method with a `Collection<Something>` type. The framework has to copy the payloads from the messages in the group into a new collection (and possibly attempt conversion on the payloads to `Something`) every time the release strategy is called.
+The least efficient is a POJO method with a `Collection<Something>` type.
+The framework has to copy the payloads from the messages in the group into a new collection (and possibly attempt conversion on the payloads to `Something`) every time the release strategy is called.
 Using `Collection<?>` avoids the conversion but still requires creating the new `Collection`.
 
 For these reasons, for large groups, we recommended that you implement `ReleaseStrategy`.
@@ -597,7 +598,8 @@ Since Spring Integration 2.0, you can handle the various strategies (correlation
 Suppose you have a legacy component that was designed to receive an array of objects.
 We know that the default release strategy assembles all aggregated messages in the `List`.
 Now we have two problems.
-First, we need to extract individual messages from the list. Second, we need to extract the payload of each message and assemble the array of objects.
+First, we need to extract individual messages from the list.
+Second, we need to extract the payload of each message and assemble the array of objects.
 The following example solves both problems:
 
 ====

src/reference/asciidoc/amqp.adoc

@@ -551,16 +551,14 @@ If that is not customized at all, the default is `PERSISTENT`.
 Optional.
 <10> An expression that defines correlation data.
 When provided, this configures the underlying AMQP template to receive publisher confirmations.
-Requires a dedicated `RabbitTemplate` and a `CachingConnectionFactory` with the `publisherConfirms` property set to
-`true`. When a publisher confirmation is received and correlation data is supplied, it is written to either the
-`confirm-ack-channel` or the `confirm-nack-channel`, depending on the confirmation type. The payload of the confirmation is
-the correlation data, as defined by this expression.
+Requires a dedicated `RabbitTemplate` and a `CachingConnectionFactory` with the `publisherConfirms` property set to `true`.
+When a publisher confirmation is received and correlation data is supplied, it is written to either the `confirm-ack-channel` or the `confirm-nack-channel`, depending on the confirmation type.
+The payload of the confirmation is the correlation data, as defined by this expression.
 The message has an 'amqp_publishConfirm' header set to `true` (`ack`) or `false` (`nack`).
 Examples: `headers['myCorrelationData']` and `payload`.
 Version 4.1 introduced the `amqp_publishConfirmNackCause` message header.
 It contains the `cause` of a 'nack' for a publisher confirmation.
-Starting with version 4.2, if the expression resolves to a `Message<?>` instance (such as `#this`), the message
-emitted on the `ack`/`nack` channel is based on that message, with the additional header(s) added.
+Starting with version 4.2, if the expression resolves to a `Message<?>` instance (such as `#this`), the message emitted on the `ack`/`nack` channel is based on that message, with the additional header(s) added.
 Previously, a new message was created with the correlation data as its payload, regardless of type.
 Optional.
 <11> The channel to which positive (`ack`) publisher confirms are sent.
@@ -964,28 +962,25 @@ If that is not customized, the default is `PERSISTENT`.
 Optional.
 <13> An expression that defines correlation data.
 When provided, this configures the underlying AMQP template to receive publisher confirmations.
-Requires a dedicated `RabbitTemplate` and a `CachingConnectionFactory` with its `publisherConfirms` property set to
-`true`. When a publisher confirmation is received and correlation data is supplied, the confirmation is written to either the
-`confirm-ack-channel` or the `confirm-nack-channel`, depending on the confirmation type. The payload of the confirmation is
-the correlation data as defined by this expression, and the message has its 'amqp_publishConfirm' header set to `true`
-(`ack`) or `false` (`nack`).
+Requires a dedicated `RabbitTemplate` and a `CachingConnectionFactory` with its `publisherConfirms` property set to `true`.
+When a publisher confirmation is received and correlation data is supplied, the confirmation is written to either the `confirm-ack-channel` or the `confirm-nack-channel`, depending on the confirmation type.
+The payload of the confirmation is the correlation data as defined by this expression, and the message has its 'amqp_publishConfirm' header set to `true` (`ack`) or `false` (`nack`).
 For `nack` instances, an additional header (`amqp_publishConfirmNackCause`) is provided.
 Examples: `headers['myCorrelationData']`, `payload`.
-If the expression resolves to a `Message<?>` instance (such as "`#this`"), the message
-emitted on the `ack`/`nack` channel is based on that message, with the additional headers added.
+If the expression resolves to a `Message<?>` instance (such as "`#this`"), the message emitted on the `ack`/`nack` channel is based on that message, with the additional headers added.
 Optional.
 <14> The channel to which positive (`ack`) publisher confirmations are sent.
 The payload is the correlation data defined by the `confirm-correlation-expression`.
 Requires the underlying `AsyncRabbitTemplate` to have its `enableConfirms` property set to `true`.
 Optional (the default is `nullChannel`).
-<15> Since version 4.2. The channel to which negative (`nack`) publisher confirmations are sent.
+<15> Since version 4.2.
+The channel to which negative (`nack`) publisher confirmations are sent.
 The payload is the correlation data defined by the `confirm-correlation-expression`.
 Requires the underlying `AsyncRabbitTemplate` to have its `enableConfirms` property set to `true`.
 Optional (the default is `nullChannel`).
 <16> The channel to which returned messages are sent.
 When provided, the underlying AMQP template is configured to return undeliverable messages to the gateway.
-The message is constructed from the data received from AMQP, with the following additional headers:
-`amqp_returnReplyCode`, `amqp_returnReplyText`, `amqp_returnExchange`, and `amqp_returnRoutingKey`.
+The message is constructed from the data received from AMQP, with the following additional headers: `amqp_returnReplyCode`, `amqp_returnReplyText`, `amqp_returnExchange`, and `amqp_returnRoutingKey`.
 Requires the underlying `AsyncRabbitTemplate` to have its `mandatory` property set to `true`.
 Optional.
 <17> When set to `false`, the endpoint tries to connect to the broker during application context initialization.
@@ -1391,13 +1386,11 @@ It also does not map the `deliveryMode` to the `amqp_deliveryMode` header, to av
 Instead, this header is mapped to `amqp_receivedDeliveryMode`, which is not mapped on output.
 
 Starting with version 4.3, patterns in the header mappings can be negated by preceding the pattern with `!`.
-Negated patterns get priority, so a list such as
-`STANDARD_REQUEST_HEADERS,thing1,ba*,!thing2,!thing3,qux,!thing1` does not map `thing1`
-(nor `thing2` nor `thing3`).
+Negated patterns get priority, so a list such as `STANDARD_REQUEST_HEADERS,thing1,ba*,!thing2,!thing3,qux,!thing1` does not map `thing1` (nor `thing2` nor `thing3`).
 The standard headers plus `bad` and `qux` are mapped.
 
-IMPORTANT: If you have a user-defined header that begins with `!` that you do wish to map, you need to escape it with
-`\`, as follows: `STANDARD_REQUEST_HEADERS,\!myBangHeader`. The header named `!myBangHeader` is now mapped.
+IMPORTANT: If you have a user-defined header that begins with `!` that you do wish to map, you need to escape it with `\`, as follows: `STANDARD_REQUEST_HEADERS,\!myBangHeader`.
+The header named `!myBangHeader` is now mapped.
 
 NOTE: Starting with _version 5.1_, the `DefaultAmqpHeaderMapper` will fall back to mapping `MessageHeaders.ID` and `MessageHeaders.TIMESTAMP` to `MessageProperties.messageId` and `MessageProperties.timestamp` respectively, if the corresponding `amqp_messageId` or `amqp_timestamp` headers are not present on outbound messages.
 Inbound properties will be mapped to the `amqp_*` headers as before.
@@ -1407,7 +1400,7 @@ It is useful to populate the `messageId` property when message consumers are usi
 ==== contentType Header
 
 Unlike other headers, the `AmqpHeaders.CONTENT_TYPE` is not prefixed with `amqp_`; this allows transparent passing of the contentType header across different technologies.
-E.g. an inbound HTTP message sent to a RabbitMQ queue.
+For example an inbound HTTP message sent to a RabbitMQ queue.
 
 The `contentType` header is mapped to Spring AMQP's `MessageProperties.contentType` property and that is subsequently mapped to RabbitMQ's `content_type` property.
 

src/reference/asciidoc/changes-1.0-2.0.adoc

@@ -118,7 +118,8 @@ See <<feed>> for more details.
 
 [[new-other]]
 ==== Other Additions
-Spring Integration adds a number of other features. This section describes them.
+Spring Integration adds a number of other features.
+This section describes them.
 
 [[new-groovy]]
 ===== Groovy Support
@@ -165,7 +166,8 @@ We have also switched our build system to http://gradle.org/[Gradle].
 ==== New Spring Integration Samples
 
 With Spring Integration 2.0, we have decoupled the samples from our main release distribution.
-Please read the following blog to get more information: http://blog.springsource.com/2010/09/29/new-spring-integration-samples/[New Spring Integration Samples]. We have also created many new samples, including samples for every new adapter.
+Please read the following blog to get more information: http://blog.springsource.com/2010/09/29/new-spring-integration-samples/[New Spring Integration Samples].
+We have also created many new samples, including samples for every new adapter.
 
 [[new-sts]]
 ==== Spring Tool Suite Visual Editor for Spring Integration

src/reference/asciidoc/changes-2.1-2.2.adoc

@@ -50,7 +50,7 @@ Spring Integration now uses Spring 3.1.
 The ability to add an `<advice-chain/>` to a poller has been available for some time.
 However, the behavior added by this affects the entire integration flow.
 It did not address the ability to add (for example) retry to an individual endpoint.
-The 2.2. release introduced the `<request-handler-advice-chain/>` to many endpoints.
+The 2.2 release introduced the `<request-handler-advice-chain/>` to many endpoints.
 
 In addition, we added three standard advice classes for this purpose:
 

src/reference/asciidoc/changes-4.1-4.2.adoc

@@ -213,7 +213,8 @@ See <<jms-outbound-gateway>> for more information.
 
 ===== Conversion Errors in Message-Driven Endpoints
 
-The `error-channel` is now used for the conversion errors. In previous versions, they caused transaction rollback and message redelivery.
+The `error-channel` is now used for the conversion errors.
+In previous versions, they caused transaction rollback and message redelivery.
 
 See <<jms-message-driven-channel-adapter>> and <<jms-inbound-gateway>> for more information.
 

src/reference/asciidoc/channel-adapter.adoc

@@ -147,7 +147,8 @@ If you want the script to be checked on each poll, you would need to coordinate
 ====
 
 See also the `cacheSeconds` property on the `ReloadableResourceBundleExpressionSource` when using the `<expression/>` sub-element.
-For more information regarding expressions, see <<spel>>. For scripts, see <<groovy>> and <<scripting>>.
+For more information regarding expressions, see <<spel>>.
+For scripts, see <<groovy>> and <<scripting>>.
 
 IMPORTANT: The `<int:inbound-channel-adapter/>` is endpoint starts a message flow by periodically triggering to poll some underlying `MessageSource`.
 Since, at the time of polling, there is no message object, expressions and scripts do not have access to a root `Message`, so there are no payload or headers properties that are available in most other messaging SpEL expressions.

src/reference/asciidoc/channel.adoc

@@ -857,7 +857,8 @@ Instead, Spring Integration focuses on a single unified approach to configuring
 What makes certain parts of the message flow synchronous or asynchronous is the type of Message Channel that has been configured within that flow.
 That is one of the primary benefits of the message channel abstraction.
 From the inception of the framework, we have always emphasized the need and the value of the message channel as a first-class citizen of the framework.
-It is not just an internal, implicit realization of the EIP pattern. It is fully exposed as a configurable component to the end user.
+It is not just an internal, implicit realization of the EIP pattern.
+It is fully exposed as a configurable component to the end user.
 So, the wire tap component is only responsible for performing the following tasks:
 
 * Intercept a message flow by tapping into a channel (for example, `channelA`)

src/reference/asciidoc/codec.adoc

@@ -54,8 +54,8 @@ The second and third are used with the `MessageCodec`, which is initialized with
 
 By default, Kryo delegates unknown Java types to its `FieldSerializer`.
 Kryo also registers default serializers for each primitive type, along with `String`, `Collection`, and `Map`.
-`FieldSerializer` uses reflection to navigate the object graph. A more efficient approach is to implement a custom
-serializer that is aware of the object's structure and can directly serialize selected primitive fields.
+`FieldSerializer` uses reflection to navigate the object graph.
+A more efficient approach is to implement a custom serializer that is aware of the object's structure and can directly serialize selected primitive fields.
 The following example shows such a serializer:
 
 ====

src/reference/asciidoc/dsl.adoc

@@ -301,7 +301,7 @@ public IntegrationFlow clientTcpFlow() {
 }
 ----
 
-i.e. they are not merged, only the `testAdvice()` bean is used in this case.
+That is they are not merged, only the `testAdvice()` bean is used in this case.
 
 [[java-dsl-transformers]]
 === Transformers

src/reference/asciidoc/endpoint.adoc

@@ -149,7 +149,8 @@ The `receiveTimeout` property specifies the amount of time the poller should wai
 For example, consider two options that seem similar on the surface but are actually quite different: The first has an interval trigger of 5 seconds and a receive timeout of 50 milliseconds, while the second has an interval trigger of 50 milliseconds and a receive timeout of 5 seconds.
 The first one may receive a message up to 4950 milliseconds later than it arrived on the channel (if that message arrived immediately after one of its poll calls returned).
 On the other hand, the second configuration never misses a message by more than 50 milliseconds.
-The difference is that the second option requires a thread to wait. However, as a result, it can respond much more quickly to arriving messages.
+The difference is that the second option requires a thread to wait.
+However, as a result, it can respond much more quickly to arriving messages.
 This technique, known as "`long polling`", can be used to emulate event-driven behavior on a polled source.
 
 A polling consumer can also delegate to a Spring `TaskExecutor`, as the following example shows:
@@ -770,7 +771,8 @@ public Map<String, Boolean> getEndpointsRunningStatus(String role) <4>
 
 <3> Returns `true` if none of the endpoints in the role are running.
 
-<4> Returns a map of `component name : running status`. The component name is usually the bean name.
+<4> Returns a map of `component name : running status`.
+The component name is usually the bean name.
 
 [[leadership-event-handling]]
 === Leadership Event Handling