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 28ee3408842d2ee2dda4031087401989cf755801
Author: David Jencks <djen...@apache.org>
AuthorDate: Thu Mar 12 12:44:05 2020 -0700
fix user-manual eip xrefs
---
...configuration-of-camelcontext-using-spring.adoc | 4 +-
.../modules/ROOT/pages/backlog-tracer.adoc | 2 +-
.../modules/ROOT/pages/bean-binding.adoc | 6 +--
.../modules/ROOT/pages/bean-integration.adoc | 4 +-
.../modules/ROOT/pages/competing-consumers.adoc | 2 +-
.../ROOT/pages/composed-message-processor.adoc | 8 ++--
.../modules/ROOT/pages/content-enricher.adoc | 18 +++----
.../modules/ROOT/pages/correlation-identifier.adoc | 4 +-
.../modules/ROOT/pages/dead-letter-channel.adoc | 2 +-
.../pages/enterprise-integration-patterns.adoc | 56 +++++++++++-----------
...om-processor-which-sends-multiple-messages.adoc | 2 +-
.../faq/how-does-camel-work-with-activemq.adoc | 2 +-
...end-the-same-message-to-multiple-endpoints.adoc | 8 ++--
.../pages/faq/how-to-use-a-dynamic-uri-in-to.adoc | 2 +-
...f-i-use-servicemix-when-should-i-use-camel.adoc | 2 +-
.../modules/ROOT/pages/faq/what-is-a-router.adoc | 4 +-
...se-when-or-otherwise-in-a-java-camel-route.adoc | 18 +++----
...ge-with-error-handler-not-work-as-expected.adoc | 8 ++--
.../modules/ROOT/pages/message-dispatcher.adoc | 2 +-
.../modules/ROOT/pages/message-endpoint.adoc | 2 +-
docs/user-manual/modules/ROOT/pages/message.adoc | 2 +-
.../user-manual/modules/ROOT/pages/normalizer.adoc | 2 +-
.../modules/ROOT/pages/polling-consumer.adoc | 2 +-
docs/user-manual/modules/ROOT/pages/predicate.adoc | 4 +-
.../modules/ROOT/pages/process-manager.adoc | 4 +-
.../modules/ROOT/pages/route-policy.adoc | 6 +--
.../modules/ROOT/pages/scatter-gather.adoc | 4 +-
.../modules/ROOT/pages/selective-consumer.adoc | 2 +-
.../modules/ROOT/pages/servlet-tomcat-example.adoc | 2 +-
.../modules/ROOT/pages/spring-remoting.adoc | 6 +--
.../modules/ROOT/pages/stream-caching.adoc | 2 +-
.../modules/ROOT/pages/threading-model.adoc | 4 +-
.../ROOT/pages/using-propertyplaceholder.adoc | 2 +-
.../ROOT/pages/walk-through-another-example.adoc | 2 +-
.../modules/ROOT/pages/writing-components.adoc | 2 +-
35 files changed, 101 insertions(+), 101 deletions(-)
diff --git
a/docs/user-manual/modules/ROOT/pages/advanced-configuration-of-camelcontext-using-spring.adoc
b/docs/user-manual/modules/ROOT/pages/advanced-configuration-of-camelcontext-using-spring.adoc
index cdd76de..9ddc2f8 100644
---
a/docs/user-manual/modules/ROOT/pages/advanced-configuration-of-camelcontext-using-spring.adoc
+++
b/docs/user-manual/modules/ROOT/pages/advanced-configuration-of-camelcontext-using-spring.adoc
@@ -53,7 +53,7 @@ configured.
|HandleFault |0..1 |To use a 3rd part fault handler to handle FAULT
messages.
-|Delayer |0..1 |To use a 3rd part xref:delay-eip.adoc[Delayer].
+|Delayer |0..1 |To use a 3rd part xref:eips:delay-eip.adoc[Delayer].
|ManagementStrategy |0..1 |*Camel 2.1:* To use a 3rd part strategy for
xref:jmx.adoc[management], for example JMX management.
@@ -101,7 +101,7 @@ xref:stream-caching.adoc[Stream caching] strategy.
RuntimeEndpointRegistry implementation.
|Logger |0..1 |*Camel 2.12.4/2.13.1:* To use provided org.slf4j.Logger
-for xref:components::log-component.adoc[Log] component and
xref:log-eip.adoc[log() EIP].
+for xref:eips:components::log-component.adoc[Log] component and
xref:eips:log-eip.adoc[log() EIP].
|AsyncProcessorAwaitManager |0..1 |*Camel 2.15:* To use a 3rd part async
process await manager.
diff --git a/docs/user-manual/modules/ROOT/pages/backlog-tracer.adoc
b/docs/user-manual/modules/ROOT/pages/backlog-tracer.adoc
index f0bc92c..c59b9ac 100644
--- a/docs/user-manual/modules/ROOT/pages/backlog-tracer.adoc
+++ b/docs/user-manual/modules/ROOT/pages/backlog-tracer.adoc
@@ -26,7 +26,7 @@ xref:tracer.adoc[Tracer] is event based and logs the messages
as they
happen (or route to another Camel destination). Also the
xref:tracer.adoc[Tracer] has more fine grained events where it dives
into xref:enterprise-integration-patterns.adoc[EIP]s such as the
-xref:content-based-router-eip.adoc[Content Based Router] and traces the
+xref:eips:content-based-router-eip.adoc[Content Based Router] and traces the
when/otherwise(s). Though the xref:tracer.adoc[Tracer] has much more
complicated logic to handle this (there is some edge-cases where this
may not work). The BacklogTracer allows you to pull the messages from
diff --git a/docs/user-manual/modules/ROOT/pages/bean-binding.adoc
b/docs/user-manual/modules/ROOT/pages/bean-binding.adoc
index 643b856..6fd955c 100644
--- a/docs/user-manual/modules/ROOT/pages/bean-binding.adoc
+++ b/docs/user-manual/modules/ROOT/pages/bean-binding.adoc
@@ -174,7 +174,7 @@ the xref:message.adoc[Message]
[[BeanBinding-Examples]]
=== Examples
-For example, a xref:bean-eip.adoc[Bean] such as:
+For example, a xref:eips:bean-eip.adoc[Bean] such as:
[source,syntaxhighlighter-pre]
----
@@ -239,7 +239,7 @@ $\{ }.
Any other value is consider to be a type declaration instead - see the
next section about specifying types for overloaded methods.
-When invoking a xref:bean-eip.adoc[Bean] you can instruct Camel to invoke a
+When invoking a xref:eips:bean-eip.adoc[Bean] you can instruct Camel to invoke
a
specific method by providing the method name:
[source,syntaxhighlighter-pre]
@@ -343,7 +343,7 @@ use `.to` instead as shown:
*Since Camel 2.8*
-If you have a xref:bean-eip.adoc[Bean] with overloaded methods, you can now
+If you have a xref:eips:bean-eip.adoc[Bean] with overloaded methods, you can
now
specify parameter types in the method name so Camel can match the method
you intend to use.
diff --git a/docs/user-manual/modules/ROOT/pages/bean-integration.adoc
b/docs/user-manual/modules/ROOT/pages/bean-integration.adoc
index 1886a97..f85fd17 100644
--- a/docs/user-manual/modules/ROOT/pages/bean-integration.adoc
+++ b/docs/user-manual/modules/ROOT/pages/bean-integration.adoc
@@ -33,8 +33,8 @@ See more details at:
* xref:pojo-consuming.adoc[POJO Consuming] to consume and possibly route
messages from Camel
* xref:pojo-producing.adoc[POJO Producing] to make it easy to produce camel
messages from your POJOs
* `@DynamicRouter` Annotation for creating a xref:dynamic-router.adoc[Dynamic
Router] from a POJO method
-* `@RecipientList` Annotation for creating a
xref:recipientList-eip.adoc[Recipient List] from a POJO method
-* `@RoutingSlip` Annotation for creating a xref:routingSlip-eip.adoc[Routing
Slip] for a POJO method
+* `@RecipientList` Annotation for creating a
xref:eips:recipientList-eip.adoc[Recipient List] from a POJO method
+* `@RoutingSlip` Annotation for creating a
xref:eips:routingSlip-eip.adoc[Routing Slip] for a POJO method
* xref:bean-injection.adoc[Bean Injection] to inject Camel related resources
into your POJOs
* xref:using-exchange-pattern-annotations.adoc[Using Exchange Pattern
Annotations]
describes how the pattern annotations can be used to change
diff --git a/docs/user-manual/modules/ROOT/pages/competing-consumers.adoc
b/docs/user-manual/modules/ROOT/pages/competing-consumers.adoc
index 845b39e..615766a 100644
--- a/docs/user-manual/modules/ROOT/pages/competing-consumers.adoc
+++ b/docs/user-manual/modules/ROOT/pages/competing-consumers.adoc
@@ -73,7 +73,7 @@ And what if we need more, then we need to add a 3rd, a 4th
and so on.
What if the processing of the file itself is the bottleneck? That is the
calculateBean is slow.
So how can we process messages with this bean concurrently?
-Yeah we can use the xref:threads-eip.adoc[Threads EIP], so if we insert it in
the route we get:
+Yeah we can use the xref:eips:threads-eip.adoc[Threads EIP], so if we insert
it in the route we get:
[source,java]
----
diff --git
a/docs/user-manual/modules/ROOT/pages/composed-message-processor.adoc
b/docs/user-manual/modules/ROOT/pages/composed-message-processor.adoc
index 7571b58..01aec49 100644
--- a/docs/user-manual/modules/ROOT/pages/composed-message-processor.adoc
+++ b/docs/user-manual/modules/ROOT/pages/composed-message-processor.adoc
@@ -13,15 +13,15 @@ Use Composed Message Processor to process a composite
message.
The Composed Message Processor splits the message up, routes the sub-messages
to the appropriate destinations
and re-aggregates the responses back into a single message.
-With Camel this pattern is implemented by the xref:split-eip.adoc[Splitter]
+With Camel this pattern is implemented by the
xref:eips:split-eip.adoc[Splitter]
which has built-in aggregation to re-aggregate the responses back into a
single message.
== Sample
-This sample uses the xref:split-eip.adoc[Splitter] as composed message
processor to process each splitted message,
+This sample uses the xref:eips:split-eip.adoc[Splitter] as composed message
processor to process each splitted message,
aggregate and return a combined single response.
-The route and the code comments below explains how you can use the
xref:split-eip.adoc[Splitter] to
+The route and the code comments below explains how you can use the
xref:eips:split-eip.adoc[Splitter] to
split each message to sub-message which are processed individuallay and then
combined back into
a single response message via the custom ``aggregationStrategy`
(`MyOrderStategy`), which
then are the output of the splitter, that are then further processed at the
end of the route.
@@ -48,4 +48,4 @@ from("direct:start")
== More details
-See the xref:split-eip.adoc[Splitter] EIP.
+See the xref:eips:split-eip.adoc[Splitter] EIP.
diff --git a/docs/user-manual/modules/ROOT/pages/content-enricher.adoc
b/docs/user-manual/modules/ROOT/pages/content-enricher.adoc
index 386d700..2c7252d 100644
--- a/docs/user-manual/modules/ROOT/pages/content-enricher.adoc
+++ b/docs/user-manual/modules/ROOT/pages/content-enricher.adoc
@@ -108,9 +108,9 @@ xref:exchange.adoc[Exchange]. For example you cannot set a
filename in
the `Exchange.FILE_NAME` header and use `pollEnrich` to consume only
that file. For that you *must* set the filename in the endpoint URI.
-Instead of using `enrich` you can use xref:recipientList-eip.adoc[Recipient
+Instead of using `enrich` you can use
xref:eips:recipientList-eip.adoc[Recipient
List] and have dynamic endpoints and define an `AggregationStrategy` on
-the xref:recipientList-eip.adoc[Recipient List] which then would work as a
+the xref:eips:recipientList-eip.adoc[Recipient List] which then would work as a
`enrich` would do.
pollEnrich only accept one message as response. That means that if you
@@ -160,18 +160,18 @@ to be used to merge the reply from the external service,
into a single
outgoing message. By default Camel will use the reply from the external
service as outgoing message. From *Camel 2.12* onwards you can also use
a POJO as the `AggregationStrategy`, see the
-xref:aggregate-eip.adoc[Aggregate] page for more details.
+xref:eips:aggregate-eip.adoc[Aggregate] page for more details.
|`strategyMethodName` | |*Camel 2.12:* This option can be used to
explicit declare the method name to use, when using POJOs as the
-`AggregationStrategy`. See the xref:aggregate-eip.adoc[Aggregate] page for
+`AggregationStrategy`. See the xref:eips:aggregate-eip.adoc[Aggregate] page for
more details.
|`strategyMethodAllowNull` |`false` |*Camel 2.12:* If this option is
`false` then the aggregate method is not used if there was no data to
enrich. If this option is `true` then `null` values is used as the
`oldExchange` (when no data to enrich), when using POJOs as the
-`AggregationStrategy`. See the xref:aggregate-eip.adoc[Aggregate] page for
+`AggregationStrategy`. See the xref:eips:aggregate-eip.adoc[Aggregate] page for
more details.
|`aggregateOnException` |`false` |*Camel 2.14:* If this option is
@@ -185,7 +185,7 @@ to suppress the exception or set a custom message body etc.
the parent and the resource exchange. Enrich will by default not share
unit of work between the parent exchange and the resource exchange. This
means the resource exchange has its own individual unit of work. See
-xref:split-eip.adoc[Splitter] for more information and example.
+xref:eips:split-eip.adoc[Splitter] for more information and example.
|`cacheSize` | |*Camel 2.16:* Allows to configure the cache size for
the `ProducerCache` which caches producers for reuse in the enrich. Will
@@ -373,18 +373,18 @@ to be used to merge the reply from the external service,
into a single
outgoing message. By default Camel will use the reply from the external
service as outgoing message. From *Camel 2.12* onwards you can also use
a POJO as the `AggregationStrategy`, see the
-xref:aggregate-eip.adoc[Aggregate] page for more details.
+xref:eips:aggregate-eip.adoc[Aggregate] page for more details.
|`strategyMethodName` | |*Camel 2.12:* This option can be used to
explicit declare the method name to use, when using POJOs as the
-`AggregationStrategy`. See the xref:aggregate-eip.adoc[Aggregate] page for
+`AggregationStrategy`. See the xref:eips:aggregate-eip.adoc[Aggregate] page for
more details.
|`strategyMethodAllowNull` |`false` |*Camel 2.12:* If this option is
`false` then the aggregate method is not used if there was no data to
enrich. If this option is `true` then `null` values is used as the
`oldExchange` (when no data to enrich), when using POJOs as the
-`AggregationStrategy`. See the xref:aggregate-eip.adoc[Aggregate] page for
+`AggregationStrategy`. See the xref:eips:aggregate-eip.adoc[Aggregate] page for
more details.
|`timeout` |`-1` |Timeout in millis when polling from the external
diff --git a/docs/user-manual/modules/ROOT/pages/correlation-identifier.adoc
b/docs/user-manual/modules/ROOT/pages/correlation-identifier.adoc
index 5e79bf4..8cfcfaa 100644
--- a/docs/user-manual/modules/ROOT/pages/correlation-identifier.adoc
+++ b/docs/user-manual/modules/ROOT/pages/correlation-identifier.adoc
@@ -25,8 +25,8 @@ those cases, Camel will add a correlation id on the
xref:exchange.adoc[Exchange] as a property with they key
`Exchange.CORRELATION_ID`, which links back to the source
xref:exchange.adoc[Exchange]. For example the
-xref:split-eip.adoc[Splitter], xref:multicast-eip.adoc[Multicast],
-xref:recipientList-eip.adoc[Recipient List], and xref:wireTap-eip.adoc[Wire
+xref:eips:split-eip.adoc[Splitter], xref:eips:multicast-eip.adoc[Multicast],
+xref:eips:recipientList-eip.adoc[Recipient List], and
xref:eips:wireTap-eip.adoc[Wire
Tap] EIP does this.
The following example demonstrates using the Camel JMSMessageID as the
diff --git a/docs/user-manual/modules/ROOT/pages/dead-letter-channel.adoc
b/docs/user-manual/modules/ROOT/pages/dead-letter-channel.adoc
index 79af0f5..a2a8863 100644
--- a/docs/user-manual/modules/ROOT/pages/dead-letter-channel.adoc
+++ b/docs/user-manual/modules/ROOT/pages/dead-letter-channel.adoc
@@ -332,7 +332,7 @@ The `Exchange.FAILURE_ENDPOINT` have the constant value
This allows for example you to fetch this information in your dead
letter queue and use that for error reporting. +
This is useable if the Camel route is a bit dynamic such as the dynamic
-xref:recipientList-eip.adoc[Recipient List] so you know which endpoints
+xref:eips:recipientList-eip.adoc[Recipient List] so you know which endpoints
failed.
These information is kept on the Exchange even if the message
diff --git
a/docs/user-manual/modules/ROOT/pages/enterprise-integration-patterns.adoc
b/docs/user-manual/modules/ROOT/pages/enterprise-integration-patterns.adoc
index 53faf62..a85f8ed 100644
--- a/docs/user-manual/modules/ROOT/pages/enterprise-integration-patterns.adoc
+++ b/docs/user-manual/modules/ROOT/pages/enterprise-integration-patterns.adoc
@@ -22,7 +22,7 @@ a|image::eip/MessageIcon.gif[image]
message channel exchange a piece of information?
a|image::eip/PipesAndFiltersIcon.gif[image]
-|xref:pipeline-eip.adoc[Pipes and Filters] |How can we perform
+|xref:eips:pipeline-eip.adoc[Pipes and Filters] |How can we perform
complex processing on a message while maintaining independence and
flexibility?
@@ -116,35 +116,35 @@ when a message should be considered stale and thus
shouldn’t be processed?
[width="100%",cols="10%,10%,80%",]
|=======================================================================
a|image::eip/ContentBasedRouterIcon.gif[image]
-|xref:content-based-router-eip.adoc[Content Based Router] |How do we handle
+|xref:eips:content-based-router-eip.adoc[Content Based Router] |How do we
handle
a situation where the implementation of a single logical function (e.g.,
inventory check) is spread across multiple physical systems?
a|image::eip/MessageFilterIcon.gif[image]
-|xref:filter-eip.adoc[Message Filter] |How can a component avoid
+|xref:eips:filter-eip.adoc[Message Filter] |How can a component avoid
receiving uninteresting messages?
a|image::eip/DynamicRouterIcon.gif[image]
-|xref:dynamicRouter-eip.adoc[Dynamic Router] |How can you avoid the
+|xref:eips:dynamicRouter-eip.adoc[Dynamic Router] |How can you avoid the
dependency of the router on all possible destinations while maintaining
its efficiency?
a|image::eip/RecipientListIcon.gif[image]
-|xref:recipientList-eip.adoc[Recipient List] |How do we route a message to
+|xref:eips:recipientList-eip.adoc[Recipient List] |How do we route a message to
a list of (static or dynamically) specified recipients?
a|image::eip/SplitterIcon.gif[image]
-|xref:split-eip.adoc[Splitter] |How can we process a message if it
+|xref:eips:split-eip.adoc[Splitter] |How can we process a message if it
contains multiple elements, each of which may have to be processed in a
different way?
a|image::eip/AggregatorIcon.gif[image]
-|xref:aggregate-eip.adoc[Aggregator] |How do we combine the results of
+|xref:eips:aggregate-eip.adoc[Aggregator] |How do we combine the results of
individual, but related messages so that they can be processed as a
whole?
a|image::eip/ResequencerIcon.gif[image]
-|xref:resequence-eip.adoc[Resequencer] |How can we get a stream of related
+|xref:eips:resequence-eip.adoc[Resequencer] |How can we get a stream of related
but out-of-sequence messages back into the correct order?
a|image::eip/DistributionAggregateIcon.gif[image]
@@ -159,7 +159,7 @@ overall message flow when a message needs to be sent to
multiple
recipients, each of which may send a reply?
a|image::eip/RoutingTableIcon.gif[image]
-|xref:routingSlip-eip.adoc[Routing Slip] |How do we route a message
+|xref:eips:routingSlip-eip.adoc[Routing Slip] |How do we route a message
consecutively through a series of processing steps when the sequence of
steps is not known at design-time and may vary for each message?
@@ -174,38 +174,38 @@ destination of a message from the sender and maintain
central control
over the flow of messages?
|
-|xref:throttle-eip.adoc[Throttler] |How can I throttle messages to ensure
+|xref:eips:throttle-eip.adoc[Throttler] |How can I throttle messages to ensure
that a specific endpoint does not get overloaded, or we don't exceed an
agreed SLA with some external service?
|
-|xref:sample-eip.adoc[Sampling] |How can I sample one message out of many
+|xref:eips:sample-eip.adoc[Sampling] |How can I sample one message out of many
in a given period to avoid downstream route does not get overloaded?
|
-|xref:delay-eip.adoc[Delayer] |How can I delay the sending of a message?
+|xref:eips:delay-eip.adoc[Delayer] |How can I delay the sending of a message?
|
-|xref:loadBalance-eip.adoc[Load Balancer] |How can I balance load across a
+|xref:eips:loadBalance-eip.adoc[Load Balancer] |How can I balance load across a
number of endpoints?
|
-|xref:circuitBreaker-eip.adoc[Circuit Breaker] |How can I stop to call an
external service if the service is broken?
+|xref:eips:circuitBreaker-eip.adoc[Circuit Breaker] |How can I stop to call an
external service if the service is broken?
|
-|xref:serviceCall-eip.adoc[Service Call] |How can I call a remote service in a
distributed system
+|xref:eips:serviceCall-eip.adoc[Service Call] |How can I call a remote service
in a distributed system
where the service is looked up from a service registry of some sorts?
|
-|xref:saga-eip.adoc[Saga] |How can I define a series of related actions in a
Camel route
+|xref:eips:saga-eip.adoc[Saga] |How can I define a series of related actions
in a Camel route
that should be either completed successfully (all of them) or
not-executed/compensated?
|
-|xref:multicast-eip.adoc[Multicast] |How can I route a message to a number
+|xref:eips:multicast-eip.adoc[Multicast] |How can I route a message to a number
of endpoints at the same time?
|
-|xref:loop-eip.adoc[Loop] |How can I repeat processing a message in a loop?
+|xref:eips:loop-eip.adoc[Loop] |How can I repeat processing a message in a
loop?
|=======================================================================
[[EnterpriseIntegrationPatterns-MessageTransformation]]
@@ -219,11 +219,11 @@ with another system if the message originator does not
have all the
required data items available?
a|image::eip/ContentFilterIcon.gif[image]
-|xref:content-filter-eip.adoc[Content Filter] |How do you simplify dealing
+|xref:eips:content-filter-eip.adoc[Content Filter] |How do you simplify dealing
with a large message, when you are interested only in a few data items?
a|image::eip/StoreInLibraryIcon.gif[image]
-|xref:claimCheck-eip.adoc[Claim Check] |How can we reduce the data volume
+|xref:eips:claimCheck-eip.adoc[Claim Check] |How can we reduce the data volume
of message sent across the system without sacrificing information
content?
@@ -232,13 +232,13 @@ a|image::eip/NormalizerIcon.gif[image]
semantically equivalent, but arrive in a different format?
|
-|xref:sort-eip.adoc[Sort] |How can I sort the body of a message?
+|xref:eips:sort-eip.adoc[Sort] |How can I sort the body of a message?
|
-|xref:script-eip.adoc[Script] |How do I execute a script which may not change
the message?
+|xref:eips:script-eip.adoc[Script] |How do I execute a script which may not
change the message?
|
-|xref:validate-eip.adoc[Validate] |How can I validate a message?
+|xref:eips:validate-eip.adoc[Validate] |How can I validate a message?
|=======================================================================
[[EnterpriseIntegrationPatterns-MessagingEndpoints]]
@@ -252,7 +252,7 @@ between domain objects and the messaging infrastructure
while keeping
the two independent of each other?
a|image::eip/EventDrivenConsumerIcon.gif[image]
-|xref:eventDrivenConsumer-eip.adoc[Event Driven Consumer] |How can an
+|xref:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer] |How can an
application automatically consume messages as they become available?
a|image::eip/PollingConsumerIcon.gif[image]
@@ -276,7 +276,7 @@ a|image::eip/DurableSubscriptionIcon.gif[image]
avoid missing messages while it's not listening for them?
|
-|xref:idempotentConsumer-eip.adoc[Idempotent Consumer] |How can a message
+|xref:eips:idempotentConsumer-eip.adoc[Idempotent Consumer] |How can a message
receiver deal with duplicate messages?
a|image::eip/TransactionalClientIcon.gif[image]
@@ -309,7 +309,7 @@ intermediate steps to perform validation, testing or
debugging
functions?
a|image::eip/WireTapIcon.gif[image]
-|xref:wireTap-eip.adoc[Wire Tap] |How do you inspect messages that travel
+|xref:eips:wireTap-eip.adoc[Wire Tap] |How do you inspect messages that travel
on a point-to-point channel?
|
@@ -317,10 +317,10 @@ on a point-to-point channel?
analyze and debug the flow of messages in a loosely coupled system?
|
-|xref:log-eip.adoc[Log] |How can I log processing a message?
+|xref:eips:log-eip.adoc[Log] |How can I log processing a message?
|
-|xref:step-eip.adoc[Step] | Steps groups together a set of EIPs into a
composite logical unit for metrics and monitoring. |
+|xref:eips:step-eip.adoc[Step] | Steps groups together a set of EIPs into a
composite logical unit for metrics and monitoring. |
|=======================================================================
diff --git
a/docs/user-manual/modules/ROOT/pages/faq/how-do-i-write-a-custom-processor-which-sends-multiple-messages.adoc
b/docs/user-manual/modules/ROOT/pages/faq/how-do-i-write-a-custom-processor-which-sends-multiple-messages.adoc
index cdad5a7..745952b 100644
---
a/docs/user-manual/modules/ROOT/pages/faq/how-do-i-write-a-custom-processor-which-sends-multiple-messages.adoc
+++
b/docs/user-manual/modules/ROOT/pages/faq/how-do-i-write-a-custom-processor-which-sends-multiple-messages.adoc
@@ -1,7 +1,7 @@
[[HowdoIwriteacustomProcessorwhichsendsmultiplemessages-HowdoIwriteacustomProcessorwhichsendsmultiplemessages]]
= How do I write a custom Processor which sends multiple messages?
-You could use a xref:split-eip.adoc[Splitter] or use multiple
+You could use a xref:eips:split-eip.adoc[Splitter] or use multiple
xref:message-translator.adoc[Message Translator] instances in your
route.
diff --git
a/docs/user-manual/modules/ROOT/pages/faq/how-does-camel-work-with-activemq.adoc
b/docs/user-manual/modules/ROOT/pages/faq/how-does-camel-work-with-activemq.adoc
index ce165b0..cd9e2d6 100644
---
a/docs/user-manual/modules/ROOT/pages/faq/how-does-camel-work-with-activemq.adoc
+++
b/docs/user-manual/modules/ROOT/pages/faq/how-does-camel-work-with-activemq.adoc
@@ -13,7 +13,7 @@ xref:components::file-component.adoc[File],
xref:components::ftp-component.adoc[
xref:components::xmpp-component.adoc[XMPP] other
xref:components::jms-component.adoc[JMS] providers and any of the
other Camel xref:component.adoc[Components] as well as implementating
all of the xref:enterprise-integration-patterns.adoc[Enterprise
-Integration Patterns] such as xref:content-based-router-eip.adoc[Content
+Integration Patterns] such as xref:eips:content-based-router-eip.adoc[Content
Based Router] or xref:message-translator.adoc[Message Translator].
For more details see
diff --git
a/docs/user-manual/modules/ROOT/pages/faq/how-to-send-the-same-message-to-multiple-endpoints.adoc
b/docs/user-manual/modules/ROOT/pages/faq/how-to-send-the-same-message-to-multiple-endpoints.adoc
index 455f494..88664f3 100644
---
a/docs/user-manual/modules/ROOT/pages/faq/how-to-send-the-same-message-to-multiple-endpoints.adoc
+++
b/docs/user-manual/modules/ROOT/pages/faq/how-to-send-the-same-message-to-multiple-endpoints.adoc
@@ -2,12 +2,12 @@
= How to send the same message to multiple endpoints?
When you need to send the *same* message to multiple endpoints then you
-should use xref:multicast-eip.adoc[Multicast].
+should use xref:eips:multicast-eip.adoc[Multicast].
In the sample below we consume messages from the activemq queue `foo`
and want to send the *same message* to both `seda:foo` and `seda:bar`.
Sending the same message requires that we use
-xref:multicast-eip.adoc[Multicast]. This is done by adding the `multicast()`
+xref:eips:multicast-eip.adoc[Multicast]. This is done by adding the
`multicast()`
before the to type:
[source,java]
@@ -26,8 +26,8 @@ If you have a route such as:
from("activemq:queue:foo").to("seda:foo", "seda:bar");
----
-It is by default a xref:pipeline-eip.adoc[pipeline] in Camel (that is
-the opposite to xref:multicast-eip.adoc[Multicast]). In the above example
+It is by default a xref:eips:pipeline-eip.adoc[pipeline] in Camel (that is
+the opposite to xref:eips:multicast-eip.adoc[Multicast]). In the above example
using pipes and filters then the result from seda:foo is sent to
seda:bar, ie. its not the *same* message sent to multiple destinations,
but a sent through a chain (the pipes and the filters).
diff --git
a/docs/user-manual/modules/ROOT/pages/faq/how-to-use-a-dynamic-uri-in-to.adoc
b/docs/user-manual/modules/ROOT/pages/faq/how-to-use-a-dynamic-uri-in-to.adoc
index a1927ca..7ecca1b 100644
---
a/docs/user-manual/modules/ROOT/pages/faq/how-to-use-a-dynamic-uri-in-to.adoc
+++
b/docs/user-manual/modules/ROOT/pages/faq/how-to-use-a-dynamic-uri-in-to.adoc
@@ -24,7 +24,7 @@ This snippet is not valid code. Read on.
In this case, you must use an EIP (Enterprise Integration Pattern) that
is capable of computing a dynamic URI using
an xref:expression.adoc[Expression], such as
-the xref:toD-eip.adoc[ToD] or xref:recipientList-eip.adoc[Recipient List] EIP
pattern.
+the xref:eips:toD-eip.adoc[ToD] or xref:eips:recipientList-eip.adoc[Recipient
List] EIP pattern.
[TIP]
====
diff --git
a/docs/user-manual/modules/ROOT/pages/faq/if-i-use-servicemix-when-should-i-use-camel.adoc
b/docs/user-manual/modules/ROOT/pages/faq/if-i-use-servicemix-when-should-i-use-camel.adoc
index 93a7d6b..6b45011 100644
---
a/docs/user-manual/modules/ROOT/pages/faq/if-i-use-servicemix-when-should-i-use-camel.adoc
+++
b/docs/user-manual/modules/ROOT/pages/faq/if-i-use-servicemix-when-should-i-use-camel.adoc
@@ -7,7 +7,7 @@ So if you are already using
http://servicemix.apache.org/[ServiceMix]
then you can use Camel implement the
xref:enterprise-integration-patterns.adoc[Enterprise Integration Patterns]
inside JBI such as
-xref:content-based-router-eip.adoc[Content Based Router], routing messages
+xref:eips:content-based-router-eip.adoc[Content Based Router], routing messages
between your existing JBI endpoints.
You can also reuse any of the Camel xref:component.adoc[Components]
diff --git a/docs/user-manual/modules/ROOT/pages/faq/what-is-a-router.adoc
b/docs/user-manual/modules/ROOT/pages/faq/what-is-a-router.adoc
index 988693b..19cf6af 100644
--- a/docs/user-manual/modules/ROOT/pages/faq/what-is-a-router.adoc
+++ b/docs/user-manual/modules/ROOT/pages/faq/what-is-a-router.adoc
@@ -11,12 +11,12 @@ xref:enterprise-integration-patterns.adoc[Enterprise
Integration
Patterns].
For example a router could implement the
-xref:content-based-router-eip.adoc[Content Based Router] pattern, to route
+xref:eips:content-based-router-eip.adoc[Content Based Router] pattern, to route
from an endpoint to one or more destination endpoints using a
xref:predicate.adoc[Predicate] based on the message content.
Typically a route or router consists of one or more consumers; either an
-xref:eventDrivenConsumer-eip.adoc[Event Driven Consumer] or a
+xref:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer] or a
xref:polling-consumer.adoc[Polling Consumer] or possibly a
xref:transactional-client.adoc[Transactional Client]. Then there are one
or more xref:processor.adoc[Processor] instances which could send the
diff --git
a/docs/user-manual/modules/ROOT/pages/faq/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc
b/docs/user-manual/modules/ROOT/pages/faq/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc
index 7c22202..eff2fb7 100644
---
a/docs/user-manual/modules/ROOT/pages/faq/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc
+++
b/docs/user-manual/modules/ROOT/pages/faq/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc
@@ -1,7 +1,7 @@
[[WhycanInotusewhenorotherwiseinaJavaCamelroute-WhycanInotusewhenotherwiseinaJavaCamelroute]]
= Why can I not use when/otherwise in a Java Camel route?
-When using the xref:content-based-router-eip.adoc[Content Based Router] in
+When using the xref:eips:content-based-router-eip.adoc[Content Based Router] in
the Java DSL you may have a situation where the compiler will not accept
the following `when()` or `otherwise()` statement.
@@ -10,12 +10,12 @@ the following `when()` or `otherwise()` statement.
**Quick tip**
Use `.endChoice()` to return "back" to the
-xref:content-based-router-eip.adoc[Content Based Router].
+xref:eips:content-based-router-eip.adoc[Content Based Router].
====
For example as shown in the route below where we use the
-xref:loadBalance-eip.adoc[Load Balancer] inside the
-xref:content-based-router-eip.adoc[Content Based Router] in the first when:
+xref:eips:loadBalance-eip.adoc[Load Balancer] inside the
+xref:eips:content-based-router-eip.adoc[Content Based Router] in the first
when:
*Code will not compile*
@@ -29,7 +29,7 @@ from("direct:start")
.to("mock:result");
----
-Well the first issue is that the xref:loadBalance-eip.adoc[Load Balancer]
+Well the first issue is that the xref:eips:loadBalance-eip.adoc[Load Balancer]
uses the additional routing to know what to use in the load balancing.
In this example that would be the:
@@ -59,10 +59,10 @@ xref:dsl.adoc[DSL]. In a more modern language such as
Scala or Groovy you would be able
to let it be stack based, so the `.end()` will pop the last type of the
stack, and you would return back to the scope of the
-xref:content-based-router-eip.adoc[Content Based Router]. However that's not
+xref:eips:content-based-router-eip.adoc[Content Based Router]. However that's
not
easily doable in Java. So we need to help Java a bit, which you do by
using `.endChoice()`, which tells Camel to "pop the stack" and return
-back to the scope of the xref:content-based-router-eip.adoc[Content Based
+back to the scope of the xref:eips:content-based-router-eip.adoc[Content Based
Router].
*Code compiles*
@@ -81,10 +81,10 @@ You only need to use `.endChoice()` when using certain
xref:enterprise-integration-patterns.adoc[EIP]s which often have additional
methods to configure or as part of the
xref:enterprise-integration-patterns.adoc[EIP] itself. For example the
-xref:split-eip.adoc[Splitter] EIP has a sub-route which denotes the
+xref:eips:split-eip.adoc[Splitter] EIP has a sub-route which denotes the
routing of each splitted message. You would also have to use
`.endChoice()` to indicate the end of the sub-route and to return back
-to the xref:content-based-router-eip.adoc[Content Based Router]. Note
+to the xref:eips:content-based-router-eip.adoc[Content Based Router]. Note
`.endChoice()` is *Since Camel 2.7*.
[[WhycanInotusewhenorotherwiseinaJavaCamelroute-Stillproblems]]
diff --git
a/docs/user-manual/modules/ROOT/pages/faq/why-does-useoriginalmessage-with-error-handler-not-work-as-expected.adoc
b/docs/user-manual/modules/ROOT/pages/faq/why-does-useoriginalmessage-with-error-handler-not-work-as-expected.adoc
index 0a7a748..25b946c 100644
---
a/docs/user-manual/modules/ROOT/pages/faq/why-does-useoriginalmessage-with-error-handler-not-work-as-expected.adoc
+++
b/docs/user-manual/modules/ROOT/pages/faq/why-does-useoriginalmessage-with-error-handler-not-work-as-expected.adoc
@@ -5,12 +5,12 @@ If you use the xref:exception-clause.adoc[useOriginalMessage]
option
from the Camel xref:exception-clause.adoc[Error Handler] then it matters
if you use this with xref:enterprise-integration-patterns.adoc[EIP]s such as:
-* xref:recipientList-eip.adoc[Recipient List]
-* xref:split-eip.adoc[Splitter]
-* xref:multicast-eip.adoc[Multicast]
+* xref:eips:recipientList-eip.adoc[Recipient List]
+* xref:eips:split-eip.adoc[Splitter]
+* xref:eips:multicast-eip.adoc[Multicast]
Then the option `shareUnitOfWork` on these
xref:enterprise-integration-patterns.adoc[EIP]s
influence the message in use by the `useOriginalMessage` option.
-See more details at xref:split-eip.adoc[Splitter] and further below with
+See more details at xref:eips:split-eip.adoc[Splitter] and further below with
the examples explaining this in more detail.
diff --git a/docs/user-manual/modules/ROOT/pages/message-dispatcher.adoc
b/docs/user-manual/modules/ROOT/pages/message-dispatcher.adoc
index c858e0a..55515cd 100644
--- a/docs/user-manual/modules/ROOT/pages/message-dispatcher.adoc
+++ b/docs/user-manual/modules/ROOT/pages/message-dispatcher.adoc
@@ -11,5 +11,5 @@ image::eip/MessageDispatcher.gif[image]
You can use a component like JMS with selectors to implement a
xref:selective-consumer.adoc[Selective Consumer]
as the Message Dispatcher implementation. Or you can use an
xref:message-endpoint.adoc[Message Endpoint]
-as the Message Dispatcher itself and then use a
xref:content-based-router-eip.adoc[Content Based Router]
+as the Message Dispatcher itself and then use a
xref:eips:content-based-router-eip.adoc[Content Based Router]
as the Message Dispatcher.
diff --git a/docs/user-manual/modules/ROOT/pages/message-endpoint.adoc
b/docs/user-manual/modules/ROOT/pages/message-endpoint.adoc
index b7a9ce1..30f6d41 100644
--- a/docs/user-manual/modules/ROOT/pages/message-endpoint.adoc
+++ b/docs/user-manual/modules/ROOT/pages/message-endpoint.adoc
@@ -24,5 +24,5 @@ implementations.
[[messageEndpoint-Example]]
== Samples
-See first example in xref:to-eip.adoc[To EIP]
+See first example in xref:eips:to-eip.adoc[To EIP]
diff --git a/docs/user-manual/modules/ROOT/pages/message.adoc
b/docs/user-manual/modules/ROOT/pages/message.adoc
index 708fc69..845e9ea 100644
--- a/docs/user-manual/modules/ROOT/pages/message.adoc
+++ b/docs/user-manual/modules/ROOT/pages/message.adoc
@@ -41,4 +41,4 @@ from("direct:startInOut")
.inOut("bean:process");
----
-See xref:to-eip.adoc[to-eip with pattern]
+See xref:eips:to-eip.adoc[to-eip with pattern]
diff --git a/docs/user-manual/modules/ROOT/pages/normalizer.adoc
b/docs/user-manual/modules/ROOT/pages/normalizer.adoc
index abf9333..0678570 100644
--- a/docs/user-manual/modules/ROOT/pages/normalizer.adoc
+++ b/docs/user-manual/modules/ROOT/pages/normalizer.adoc
@@ -10,7 +10,7 @@ but arrive in different formats. The normalizer transforms
the incoming messages
image::eip/NormalizerDetail.gif[image]
-In Apache Camel, you can implement the normalizer pattern by combining a
xref:content-based-router-eip.adoc[Content Based Router],
+In Apache Camel, you can implement the normalizer pattern by combining a
xref:eips:content-based-router-eip.adoc[Content Based Router],
which detects the incoming message's format, with a collection of different
xref:message-translator.adoc[Message Translator]'s,
which transform the different incoming formats into a common format.
diff --git a/docs/user-manual/modules/ROOT/pages/polling-consumer.adoc
b/docs/user-manual/modules/ROOT/pages/polling-consumer.adoc
index fd28244..6af6737 100644
--- a/docs/user-manual/modules/ROOT/pages/polling-consumer.adoc
+++ b/docs/user-manual/modules/ROOT/pages/polling-consumer.adoc
@@ -155,7 +155,7 @@ process the message and send them to the next queue.
Quite a few inbound Camel endpoints use a scheduled poll pattern to
receive messages and push them through the Camel processing routes. That
is to say externally from the client the endpoint appears to use an
-xref:eventDrivenConsumer-eip.adoc[Event Driven Consumer] but internally a
+xref:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer] but internally a
scheduled poll is used to monitor some kind of state or resource and
then fire message exchanges.
diff --git a/docs/user-manual/modules/ROOT/pages/predicate.adoc
b/docs/user-manual/modules/ROOT/pages/predicate.adoc
index 3217415..c9ba4cc 100644
--- a/docs/user-manual/modules/ROOT/pages/predicate.adoc
+++ b/docs/user-manual/modules/ROOT/pages/predicate.adoc
@@ -5,8 +5,8 @@ Camel supports a pluggable interface called
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/Predicate.html[Predicate]
which can be used to integrate a dynamic predicate into
xref:enterprise-integration-patterns.adoc[Enterprise Integration
-Patterns] such as when using the xref:filter-eip.adoc[Message Filter]
-or xref:content-based-router-eip.adoc[Content Based Router].
+Patterns] such as when using the xref:eips:filter-eip.adoc[Message Filter]
+or xref:eips:content-based-router-eip.adoc[Content Based Router].
A Predicate is being evaluated to a boolean value so the result is
either `true` or `false`. This makes xref:predicate.adoc[Predicate] so
diff --git a/docs/user-manual/modules/ROOT/pages/process-manager.adoc
b/docs/user-manual/modules/ROOT/pages/process-manager.adoc
index e22086d..e25376e 100644
--- a/docs/user-manual/modules/ROOT/pages/process-manager.adoc
+++ b/docs/user-manual/modules/ROOT/pages/process-manager.adoc
@@ -5,7 +5,7 @@ Camel supports the
https://www.enterpriseintegrationpatterns.com/patterns/messaging/ProcessManager.html[Process
Manager]
from the xref:enterprise-integration-patterns.adoc[EIP patterns] book.
-The xref:routingSlip-eip.adoc[Routing Slip] demonstrates how a message can be
routed through a dynamic series of processing steps.
+The xref:eips:routingSlip-eip.adoc[Routing Slip] demonstrates how a message
can be routed through a dynamic series of processing steps.
The solution of the Routing Slip is based on two key assumptions: the sequence
of processing steps has
to be determined up-front and the sequence is linear. In many cases, these
assumptions may not be fulfilled.
For example, routing decisions might have to be made based on intermediate
results.
@@ -19,7 +19,7 @@ image::eip/ProcessManager.gif[image]
Use a central processing unit, a Process Manager, to maintain the state of the
sequence and determine
the next processing step based on intermediate results.
-With Camel this pattern is implemented by using the
xref:dynamicRouter-eip.adoc[Dynamic Router] pattern.
+With Camel this pattern is implemented by using the
xref:eips:dynamicRouter-eip.adoc[Dynamic Router] pattern.
Camel's implementation of the dynamic router maintains the state of the
sequence, and allows
to determine the next processing step based dynamically.
diff --git a/docs/user-manual/modules/ROOT/pages/route-policy.adoc
b/docs/user-manual/modules/ROOT/pages/route-policy.adoc
index 3c77f40..3f140eb 100644
--- a/docs/user-manual/modules/ROOT/pages/route-policy.adoc
+++ b/docs/user-manual/modules/ROOT/pages/route-policy.adoc
@@ -87,14 +87,14 @@ again in case it has been suspended.
== ThrottlingInflightRoutePolicy compared to the Throttler EIP
The *`ThrottlingInflightRoutePolicy`* compared to
-xref:throttle-eip.adoc[Throttler] is that it does *not* block during
+xref:eips:throttle-eip.adoc[Throttler] is that it does *not* block during
throttling. It does throttling that is approximate based, meaning that
its more coarse grained and not explicit precise as the
-xref:throttle-eip.adoc[Throttler]. The xref:throttle-eip.adoc[Throttler] can
+xref:eips:throttle-eip.adoc[Throttler]. The
xref:eips:throttle-eip.adoc[Throttler] can
be much more accurate and only allow a specific number of messages being
passed per a given time unit. Also the *`ThrottlingInflightRoutePolicy`*
is based its metrics on number of inflight exchanges where as
-xref:throttle-eip.adoc[Throttler] is based on number of messages per time
+xref:eips:throttle-eip.adoc[Throttler] is based on number of messages per time
unit.
== `ScheduledRoutePolicy` (Simple and Cron based) using camel Quartz
diff --git a/docs/user-manual/modules/ROOT/pages/scatter-gather.adoc
b/docs/user-manual/modules/ROOT/pages/scatter-gather.adoc
index 3c1790f..58a6a1e 100644
--- a/docs/user-manual/modules/ROOT/pages/scatter-gather.adoc
+++ b/docs/user-manual/modules/ROOT/pages/scatter-gather.adoc
@@ -10,8 +10,8 @@ specified recipients and re-aggregate the responses back into
a single message.
image::eip/BroadcastAggregate.gif[image]
-With Camel this pattern is implemented by using the
xref:recipientList-eip.adoc[Recipient List]
-and the xref:aggregate-eip.adoc[Aggregate] patterns.
+With Camel this pattern is implemented by using the
xref:eips:recipientList-eip.adoc[Recipient List]
+and the xref:eips:aggregate-eip.adoc[Aggregate] patterns.
== Sample
diff --git a/docs/user-manual/modules/ROOT/pages/selective-consumer.adoc
b/docs/user-manual/modules/ROOT/pages/selective-consumer.adoc
index a1f8c5f..d193f48 100644
--- a/docs/user-manual/modules/ROOT/pages/selective-consumer.adoc
+++ b/docs/user-manual/modules/ROOT/pages/selective-consumer.adoc
@@ -22,7 +22,7 @@ from("activemq:queue:hello?selector=color='red'")
== Selective Consumer using Filter pattern
-The other approach is to use a xref:filter-eip.adoc[Message Filter] which is
applied;
+The other approach is to use a xref:eips:filter-eip.adoc[Message Filter] which
is applied;
then if the filter matches the message your consumer is invoked as shown in
the following example.
[source,java]
diff --git a/docs/user-manual/modules/ROOT/pages/servlet-tomcat-example.adoc
b/docs/user-manual/modules/ROOT/pages/servlet-tomcat-example.adoc
index db3241c..13a1c23 100644
--- a/docs/user-manual/modules/ROOT/pages/servlet-tomcat-example.adoc
+++ b/docs/user-manual/modules/ROOT/pages/servlet-tomcat-example.adoc
@@ -62,7 +62,7 @@ component.
</web-app>
----
-The route is a simple xref:content-based-router-eip.adoc[Content Based Router]
defined
+The route is a simple xref:eips:content-based-router-eip.adoc[Content Based
Router] defined
in the DSL XML as shown:
[source,xml]
diff --git a/docs/user-manual/modules/ROOT/pages/spring-remoting.adoc
b/docs/user-manual/modules/ROOT/pages/spring-remoting.adoc
index 08123af..bbb330f 100644
--- a/docs/user-manual/modules/ROOT/pages/spring-remoting.adoc
+++ b/docs/user-manual/modules/ROOT/pages/spring-remoting.adoc
@@ -6,7 +6,7 @@ the underlying transport mechanism. The nice thing about this
approach
is we can use any of the Camel transport
xref:components::index.adoc[Components] to communicate between beans.
-It also means we can use xref:content-based-router-eip.adoc[Content Based
+It also means we can use xref:eips:content-based-router-eip.adoc[Content Based
Router] and the other
xref:enterprise-integration-patterns.adoc[Enterprise Integration
Patterns] in between the beans; in particular we can use
@@ -359,7 +359,7 @@ $\{ }.
Any other value is consider to be a type declaration instead - see the
next section about specifying types for overloaded methods.
-When invoking a xref:bean-eip.adoc[Bean] you can instruct Camel to invoke a
+When invoking a xref:eips:bean-eip.adoc[Bean] you can instruct Camel to invoke
a
specific method by providing the method name:
[source,syntaxhighlighter-pre]
@@ -465,7 +465,7 @@ use `.to` instead as shown:
*Since Camel 2.8*
-If you have a xref:bean-eip.adoc[Bean] with overloaded methods, you can now
+If you have a xref:eips:bean-eip.adoc[Bean] with overloaded methods, you can
now
specify parameter types in the method name so Camel can match the method
you intend to use.
diff --git a/docs/user-manual/modules/ROOT/pages/stream-caching.adoc
b/docs/user-manual/modules/ROOT/pages/stream-caching.adoc
index ce69d9f..24852c9 100644
--- a/docs/user-manual/modules/ROOT/pages/stream-caching.adoc
+++ b/docs/user-manual/modules/ROOT/pages/stream-caching.adoc
@@ -13,7 +13,7 @@ Streams are caching in memory. In Camel 2.0, large stream
messages (over 64 KB i
*StreamCache Affects your payload object*
The `StreamCache` will affect your payload object as it will replace the
`Stream` payload with a `org.apache.camel.StreamCache` object.
-This `StreamCache` is capable of being re-readable and thus possible to better
be routed within Camel using redelivery or
xref:content-based-router-eip.adoc[Content Based Router] or the likes.
+This `StreamCache` is capable of being re-readable and thus possible to better
be routed within Camel using redelivery or
xref:eips:content-based-router-eip.adoc[Content Based Router] or the likes.
However to not change the payload under the covers without the end user really
knowing we changed the default in Camel 2.0 to *disabled*. So in Camel 2.0 you
have to explicit enable it if you want to use it.
====
diff --git a/docs/user-manual/modules/ROOT/pages/threading-model.adoc
b/docs/user-manual/modules/ROOT/pages/threading-model.adoc
index 6c5e5cb..32acbe4 100644
--- a/docs/user-manual/modules/ROOT/pages/threading-model.adoc
+++ b/docs/user-manual/modules/ROOT/pages/threading-model.adoc
@@ -29,7 +29,7 @@ default thread pool profile which is:
--------------------------------------------------------------------------------------------------------
What that means is that for example when you use
-xref:multicast-eip.adoc[Multicast] with `parallelProcessing=true` enabled,
+xref:eips:multicast-eip.adoc[Multicast] with `parallelProcessing=true` enabled,
then it would create a thread pool based on the profile above. The
`rejectedPolicy` has four options:
`Abort, CallerRuns, Discard, DiscardOldest` which corresponds to the
@@ -79,7 +79,7 @@ xref:registry.adoc[Registry] for a `ExecutorService` with the
id =
fooProfile. If none found it will fallback and see if there is a
`ThreadPoolProfile` defined with that id. And in this example there is
and so the profile is used for creating a new `ExecutorService` which is
-handed back to the xref:multicast-eip.adoc[Multicast] EIP to use in the
+handed back to the xref:eips:multicast-eip.adoc[Multicast] EIP to use in the
route.
[[ThreadingModel-Createcustomthreadpool]]
diff --git a/docs/user-manual/modules/ROOT/pages/using-propertyplaceholder.adoc
b/docs/user-manual/modules/ROOT/pages/using-propertyplaceholder.adoc
index cc8fabe..54cbe8d 100644
--- a/docs/user-manual/modules/ROOT/pages/using-propertyplaceholder.adoc
+++ b/docs/user-manual/modules/ROOT/pages/using-propertyplaceholder.adoc
@@ -384,7 +384,7 @@ placeholder namespace.
In the example below we use the `prop` prefix for the namespace
`\http://camel.apache.org/schema/placeholder` by which we can use the
`prop` prefix in the attributes in the XML DSLs. Notice how we use
-that in the xref:multicast-eip.adoc[Multicast] to indicate that the option
+that in the xref:eips:multicast-eip.adoc[Multicast] to indicate that the option
`stopOnException` should be the value of the placeholder with the key
`stop`.
diff --git
a/docs/user-manual/modules/ROOT/pages/walk-through-another-example.adoc
b/docs/user-manual/modules/ROOT/pages/walk-through-another-example.adoc
index 951c656..ecc3c86 100644
--- a/docs/user-manual/modules/ROOT/pages/walk-through-another-example.adoc
+++ b/docs/user-manual/modules/ROOT/pages/walk-through-another-example.adoc
@@ -156,7 +156,7 @@ sendConfirmEmai bean
What to notice here is that the `to` is not the end of the route (the
world) in this example it's used in the middle of the
-xref:pipeline-eip.adoc[Pipes and filters]. In fact we can change
+xref:eips:pipeline-eip.adoc[Pipes and filters]. In fact we can change
the `bean` types to `to` as well:
[source,syntaxhighlighter-pre]
diff --git a/docs/user-manual/modules/ROOT/pages/writing-components.adoc
b/docs/user-manual/modules/ROOT/pages/writing-components.adoc
index 333ccc8..9cca6df 100644
--- a/docs/user-manual/modules/ROOT/pages/writing-components.adoc
+++ b/docs/user-manual/modules/ROOT/pages/writing-components.adoc
@@ -27,7 +27,7 @@ When implementing an xref:endpoint.adoc[Endpoint] you
typically may
implement one or more of the following methods:
* `createProducer` will create a producer for sending message exchanges to the
endpoint
-* `createConsumer` implements the xref:eventDrivenConsumer-eip.adoc[Event
Driven Consumer]
+* `createConsumer` implements the xref:eips:eventDrivenConsumer-eip.adoc[Event
Driven Consumer]
pattern for consuming message exchanges from the endpoint.
Typically you just derive from `DefaultEndpoint`
