This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/master by this push:
new e1cff9a CAMEL-15302: Remove duplicate pages under eip section (#4019)
e1cff9a is described below
commit e1cff9a72f648cd80349f05387a85384eb6051f8
Author: Aemie Jariwala <44139348+aem...@users.noreply.github.com>
AuthorDate: Mon Jul 20 13:27:54 2020 +0530
CAMEL-15302: Remove duplicate pages under eip section (#4019)
* CAMEL-15302: Remove duplicate pages under eip section
* CAMEL-15302: remove false links from docs pages
Add some further docs
---
.../src/main/docs/language-component.adoc | 2 +-
.../src/main/docs/modules/eips/nav.adoc | 2 -
.../docs/modules/eips/pages/content-enricher.adoc | 2 +-
.../docs/modules/eips/pages/dynamic-router.adoc | 198 ---------------------
.../docs/modules/eips/pages/dynamicRouter-eip.adoc | 91 +++++++---
.../pages/enterprise-integration-patterns.adoc | 2 +-
.../docs/modules/eips/pages/event-message.adoc | 2 +-
.../src/main/docs/modules/eips/pages/message.adoc | 4 +-
.../docs/modules/eips/pages/request-reply.adoc | 44 -----
.../docs/modules/eips/pages/requestReply-eip.adoc | 1 +
.../modules/ROOT/pages/language-component.adoc | 2 +-
.../modules/ROOT/pages/bean-integration.adoc | 2 +-
.../modules/ROOT/pages/spring-remoting.adoc | 2 +-
.../pages/using-exchange-pattern-annotations.adoc | 2 +-
.../using-getin-or-getout-methods-on-exchange.adoc | 2 +-
15 files changed, 77 insertions(+), 281 deletions(-)
diff --git a/components/camel-language/src/main/docs/language-component.adoc
b/components/camel-language/src/main/docs/language-component.adoc
index 4dc02ef..b56a577 100644
--- a/components/camel-language/src/main/docs/language-component.adoc
+++ b/components/camel-language/src/main/docs/language-component.adoc
@@ -17,7 +17,7 @@ to an endpoint which executes a script by any of the supported
Languages in Camel. +
By having a component to execute language scripts, it allows more
dynamic routing capabilities. For example by using the
-Routing Slip or xref:{eip-vc}:eips:dynamic-router.adoc[Dynamic
+Routing Slip or xref:{eip-vc}:eips:dynamicRouter-eip.adoc[Dynamic
Router] EIPs you can send messages to `language` endpoints where the
script is dynamic defined as well.
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/nav.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/nav.adoc
index 54ad1c9..7471262 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/nav.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/nav.adoc
@@ -21,7 +21,6 @@
** xref:eips:dead-letter-channel.adoc[Dead Letter Channel]
** xref:eips:delay-eip.adoc[Delay]
** xref:eips:durable-subscriber.adoc[Durable Subscriber]
- ** xref:eips:dynamic-router.adoc[Dynamic Router]
** xref:eips:dynamicRouter-eip.adoc[Dynamic Router]
** xref:eips:enrich-eip.adoc[Enrich]
** xref:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer]
@@ -72,7 +71,6 @@
** xref:eips:removeHeaders-eip.adoc[Remove Headers]
** xref:eips:removeProperties-eip.adoc[Remove Properties]
** xref:eips:removeProperty-eip.adoc[Remove Property]
- ** xref:eips:request-reply.adoc[Request Reply]
** xref:eips:requestReply-eip.adoc[Request Reply]
** xref:eips:resequence-eip.adoc[Resequence]
** xref:eips:resilience4jConfiguration-eip.adoc[Resilience4j Configuration]
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/content-enricher.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/content-enricher.adoc
index 2221ae9..fe31423 100644
---
a/core/camel-core-engine/src/main/docs/modules/eips/pages/content-enricher.adoc
+++
b/core/camel-core-engine/src/main/docs/modules/eips/pages/content-enricher.adoc
@@ -101,7 +101,7 @@ Camel comes with two flavors of content enricher in the DSL
* `pollEnrich`
`enrich` uses a `Producer` to obtain the additional data. It is usually
-used for xref:request-reply.adoc[Request Reply] messaging, for instance
+used for xref:requestReply-eip.adoc[Request Reply] messaging, for instance
to invoke an external web service. +
`pollEnrich` on the other hand uses a xref:polling-consumer.adoc[Polling
Consumer] to obtain the additional data. It is usually used for
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/dynamic-router.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/dynamic-router.adoc
deleted file mode 100644
index 6bd839f..0000000
---
a/core/camel-core-engine/src/main/docs/modules/eips/pages/dynamic-router.adoc
+++ /dev/null
@@ -1,198 +0,0 @@
-[[DynamicRouter-DynamicRouter]]
-= Dynamic Router
-
-The
-http://www.enterpriseintegrationpatterns.com/DynamicRouter.html[Dynamic
-Router] from the 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]
-
-The `dynamicRouter` in the DSL is similar to
-a dynamic Routing Slip which evaluates the slip
-_on-the-fly_.
-
-WARNING: *Beware*
-You must ensure the expression used for the `dynamicRouter` such as a
-bean, will return `null` to indicate the end. Otherwise the
-`dynamicRouter` will keep repeating endlessly.
-
-[[DynamicRouter-DynamicRouterinCamel2.5onwards]]
-== Dynamic Router in Camel 2.5 onwards
-
-The Dynamic Router will set a
-property (Exchange.SLIP_ENDPOINT) on the Exchange
-which contains the current endpoint as it advanced though the slip. This
-allows you to know how far we have processed in the slip. (It's a slip
-because the Dynamic Router implementation is
-based on top of Routing Slip).
-
-TIP: See the `cacheSize` option for more details on _how much cache_ to use
depending on how many or few unique endpoints are used.
-
-== Options
-
-// eip options: START
-The Dynamic Router EIP supports 3 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *uriDelimiter* | Sets the uri delimiter to use | , | String
-| *ignoreInvalidEndpoints* | Ignore the invalidate endpoint exception when try
to create a producer with that endpoint | false | Boolean
-| *cacheSize* | Sets the maximum size used by the
org.apache.camel.spi.ProducerCache which is used to cache and reuse producers
when using this routing slip, when uris are reused. Beware that when using
dynamic endpoints then it affects how well the cache can be utilized. If each
dynamic endpoint is unique then its best to turn of caching by setting this to
-1, which allows Camel to not cache both the producers and endpoints; they are
regarded as prototype scoped and will be stopped and [...]
-|===
-// eip options: END
-
-[[DynamicRouter-JavaDSL]]
-== Java DSL
-
-In Java DSL you can use the `dynamicRouter` as shown below:
-
-[source,java]
-----
-from("direct:start")
- // use a bean as the dynamic router
- .dynamicRouter(method(DynamicRouterTest.class, "slip"));
-----
-
-Which will leverage a xref:components::bean-component.adoc[Bean] to compute
the slip
-_on-the-fly_, which could be implemented as follows:
-
-[source,java]
-----
-/**
- * Use this method to compute dynamic where we should route next.
- *
- * @param body the message body
- * @return endpoints to go, or <tt>null</tt> to indicate the end
- */
-public String slip(String body) {
- bodies.add(body);
- invoked++;
-
- if (invoked == 1) {
- return "mock:a";
- } else if (invoked == 2) {
- return "mock:b,mock:c";
- } else if (invoked == 3) {
- return "direct:foo";
- } else if (invoked == 4) {
- return "mock:result";
- }
-
- // no more so return null
- return null;
-}
-----
-
-Mind that this example is only for show and tell. The current
-implementation is not thread safe. You would have to store the state on
-the Exchange, to ensure thread safety, as shown
-below:
-
-[source,java]
-----
-/**
- * Use this method to compute dynamic where we should route next.
- *
- * @param body the message body
- * @param properties the exchange properties where we can store state between
invocations
- * @return endpoints to go, or <tt>null</tt> to indicate the end
- */
-public String slip(String body, @Properties Map<String, Object> properties) {
- bodies.add(body);
-
- // get the state from the exchange properties and keep track how many times
- // we have been invoked
- int invoked = 0;
- Object current = properties.get("invoked");
- if (current != null) {
- invoked = Integer.valueOf(current.toString());
- }
- invoked++;
- // and store the state back on the properties
- properties.put("invoked", invoked);
-
- if (invoked == 1) {
- return "mock:a";
- } else if (invoked == 2) {
- return "mock:b,mock:c";
- } else if (invoked == 3) {
- return "direct:foo";
- } else if (invoked == 4) {
- return "mock:result";
- }
-
- // no more so return null
- return null;
-}
-----
-
-You could also store state as message headers, but they are not
-guaranteed to be preserved during routing, where as properties on the
-Exchange are. Although there was a bug in the method
-call expression, see the warning below.
-
-[[DynamicRouter-SpringXML]]
-== Spring XML
-
-The same example in Spring XML would be:
-
-[source,xml]
-----
-<bean id="mySlip" class="org.apache.camel.processor.DynamicRouterTest"/>
-
-<camelContext xmlns="http://camel.apache.org/schema/spring";>
- <route>
- <from uri="direct:start"/>
- <dynamicRouter>
- <!-- use a method call on a bean as dynamic router -->
- <method ref="mySlip" method="slip"/>
- </dynamicRouter>
- </route>
-
- <route>
- <from uri="direct:foo"/>
- <transform><constant>Bye World</constant></transform>
- </route>
-
-</camelContext>
-----
-
-[[DynamicRouter-DynamicRouterannotation]]
-== @DynamicRouter annotation
-
-You can also use the `@DynamicRouter` annotation. The `route` method would
-then be invoked repeatedly as the message is processed dynamically. The
-idea is to return the next endpoint uri where to go. Return `null` to
-indicate the end. You can return multiple endpoints if you like, just as
-the Routing Slip, where each endpoint is
-separated by a delimiter.
-
-[source,java]
-----
-public class MyDynamicRouter {
-
- @Consume(uri = "activemq:foo")
- @DynamicRouter
- public String route(@XPath("/customer/id") String customerId,
@Header("Location") String location, Document body) {
- // query a database to find the best match of the endpoint based on
the input parameteres
- // return the next endpoint uri, where to go. Return null to indicate
the end.
- }
-}
-----
-
-In the above we can use the
-Parameter Binding Annotations
-to bind different parts of the Message to method
-parameters or use an Expression such as using
-xref:components:languages:xpath-language.adoc[XPath] or
xref:components:languages:xpath-language.adoc[XQuery].
-
-The method can be invoked in a number of ways as described in the
-Bean Integration such as
-
-* POJO Producing
-* Spring Remoting
-* xref:components::bean-component.adoc[Bean] component
-
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 cf3264e..c404f5f 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
@@ -5,7 +5,11 @@
:since:
:supportLevel: Stable
-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 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]
@@ -13,11 +17,20 @@ The `dynamicRouter` in the DSL is similar to
a dynamic Routing Slip which evaluates the slip
_on-the-fly_.
-[IMPORTANT]
-.Avoid endless looping
-===
-You must ensure the expression used for the `dynamicRouter` such as a bean,
will return `null` to indicate the end. Otherwise the `dynamicRouter` will keep
repeating endlessly.
-===
+WARNING: *Beware*
+You must ensure the expression used for the `dynamicRouter` such as a
+bean, will return `null` to indicate the end. Otherwise the
+`dynamicRouter` will keep repeating endlessly.
+
+[[DynamicRouter-DynamicRouterinCamel2.5onwards]]
+== Dynamic Router in Camel 2.5 onwards
+
+The Dynamic Router will set a
+property (Exchange.SLIP_ENDPOINT) on the Exchange
+which contains the current endpoint as it advanced though the slip. This
+allows you to know how far we have processed in the slip. (It's a slip
+because the Dynamic Router implementation is
+based on top of Routing Slip).
TIP: See the `cacheSize` option for more details on _how much cache_ to use
depending on how many or few unique endpoints are used.
@@ -30,15 +43,13 @@ The Dynamic Router EIP supports 3 options which are listed
below:
|===
| Name | Description | Default | Type
| *uriDelimiter* | Sets the uri delimiter to use | , | String
-| *ignoreInvalidEndpoints* | Ignore the invalidate endpoint exception when try
to create a producer with that endpoint | | String
-| *cacheSize* | Sets the maximum size used by the
org.apache.camel.spi.ProducerCache which is used to cache and reuse producers
when using this dynamic router, when uris are reused. Beware that when using
dynamic endpoints then it affects how well the cache can be utilized. If each
dynamic endpoint is unique then its best to turn of caching by setting this to
-1, which allows Camel to not cache both the producers and endpoints; they are
regarded as prototype scoped and will be stopped an [...]
+| *ignoreInvalidEndpoints* | Ignore the invalidate endpoint exception when try
to create a producer with that endpoint | false | Boolean
+| *cacheSize* | Sets the maximum size used by the
org.apache.camel.spi.ProducerCache which is used to cache and reuse producers
when using this routing slip, when uris are reused. Beware that when using
dynamic endpoints then it affects how well the cache can be utilized. If each
dynamic endpoint is unique then its best to turn of caching by setting this to
-1, which allows Camel to not cache both the producers and endpoints; they are
regarded as prototype scoped and will be stopped and [...]
|===
// eip options: END
-The Dynamic Router will set the property `Exchange.SLIP_ENDPOINT` on the
Exchange which contains the current endpoint as it advanced though the slip.
This allows you to know how far we have processed in the slip.
-(It's a slip because the Dynamic Router implementation is based on top of
Routing Slip).
-
-== Samples
+[[DynamicRouter-JavaDSL]]
+== Java DSL
In Java DSL you can use the `dynamicRouter` as shown below:
@@ -49,7 +60,8 @@ from("direct:start")
.dynamicRouter(method(DynamicRouterTest.class, "slip"));
----
-Which will leverage a Bean to compute the slip _on-the-fly_, which could be
implemented as follows:
+Which will leverage a xref:components::bean-component.adoc[Bean] to compute
the slip
+_on-the-fly_, which could be implemented as follows:
[source,java]
----
@@ -62,7 +74,7 @@ Which will leverage a Bean to compute the slip _on-the-fly_,
which could be impl
public String slip(String body) {
bodies.add(body);
invoked++;
-
+
if (invoked == 1) {
return "mock:a";
} else if (invoked == 2) {
@@ -72,13 +84,16 @@ public String slip(String body) {
} else if (invoked == 4) {
return "mock:result";
}
-
+
// no more so return null
return null;
}
----
-Mind that this example is only for show and tell. The current implementation
is not thread safe. You would have to store the state on the Exchange, to
ensure thread safety, as shown below:
+Mind that this example is only for show and tell. The current
+implementation is not thread safe. You would have to store the state on
+the Exchange, to ensure thread safety, as shown
+below:
[source,java]
----
@@ -91,7 +106,7 @@ Mind that this example is only for show and tell. The
current implementation is
*/
public String slip(String body, @Properties Map<String, Object> properties) {
bodies.add(body);
-
+
// get the state from the exchange properties and keep track how many times
// we have been invoked
int invoked = 0;
@@ -102,7 +117,7 @@ public String slip(String body, @Properties Map<String,
Object> properties) {
invoked++;
// and store the state back on the properties
properties.put("invoked", invoked);
-
+
if (invoked == 1) {
return "mock:a";
} else if (invoked == 2) {
@@ -112,21 +127,26 @@ public String slip(String body, @Properties Map<String,
Object> properties) {
} else if (invoked == 4) {
return "mock:result";
}
-
+
// no more so return null
return null;
}
----
-You could also store state as message headers, but they are not guaranteed to
be preserved during routing, where as properties on the Exchange are. Although
there was a bug in the method call expression, see the warning below.
+You could also store state as message headers, but they are not
+guaranteed to be preserved during routing, where as properties on the
+Exchange are. Although there was a bug in the method
+call expression, see the warning below.
+
+[[DynamicRouter-SpringXML]]
+== Spring XML
-=== Spring XML
The same example in Spring XML would be:
[source,xml]
----
<bean id="mySlip" class="org.apache.camel.processor.DynamicRouterTest"/>
-
+
<camelContext xmlns="http://camel.apache.org/schema/spring";>
<route>
<from uri="direct:start"/>
@@ -135,18 +155,24 @@ The same example in Spring XML would be:
<method ref="mySlip" method="slip"/>
</dynamicRouter>
</route>
-
+
<route>
<from uri="direct:foo"/>
<transform><constant>Bye World</constant></transform>
</route>
-
+
</camelContext>
----
+[[DynamicRouter-DynamicRouterannotation]]
== @DynamicRouter annotation
-You can also use the `@DynamicRouter` annotation. The `route` method would
then be invoked repeatedly as the message is processed dynamically.
-The idea is to return the next endpoint uri where to go. Return `null` to
indicate the end. You can return multiple endpoints if you like, just as the
Routing Slip, where each endpoint is separated by a delimiter.
+
+You can also use the `@DynamicRouter` annotation. The `route` method would
+then be invoked repeatedly as the message is processed dynamically. The
+idea is to return the next endpoint uri where to go. Return `null` to
+indicate the end. You can return multiple endpoints if you like, just as
+the Routing Slip, where each endpoint is
+separated by a delimiter.
[source,java]
----
@@ -160,3 +186,16 @@ public class MyDynamicRouter {
}
}
----
+
+In the above we can use the
+Parameter Binding Annotations
+to bind different parts of the Message to method
+parameters or use an Expression such as using
+xref:components:languages:xpath-language.adoc[XPath] or
xref:components:languages:xpath-language.adoc[XQuery].
+
+The method can be invoked in a number of ways as described in the
+Bean Integration such as
+
+* POJO Producing
+* Spring Remoting
+* xref:components::bean-component.adoc[Bean] component
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/enterprise-integration-patterns.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/enterprise-integration-patterns.adoc
index ea10721..98b3279 100644
---
a/core/camel-core-engine/src/main/docs/modules/eips/pages/enterprise-integration-patterns.adoc
+++
b/core/camel-core-engine/src/main/docs/modules/eips/pages/enterprise-integration-patterns.adoc
@@ -92,7 +92,7 @@ a|image::eip/EventMessageIcon.gif[image]
transmit events from one application to another?
a|image::eip/RequestReplyIcon.gif[image]
-|xref:request-reply.adoc[Request Reply] |When an application sends a
+|xref:requestReply-eip.adoc[Request Reply] |When an application sends a
message, how can it get a response from the receiver?
a|image::eip/ReturnAddressIcon.gif[image]
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/event-message.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/event-message.adoc
index ba25e1b..bdbb468 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/event-message.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/event-message.adoc
@@ -15,7 +15,7 @@ The default behaviour of many
xref:components::index.adoc[Components] is InOnly
such as for xref:components::jms-component.adoc[JMS],
xref:components::jms-component.adoc[File] or
xref:components::seda-component.adoc[SEDA]
-TIP: See the related xref:request-reply.adoc[Request Reply] message.
+TIP: See the related xref:requestReply-eip.adoc[Request Reply] message.
[[eventMessage-ExplicitlyspecifyingInOnly]]
== Explicitly specifying InOnly
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/message.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/message.adoc
index 6837faa..737ec05 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/message.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/message.adoc
@@ -11,11 +11,11 @@ image::eip/MessageSolution.gif[image]
To support various message
xref:latest@manual:ROOT:exchange-pattern.adoc[exchange patterns]
like one way xref:event-message.adoc[Event Message] and
-xref:request-reply.adoc[Request Reply] messages Camel uses an
+xref:requestReply-eip.adoc[Request Reply] messages Camel uses an
xref:latest@manual:ROOT:exchange.adoc[Exchange] interface which has a
*pattern* property
which can be set to *InOnly* for an xref:event-message.adoc[Event
Message] which has a single inbound Message, or *InOut* for a
-xref:request-reply.adoc[Request Reply] where there is an inbound and
+xref:requestReply-eip.adoc[Request Reply] where there is an inbound and
outbound message.
Here is a basic example of sending a Message to a route in *InOnly* and
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/request-reply.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/request-reply.adoc
deleted file mode 100644
index 907a9f2..0000000
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/request-reply.adoc
+++ /dev/null
@@ -1,44 +0,0 @@
-[[request-reply]]
-= Request Reply
-:page-source: core/camel-core-engine/src/main/docs/eips/request-reply.adoc
-
-Camel supports the
-http://www.enterpriseintegrationpatterns.com/RequestReply.html[Request
-Reply] from the EIP patterns
-by supporting the Exchange Pattern on a
-Message which can be set to *InOut* to indicate a
-request/reply. Camel Components then implement
-this pattern using the underlying transport or protocols.
-
-image::eip/RequestReply.gif[image]
-
-For example when using xref:components::jms-component.adoc[JMS] with InOut the
component will
-by default perform these actions
-
-* create by default a temporary inbound queue
-* set the JMSReplyTo destination on the request message
-* set the JMSCorrelationID on the request message
-* send the request message
-* consume the response and associate the inbound message to the request
-using the JMSCorrelationID (as you may be performing many concurrent
-request/responses).
-
-TIP: *Related* See the related Event Message message
-
-[[RequestReply-ExplicitlyspecifyingInOut]]
-== Explicitly specifying InOut
-
-When consuming messages from xref:components::jms-component.adoc[JMS] a
Request-Reply is
-indicated by the presence of the *JMSReplyTo* header.
-
-You can explicitly force an endpoint to be in Request Reply mode by
-setting the exchange pattern on the URI. e.g.
-
-[source,text]
-----
-jms:MyQueue?exchangePattern=InOut
-----
-
-You can specify the exchange pattern in DSL rule or Spring
-configuration.
-
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc
index 9a96feb..191881d 100644
---
a/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc
+++
b/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc
@@ -1,5 +1,6 @@
[[requestReply-eip]]
= Request Reply
+:page-source: core/camel-core-engine/src/main/docs/eips/requestreply-eip.adoc
Camel supports the
http://www.enterpriseintegrationpatterns.com/RequestReply.html[Request
diff --git a/docs/components/modules/ROOT/pages/language-component.adoc
b/docs/components/modules/ROOT/pages/language-component.adoc
index 0f8a672..347ca2a 100644
--- a/docs/components/modules/ROOT/pages/language-component.adoc
+++ b/docs/components/modules/ROOT/pages/language-component.adoc
@@ -19,7 +19,7 @@ to an endpoint which executes a script by any of the supported
Languages in Camel. +
By having a component to execute language scripts, it allows more
dynamic routing capabilities. For example by using the
-Routing Slip or xref:{eip-vc}:eips:dynamic-router.adoc[Dynamic
+Routing Slip or xref:{eip-vc}:eips:dynamicRouter-eip.adoc[Dynamic
Router] EIPs you can send messages to `language` endpoints where the
script is dynamic defined as well.
diff --git a/docs/user-manual/modules/ROOT/pages/bean-integration.adoc
b/docs/user-manual/modules/ROOT/pages/bean-integration.adoc
index f40ac26..551b20c 100644
--- a/docs/user-manual/modules/ROOT/pages/bean-integration.adoc
+++ b/docs/user-manual/modules/ROOT/pages/bean-integration.adoc
@@ -32,7 +32,7 @@ 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:{eip-vc}:eips:dynamic-router.adoc[Dynamic Router] from a POJO method
+* `@DynamicRouter` Annotation for creating a
xref:{eip-vc}:eips:dynamicRouter-eip.adoc[Dynamic Router] from a POJO method
* `@RecipientList` Annotation for creating a
xref:{eip-vc}:eips:recipientList-eip.adoc[Recipient List] from a POJO method
* `@RoutingSlip` Annotation for creating a
xref:{eip-vc}:eips:routingSlip-eip.adoc[Routing Slip] for a POJO method
* xref:bean-injection.adoc[Bean Injection] to inject Camel related resources
into your POJOs
diff --git a/docs/user-manual/modules/ROOT/pages/spring-remoting.adoc
b/docs/user-manual/modules/ROOT/pages/spring-remoting.adoc
index de20c21..23cb023 100644
--- a/docs/user-manual/modules/ROOT/pages/spring-remoting.adoc
+++ b/docs/user-manual/modules/ROOT/pages/spring-remoting.adoc
@@ -112,7 +112,7 @@ serviceInterface.
== Working with InOnly method calls
As of 1.5 Camel supports the @InOnly and @Pattern annotations to let you
-specify which methods are not InOut
(xref:{eip-vc}:eips:request-reply.adoc[Request
+specify which methods are not InOut
(xref:{eip-vc}:eips:requestReply-eip.adoc[Request
Reply]) but are InOnly (oneway or fire and forget
xref:{eip-vc}:eips:event-message.adoc[Event Message]).
diff --git
a/docs/user-manual/modules/ROOT/pages/using-exchange-pattern-annotations.adoc
b/docs/user-manual/modules/ROOT/pages/using-exchange-pattern-annotations.adoc
index 26be3b3..44abd03 100644
---
a/docs/user-manual/modules/ROOT/pages/using-exchange-pattern-annotations.adoc
+++
b/docs/user-manual/modules/ROOT/pages/using-exchange-pattern-annotations.adoc
@@ -3,7 +3,7 @@
When working with xref:pojo-producing.adoc[POJO Producing] or
xref:spring-remoting.adoc[Spring Remoting] you invoke methods which
-typically by default are InOut for
xref:{eip-vc}:eips:request-reply.adoc[Request
+typically by default are InOut for
xref:{eip-vc}:eips:requestReply-eip.adoc[Request
Reply]. That is there is an In message and an Out for the result.
Typically invoking this operation will be synchronous, the caller will
block until the server returns a result.
diff --git
a/docs/user-manual/modules/faq/pages/using-getin-or-getout-methods-on-exchange.adoc
b/docs/user-manual/modules/faq/pages/using-getin-or-getout-methods-on-exchange.adoc
index 03a99d7..7a496d4 100644
---
a/docs/user-manual/modules/faq/pages/using-getin-or-getout-methods-on-exchange.adoc
+++
b/docs/user-manual/modules/faq/pages/using-getin-or-getout-methods-on-exchange.adoc
@@ -8,7 +8,7 @@ called Message Exchange Patterns (MEP for short).
The MEP defines the messaging style used such as one-way
(xref:{eip-vc}:eips:event-message.adoc[InOnly]) or request-reply
-(xref:{eip-vc}:eips:request-reply.adoc[InOut]),
+(xref:{eip-vc}:eips:requestReply-eip.adoc[InOut]),
which means you have IN and optionally OUT messages. This closely maps
to other APIs such as WS, WSDL, REST, JBI and the likes.
