You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by dj...@apache.org on 2020/03/13 01:14:16 UTC

[camel] 08/18: fix xrefs in eip pages

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

djencks pushed a commit to branch issue-14698-rearrange-adocs
in repository https://gitbox.apache.org/repos/asf/camel.git

commit ce69d8dac53193b3c1c8e40c22dd5981c70ed919
Author: David Jencks <dj...@apache.org>
AuthorDate: Thu Mar 12 12:32:18 2020 -0700

    fix xrefs in eip pages
---
 .../docs/modules/eips/pages/aggregate-eip.adoc     | 20 ++++-----
 .../src/main/docs/modules/eips/pages/bean-eip.adoc | 12 ++---
 .../main/docs/modules/eips/pages/choice-eip.adoc   |  6 +--
 .../docs/modules/eips/pages/claimCheck-eip.adoc    |  2 +-
 .../eips/pages/content-based-router-eip.adoc       | 18 ++++----
 .../modules/eips/pages/content-filter-eip.adoc     | 26 +++++------
 .../docs/modules/eips/pages/dynamicRouter-eip.adoc |  2 +-
 .../eips/pages/eventDrivenConsumer-eip.adoc        | 24 +++++-----
 .../main/docs/modules/eips/pages/filter-eip.adoc   | 12 ++---
 .../modules/eips/pages/idempotentConsumer-eip.adoc |  4 +-
 .../src/main/docs/modules/eips/pages/log-eip.adoc  |  8 ++--
 .../main/docs/modules/eips/pages/marshal-eip.adoc  |  4 +-
 .../docs/modules/eips/pages/multicast-eip.adoc     |  2 +-
 .../docs/modules/eips/pages/otherwise-eip.adoc     |  4 +-
 .../main/docs/modules/eips/pages/pipeline-eip.adoc |  6 +--
 .../main/docs/modules/eips/pages/process-eip.adoc  | 10 ++---
 .../main/docs/modules/eips/pages/rollback-eip.adoc | 12 ++---
 .../main/docs/modules/eips/pages/script-eip.adoc   |  2 +-
 .../main/docs/modules/eips/pages/split-eip.adoc    |  2 +-
 .../src/main/docs/modules/eips/pages/step-eip.adoc |  2 +-
 .../src/main/docs/modules/eips/pages/to-eip.adoc   | 12 ++---
 .../src/main/docs/modules/eips/pages/toD-eip.adoc  | 12 ++---
 .../docs/modules/eips/pages/transform-eip.adoc     |  2 +-
 .../docs/modules/eips/pages/unmarshal-eip.adoc     |  4 +-
 .../src/main/docs/modules/eips/pages/when-eip.adoc |  4 +-
 .../main/docs/modules/eips/pages/wireTap-eip.adoc  | 52 +++++++++++-----------
 26 files changed, 132 insertions(+), 132 deletions(-)

diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/aggregate-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/aggregate-eip.adoc
index 077725c..e0ff477 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/aggregate-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/aggregate-eip.adoc
@@ -3,12 +3,12 @@
 
 The
 http://www.enterpriseintegrationpatterns.com/Aggregator.html[Aggregator]
-from the xref:enterprise-integration-patterns.adoc[EIP patterns] allows
+from the xref:ROOT:enterprise-integration-patterns.adoc[EIP patterns] allows
 you to combine a number of messages together into a single message.
 
 image::eip/Aggregator.gif[image]
 
-A correlation xref:expression.adoc[Expression] is used to determine the
+A correlation xref:ROOT:expression.adoc[Expression] is used to determine the
 messages which should be aggregated together. If you want to aggregate
 all messages into a single message, just use a constant expression. An
 AggregationStrategy is used to combine all the message exchanges for a
@@ -111,7 +111,7 @@ class ArrayListAggregationStrategy implements AggregationStrategy {
 
 == About completion
 
-When aggregation xref:exchange.adoc[Exchange]s at some point you need to
+When aggregation xref:ROOT:exchange.adoc[Exchange]s at some point you need to
 indicate that the aggregated exchanges is complete, so they can be send
 out of the aggregator. Camel allows you to indicate completion in
 various ways as follows:
@@ -123,7 +123,7 @@ key within the period.
 exchanges are completed.
 * completionSize - Is a number indicating that after X aggregated
 exchanges it's complete.
-* completionPredicate - Runs a xref:predicate.adoc[Predicate] when a new
+* completionPredicate - Runs a xref:ROOT:predicate.adoc[Predicate] when a new
 exchange is aggregated to determine if we are complete or not.
 The configured aggregationStrategy can implement the
 Predicate interface and will be used as the completionPredicate if no
@@ -132,7 +132,7 @@ implement `PreCompletionAwareAggregationStrategy` and will be used as
 the completionPredicate in pre-complete check mode. See further below
 for more details.
 * completionFromBatchConsumer - Special option for
-xref:batch-consumer.adoc[Batch Consumer] which allows you to complete
+xref:ROOT:batch-consumer.adoc[Batch Consumer] which allows you to complete
 when all the messages from the batch has been aggregated.
 * forceCompletionOnStop - Indicates to complete all current
 aggregated exchanges when the context is stopped
@@ -152,9 +152,9 @@ aggregator. If not provided Camel will thrown an Exception on startup.
 == Pre-completion mode
 
 There can be use-cases where you want the incoming
-xref:exchange.adoc[Exchange] to determine if the correlation group
+xref:ROOT:exchange.adoc[Exchange] to determine if the correlation group
 should pre-complete, and then the incoming
-xref:exchange.adoc[Exchange] is starting a new group from scratch. To
+xref:ROOT:exchange.adoc[Exchange] is starting a new group from scratch. To
 determine this the `AggregationStrategy` can
 implement `PreCompletionAwareAggregationStrategy` which has
 a `preComplete` method:
@@ -558,7 +558,7 @@ without using POJOs then you may have `null` as `oldExchange` or
 Aggregate EIP will invoke the
 `AggregationStrategy` with `oldExchange` as null, for the first
 Exchange incoming to the aggregator. And then for
-subsequent xref:exchange.adoc[Exchange]s then `oldExchange` and
+subsequent xref:ROOT:exchange.adoc[Exchange]s then `oldExchange` and
 `newExchange` parameters are both not null.
 
 Example with Content Enricher EIP and no data
@@ -614,14 +614,14 @@ public class MyBodyAppender {
 }
 ----
 
-In the example above we use the xref:content-enricher.adoc[Content Enricher]
+In the example above we use the xref:ROOT:content-enricher.adoc[Content Enricher]
 EIP using `pollEnrich`. The `newExchange` will be null in the
 situation we could not get any data from the "seda:foo" endpoint, and
 therefore the timeout was hit after 1 second. So if we need to do some
 special merge logic we would need to set `setAllowNullNewExchange=true`,
 so the `append` method will be invoked. If we do not do that then when
 the timeout was hit, then the append method would normally not be
-invoked, meaning the xref:content-enricher.adoc[Content Enricher] did
+invoked, meaning the xref:ROOT:content-enricher.adoc[Content Enricher] did
 not merge/change the message.
 
 In XML DSL you would configure the `strategyMethodAllowNull` option and
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/bean-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/bean-eip.adoc
index 6de8313..eee6fc0 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/bean-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/bean-eip.adoc
@@ -11,7 +11,7 @@ bean:beanID[?options]
 ----
 
 Where *beanID* can be any string which is used to look up the bean in
-the xref:registry.adoc[Registry]
+the xref:ROOT:registry.adoc[Registry]
 
 == EIP options
 
@@ -46,10 +46,10 @@ Camel also supports invoking xref:components::bean-component.adoc[Bean] as an En
 route below:
 
 What happens is that when the exchange is routed to the `myBean` Camel
-will use the xref:bean-binding.adoc[Bean Binding] to invoke the bean. +
+will use the xref:ROOT:bean-binding.adoc[Bean Binding] to invoke the bean. +
  The source for the bean is just a plain POJO:
 
-Camel will use xref:bean-binding.adoc[Bean Binding] to invoke the
+Camel will use xref:ROOT:bean-binding.adoc[Bean Binding] to invoke the
 `sayHello` method, by converting the Exchange's In body to the `String`
 type and storing the output of the method on the Exchange Out body.
 
@@ -89,8 +89,8 @@ from("direct:start").bean(ExampleBean.class);
 
 How bean methods to be invoked are chosen (if they are not specified
 explicitly through the *method* parameter) and how parameter values are
-constructed from the xref:message.adoc[Message] are all defined by the
-xref:bean-binding.adoc[Bean Binding] mechanism which is used throughout
-all of the various xref:bean-integration.adoc[Bean Integration]
+constructed from the xref:ROOT:message.adoc[Message] are all defined by the
+xref:ROOT:bean-binding.adoc[Bean Binding] mechanism which is used throughout
+all of the various xref:ROOT:bean-integration.adoc[Bean Integration]
 mechanisms in Camel.
 
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/choice-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/choice-eip.adoc
index d1fdd27..c24766d 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/choice-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/choice-eip.adoc
@@ -3,7 +3,7 @@
 
 The
 http://www.enterpriseintegrationpatterns.com/ContentBasedRouter.html[Content
-Based Router] from the xref:enterprise-integration-patterns.adoc[EIP
+Based Router] from the xref:ROOT:enterprise-integration-patterns.adoc[EIP
 patterns] allows you to route messages to the correct destination based
 on the contents of the message exchanges.
 
@@ -26,7 +26,7 @@ The Choice EIP supports 2 options which are listed below:
 
 The following example shows how to route a request from an input
 *seda:a* endpoint to either *seda:b*, *seda:c* or *seda:d* depending on
-the evaluation of various xref:predicate.adoc[Predicate] expressions
+the evaluation of various xref:ROOT:predicate.adoc[Predicate] expressions
 
 [source,java]
 ----
@@ -46,7 +46,7 @@ RouteBuilder builder = new RouteBuilder() {
 
 [TIP]
 ====
-See xref:faq/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc[Why
+See xref:ROOT:faq/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc[Why
 can I not use when or otherwise in a Java Camel route] if you have
 problems with the Java DSL, accepting using `when` or `otherwise`.
 ====
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/claimCheck-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/claimCheck-eip.adoc
index 4f0d729..d9077c3 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/claimCheck-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/claimCheck-eip.adoc
@@ -1,7 +1,7 @@
 [[claimCheck-eip]]
 = Claim Check EIP
 
-The http://www.enterpriseintegrationpatterns.com/patterns/messaging/StoreInLibrary.html[Claim Check] from the xref:enterprise-integration-patterns.adoc[EIP patterns]
+The http://www.enterpriseintegrationpatterns.com/patterns/messaging/StoreInLibrary.html[Claim Check] from the xref:ROOT:enterprise-integration-patterns.adoc[EIP patterns]
 allows you to replace message content with a claim check (a unique key), which can be used to retrieve the message content at a later time.
 
 image::eip/StoreInLibrary.gif[image]
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/content-based-router-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/content-based-router-eip.adoc
index 48ebb36..f4495de 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/content-based-router-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/content-based-router-eip.adoc
@@ -3,7 +3,7 @@
 
 The
 http://www.enterpriseintegrationpatterns.com/ContentBasedRouter.html[Content
-Based Router] from the xref:enterprise-integration-patterns.adoc[EIP
+Based Router] from the xref:ROOT:enterprise-integration-patterns.adoc[EIP
 patterns] allows you to route messages to the correct destination based
 on the contents of the message exchanges.
 
@@ -11,9 +11,9 @@ image::eip/ContentBasedRouter.gif[image]
 
 The following example shows how to route a request from an input
 *seda:a* endpoint to either *seda:b*, *seda:c* or *seda:d* depending on
-the evaluation of various xref:predicate.adoc[Predicate] expressions
+the evaluation of various xref:ROOT:predicate.adoc[Predicate] expressions
 
-== Using the xref:fluent-builders.adoc[Fluent Builders]
+== Using the xref:ROOT:fluent-builders.adoc[Fluent Builders]
 
 [source,java]
 ----
@@ -36,12 +36,12 @@ RouteBuilder builder = new RouteBuilder() {
 [TIP]
 ====
 See
-xref:faq/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc[Why
+xref:ROOT:faq/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc[Why
 can I not use when or otherwise in a Java Camel route] if you have
 problems with the Java DSL, accepting using `when` or `otherwise`.
 ====
 
-== Using the xref:spring-xml-extensions.adoc[Spring XML Extensions]
+== Using the xref:ROOT:spring-xml-extensions.adoc[Spring XML Extensions]
 
 [source,java]
 ----
@@ -72,8 +72,8 @@ https://github.com/apache/camel/blob/master/core/camel-core/src/test/java/org/ap
 == Using This Pattern
 
 If you would like to use this EIP Pattern then please read the
-xref:getting-started.adoc[Getting Started]. You may also find the
-xref:architecture.adoc[Architecture] useful particularly the description
-of xref:endpoint.adoc[Endpoint] and xref:uris.adoc[URIs]. Then you could
-try out some of the xref:examples.adoc[Examples] first before trying
+xref:ROOT:getting-started.adoc[Getting Started]. You may also find the
+xref:ROOT:architecture.adoc[Architecture] useful particularly the description
+of xref:ROOT:endpoint.adoc[Endpoint] and xref:ROOT:uris.adoc[URIs]. Then you could
+try out some of the xref:ROOT:examples.adoc[Examples] first before trying
 this pattern out.
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/content-filter-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/content-filter-eip.adoc
index 5d106e7..6adf9bc 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/content-filter-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/content-filter-eip.adoc
@@ -4,26 +4,26 @@
 Camel supports the
 http://www.enterpriseintegrationpatterns.com/ContentFilter.html[Content
 Filter] from the
-xref:enterprise-integration-patterns.adoc[EIP patterns]
+xref:ROOT:enterprise-integration-patterns.adoc[EIP patterns]
 using one of the following mechanisms in the routing logic to transform
 content from the inbound message.
 
-* xref:message-translator.adoc[Message Translator]
-* invoking a xref:bean-integration.adoc[Java bean]
-* xref:processor.adoc[Processor] object
+* xref:ROOT:message-translator.adoc[Message Translator]
+* invoking a xref:ROOT:bean-integration.adoc[Java bean]
+* xref:ROOT:processor.adoc[Processor] object
 
 image::eip/ContentFilter.gif[image]
 
 A common way to filter messages is to use an
-xref:expression.adoc[Expression] in the xref:dsl.adoc[DSL] like
+xref:ROOT:expression.adoc[Expression] in the xref:ROOT:dsl.adoc[DSL] like
 xref:components::xquery-language.adoc[XQuery] or one of the supported
-xref:scripting-languages.adoc[Scripting Languages].
+xref:ROOT:scripting-languages.adoc[Scripting Languages].
 
-== Using the xref:fluent-builders.adoc[Fluent Builders]
+== Using the xref:ROOT:fluent-builders.adoc[Fluent Builders]
 
-Here is a simple example using the xref:dsl.adoc[DSL] directly
+Here is a simple example using the xref:ROOT:dsl.adoc[DSL] directly
 
-In this example we add our own xref:processor.adoc[Processor]
+In this example we add our own xref:ROOT:processor.adoc[Processor]
 
 For further examples of this pattern in use you could look at one of the
 JUnit tests
@@ -58,8 +58,8 @@ interested in:
 == Using This Pattern
 
 If you would like to use this EIP Pattern then please read the
-xref:getting-started.adoc[Getting Started], you may also find the
-xref:architecture.adoc[Architecture] useful particularly the description
-of xref:endpoint.adoc[Endpoint] and xref:uris.adoc[URIs]. Then you could
-try out some of the xref:examples.adoc[Examples] first before trying
+xref:ROOT:getting-started.adoc[Getting Started], you may also find the
+xref:ROOT:architecture.adoc[Architecture] useful particularly the description
+of xref:ROOT:endpoint.adoc[Endpoint] and xref:ROOT:uris.adoc[URIs]. Then you could
+try out some of the xref:ROOT:examples.adoc[Examples] first before trying
 this pattern out.
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/dynamicRouter-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/dynamicRouter-eip.adoc
index 3453e72e..e4cca6a 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/dynamicRouter-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/dynamicRouter-eip.adoc
@@ -1,7 +1,7 @@
 [[dynamicRouter-eip]]
 = Dynamic Router EIP
 
-The http://www.enterpriseintegrationpatterns.com/DynamicRouter.html[Dynamic Router] from the xref:enterprise-integration-patterns.adoc[EIP patterns] allows you to route messages while avoiding the dependency of the router on all possible destinations while maintaining its efficiency.
+The http://www.enterpriseintegrationpatterns.com/DynamicRouter.html[Dynamic Router] from the xref:ROOT:enterprise-integration-patterns.adoc[EIP patterns] allows you to route messages while avoiding the dependency of the router on all possible destinations while maintaining its efficiency.
 
 image::eip/DynamicRouter.gif[image]
 
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/eventDrivenConsumer-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/eventDrivenConsumer-eip.adoc
index d6da362..371ff12 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/eventDrivenConsumer-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/eventDrivenConsumer-eip.adoc
@@ -4,7 +4,7 @@
 Camel supports the
 http://www.enterpriseintegrationpatterns.com/EventDrivenConsumer.html[Event Driven Consumer]
 from the
-xref:enterprise-integration-patterns.adoc[EIP patterns].
+xref:ROOT:enterprise-integration-patterns.adoc[EIP patterns].
 The default consumer model is event based (i.e. asynchronous)
 as this means that the Camel container can then manage pooling,
 threading and concurrency for you in a declarative manner.
@@ -13,18 +13,18 @@ image::eip/EventDrivenConsumerSolution.gif[image]
 
 The Event Driven Consumer is implemented by consumers implementing the
 http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/Processor.html[Processor]
-interface which is invoked by the xref:message-endpoint.adoc[Message Endpoint]
-when a xref:message.adoc[Message] is available for processing.
+interface which is invoked by the xref:ROOT:message-endpoint.adoc[Message Endpoint]
+when a xref:ROOT:message.adoc[Message] is available for processing.
 
 [[eventDrivenConsumer-Example]]
 == Example
 
 The following demonstrates a
 http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/Processor.html[Processor]
-defined in the Camel xref:registry.adoc[Registry] which is
+defined in the Camel xref:ROOT:registry.adoc[Registry] which is
 invoked when an event occurs from a xref:components::jms-component.adoc[JMS] queue.
 
-*Using the xref:fluent-builders.adoc[Fluent Builders]*
+*Using the xref:ROOT:fluent-builders.adoc[Fluent Builders]*
 
 [source,java]
 ----
@@ -32,7 +32,7 @@ from("jms:queue:foo")
     .processRef("processor");
 ----
 
-**Using the xref:spring-xml-extensions.adoc[Spring XML Extensions]**
+**Using the xref:ROOT:spring-xml-extensions.adoc[Spring XML Extensions]**
 
 [source,xml]
 ----
@@ -44,15 +44,15 @@ from("jms:queue:foo")
 
 For more details see:
 
-* xref:message.adoc[Message]
-* xref:message-endpoint.adoc[Message Endpoint]
+* xref:ROOT:message.adoc[Message]
+* xref:ROOT:message-endpoint.adoc[Message Endpoint]
 
 [[eventDrivenConsumer-UsingThisPattern]]
 == Using This Pattern
 
 If you would like to use this EIP Pattern then please read the
-xref:getting-started.adoc[Getting Started], you may also find the
-xref:architecture.adoc[Architecture] useful particularly the description
-of xref:endpoint.adoc[Endpoint] and xref:uris.adoc[URIs]. Then you could
-try out some of the xref:examples.adoc[Examples] first before trying
+xref:ROOT:getting-started.adoc[Getting Started], you may also find the
+xref:ROOT:architecture.adoc[Architecture] useful particularly the description
+of xref:ROOT:endpoint.adoc[Endpoint] and xref:ROOT:uris.adoc[URIs]. Then you could
+try out some of the xref:ROOT:examples.adoc[Examples] first before trying
 this pattern out.
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/filter-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/filter-eip.adoc
index f7f9982..053abbc 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/filter-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/filter-eip.adoc
@@ -2,14 +2,14 @@
 = Filter EIP
 
 The http://www.enterpriseintegrationpatterns.com/Filter.html[Message
-Filter] from the xref:enterprise-integration-patterns.adoc[EIP patterns]
+Filter] from the xref:ROOT:enterprise-integration-patterns.adoc[EIP patterns]
 allows you to filter messages
 
 image::eip/MessageFilter.gif[image]
 
 The following example shows how to create a Message Filter route
 consuming messages from an endpoint called *queue:a*, which if the
-xref:predicate.adoc[Predicate] is true will be dispatched to *queue:b*
+xref:ROOT:predicate.adoc[Predicate] is true will be dispatched to *queue:b*
 
 == EIP options
 
@@ -86,15 +86,15 @@ the when predicate by using the `.stop()`.
 == Knowing if Exchange was filtered or not
 
 The xref:filter-eip.adoc[Message Filter] EIP will add a property on
-the xref:exchange.adoc[Exchange] that states if it was filtered or not.
+the xref:ROOT:exchange.adoc[Exchange] that states if it was filtered or not.
 
 The property has the key `Exchange.FILTER_MATCHED`, which has the String
 value of `CamelFilterMatched`. Its value is a boolean indicating `true`
-or `false`. If the value is `true` then the xref:exchange.adoc[Exchange]
+or `false`. If the value is `true` then the xref:ROOT:exchange.adoc[Exchange]
 was routed in the filter block. This property will be visible within the
 xref:filter-eip.adoc[Message Filter] block who's
-xref:predicate.adoc[Predicate] matches (value set to `true`), and to the
+xref:ROOT:predicate.adoc[Predicate] matches (value set to `true`), and to the
 steps immediately following the xref:filter-eip.adoc[Message Filter]
 with the value set based on the results of the last
-xref:filter-eip.adoc[Message Filter] xref:predicate.adoc[Predicate]
+xref:filter-eip.adoc[Message Filter] xref:ROOT:predicate.adoc[Predicate]
 evaluated.
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/idempotentConsumer-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/idempotentConsumer-eip.adoc
index 6835947..2492dd1 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/idempotentConsumer-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/idempotentConsumer-eip.adoc
@@ -3,7 +3,7 @@
 
 The
 http://www.enterpriseintegrationpatterns.com/IdempotentReceiver.html[Idempotent
-Consumer] from the xref:enterprise-integration-patterns.adoc[EIP
+Consumer] from the xref:ROOT:enterprise-integration-patterns.adoc[EIP
 patterns] is used to filter out duplicate messages.
 
 The Idempotent Consumer essentially acts like a
@@ -23,7 +23,7 @@ Camel provides the following Idempotent Consumer implementations:
 * xref:components::jpa-component.adoc[JpaMessageIdRepository]
 * xref:components::infinispan-component.adoc[InfinispanIdempotentRepository]
 * xref:components::jcache-component.adoc[JCacheIdempotentRepository]
-* xref:spring.adoc[SpringCacheIdempotentRepository]
+* xref:ROOT:spring.adoc[SpringCacheIdempotentRepository]
 * xref:components::ehcache-component.adoc[EhcacheIdempotentRepository]
 * xref:components::kafka-component.adoc[KafkaIdempotentRepository]
 
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/log-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/log-eip.adoc
index 151fd43..d0e02b7 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/log-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/log-eip.adoc
@@ -1,12 +1,12 @@
 [[log-eip]]
 = Log EIP
 
-How can I log the processing of a xref:message.adoc[Message]?
+How can I log the processing of a xref:ROOT:message.adoc[Message]?
 
 Camel provides many ways to log the fact that you are processing a message. Here are just a few examples:
 * You can use the xref:components::log-component.adoc[Log] component which logs the Message content.
-* You can use the xref:tracer.adoc[Tracer] which trace logs message flow.
-* You can also use a xref:processor.adoc[Processor] or xref:bean-binding.adoc[Bean] and log from Java code.
+* You can use the xref:ROOT:tracer.adoc[Tracer] which trace logs message flow.
+* You can also use a xref:ROOT:processor.adoc[Processor] or xref:ROOT:bean-binding.adoc[Bean] and log from Java code.
 * You can use the log DSL.
 
 == Options
@@ -31,7 +31,7 @@ The log DSL is much lighter and meant for logging human logs such as Starting to
 
 == Samples
 
-You can use the log DSL which allows you to use xref:simple-language.adoc[Simple] language to construct a dynamic message which gets logged.
+You can use the log DSL which allows you to use xref:languages:simple-language.adoc[Simple] language to construct a dynamic message which gets logged.
 
 For example you can do
 
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/marshal-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/marshal-eip.adoc
index ddc53aa..8078e09 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/marshal-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/marshal-eip.adoc
@@ -1,7 +1,7 @@
 [[marshal-eip]]
 = Marshal EIP
 
-Marshalling is the opposite of unmarshalling, where a bean is marshalled into some binary or textual format for transmission over some transport via a Camel xref:components::index.adoc[Components]. Marshalling is used in the same way as unmarshalling above; in the xref:dsl.adoc[DSL] you can use a DataFormat instance, you can configure the DataFormat dynamically using the DSL or you can refer to a named instance of the format in the xref:registry.adoc[Registry].
+Marshalling is the opposite of unmarshalling, where a bean is marshalled into some binary or textual format for transmission over some transport via a Camel xref:components::index.adoc[Components]. Marshalling is used in the same way as unmarshalling above; in the xref:ROOT:dsl.adoc[DSL] you can use a DataFormat instance, you can configure the DataFormat dynamically using the DSL or you can refer to a named instance of the format in the xref:ROOT:registry.adoc[Registry].
 
 == Options
 
@@ -17,7 +17,7 @@ The Marshal EIP supports 1 options which are listed below:
 
 == Samples
 
-The following example unmarshals via serialization then marshals using a named JAXB data format to perform a kind of xref:message-translator.adoc[Message Translator].
+The following example unmarshals via serialization then marshals using a named JAXB data format to perform a kind of xref:ROOT:message-translator.adoc[Message Translator].
 
 [source,java]
 ----
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/multicast-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/multicast-eip.adoc
index 3363680..6f66b48 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/multicast-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/multicast-eip.adoc
@@ -140,5 +140,5 @@ allows you to do this using the processor
 interface.
 
 Notice the `onPrepare` can be used for any kind of custom logic which
-you would like to execute before the xref:exchange.adoc[Exchange] is
+you would like to execute before the xref:ROOT:exchange.adoc[Exchange] is
 being multicasted.
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/otherwise-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/otherwise-eip.adoc
index 45d4547..5314c76 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/otherwise-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/otherwise-eip.adoc
@@ -2,7 +2,7 @@
 = Otherwise EIP
 
 The Otherwise EIP is related to http://www.enterpriseintegrationpatterns.com/ContentBasedRouter.html[Content
-Based Router] from the xref:enterprise-integration-patterns.adoc[EIP
+Based Router] from the xref:ROOT:enterprise-integration-patterns.adoc[EIP
 patterns]
 
 image::eip/ContentBasedRouter.gif[image]
@@ -17,7 +17,7 @@ The Otherwise EIP has no options.
 
 The following example shows how to route a request from an input
 *direct:a* endpoint to either *direct:b*, *direct:c* or *direct:d* depending on
-the evaluation of various xref:predicate.adoc[Predicate] expressions
+the evaluation of various xref:ROOT:predicate.adoc[Predicate] expressions
 
 [source,java]
 ----
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/pipeline-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/pipeline-eip.adoc
index 8396970..e949952 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/pipeline-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/pipeline-eip.adoc
@@ -1,12 +1,12 @@
 [[pipeline-eip]]
 = Pipeline EIP
 
-Camel supports the http://www.enterpriseintegrationpatterns.com/PipesAndFilters.html[Pipes and Filters] from the xref:enterprise-integration-patterns.adoc[EIP patterns] in various ways.
+Camel supports the http://www.enterpriseintegrationpatterns.com/PipesAndFilters.html[Pipes and Filters] from the xref:ROOT:enterprise-integration-patterns.adoc[EIP patterns] in various ways.
 
 image::eip/PipesAndFilters.gif[image]
 
 With Camel you can split your processing across multiple independent
-xref:endpoint.adoc[Endpoint] instances which can then be chained
+xref:ROOT:endpoint.adoc[Endpoint] instances which can then be chained
 together.
 
 == Options
@@ -19,7 +19,7 @@ The Pipeline EIP has no options.
 == Examples
 
 You can create pipelines of logic using multiple
-xref:endpoint.adoc[Endpoint] or xref:message-translator.adoc[Message
+xref:ROOT:endpoint.adoc[Endpoint] or xref:ROOT:message-translator.adoc[Message
 Translator] instances as follows
 
 Though pipeline is the default mode of operation when you specify
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/process-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/process-eip.adoc
index c7c1c09..ca42f8b 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/process-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/process-eip.adoc
@@ -1,7 +1,7 @@
 [[process-eip]]
 = Process EIP
 
-The http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/Processor.html[Processor] interface is used to implement consumers of message exchanges or to implement a xref:message-translator.adoc[Message Translator]
+The http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/Processor.html[Processor] interface is used to implement consumers of message exchanges or to implement a xref:ROOT:message-translator.adoc[Message Translator]
 
 == Options
 
@@ -32,7 +32,7 @@ public class MyProcessor implements Processor {
 
 You can then easily use this inside a route by declaring the bean in
 Spring, say via the XML (or registering it in JNDI if that is your
-xref:registry.adoc[Registry])
+xref:ROOT:registry.adoc[Registry])
 
 [source,xml]
 --------------------------------------------------------
@@ -58,7 +58,7 @@ Processor myProcessor = new MyProcessor();
 from("activemq:myQueue").process(myProcessor);
 ----
 
-If you need to lookup the processor in the xref:registry.adoc[Registry]
+If you need to lookup the processor in the xref:ROOT:registry.adoc[Registry]
 then you should use the *processRef* DSL:
 
 [source,java]
@@ -89,12 +89,12 @@ refactor it into a separate class.
 
 There is a base class called
 http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/impl/ProcessorEndpoint.html[ProcessorEndpoint]
-which supports the full xref:endpoint.adoc[Endpoint] semantics given a
+which supports the full xref:ROOT:endpoint.adoc[Endpoint] semantics given a
 Processor instance.
 
 So you just need to create a https://github.com/apache/camel/tree/master/components[Component] class by
 deriving from
 http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/impl/DefaultComponent.html[DefaultComponent]
 which returns instances of ProcessorEndpoint. For more details see
-xref:writing-components.adoc[Writing Components]
+xref:ROOT:writing-components.adoc[Writing Components]
 
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/rollback-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/rollback-eip.adoc
index a16a732..2dff166 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/rollback-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/rollback-eip.adoc
@@ -4,7 +4,7 @@ Rollback might be needed if there is a transaction or transactional pieces in yo
 
 Camel recommends supporting the
 http://www.enterpriseintegrationpatterns.com/TransactionalClient.html[Transactional
-Client] from the xref:enterprise-integration-patterns.adoc[EIP patterns]
+Client] from the xref:ROOT:enterprise-integration-patterns.adoc[EIP patterns]
 using spring transactions.
 
 image::eip/TransactionalClientSolution.gif[image]
@@ -115,7 +115,7 @@ from("activemq:queue:foo").policy(notsupported).to("activemq:queue:bar");
 
 === OSGi Blueprint
 
-If you are using xref:using-osgi-blueprint-with-camel.adoc[OSGi
+If you are using xref:ROOT:using-osgi-blueprint-with-camel.adoc[OSGi
 Blueprint] then you most likely have to explicit declare a policy and
 refer to the policy from the transacted in the route.
 
@@ -187,10 +187,10 @@ Transaction error handler
 
 When a route is marked as transacted using *transacted* Camel will
 automatic use the
-xref:transactionerrorhandler.adoc[TransactionErrorHandler] as
-xref:error-handler.adoc[Error Handler]. It supports basically the same
-feature set as the xref:defaulterrorhandler.adoc[DefaultErrorHandler],
-so you can for instance use xref:exception-clause.adoc[Exception Clause]
+xref:ROOT:transactionerrorhandler.adoc[TransactionErrorHandler] as
+xref:ROOT:error-handler.adoc[Error Handler]. It supports basically the same
+feature set as the xref:ROOT:defaulterrorhandler.adoc[DefaultErrorHandler],
+so you can for instance use xref:ROOT:exception-clause.adoc[Exception Clause]
 as well.
 
 == Integration Testing with Spring
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/script-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/script-eip.adoc
index a336093..9e52240 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/script-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/script-eip.adoc
@@ -6,7 +6,7 @@ This is useful when you need to invoke some logic that are not in Java code such
 Groovy or any of the other Languages. The message body is not changed (by default) however the scripting
 context has access to the current Exchange and can essentially change the message or headers directly.
 But the return value from the script is discarded and not used.
-If the return value should be used as a changed message body then use xref:message-translator.adoc[Message Translator] EIP instead.
+If the return value should be used as a changed message body then use xref:ROOT:message-translator.adoc[Message Translator] EIP instead.
 
 == Options
 
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/split-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/split-eip.adoc
index 784510b..5771109 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/split-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/split-eip.adoc
@@ -1,7 +1,7 @@
 [[split-eip]]
 = Split EIP
 
-The http://www.enterpriseintegrationpatterns.com/patterns/messaging/Sequencer.html[Splitter] from the xref:enterprise-integration-patterns.adoc[EIP patterns] allows you split a message into a number of pieces and process them individually.
+The http://www.enterpriseintegrationpatterns.com/patterns/messaging/Sequencer.html[Splitter] from the xref:ROOT:enterprise-integration-patterns.adoc[EIP patterns] allows you split a message into a number of pieces and process them individually.
 
 image::eip/Sequencer.gif[image]
 
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/step-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/step-eip.adoc
index d95fa00..c44b88c 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/step-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/step-eip.adoc
@@ -1,7 +1,7 @@
 [[step-eip]]
 = Step EIP
 
-Camel supports the http://www.enterpriseintegrationpatterns.com/PipesAndFilters.html[Pipes and Filters] from the xref:enterprise-integration-patterns.adoc[EIP patterns] in various ways.
+Camel supports the http://www.enterpriseintegrationpatterns.com/PipesAndFilters.html[Pipes and Filters] from the xref:ROOT:enterprise-integration-patterns.adoc[EIP patterns] in various ways.
 
 image::eip/PipesAndFilters.gif[image]
 
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/to-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/to-eip.adoc
index f9ceb03..e6351ea 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/to-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/to-eip.adoc
@@ -3,12 +3,12 @@
 
 See message related documentation
 
-* xref:message.adoc[Message]
-* xref:message-bus.adoc[Message Bus]
-* xref:message-channel.adoc[Message Channel]
-* xref:message-endpoint.adoc[Message Endpoint]
-* xref:message-router.adoc[Message Router]
-* xref:message-translator.adoc[Message Translator]
+* xref:ROOT:message.adoc[Message]
+* xref:ROOT:message-bus.adoc[Message Bus]
+* xref:ROOT:message-channel.adoc[Message Channel]
+* xref:ROOT:message-endpoint.adoc[Message Endpoint]
+* xref:ROOT:message-router.adoc[Message Router]
+* xref:ROOT:message-translator.adoc[Message Translator]
 
 == Options
 
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/toD-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/toD-eip.adoc
index 2b9aca7..e024a25 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/toD-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/toD-eip.adoc
@@ -2,9 +2,9 @@
 = To D EIP
 
 There is a new `.toD` / `<toD>` that allows to send a message to a dynamic
-computed xref:endpoint.adoc[Endpoint] using one or
-more xref:expression.adoc[Expression] that are concat together. By
-default the xref:simple-language.adoc[Simple] language is used to compute
+computed xref:ROOT:endpoint.adoc[Endpoint] using one or
+more xref:ROOT:expression.adoc[Expression] that are concat together. By
+default the xref:languages:simple-language.adoc[Simple] language is used to compute
 the endpoint.
 
 == Options
@@ -45,7 +45,7 @@ And in XML:
 ----
 
 You can also prefix the uri with a value because by default the uri is
-evaluated using the xref:simple-language.adoc[Simple] language
+evaluated using the xref:languages:simple-language.adoc[Simple] language
 
 [source,java]
 ----
@@ -67,7 +67,7 @@ In the example above we compute an endpoint that has prefix "mock:" and
 then the header foo is appended. So for example if the header foo has
 value order, then the endpoint is computed as "mock:order".
 
-You can also use other languages than xref:simple-language.adoc[Simple] such
+You can also use other languages than xref:languages:simple-language.adoc[Simple] such
 as xref:components::xpath-language.adoc[XPath] - this requires to prefix with language: as
 shown below (simple language is the default language). If you do not
 specify language: then the endpoint is a component name. And in some
@@ -102,7 +102,7 @@ using the plus sign `+` such as shown below:
 ----
 
 In the example above the uri is a combination
-of xref:simple-language.adoc[Simple] language and xref:simple-language.adoc[XPath] where
+of xref:languages:simple-language.adoc[Simple] language and xref:languages:simple-language.adoc[XPath] where
 the first part is simple (simple is default language). And then the plus
 sign separate to another language, where we specify the language name
 followed by a colon
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/transform-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/transform-eip.adoc
index 687d16c..5d1503f 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/transform-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/transform-eip.adoc
@@ -3,7 +3,7 @@
 
 See below for details
 
-* xref:message-translator.adoc[Message Translator]
+* xref:ROOT:message-translator.adoc[Message Translator]
 
 == Options
 
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/unmarshal-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/unmarshal-eip.adoc
index c4e2816..7306998 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/unmarshal-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/unmarshal-eip.adoc
@@ -1,7 +1,7 @@
 [[unmarshal-eip]]
 = Unmarshal EIP
 
-If you receive a message from one of the Camel xref:components::index.adoc[Components] such as xref:components::file-component.adoc[File], xref:components::http-component.adoc[HTTP] or xref:components::jms-component.adoc[JMS] you often want to unmarshal the payload into some bean so that you can process it using some xref:bean-integration.adoc[Bean Integration] or perform xref:predicate.adoc[Predicate] evaluation and so forth. To do this use the *unmarshal* word in the xref:dsl.adoc[DSL] [...]
+If you receive a message from one of the Camel xref:components::index.adoc[Components] such as xref:components::file-component.adoc[File], xref:components::http-component.adoc[HTTP] or xref:components::jms-component.adoc[JMS] you often want to unmarshal the payload into some bean so that you can process it using some xref:ROOT:bean-integration.adoc[Bean Integration] or perform xref:ROOT:predicate.adoc[Predicate] evaluation and so forth. To do this use the *unmarshal* word in the xref:ROO [...]
 
 == Options
 
@@ -28,7 +28,7 @@ from("activemq:My.Queue").
   to("mqseries:Another.Queue");
 ----
 
-The above uses a named DataFormat of _jaxb_ which is configured with a number of Java package names. You can if you prefer use a named reference to a data format which can then be defined in your xref:registry.adoc[Registry] such as via your xref:components::spring.adoc[Spring] XML file.
+The above uses a named DataFormat of _jaxb_ which is configured with a number of Java package names. You can if you prefer use a named reference to a data format which can then be defined in your xref:ROOT:registry.adoc[Registry] such as via your xref:components::spring.adoc[Spring] XML file.
 
 You can also use the DSL itself to define the data format as you use it.
 For example the following uses Java serialization to unmarshal a binary
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/when-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/when-eip.adoc
index 5070c54..f659281 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/when-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/when-eip.adoc
@@ -2,7 +2,7 @@
 = When EIP
 
 The When EIP is related to http://www.enterpriseintegrationpatterns.com/ContentBasedRouter.html[Content
-Based Router] from the xref:enterprise-integration-patterns.adoc[EIP
+Based Router] from the xref:ROOT:enterprise-integration-patterns.adoc[EIP
 patterns]
 
 image::eip/ContentBasedRouter.gif[image]
@@ -17,7 +17,7 @@ The When EIP has no options.
 
 The following example shows how to route a request from an input
 *direct:a* endpoint to either *direct:b*, *direct:c* or *direct:d* depending on
-the evaluation of various xref:predicate.adoc[Predicate] expressions
+the evaluation of various xref:ROOT:predicate.adoc[Predicate] expressions
 
 [source,java]
 ----
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/wireTap-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/wireTap-eip.adoc
index 1aabcae..e3c6427 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/wireTap-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/wireTap-eip.adoc
@@ -2,7 +2,7 @@
 = Wire Tap EIP
 
 http://www.enterpriseintegrationpatterns.com/WireTap.html[Wire Tap]
-(from the xref:enterprise-integration-patterns.adoc[EIP patterns])
+(from the xref:ROOT:enterprise-integration-patterns.adoc[EIP patterns])
 allows you to route messages to a separate location while they are being
 forwarded to the ultimate destination.
 
@@ -11,9 +11,9 @@ image::eip/WireTap.gif[image]
 == Streams
 
 If you xref:wireTap-eip.adoc[Wire Tap] a stream message body then you
-should consider enabling xref:stream-caching.adoc[Stream caching] to
+should consider enabling xref:ROOT:stream-caching.adoc[Stream caching] to
 ensure the message body can be read at each endpoint. See more details
-at xref:stream-caching.adoc[Stream caching].
+at xref:ROOT:stream-caching.adoc[Stream caching].
 
 TIP: See the `cacheSize` option for more details on _how much cache_ to use depending on how many or few unique endpoints are used.
 
@@ -43,7 +43,7 @@ The Wire Tap EIP supports 11 options which are listed below:
 
 The WireTap uses a thread pool to process the
 tapped messages. This thread pool will by default use the settings
-detailed at xref:threading-model.adoc[Threading Model]. In particular,
+detailed at xref:ROOT:threading-model.adoc[Threading Model]. In particular,
 when the pool is exhausted (with all threads utilized), further wiretaps
 will be executed synchronously by the calling thread. To remedy this,
 you can configure an explicit thread pool on the xref:wireTap-eip.adoc[Wire
@@ -53,24 +53,24 @@ or more worker threads.
 == WireTap Node
 
 Camel's Wire Tap node supports two flavors when tapping an
-xref:exchange.adoc[Exchange]:
+xref:ROOT:exchange.adoc[Exchange]:
 
 - With the traditional Wire Tap, Camel will copy the original
-xref:exchange.adoc[Exchange] and set its
-xref:exchange-pattern.adoc[Exchange Pattern] to *`InOnly`*, as we want
-the tapped xref:exchange.adoc[Exchange] to be sent in a fire and forget
-style. The tapped xref:exchange.adoc[Exchange] is then sent in a
+xref:ROOT:exchange.adoc[Exchange] and set its
+xref:ROOT:exchange-pattern.adoc[Exchange Pattern] to *`InOnly`*, as we want
+the tapped xref:ROOT:exchange.adoc[Exchange] to be sent in a fire and forget
+style. The tapped xref:ROOT:exchange.adoc[Exchange] is then sent in a
 separate thread so it can run in parallel with the original. Beware that
 only the Exchange is copied - Wire Tap won't do a deep clone (unless you
 specify a custom processor via *`onPrepareRef`* which does that). So all
 copies could share objects from the original Exchange.
 - Camel also provides an option of sending a new
-xref:exchange.adoc[Exchange] allowing you to populate it with new
+xref:ROOT:exchange.adoc[Exchange] allowing you to populate it with new
 values.
 
 == Sending a Copy (traditional wiretap)
 
-* Using the xref:fluent-builders.adoc[Fluent Builders]
+* Using the xref:ROOT:fluent-builders.adoc[Fluent Builders]
 
 [source,java]
 ----
@@ -95,27 +95,27 @@ values.
     }
 ----
 
-== Sending a New xref:exchange.adoc[Exchange]
+== Sending a New xref:ROOT:exchange.adoc[Exchange]
 
-*Using the xref:fluent-builders.adoc[Fluent Builders]*
+*Using the xref:ROOT:fluent-builders.adoc[Fluent Builders]*
 
 Camel supports either a processor or an
-xref:expression.adoc[Expression] to populate the new
-xref:exchange.adoc[Exchange]. Using a processor gives you full power
-over how the xref:exchange.adoc[Exchange] is populated as you can set
-properties, headers, etc. An xref:expression.adoc[Expression] can only
+xref:ROOT:expression.adoc[Expression] to populate the new
+xref:ROOT:exchange.adoc[Exchange]. Using a processor gives you full power
+over how the xref:ROOT:exchange.adoc[Exchange] is populated as you can set
+properties, headers, etc. An xref:ROOT:expression.adoc[Expression] can only
 be used to set the *`IN`* body.
 
-The xref:expression.adoc[Expression] or
-xref:processor.adoc[Processor] is pre-populated with a copy of the
-original xref:exchange.adoc[Exchange], which allows you to access the
-original message when you prepare a new xref:exchange.adoc[Exchange] to
+The xref:ROOT:expression.adoc[Expression] or
+xref:ROOT:processor.adoc[Processor] is pre-populated with a copy of the
+original xref:ROOT:exchange.adoc[Exchange], which allows you to access the
+original message when you prepare a new xref:ROOT:exchange.adoc[Exchange] to
 be sent. You can use the *`copy`* option (enabled by default) to
 indicate whether you want this.
 
 Below is the processor variation,
 where we disable *`copy`* by passing in *`false`* to create a new, empty
-xref:exchange.adoc[Exchange]
+xref:ROOT:exchange.adoc[Exchange]
 
 [source,java]
 ----
@@ -144,7 +144,7 @@ xref:exchange.adoc[Exchange]
 == Using Dynamic URIs
 
 For example to wire tap to a dynamic URI, then it supports the same
-dynamic URIs as documented in xref:message-endpoint.adoc[Message
+dynamic URIs as documented in xref:ROOT:message-endpoint.adoc[Message
 Endpoint]. For example to wire tap to a JMS queue where the header ID is
 part of the queue name:
 
@@ -158,8 +158,8 @@ part of the queue name:
 
 If you send a new message using xref:wireTap-eip.adoc[Wire Tap], then you
 could only set the message body using an
-xref:expression.adoc[Expression] from the DSL. If you also need to set
-headers, you would have to use a xref:processor.adoc[Processor]. From
+xref:ROOT:expression.adoc[Expression] from the DSL. If you also need to set
+headers, you would have to use a xref:ROOT:processor.adoc[Processor]. From
 It's possible to set headers as well using the DSL.
 
 The following example sends a new message which has
@@ -204,4 +204,4 @@ The following example sends a new message which has
 
 See details at xref:multicast-eip.adoc[Multicast]
 
-xref:using-this-pattern.adoc[Using This Pattern]
+xref:ROOT:using-this-pattern.adoc[Using This Pattern]