[camel] branch master updated: use the enumeration functionality of AsciiDoc

[ac...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

acosentino pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/camel.git


The following commit(s) were added to refs/heads/master by this push:
     new 419337f  use the enumeration functionality of AsciiDoc
     new 6c85857  Merge pull request #3448 from ahus1/use-enumeration-in-async
419337f is described below

commit 419337ffe159721ea6b4d7acdbab6cea2f1a1788
Author: Alexander Schwartz <al...@gmx.net>
AuthorDate: Thu Dec 26 21:23:07 2019 +0100

    use the enumeration functionality of AsciiDoc
---
 docs/user-manual/modules/ROOT/pages/async.adoc | 28 +++++++++++++-------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/docs/user-manual/modules/ROOT/pages/async.adoc b/docs/user-manual/modules/ROOT/pages/async.adoc
index c7ca2fd..9fad672 100644
--- a/docs/user-manual/modules/ROOT/pages/async.adoc
+++ b/docs/user-manual/modules/ROOT/pages/async.adoc
@@ -7,10 +7,10 @@ The asynchronous API in Camel has been rewritten for Camel 2.0, and the
 information on this page applies for Camel 2.0 and later.
 
 The Async API in Camel is primarily divided in two
-areas +
- 1. Initiating an Async messaging from the client +
- 2. Turning a route into Async using the *threads*
-DSL
+areas:
+
+ 1. Initiating an Async messaging from the client
+ 2. Turning a route into Async using the *threads* DSL
 
 Before we look at these two areas we start with a bit of background
 information and look at the concept from a higher level using
@@ -73,10 +73,10 @@ image::camel_sync_request_reply.png[image]
 
  1. The client sends a sync Request Reply
 message over xref:components::http-component.adoc[HTTP] to Camel. The client application will
-wait for the response that Camel routes and processes. +
+wait for the response that Camel routes and processes.
  2. The message invokes an external xref:components::mina-component.adoc[TCP] service using
 synchronous Request Reply. The client
-application still waits for the response. +
+application still waits for the response.
  3. The response is sent back to the client.
 
 [[Async-AsynchronousRequestReply]]
@@ -94,10 +94,10 @@ image::camel_async_request_reply.png[image]
  1. The client sends an Async
 Request Reply message over HTTP
 to Camel. The control is immediately returned to the client application,
-that can continue and do other work while Camel routes the message. +
+that can continue and do other work while Camel routes the message.
  2. Camel invokes an external xref:components::mina-component.adoc[TCP] service using
 synchronous Request Reply. The client
-application can do other work simultaneously. +
+application can do other work simultaneously.
  3. The client wants to get the reply so it uses the Future handle it
 got as _response_ from step 1. With this handle it retrieves the reply,
 wait if necessary if the reply is not ready.
@@ -114,14 +114,14 @@ image::camel_sync_request_only.png[image]
 
  1. The client sends a Request only and we can
 still use xref:components::http-component.adoc[HTTP] despite http being
-Request Reply by nature. +
+Request Reply by nature.
  2. Camel invokes an external xref:components::mina-component.adoc[TCP] service using
 synchronous Request Reply. The client
-application is still waiting. +
+application is still waiting.
  3. The message is processed completely and the control is returned to
 the client.
 
-So why do you want to use synchronous xref:event-message.adoc[Request Only]? 
+So why do you want to use synchronous xref:event-message.adoc[Request Only]?
 Well if you want to know whether the message was processed
 successfully or not before continuing. With synchronous it allows you to
 wait while the message is being processed. In case the processing was
@@ -144,10 +144,10 @@ image::camel_async_request_only.png[image]
 still use xref:components::http-component.adoc[HTTP] despite http being
 Request Reply by nature. The control is
 immediately returned to the client application, that can continue and do
-other work while Camel routes the message. +
+other work while Camel routes the message.
  2. Camel invokes an external xref:components::mina-component.adoc[TCP] service using
 synchronous Request Reply. The client
-application can do other work simultaneously. +
+application can do other work simultaneously.
  3. The message completes but no result is returned to the client.
 
 *Notice:* As Camel always returns a `Future` handle for
@@ -483,7 +483,7 @@ Request Only messaging.
 The `threads` DSL leverages the JDK concurrency framework for multi-threading. It can be used to turn a synchronous route into
 Async. What happens is that from the point forwards
 from `threads` the messages are routed asynchronous in a new thread.
-Camel leverages the xref:asynchronous-routing-engine.adoc[asynchronous routing engine], 
+Camel leverages the xref:asynchronous-routing-engine.adoc[asynchronous routing engine],
 which was re-introduced in Camel 2.4, to continue
 routing the Exchange asynchronously.