This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new 04446d9 [CAMEL-16992] Adjust so user-manual links to latest released
version of components. Eliminate eip-vc. Fix in-component user-manual xrefs.
04446d9 is described below
commit 04446d93d368e10e3a71992cd3fae04eeac134bd
Author: David Jencks <djen...@apache.org>
AuthorDate: Wed Sep 22 14:03:35 2021 -0700
[CAMEL-16992] Adjust so user-manual links to latest released version of
components.
Eliminate eip-vc.
Fix in-component user-manual xrefs.
---
docs/user-manual/antora.yml | 2 +-
docs/user-manual/modules/ROOT/nav.adoc | 4 ++--
...configuration-of-camelcontext-using-spring.adoc | 6 +++---
.../modules/ROOT/pages/advice-with.adoc | 12 +++++------
.../modules/ROOT/pages/architecture.adoc | 2 +-
.../modules/ROOT/pages/batch-consumer.adoc | 2 +-
.../modules/ROOT/pages/bean-binding.adoc | 12 +++++------
.../modules/ROOT/pages/bean-integration.adoc | 8 ++++----
.../ROOT/pages/camel-3x-upgrade-guide-3_1.adoc | 2 +-
.../ROOT/pages/camelcontext-autoconfigure.adoc | 4 ++--
docs/user-manual/modules/ROOT/pages/component.adoc | 6 +++---
.../modules/ROOT/pages/data-format.adoc | 6 +++---
.../modules/ROOT/pages/defaulterrorhandler.adoc | 4 ++--
docs/user-manual/modules/ROOT/pages/dsl.adoc | 2 +-
docs/user-manual/modules/ROOT/pages/endpoint.adoc | 6 +++---
.../modules/ROOT/pages/error-handler.adoc | 8 ++++----
docs/user-manual/modules/ROOT/pages/examples.adoc | 2 +-
.../modules/ROOT/pages/exception-clause.adoc | 18 ++++++++--------
.../modules/ROOT/pages/exchange-pattern.adoc | 10 ++++-----
docs/user-manual/modules/ROOT/pages/exchange.adoc | 8 ++++----
.../user-manual/modules/ROOT/pages/expression.adoc | 6 +++---
.../modules/ROOT/pages/getting-started.adoc | 2 +-
.../modules/ROOT/pages/http-session-handling.adoc | 2 +-
docs/user-manual/modules/ROOT/pages/index.adoc | 6 +++---
docs/user-manual/modules/ROOT/pages/java-dsl.adoc | 2 +-
docs/user-manual/modules/ROOT/pages/jmx.adoc | 2 +-
docs/user-manual/modules/ROOT/pages/json.adoc | 2 +-
docs/user-manual/modules/ROOT/pages/languages.adoc | 4 ++--
.../ROOT/pages/parameter-binding-annotations.adoc | 4 ++--
.../modules/ROOT/pages/pojo-consuming.adoc | 2 +-
.../modules/ROOT/pages/pojo-producing.adoc | 4 ++--
docs/user-manual/modules/ROOT/pages/predicate.adoc | 8 ++++----
docs/user-manual/modules/ROOT/pages/processor.adoc | 2 +-
.../modules/ROOT/pages/producertemplate.adoc | 4 ++--
docs/user-manual/modules/ROOT/pages/rest-dsl.adoc | 4 ++--
.../modules/ROOT/pages/route-configuration.adoc | 2 +-
.../modules/ROOT/pages/route-policy.adoc | 8 ++++----
docs/user-manual/modules/ROOT/pages/spring.adoc | 2 +-
.../modules/ROOT/pages/stream-caching.adoc | 2 +-
.../modules/ROOT/pages/threading-model.adoc | 8 ++++----
.../pages/using-exchange-pattern-annotations.adoc | 4 ++--
.../ROOT/pages/using-propertyplaceholder.adoc | 2 +-
.../ROOT/pages/walk-through-another-example.adoc | 4 ++--
.../modules/ROOT/pages/writing-components.adoc | 2 +-
docs/user-manual/modules/ROOT/references.adoc | 8 ++++----
...en-consuming-for-example-from-a-ftp-server.adoc | 2 +-
...ow-do-i-make-my-jms-endpoint-transactional.adoc | 2 +-
.../how-do-i-retry-failed-messages-forever.adoc | 2 +-
...om-processor-which-sends-multiple-messages.adoc | 4 ++--
...end-the-same-message-to-multiple-endpoints.adoc | 8 ++++----
.../faq/pages/how-to-use-a-dynamic-uri-in-to.adoc | 2 +-
.../using-getin-or-getout-methods-on-exchange.adoc | 8 ++++----
.../modules/faq/pages/what-is-a-router.adoc | 12 +++++------
.../modules/faq/pages/what-is-camel.adoc | 2 +-
...se-when-or-otherwise-in-a-java-camel-route.adoc | 24 +++++++++++-----------
...ge-with-error-handler-not-work-as-expected.adoc | 12 +++++------
56 files changed, 149 insertions(+), 149 deletions(-)
diff --git a/docs/user-manual/antora.yml b/docs/user-manual/antora.yml
index 39c3268..c93e006 100644
--- a/docs/user-manual/antora.yml
+++ b/docs/user-manual/antora.yml
@@ -25,4 +25,4 @@ nav:
asciidoc:
attributes:
- eip-vc: latest@components
+ eip-vc: components
diff --git a/docs/user-manual/modules/ROOT/nav.adoc
b/docs/user-manual/modules/ROOT/nav.adoc
index f890e2a..09371a7 100644
--- a/docs/user-manual/modules/ROOT/nav.adoc
+++ b/docs/user-manual/modules/ROOT/nav.adoc
@@ -56,9 +56,9 @@
** xref:exchange-pattern.adoc[Exchange Pattern]
** xref:using-exchange-pattern-annotations.adoc[Using Exchange pattern
annotations]
** xref:expression.adoc[Expressions]
-** xref:{eip-vc}:eips:content-enricher.adoc[Content Enrichment]
+** xref:components:eips:content-enricher.adoc[Content Enrichment]
** xref:injector.adoc[Injector]
-** xref:{eip-vc}:eips:intercept.adoc[Intercept]
+** xref:components:eips:intercept.adoc[Intercept]
** xref:jmx.adoc[JMX]
** xref:lifecycle.adoc[Camel Lifecycle]
** xref:oncompletion.adoc[OnCompletion]
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 eeb4d30..690694f 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
@@ -38,7 +38,7 @@ tooling.
|TraceFormatter |0..1 |To use a bean that has the tracing options
configured.
-|Delayer |0..1 |To use a 3rd part xref:{eip-vc}:eips:delay-eip.adoc[Delayer].
+|Delayer |0..1 |To use a 3rd part xref:components:eips:delay-eip.adoc[Delayer].
|ManagementStrategy |0..1 |To use a 3rd part strategy for
xref:jmx.adoc[management], for example JMX management.
@@ -86,7 +86,7 @@ xref:stream-caching.adoc[Stream caching] strategy.
RuntimeEndpointRegistry implementation.
|Logger |0..1 |To use provided org.slf4j.Logger
-for xref:components::log-component.adoc[Log] component and
xref:{eip-vc}:eips:log-eip.adoc[log() EIP].
+for xref:components::log-component.adoc[Log] component and
xref:components:eips:log-eip.adoc[log() EIP].
|AsyncProcessorAwaitManager |0..1 |To use a 3rd part async
process await manager.
@@ -103,7 +103,7 @@ And the following options have support for any number of
beans defined.
[width="100%",cols="34%,33%,33%",options="header",]
|=======================================================================
|Type |Number of beans |Description
-|InterceptStrategy |0..n |To use your own
xref:{eip-vc}:eips:intercept.adoc[Intercept]
+|InterceptStrategy |0..n |To use your own
xref:components:eips:intercept.adoc[Intercept]
that intercepts every processing steps in all routes in the
xref:camelcontext.adoc[CamelContext]. For instance you can use this to
do an AOP like performance timer interceptor.
diff --git a/docs/user-manual/modules/ROOT/pages/advice-with.adoc
b/docs/user-manual/modules/ROOT/pages/advice-with.adoc
index b2ce3dc..ba0a6c09 100644
--- a/docs/user-manual/modules/ROOT/pages/advice-with.adoc
+++ b/docs/user-manual/modules/ROOT/pages/advice-with.adoc
@@ -35,7 +35,7 @@ the most commonly used methods:
=== Pattern matching
-The pattern option is used for matching. It uses the same rules as
xref:{eip-vc}:eips:intercept.adoc[Intercept], which is applied in the following
order:
+The pattern option is used for matching. It uses the same rules as
xref:components:eips:intercept.adoc[Intercept], which is applied in the
following order:
* match exact
* match by wildcard (`*`)
@@ -325,7 +325,7 @@ That means the message being sent after mock:bar would have
been transformed to
When weaving a route, you need to use one of the `weaveBy` methods
as criteria to select one or more nodes in the route graph.
-Suppose you use the xref:{eip-vc}:eips:split-eip.adoc[Split] EIP in a route;
then you can use `weaveByType` to select this EIP.
+Suppose you use the xref:components:eips:split-eip.adoc[Split] EIP in a route;
then you can use `weaveByType` to select this EIP.
Given the following route:
[source,java]
@@ -338,7 +338,7 @@ from("file:inbox").routeId("inbox")
.to("mock:combined");
----
-Due to that route has only one xref:{eip-vc}:eips:split-eip.adoc[Split] EIP,
you can use `weaveByType` to find this single
+Due to that route has only one xref:components:eips:split-eip.adoc[Split] EIP,
you can use `weaveByType` to find this single
splitter in the route. Using `weaveByType` requires you to pass in the model
type of
the EIP. The name of the model type is using the pattern _name_Definition.
@@ -349,7 +349,7 @@ weaveByType(SplitDefinition.class)
.transform(simple("${body},Camel is awesome"));
----
-Here we weave and select the xref:{eip-vc}:eips:split-eip.adoc[Split] EIP and
weave in a message transformation, that
+Here we weave and select the xref:components:eips:split-eip.adoc[Split] EIP
and weave in a message transformation, that
is processed before calling the splitter. This means the message body is
appended with _Camel is awesome_.
=== weaveByToUri
@@ -357,7 +357,7 @@ is processed before calling the splitter. This means the
message body is appende
The `weaveByToUri` is a handy method that makes it easy to _weave_ a Camel
route that
send messages to a given endpoint URI or pattern.
-Given the following route having two branches in the
xref:{eip-vc}:eips:choice-eip.adoc[Content Based Router] EIP:
+Given the following route having two branches in the
xref:components:eips:choice-eip.adoc[Content Based Router] EIP:
[source,java]
----
@@ -401,7 +401,7 @@ the selection to a specific node. This can be done by using
the select methods:
- `selectRange(from, to)` Selects the nodes within the given range. The index
is zero based.
- `maxDeep(level)` Limits the selection to at most N levels deep in the Camel
route tree. The first level is number 1. So number 2 is the children of the
first-level nodes.
-Given the following route which has multiple
xref:{eip-vc}:eips:filter-eip.adoc[Filter] EIP,
+Given the following route which has multiple
xref:components:eips:filter-eip.adoc[Filter] EIP,
then we want to only advice the 2nd filter.
[source,java]
diff --git a/docs/user-manual/modules/ROOT/pages/architecture.adoc
b/docs/user-manual/modules/ROOT/pages/architecture.adoc
index 6196df2..9107cb9 100644
--- a/docs/user-manual/modules/ROOT/pages/architecture.adoc
+++ b/docs/user-manual/modules/ROOT/pages/architecture.adoc
@@ -5,7 +5,7 @@ or an XML Configuration to configure
routing and mediation rules which are added to a
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/CamelContext.html[CamelContext]
to implement the various
-xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise Integration
Patterns].
+xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
Integration Patterns].
At a high level Camel consists of a
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/CamelContext.html[CamelContext]
diff --git a/docs/user-manual/modules/ROOT/pages/batch-consumer.adoc
b/docs/user-manual/modules/ROOT/pages/batch-consumer.adoc
index 09e62bc..0d98102 100644
--- a/docs/user-manual/modules/ROOT/pages/batch-consumer.adoc
+++ b/docs/user-manual/modules/ROOT/pages/batch-consumer.adoc
@@ -1,6 +1,6 @@
= Batch Consumer
-Batch Consumer is basically a xref:{eip-vc}:eips:polling-consumer.adoc[Polling
+Batch Consumer is basically a
xref:components:eips:polling-consumer.adoc[Polling
Consumer] that is capable of polling multiple
Exchanges in a single pool.
diff --git a/docs/user-manual/modules/ROOT/pages/bean-binding.adoc
b/docs/user-manual/modules/ROOT/pages/bean-binding.adoc
index ff20e85..6c1d022 100644
--- a/docs/user-manual/modules/ROOT/pages/bean-binding.adoc
+++ b/docs/user-manual/modules/ROOT/pages/bean-binding.adoc
@@ -1,7 +1,7 @@
= Bean Binding
Bean Binding in Camel defines both which methods are invoked and also
-how the xref:{eip-vc}:eips:message.adoc[Message] is converted into the
parameters of
+how the xref:components:eips:message.adoc[Message] is converted into the
parameters of
the method when it is invoked.
NOTE: This requires to include `camel-bean` as dependency on the classpath.
@@ -9,7 +9,7 @@ NOTE: This requires to include `camel-bean` as dependency on
the classpath.
[[BeanBinding-Choosingthemethodtoinvoke]]
== Choosing the method to invoke
-The binding of a Camel xref:{eip-vc}:eips:message.adoc[Message] to a bean
method call
+The binding of a Camel xref:components:eips:message.adoc[Message] to a bean
method call
can occur in different ways, in the following order of importance:
* if the message contains the header *CamelBeanMethodName* then that
@@ -162,12 +162,12 @@ See the following sections for more detail.
You can use the xref:parameter-binding-annotations.adoc[Parameter
Binding Annotations] to customize how parameter values are created from
-the xref:{eip-vc}:eips:message.adoc[Message]
+the xref:components:eips:message.adoc[Message]
[[BeanBinding-Examples]]
=== Examples
-For example, a xref:{eip-vc}:eips:bean-eip.adoc[Bean] such as:
+For example, a xref:components:eips:bean-eip.adoc[Bean] such as:
[source,java]
----
@@ -230,7 +230,7 @@ ${ }.
Any other value is considered to be a type declaration instead - see the
next section about specifying types for overloaded methods.
-When invoking a xref:{eip-vc}:eips:bean-eip.adoc[Bean] you can instruct Camel
to invoke a
+When invoking a xref:components:eips:bean-eip.adoc[Bean] you can instruct
Camel to invoke a
specific method by providing the method name:
[source,java]
@@ -331,7 +331,7 @@ use `.to` instead as shown:
[[BeanBinding-Usingtypequalifierstoselectamongoverloadedmethods]]
== Using type qualifiers to select among overloaded methods
-If you have a xref:{eip-vc}:eips:bean-eip.adoc[Bean] with overloaded methods,
you can now
+If you have a xref:components: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 7c822bc..61fe874 100644
--- a/docs/user-manual/modules/ROOT/pages/bean-integration.adoc
+++ b/docs/user-manual/modules/ROOT/pages/bean-integration.adoc
@@ -19,7 +19,7 @@ The following annotations is supported and inject by Camel's
|`@EndpointInject` |To inject an endpoint, see more details at
xref:pojo-producing.adoc[POJO Producing].
|`@BeanInject` |To inject a bean obtained from the Registry. See
xref:bean-injection.adoc[Bean Injection].
|`@BeanConfigInject` |To inject a configuration bean obtained from the
Registry. The bean is a POJO that represents
-a set of configuration options, which is automatic configured with values
loaded via Camel xref:latest@manual::using-propertyplaceholder.adoc[Property
Placeholders].
+a set of configuration options, which is automatic configured with values
loaded via Camel xref:using-propertyplaceholder.adoc[Property Placeholders].
|`@PropertyInject` |To inject a value using property placeholder.
|`@Produce` |To inject a producer to send message to an endpoint. See
xref:pojo-producing.adoc[POJO Producing].
|`@Consume` |To inject a consumer on a method. See
xref:pojo-consuming.adoc[POJO Consuming].
@@ -33,9 +33,9 @@ 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: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
+* `@DynamicRouter` Annotation for creating a
xref:components:eips:dynamicRouter-eip.adoc[Dynamic Router] from a POJO method
+* `@RecipientList` Annotation for creating a
xref:components:eips:recipientList-eip.adoc[Recipient List] from a POJO method
+* `@RoutingSlip` Annotation for creating a
xref:components: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/camel-3x-upgrade-guide-3_1.adoc
b/docs/user-manual/modules/ROOT/pages/camel-3x-upgrade-guide-3_1.adoc
index 5f417b5..29b0260 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-3x-upgrade-guide-3_1.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-3x-upgrade-guide-3_1.adoc
@@ -215,7 +215,7 @@ Camel a bit more time, and hence added 15 seconds so the
default is 45 seconds.
=== Message History
The message history is now default disabled (due to optimize core for lower
footprint out of the box).
-See the xref:{eip-vc}:eips:message-history.adoc[Message History] documentation
for how to enabled message history.
+See the xref:components:eips:message-history.adoc[Message History]
documentation for how to enabled message history.
=== Inflight Repository
diff --git
a/docs/user-manual/modules/ROOT/pages/camelcontext-autoconfigure.adoc
b/docs/user-manual/modules/ROOT/pages/camelcontext-autoconfigure.adoc
index 14e0de6..fda3c23 100644
--- a/docs/user-manual/modules/ROOT/pages/camelcontext-autoconfigure.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camelcontext-autoconfigure.adoc
@@ -43,10 +43,10 @@ The following SPI services, can only a single instance
(singleton) be in the xre
| InflightRepository | To use a custom inflight repository
| ManagementObjectNameStrategy | To use a custom JMX MBean object naming
| ManagementStrategy | To use a custom JMX management strategy
-| MessageHistoryFactory | To use a custom factory for
xref:{eip-vc}:eips:message-history.adoc[message history]
+| MessageHistoryFactory | To use a custom factory for
xref:components:eips:message-history.adoc[message history]
| ModelJAXBContextFactory | To use a custom `JAXBContext` factory (only needed
if you run Camel on a special application server to deal with JAXB classloading)
| NodeIdFactory | To use a custom factory for creating auto generated node ids
-| ProcessorFactory | To use a custom factory for creating
xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[EIP] processors
+| ProcessorFactory | To use a custom factory for creating
xref:components:eips:enterprise-integration-patterns.adoc[EIP] processors
| PropertiesComponent | To use a custom properties component
| ReactiveExecutor | To use a custom reactive engine in the Camel routing
engine
| RouteController | To use a custom xref:route-controller.adoc[route
controller]
diff --git a/docs/user-manual/modules/ROOT/pages/component.adoc
b/docs/user-manual/modules/ROOT/pages/component.adoc
index 9947429..d5a0015 100644
--- a/docs/user-manual/modules/ROOT/pages/component.adoc
+++ b/docs/user-manual/modules/ROOT/pages/component.adoc
@@ -15,7 +15,7 @@ For example a component may have security settings,
credentials for authenticati
Some components only have a few options, and others may have many. Because
components typically have pre configured defaults
that are commonly used, then you may often only need to configure a few
options on a component; or none at all.
-Configuring components can be done with the
xref:latest@manual::component-dsl.adoc[Component DSL],
+Configuring components can be done with the xref:component-dsl.adoc[Component
DSL],
in a configuration file (application.properties|yaml), or directly with Java
code.
== Configuring Endpoint Options
@@ -25,9 +25,9 @@ configure what you need the endpoint to do. The options are
also categorized int
or as a producer (to), or used for both.
Configuring endpoints is most often done directly in the endpoint URI as path
and query parameters. You can also use
-the xref:latest@manual::Endpoint-dsl.adoc[Endpoint DSL] as a _type safe_ way
of configuring endpoints.
+the xref:Endpoint-dsl.adoc[Endpoint DSL] as a _type safe_ way of configuring
endpoints.
-A good practice when configuring options is to use
xref:latest@manual::using-propertyplaceholder.adoc[Property Placeholders],
+A good practice when configuring options is to use
xref:using-propertyplaceholder.adoc[Property Placeholders],
which allows to not hardcode urls, port numbers, sensitive information, and
other settings.
In other words placeholders allows to externalize the configuration from your
code, and gives more flexibility and reuse.
diff --git a/docs/user-manual/modules/ROOT/pages/data-format.adoc
b/docs/user-manual/modules/ROOT/pages/data-format.adoc
index 0fd37a7..7d7558f 100644
--- a/docs/user-manual/modules/ROOT/pages/data-format.adoc
+++ b/docs/user-manual/modules/ROOT/pages/data-format.adoc
@@ -2,11 +2,11 @@
Camel supports a pluggable `DataFormat` to allow messages to be marshalled
to and from binary or text formats to support a kind of
-xref:{eip-vc}:eips:message-translator.adoc[Message Translator].
+xref:components:eips:message-translator.adoc[Message Translator].
== Supported data formats
-There are more than 40 different
xref:latest@components:dataformats:index.adoc[Data Formats] that
+There are more than 40 different xref:components:dataformats:index.adoc[Data
Formats] that
supports formats such as XML, CSV, JSon, YAML, Avro, Protobuf, and many more.
== Unmarshalling
@@ -48,7 +48,7 @@ xref:registry.adoc[Registry].
The following example marshals using a
named JAXB data format to perform a kind of
-xref:{eip-vc}:eips:message-translator.adoc[Message Translator]:
+xref:components:eips:message-translator.adoc[Message Translator]:
[source,java]
----
diff --git a/docs/user-manual/modules/ROOT/pages/defaulterrorhandler.adoc
b/docs/user-manual/modules/ROOT/pages/defaulterrorhandler.adoc
index 5696f9a..fe7c3dd 100644
--- a/docs/user-manual/modules/ROOT/pages/defaulterrorhandler.adoc
+++ b/docs/user-manual/modules/ROOT/pages/defaulterrorhandler.adoc
@@ -2,12 +2,12 @@
This is the default error handler in Camel.
-The default error handler have the same power as the
xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter Channel],
+The default error handler have the same power as the
xref:components:eips:dead-letter-channel.adoc[Dead Letter Channel],
however it does *not* support a _dead letter queue_, which is
the only difference between the two of them.
The `DefaultErrorHandler` is configured differently from
-xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter Channel] as
+xref:components:eips:dead-letter-channel.adoc[Dead Letter Channel] as
it is configured to:
* not redeliver
diff --git a/docs/user-manual/modules/ROOT/pages/dsl.adoc
b/docs/user-manual/modules/ROOT/pages/dsl.adoc
index f3a48c5..0033355 100644
--- a/docs/user-manual/modules/ROOT/pages/dsl.adoc
+++ b/docs/user-manual/modules/ROOT/pages/dsl.adoc
@@ -1,7 +1,7 @@
= DSL
Camel uses a Java _Domain Specific Language_ or DSL for creating
-xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise Integration
+xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
Integration
Patterns] or Routes in a variety of domain-specific
languages (DSL) as listed below.
diff --git a/docs/user-manual/modules/ROOT/pages/endpoint.adoc
b/docs/user-manual/modules/ROOT/pages/endpoint.adoc
index cc0f696..76731bf 100644
--- a/docs/user-manual/modules/ROOT/pages/endpoint.adoc
+++ b/docs/user-manual/modules/ROOT/pages/endpoint.adoc
@@ -1,6 +1,6 @@
= Endpoints
-Camel supports the xref:{eip-vc}:eips:message-endpoint.adoc[Message Endpoint]
pattern
+Camel supports the xref:components:eips:message-endpoint.adoc[Message
Endpoint] pattern
using the
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/Endpoint.html[Endpoint]
interface.
@@ -15,14 +15,14 @@
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/P
for sending message exchanges to the endpoint.
*
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/Endpoint.html#createConsumer-org.apache.camel.Processor[`createConsumer()`]
-implements the xref:{eip-vc}:eips:eventDrivenConsumer-eip.adoc[Event Driven
Consumer]
+implements the xref:components:eips:eventDrivenConsumer-eip.adoc[Event Driven
Consumer]
pattern for consuming message exchanges from the endpoint via a
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/Processor.html[Processor]
when creating a
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/Consumer.html[Consumer].
*
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/Endpoint.html#createPollingConsumer[`createPollingConsumer()`]
-implements the xref:{eip-vc}:eips:polling-consumer.adoc[Polling Consumer]
pattern for
+implements the xref:components:eips:polling-consumer.adoc[Polling Consumer]
pattern for
consuming message exchanges from the endpoint via a
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/PollingConsumer.html[PollingConsumer].
diff --git a/docs/user-manual/modules/ROOT/pages/error-handler.adoc
b/docs/user-manual/modules/ROOT/pages/error-handler.adoc
index 3a7ec0c..8dd331a 100644
--- a/docs/user-manual/modules/ROOT/pages/error-handler.adoc
+++ b/docs/user-manual/modules/ROOT/pages/error-handler.adoc
@@ -2,7 +2,7 @@
Camel supports pluggable
https://www.javadoc.io/doc/org.apache.camel/camel-base/current/org/apache/camel/processor/ErrorHandler.html[ErrorHandler]
-strategies to deal with errors processing an
xref:{eip-vc}:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer].
+strategies to deal with errors processing an
xref:components:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer].
An alternative is to specify the error handling directly in the
xref:dsl.adoc[DSL]
using the xref:exception-clause.adoc[Exception Clause].
@@ -51,7 +51,7 @@ a single RouteBuilder
=== DefaultErrorHandler
The DefaultErrorHandler is the default
-error handler in Camel. Unlike
xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter
+error handler in Camel. Unlike
xref:components:eips:dead-letter-channel.adoc[Dead Letter
Channel] it does not have any dead letter queue, and do *not* handle
exceptions by default.
@@ -238,7 +238,7 @@ and use another error handler.
=== Spring based configuration sample
-In this sample we configure a xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead
Letter
+In this sample we configure a
xref:components:eips:dead-letter-channel.adoc[Dead Letter
Channel] on the route that should redeliver at most 3 times and use a
little delay before retrying. First we configure the reference to
*myDeadLetterErrorHandler* using
the `errorHandlerRef` attribute on the `route` tag.
@@ -287,7 +287,7 @@ etc.
The transactional error handler is based on spring transaction. This
requires the usage of the camel-spring or camel-jta component.
-See xref:{eip-vc}:eips:transactional-client.adoc[Transactional Client] that
has many
+See xref:components:eips:transactional-client.adoc[Transactional Client] that
has many
samples for how to use and transactional behavior and configuration with
this error handler.
diff --git a/docs/user-manual/modules/ROOT/pages/examples.adoc
b/docs/user-manual/modules/ROOT/pages/examples.adoc
index 70e1736..8ef732d 100644
--- a/docs/user-manual/modules/ROOT/pages/examples.adoc
+++ b/docs/user-manual/modules/ROOT/pages/examples.adoc
@@ -1,7 +1,7 @@
= Examples
Once you have read about xref:getting-started.adoc[Getting Started] and
-looked at the
xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise
+looked at the
xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
Integration Patterns], you might want to try out some examples.
diff --git a/docs/user-manual/modules/ROOT/pages/exception-clause.adoc
b/docs/user-manual/modules/ROOT/pages/exception-clause.adoc
index 2f44361..808549f 100644
--- a/docs/user-manual/modules/ROOT/pages/exception-clause.adoc
+++ b/docs/user-manual/modules/ROOT/pages/exception-clause.adoc
@@ -156,11 +156,11 @@ select the *`onException(IOException.class)`* clause.
== Configuring RedeliveryPolicy (redeliver options)
https://www.javadoc.io/doc/org.apache.camel/camel-base/current/org/apache/camel/processor/errorhandler/RedeliveryPolicy.html[RedeliveryPolicy]
-requires to use the xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter
Channel]
+requires to use the xref:components:eips:dead-letter-channel.adoc[Dead Letter
Channel]
as the xref:error-handler.adoc[Error Handler]. Dead Letter Channel
supports attempting to redeliver the message exchange a number of times
before sending it to a dead letter endpoint. See
-xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter Channel] for further
+xref:components:eips:dead-letter-channel.adoc[Dead Letter Channel] for further
information about redeliver and which redeliver options exists.
=== No redelivery is default for onException
@@ -173,7 +173,7 @@ type basis. By default in the top examples, if an
*`org.apache.camel.ValidationException`* occurs then the message will
not be redelivered; however if some other exception occurs, e.g.,
*`IOException`* or whatever, the route will be retried according to the
-settings from the xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter
Channel].
+settings from the xref:components:eips:dead-letter-channel.adoc[Dead Letter
Channel].
However if you want to customize any methods on the
https://www.javadoc.io/doc/org.apache.camel/camel-base/current/org/apache/camel/processor/errorhandler/RedeliveryPolicy.html[RedeliveryPolicy]
@@ -306,7 +306,7 @@ is being routed to our processor
*`MyFunctionFailureHandler`*. So you
can say that the exchange is diverted when a *`MyFunctionalException`*
is thrown during processing. It's important to distinct this as perfect
valid. The default redelivery policy from the
-xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter Channel] will not kick
in, so
+xref:components:eips:dead-letter-channel.adoc[Dead Letter Channel] will not
kick in, so
our processor receives the Exchange directly, without any redeliver
attempted. In our processor we need to determine what to do. Camel
regards the Exchange as *failure handled*. So our processor is the end
@@ -514,7 +514,7 @@ In the route above we handled the exception but routed it
to a different
endpoint. What if you need to alter the response and send a fixed
response back to the original caller (the client). No secret here just
do as you do in normal Camel routing, use
-xref:{eip-vc}:eips:message-translator.adoc[transform] to set the response, as
shown in
+xref:components:eips:message-translator.adoc[transform] to set the response,
as shown in
the sample below:
[source,java]
@@ -903,15 +903,15 @@ default error handler will kick in.
== Using onRedelivery Processor
-xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter Channel] has support
+xref:components:eips:dead-letter-channel.adoc[Dead Letter Channel] has support
for *`onRedelivery`* to allow custom processing of a Message before its
being redelivered. It can be used to add some customer header or
whatnot. In Camel 2.0 we have added this feature to
xref:exception-clause.adoc[Exception Clause] as well, so you can use per
exception scoped on redelivery. Camel will fallback to use the one
-defined on xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter Channel] if
any, if
+defined on xref:components:eips:dead-letter-channel.adoc[Dead Letter Channel]
if any, if
none exists on the xref:exception-clause.adoc[Exception Clause]. See
-xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter Channel] for more
details on
+xref:components:eips:dead-letter-channel.adoc[Dead Letter Channel] for more
details on
*`onRedelivery`*.
In the code below we want to do some custom code before redelivering any
@@ -977,7 +977,7 @@ class as this code is based on unit testing):
== Using onExceptionOccurred Processor
-xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter Channel] has support
+xref:components:eips:dead-letter-channel.adoc[Dead Letter Channel] has support
for *`onExceptionOccurred`* to allow custom processing of a Message just
after the exception was thrown. It can be used to do some custom logging
or whatnot. The difference between *`onRedelivery`* processor
diff --git a/docs/user-manual/modules/ROOT/pages/exchange-pattern.adoc
b/docs/user-manual/modules/ROOT/pages/exchange-pattern.adoc
index ac45bdd..8cb1c8a 100644
--- a/docs/user-manual/modules/ROOT/pages/exchange-pattern.adoc
+++ b/docs/user-manual/modules/ROOT/pages/exchange-pattern.adoc
@@ -3,18 +3,18 @@
There are two _Message Exchange Patterns_ you can use in
messaging.
-From there xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise
+From there xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
Integration Patterns] they are:
-* xref:{eip-vc}:eips:event-message.adoc[Event Message] (or one-way)
-* xref:{eip-vc}:eips:requestReply-eip.adoc[Request Reply]
+* xref:components:eips:event-message.adoc[Event Message] (or one-way)
+* xref:components:eips:requestReply-eip.adoc[Request Reply]
In Camel we have an
`org.apache.camel.ExchangePattern`
enumeration which can be configured on the *exchangePattern* property on
the Message Exchange indicating if a message
-exchange is a one way xref:{eip-vc}:eips:event-message.adoc[Event Message]
(*InOnly*) or
-a xref:{eip-vc}:eips:requestReply-eip.adoc[Request Reply] message exchange
(*InOut*).
+exchange is a one way xref:components:eips:event-message.adoc[Event Message]
(*InOnly*) or
+a xref:components:eips:requestReply-eip.adoc[Request Reply] message exchange
(*InOut*).
For example to override the default pattern on a
xref:components::jms-component.adoc[JMS]
endpoint you could use the `exchangePattern` parameter in the Endpoint
xref:uris.adoc[URI]
diff --git a/docs/user-manual/modules/ROOT/pages/exchange.adoc
b/docs/user-manual/modules/ROOT/pages/exchange.adoc
index 48d5679..58823dc 100644
--- a/docs/user-manual/modules/ROOT/pages/exchange.adoc
+++ b/docs/user-manual/modules/ROOT/pages/exchange.adoc
@@ -1,11 +1,11 @@
= Message Exchange
To support various message exchange patterns
-like one way xref:{eip-vc}:eips:event-message.adoc[Event Message] and
-xref:{eip-vc}:eips:requestReply-eip.adoc[Request Reply] messages Camel
+like one way xref:components:eips:event-message.adoc[Event Message] and
+xref:components:eips:requestReply-eip.adoc[Request Reply] messages Camel
uses an `Exchange` interface which has an xref:exchange-pattern.adoc[Exchange
Pattern]
property which can be set to *InOnly* for an
-xref:{eip-vc}:eips:event-message.adoc[Event Message] which has a single
inbound Message,
-or *InOut* for a xref:{eip-vc}:eips:requestReply-eip.adoc[Request Reply]
+xref:components:eips:event-message.adoc[Event Message] which has a single
inbound Message,
+or *InOut* for a xref:components:eips:requestReply-eip.adoc[Request Reply]
where there is an inbound and outbound Message.
diff --git a/docs/user-manual/modules/ROOT/pages/expression.adoc
b/docs/user-manual/modules/ROOT/pages/expression.adoc
index 0eada83..c5922b4 100644
--- a/docs/user-manual/modules/ROOT/pages/expression.adoc
+++ b/docs/user-manual/modules/ROOT/pages/expression.adoc
@@ -1,12 +1,12 @@
= Expressions
Expressions and xref:predicate.adoc[Predicates] can then be used to
-create the various
xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise
-Integration Patterns] in the xref:dsl.adoc[DSL] like with the
xref:{eip-vc}:eips:recipientList-eip.adoc[Recipient List] EIP.
+create the various
xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
+Integration Patterns] in the xref:dsl.adoc[DSL] like with the
xref:components:eips:recipientList-eip.adoc[Recipient List] EIP.
To support dynamic rules Camel supports pluggable
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/Expression.html[Expression]
-strategies using a variety of different
xref:latest@components:languages:index.adoc[Languages].
+strategies using a variety of different
xref:components:languages:index.adoc[Languages].
== Expression API
diff --git a/docs/user-manual/modules/ROOT/pages/getting-started.adoc
b/docs/user-manual/modules/ROOT/pages/getting-started.adoc
index 6d5cde1..e97c55c 100644
--- a/docs/user-manual/modules/ROOT/pages/getting-started.adoc
+++ b/docs/user-manual/modules/ROOT/pages/getting-started.adoc
@@ -8,7 +8,7 @@ Then come back here, and you might want to read the following
documentation before continuing:
* Longer xref:book-getting-started.adoc[Getting Started Guide]
-* Find out about
xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise Integration
Patterns]
+* Find out about
xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
Integration Patterns]
and how to implement them with Camel
* Review the xref:architecture.adoc[Architecture guide] to see how to build
Routes using the xref:dsl.adoc[DSL].
diff --git a/docs/user-manual/modules/ROOT/pages/http-session-handling.adoc
b/docs/user-manual/modules/ROOT/pages/http-session-handling.adoc
index caf2f36..9d171a8 100644
--- a/docs/user-manual/modules/ROOT/pages/http-session-handling.adoc
+++ b/docs/user-manual/modules/ROOT/pages/http-session-handling.adoc
@@ -107,7 +107,7 @@ cookies. Default is `CookiePolicy.ACCEPT_ORIGINAL_SERVER`.
== Cookies and EIPs
-Some EIPs like xref:{eip-vc}:eips:multicast-eip.adoc[Multicast] or
xref:{eip-vc}:eips:split-eip.adoc[Split]
+Some EIPs like xref:components:eips:multicast-eip.adoc[Multicast] or
xref:components:eips:split-eip.adoc[Split]
create multiple exchanges from a single one. If no
`org.apache.camel.http.common.cookie.ExchangeCookieHandler`
is used before this, each multicast or splitter branch will have its own
cookie store. This will not be the case
if the first invocation of one of the endpoints using the cookie handler is
before the multicast, because in
diff --git a/docs/user-manual/modules/ROOT/pages/index.adoc
b/docs/user-manual/modules/ROOT/pages/index.adoc
index df0a3ad..0ec0b5e 100644
--- a/docs/user-manual/modules/ROOT/pages/index.adoc
+++ b/docs/user-manual/modules/ROOT/pages/index.adoc
@@ -1,7 +1,7 @@
= Apache Camel user manual
Apache Camel™ is a versatile open-source integration framework based on
-known xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise
Integration
+known xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
Integration
Patterns].
Camel empowers you to define routing and mediation rules in a variety of
@@ -31,7 +31,7 @@ For a deeper and better understanding of Apache Camel, an
xref:faq:what-is-camel
* link:/community/books/[Books]
* xref:examples.adoc[Examples]
* xref:architecture.adoc[Architecture]
-* xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise
Integration Patterns]
+* xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
Integration Patterns]
* xref:Endpoint-dsl.adoc[Endpoint-dsl]
* xref:component-dsl.adoc[Component-dsl]
* xref:dsl.adoc[DSL]
@@ -85,7 +85,7 @@ For a deeper and better understanding of Apache Camel, an
xref:faq:what-is-camel
* xref:expression.adoc[Expression]
* xref:http-session-handling.adoc[HTTP-Session Handling]
* xref:injector.adoc[Injector]
-* xref:{eip-vc}:eips:intercept.adoc[Intercept]
+* xref:components:eips:intercept.adoc[Intercept]
* xref:languages.adoc[Languages]
* xref:lifecycle.adoc[Lifecycle]
* xref:oncompletion.adoc[OnCompletion]
diff --git a/docs/user-manual/modules/ROOT/pages/java-dsl.adoc
b/docs/user-manual/modules/ROOT/pages/java-dsl.adoc
index 9656665..88ab692 100644
--- a/docs/user-manual/modules/ROOT/pages/java-dsl.adoc
+++ b/docs/user-manual/modules/ROOT/pages/java-dsl.adoc
@@ -50,7 +50,7 @@ In the example above we have a single route, which pickup
files (the `from`).
from("file:src/data?noop=true")
---------------------------------------
-Then we use the xref:{eip-vc}:eips:choice-eip.adoc[Content Based Router] EIP
+Then we use the xref:components:eips:choice-eip.adoc[Content Based Router] EIP
(the `choice`) to route the message whether the person is from London or not.
[source,java]
diff --git a/docs/user-manual/modules/ROOT/pages/jmx.adoc
b/docs/user-manual/modules/ROOT/pages/jmx.adoc
index ef44190..206f5da 100644
--- a/docs/user-manual/modules/ROOT/pages/jmx.adoc
+++ b/docs/user-manual/modules/ROOT/pages/jmx.adoc
@@ -135,7 +135,7 @@ you for example add and remove temporary routes where
management is not
needed.
CAUTION: Be a bit careful to use the `registerAlways` option when using dynamic
-EIP patterns such as the xref:{eip-vc}:eips:recipientList-eip.adoc[Recipient
List] having unique endpoints. If so
+EIP patterns such as the xref:components:eips:recipientList-eip.adoc[Recipient
List] having unique endpoints. If so
then each unique endpoint and its associated services/producers would
also be registered. This could potentially lead to system degradation due
the rising number of mbeans in the registry. A MBean is not a
diff --git a/docs/user-manual/modules/ROOT/pages/json.adoc
b/docs/user-manual/modules/ROOT/pages/json.adoc
index 1309e97..751a2df 100644
--- a/docs/user-manual/modules/ROOT/pages/json.adoc
+++ b/docs/user-manual/modules/ROOT/pages/json.adoc
@@ -11,4 +11,4 @@ popular JSON libraries such as:
- Johnzon
How to use JSon with Camel then see the documentation (for the JSon data
library of choice)
-in the list of xref:latest@components:dataformats:index.adoc[Data Formats].
\ No newline at end of file
+in the list of xref:components:dataformats:index.adoc[Data Formats].
\ No newline at end of file
diff --git a/docs/user-manual/modules/ROOT/pages/languages.adoc
b/docs/user-manual/modules/ROOT/pages/languages.adoc
index 23377bb..564e1dd 100644
--- a/docs/user-manual/modules/ROOT/pages/languages.adoc
+++ b/docs/user-manual/modules/ROOT/pages/languages.adoc
@@ -1,14 +1,14 @@
= Languages
To support flexible and powerful
-xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise Integration
+xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
Integration
Patterns], Camel supports various Languages to create an
xref:expression.adoc[Expression] or xref:predicate.adoc[Predicate]
within the xref:routes.adoc[Routes] and xref:dsl.adoc[DSL]..
== Supported languages
-There are about 20 different
xref:latest@components:languages:index.adoc[Languages] such
+There are about 20 different xref:components:languages:index.adoc[Languages]
such
as scripted programming languages such as Groovy, and template based languages
like Velocity and Freemarker,
and XML/JSon languages, and many others.
diff --git
a/docs/user-manual/modules/ROOT/pages/parameter-binding-annotations.adoc
b/docs/user-manual/modules/ROOT/pages/parameter-binding-annotations.adoc
index 69d5000..e2f5e5c 100644
--- a/docs/user-manual/modules/ROOT/pages/parameter-binding-annotations.adoc
+++ b/docs/user-manual/modules/ROOT/pages/parameter-binding-annotations.adoc
@@ -31,7 +31,7 @@ component or when invoking beans in the xref:dsl.adoc[DSL]
Annotations can be used to define an xref:expression.adoc[Expression] or
to extract various headers, properties or payloads from a
-xref:{eip-vc}:eips:message.adoc[Message] when invoking a bean method (see
+xref:components:eips:message.adoc[Message] when invoking a bean method (see
xref:bean-integration.adoc[Bean Integration] for more detail of how to
invoke bean methods) together with being useful to help disambiguate
which method to invoke.
@@ -153,7 +153,7 @@ any of these annotations:
|=======================================================================
The table above only list some of the commonly used languages. You can find
-a list of all supported xref:latest@components:languages:index.adoc[Languages]
+a list of all supported xref:components:languages:index.adoc[Languages]
which each have their own annotation that can be used.
It is required to include the JAR of the language, for example `camel-groovy`,
diff --git a/docs/user-manual/modules/ROOT/pages/pojo-consuming.adoc
b/docs/user-manual/modules/ROOT/pages/pojo-consuming.adoc
index b1bb55d..ab0f277 100644
--- a/docs/user-manual/modules/ROOT/pages/pojo-consuming.adoc
+++ b/docs/user-manual/modules/ROOT/pages/pojo-consuming.adoc
@@ -23,7 +23,7 @@ public class Foo {
----
The xref:bean-binding.adoc[Bean Binding] is then used to convert the
-inbound xref:{eip-vc}:eips:message.adoc[Message] to the parameter list used to
invoke
+inbound xref:components:eips:message.adoc[Message] to the parameter list used
to invoke
the method .
This basically creates a route that looks kinda like this:
diff --git a/docs/user-manual/modules/ROOT/pages/pojo-producing.adoc
b/docs/user-manual/modules/ROOT/pages/pojo-producing.adoc
index 30bc54e..15fca0f 100644
--- a/docs/user-manual/modules/ROOT/pages/pojo-producing.adoc
+++ b/docs/user-manual/modules/ROOT/pages/pojo-producing.adoc
@@ -69,7 +69,7 @@ When we invoke methods on this interface the method call is
turned into an object and is sent to the
endpoint; in this case the xref:components::activemq-component.adoc[ActiveMQ]
endpoint to
queue *`foo`*. Because the `sayHello` method has a return type (`String`) then
Camel
-will use xref:{eip-vc}:eips:requestReply-eip.adoc[Request Reply] (InOut)
messaging.
+will use xref:components:eips:requestReply-eip.adoc[Request Reply] (InOut)
messaging.
[source,java]
----
@@ -78,4 +78,4 @@ public interface MyListener {
}
----
-If the method is a `void` method, then Camel will use
xref:{eip-vc}:eips:event-message.adoc[Event Message] (InOnly) messaging.
+If the method is a `void` method, then Camel will use
xref:components:eips:event-message.adoc[Event Message] (InOnly) messaging.
diff --git a/docs/user-manual/modules/ROOT/pages/predicate.adoc
b/docs/user-manual/modules/ROOT/pages/predicate.adoc
index 7c519c0..0e8c635 100644
--- a/docs/user-manual/modules/ROOT/pages/predicate.adoc
+++ b/docs/user-manual/modules/ROOT/pages/predicate.adoc
@@ -1,12 +1,12 @@
= Predicates
xref:expression.adoc[Expressions] and Predicates can then be used to
-create the various
xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise
-Integration Patterns] in the xref:dsl.adoc[DSL] like with the
xref:{eip-vc}:eips:choice-eip.adoc[Content Based Router] EIP.
+create the various
xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
+Integration Patterns] in the xref:dsl.adoc[DSL] like with the
xref:components:eips:choice-eip.adoc[Content Based Router] EIP.
To support dynamic rules Camel supports pluggable
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/Predicate.html[Predicate]
-strategies using a variety of different
xref:latest@components:languages:index.adoc[Languages].
+strategies using a variety of different
xref:components:languages:index.adoc[Languages].
== Predicate API
@@ -35,7 +35,7 @@ powerful as it is often used to control the routing of
message in which
path they should be routed.
A simple example is to route an xref:exchange.adoc[Exchange] based on a
-header value with the xref:{eip-vc}:eips:choice-eip.adoc[Content Based Router]
EIP:
+header value with the xref:components:eips:choice-eip.adoc[Content Based
Router] EIP:
[source,java]
----
diff --git a/docs/user-manual/modules/ROOT/pages/processor.adoc
b/docs/user-manual/modules/ROOT/pages/processor.adoc
index a86bbf7d..159b10a 100644
--- a/docs/user-manual/modules/ROOT/pages/processor.adoc
+++ b/docs/user-manual/modules/ROOT/pages/processor.adoc
@@ -3,7 +3,7 @@
The
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/Processor.html[Processor]
interface is used for implement consumers of message exchanges or to
-implement a xref:{eip-vc}:eips:message-translator.adoc[Message Translator],
+implement a xref:components:eips:message-translator.adoc[Message Translator],
and other use-cases.
== Using a processor in a route
diff --git a/docs/user-manual/modules/ROOT/pages/producertemplate.adoc
b/docs/user-manual/modules/ROOT/pages/producertemplate.adoc
index 05e3c49..acd37df 100644
--- a/docs/user-manual/modules/ROOT/pages/producertemplate.adoc
+++ b/docs/user-manual/modules/ROOT/pages/producertemplate.adoc
@@ -34,8 +34,8 @@ You can also supply an `Exchange` or a `Processor` to
customize the exchange.
The `ProducerTemplate` supports xref:exchange-pattern.adoc[Message Exchange
Patterns] (MEP)
that are used to control the messaging style to use:
-* _send methods_ - xref:{eip-vc}:eips:event-message.adoc[Event Message]
(InOnly)
-* _request methods_ - xref:{eip-vc}:eips:requestReply-eip.adoc[Request Reply]
(InOut)
+* _send methods_ - xref:components:eips:event-message.adoc[Event Message]
(InOnly)
+* _request methods_ - xref:components:eips:requestReply-eip.adoc[Request
Reply] (InOut)
In other words, all the methods on the `ProducerTemplate` that starts with
`sendXXX` are for InOnly messaging,
and all the methods starting with `requestXXX` are for InOut messaging.
diff --git a/docs/user-manual/modules/ROOT/pages/rest-dsl.adoc
b/docs/user-manual/modules/ROOT/pages/rest-dsl.adoc
index 9879046..5e70b73 100644
--- a/docs/user-manual/modules/ROOT/pages/rest-dsl.adoc
+++ b/docs/user-manual/modules/ROOT/pages/rest-dsl.adoc
@@ -167,8 +167,8 @@ For example:
== Using Dynamic To in Rest DSL
-The Rest DSL supports xref:{eip-vc}:eips:toD-eip.adoc[Dynamic To] EIP (`toD`)
-to in the rest-dsl. For example to do a
xref:{eip-vc}:eips:requestReply-eip.adoc[Request Reply]
+The Rest DSL supports xref:components:eips:toD-eip.adoc[Dynamic To] EIP (`toD`)
+to in the rest-dsl. For example to do a
xref:components:eips:requestReply-eip.adoc[Request Reply]
over xref:components::jms-component.adoc[JMS] where the queue name is dynamic
defined
[source,java]
diff --git a/docs/user-manual/modules/ROOT/pages/route-configuration.adoc
b/docs/user-manual/modules/ROOT/pages/route-configuration.adoc
index 4adc0d5..505cf72 100644
--- a/docs/user-manual/modules/ROOT/pages/route-configuration.adoc
+++ b/docs/user-manual/modules/ROOT/pages/route-configuration.adoc
@@ -14,7 +14,7 @@ In the route configuration you can setup common strategies
for:
- xref:exception-clause.adoc[OnException]
- xref:oncompletion.adoc[OnCompletion]
-- xref:{eip-vc}:eips:intercept.adoc[Intercept]
+- xref:components:eips:intercept.adoc[Intercept]
== Route Configuration Builder in Java DSL
diff --git a/docs/user-manual/modules/ROOT/pages/route-policy.adoc
b/docs/user-manual/modules/ROOT/pages/route-policy.adoc
index 3ae225d..34fd5b6 100644
--- a/docs/user-manual/modules/ROOT/pages/route-policy.adoc
+++ b/docs/user-manual/modules/ROOT/pages/route-policy.adoc
@@ -85,16 +85,16 @@ again in case it has been suspended.
=== ThrottlingInflightRoutePolicy compared to the Throttler EIP
The `ThrottlingInflightRoutePolicy` compared to
-xref:{eip-vc}:eips:throttle-eip.adoc[Throttler] EIP is that it does *not*
block during
+xref:components:eips:throttle-eip.adoc[Throttler] EIP 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:{eip-vc}:eips:throttle-eip.adoc[Throttler] EIP.
+xref:components:eips:throttle-eip.adoc[Throttler] EIP.
-The xref:{eip-vc}:eips:throttle-eip.adoc[Throttler] EIP can
+The xref:components:eips:throttle-eip.adoc[Throttler] EIP 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:{eip-vc}:eips:throttle-eip.adoc[Throttler] EIP is based on number o
+xref:components:eips:throttle-eip.adoc[Throttler] EIP is based on number o
messages per time unit.
== ScheduledRoutePolicy
diff --git a/docs/user-manual/modules/ROOT/pages/spring.adoc
b/docs/user-manual/modules/ROOT/pages/spring.adoc
index 346120d..b4f3da4 100644
--- a/docs/user-manual/modules/ROOT/pages/spring.adoc
+++ b/docs/user-manual/modules/ROOT/pages/spring.adoc
@@ -34,7 +34,7 @@ See xref:using-propertyplaceholder.adoc[Using Property
Placeholder] documentatio
== Using Camel with Spring transactions
-See xref:{eip-vc}:eips:transactional-client.adoc[Transactional Client]} EIP.
+See xref:components:eips:transactional-client.adoc[Transactional Client]} EIP.
== Using Camel with Spring testing
diff --git a/docs/user-manual/modules/ROOT/pages/stream-caching.adoc
b/docs/user-manual/modules/ROOT/pages/stream-caching.adoc
index 3674266..aaa47f6a 100644
--- a/docs/user-manual/modules/ROOT/pages/stream-caching.adoc
+++ b/docs/user-manual/modules/ROOT/pages/stream-caching.adoc
@@ -10,7 +10,7 @@ Streams are cached in memory. However, for large stream
messages (over 128 KB) w
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:{eip-vc}:eips:choice-eip.adoc[Content Based Router] or the likes.
+or xref:components:eips:choice-eip.adoc[Content Based Router] or the likes.
However, to not change the payload under the covers without the end user
really knowing then stream caching is by default disabled.
====
diff --git a/docs/user-manual/modules/ROOT/pages/threading-model.adoc
b/docs/user-manual/modules/ROOT/pages/threading-model.adoc
index df41ca9..3aa6c6a 100644
--- a/docs/user-manual/modules/ROOT/pages/threading-model.adoc
+++ b/docs/user-manual/modules/ROOT/pages/threading-model.adoc
@@ -6,10 +6,10 @@ and thread pools from the JDK concurrency API.
This page focuses on thread pools.
Camel leverages thread pools in several places such as:
-* several xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[EIP]
patterns supports using thread pools for
+* several xref:components:eips:enterprise-integration-patterns.adoc[EIP]
patterns supports using thread pools for
concurrency
* xref:components::seda-component.adoc[SEDA] component for asynchronous
connectivity
-* xref:{eip-vc}:eips:threads-eip.adoc[Threads] EIP in Camel routes
+* xref:components:eips:threads-eip.adoc[Threads] EIP in Camel routes
* Some components use thread pools out of the box, such as
xref:components::jms-component.adoc[JMS] or
xref:components::jetty-component.adoc[Jetty]
@@ -33,7 +33,7 @@ The default profile is pre-configured out of the box with the
following settings
|===
What that means is that for example when you use
-xref:{eip-vc}:eips:multicast-eip.adoc[Multicast] with
`parallelProcessing=true` enabled,
+xref:components:eips:multicast-eip.adoc[Multicast] with
`parallelProcessing=true` enabled,
then it would create a thread pool based on the profile above.
You can define as many thread pool profiles as you like. But there must
@@ -99,7 +99,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. In this example there is a profile,
so the profile is used as base settings for creating a new `ExecutorService`
which is
-handed back to the xref:{eip-vc}:eips:multicast-eip.adoc[Multicast] EIP to use
in the
+handed back to the xref:components:eips:multicast-eip.adoc[Multicast] EIP to
use in the
Camel route.
In Java DSL you can use `ThreadPoolProfileBuilder` to create a profile and
then register the profile:
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 baa797b..3336572 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
@@ -1,13 +1,13 @@
= Using Exchange Pattern Annotations
When working with xref:pojo-producing.adoc[POJO Producing] you invoke methods
which
-typically by default are InOut for
xref:{eip-vc}:eips:requestReply-eip.adoc[Request
+typically by default are InOut for
xref:components: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.
Camel has flexible xref:exchange-pattern.adoc[Exchange Pattern] support
-- so you can also support the xref:{eip-vc}:eips:event-message.adoc[Event
Message]
+- so you can also support the xref:components:eips:event-message.adoc[Event
Message]
pattern to use InOnly for asynchronous or one way operations. These are
often called 'fire and forget' like sending a JMS message but not
waiting for any response.
diff --git a/docs/user-manual/modules/ROOT/pages/using-propertyplaceholder.adoc
b/docs/user-manual/modules/ROOT/pages/using-propertyplaceholder.adoc
index 7a6709d..e02517f 100644
--- a/docs/user-manual/modules/ROOT/pages/using-propertyplaceholder.adoc
+++ b/docs/user-manual/modules/ROOT/pages/using-propertyplaceholder.adoc
@@ -281,7 +281,7 @@ In the example below we use the `prop` prefix for the
namespace
to configure any kind of XML attributes in Spring XML files.
In the example below we want to use a placeholder for the `stopOnException`
option in
-the xref:{eip-vc}:eips:multicast-eip.adoc[Multicast] EIP. The
`stopOnException` is a `xs:boolean` type,
+the xref:components:eips:multicast-eip.adoc[Multicast] EIP. The
`stopOnException` is a `xs:boolean` type,
so we cannot configure this as:
[source,xml]
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 3ecb3eb..02177c8 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
@@ -8,7 +8,7 @@ routing and explain a few pointers - so you won't walk into a
bear trap,
but can enjoy an after-hours walk to the local pub for a large beer.
First we take a moment to look at the
-xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise Integration
+xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
Integration
Patterns] - the base pattern catalog for integration scenarios. In
particular we focus on
http://www.enterpriseintegrationpatterns.com/PipesAndFilters.html[Pipes and
Filters] -
a central pattern. This is used to route messages through a sequence of
@@ -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:{eip-vc}:eips:pipeline-eip.adoc[Pipes and filters]. In fact we can change
+xref:components: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 e0fe667..2c90e78 100644
--- a/docs/user-manual/modules/ROOT/pages/writing-components.adoc
+++ b/docs/user-manual/modules/ROOT/pages/writing-components.adoc
@@ -31,7 +31,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:{eip-vc}:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer]
+* `createConsumer` implements the
xref:components:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer]
pattern for consuming message exchanges from the endpoint.
Typically, you just derive from `DefaultEndpoint`
diff --git a/docs/user-manual/modules/ROOT/references.adoc
b/docs/user-manual/modules/ROOT/references.adoc
index 80f7a38..5f65980 100644
--- a/docs/user-manual/modules/ROOT/references.adoc
+++ b/docs/user-manual/modules/ROOT/references.adoc
@@ -1,5 +1,5 @@
* *Reference*
-* xref:latest@components::index.adoc[Components]
-* xref:latest@components:dataformats:index.adoc[Data Formats]
-* xref:latest@components:languages:index.adoc[Languages]
-* xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[EIPs]
+* xref:components::index.adoc[Components]
+* xref:components:dataformats:index.adoc[Data Formats]
+* xref:components:languages:index.adoc[Languages]
+* xref:components:eips:enterprise-integration-patterns.adoc[EIPs]
diff --git
a/docs/user-manual/modules/faq/pages/how-do-i-handle-failures-when-consuming-for-example-from-a-ftp-server.adoc
b/docs/user-manual/modules/faq/pages/how-do-i-handle-failures-when-consuming-for-example-from-a-ftp-server.adoc
index 39b5df6..c617d8d 100644
---
a/docs/user-manual/modules/faq/pages/how-do-i-handle-failures-when-consuming-for-example-from-a-ftp-server.adoc
+++
b/docs/user-manual/modules/faq/pages/how-do-i-handle-failures-when-consuming-for-example-from-a-ftp-server.adoc
@@ -19,7 +19,7 @@ and delay in between.
But you can also plugin your own implementation and determine what to do
using the `pollStrategy` option which has more documentation
-xref:{eip-vc}:eips:polling-consumer.adoc[Polling Consumer].
+xref:components:eips:polling-consumer.adoc[Polling Consumer].
Notice that the option `pollStrategy` applies for all consumers which is
a `ScheduledPollConsumer` consumer. The page lists those.
diff --git
a/docs/user-manual/modules/faq/pages/how-do-i-make-my-jms-endpoint-transactional.adoc
b/docs/user-manual/modules/faq/pages/how-do-i-make-my-jms-endpoint-transactional.adoc
index 895fcad..5d05cb4 100644
---
a/docs/user-manual/modules/faq/pages/how-do-i-make-my-jms-endpoint-transactional.adoc
+++
b/docs/user-manual/modules/faq/pages/how-do-i-make-my-jms-endpoint-transactional.adoc
@@ -16,7 +16,7 @@ How Do I Make It Transactional?
[[HowDoIMakeMyJMSEndpointTransactional-Answer]]
== Answer:
-There are examples in the
xref:{eip-vc}:eips:transactional-client.adoc[Transactional Client]
+There are examples in the
xref:components:eips:transactional-client.adoc[Transactional Client]
and it is described in the _Enabling Transacted Consumption_
section of xref:components::jms-component.adoc[JMS]. To make a session
transactional
set `transacted=true` flag on the JMS endpoint and configure
diff --git
a/docs/user-manual/modules/faq/pages/how-do-i-retry-failed-messages-forever.adoc
b/docs/user-manual/modules/faq/pages/how-do-i-retry-failed-messages-forever.adoc
index a22a47c..740dd97 100644
---
a/docs/user-manual/modules/faq/pages/how-do-i-retry-failed-messages-forever.adoc
+++
b/docs/user-manual/modules/faq/pages/how-do-i-retry-failed-messages-forever.adoc
@@ -7,7 +7,7 @@ message.
By default Camel will retry consuming a message up til 6 times before
its moved to the default dead letter queue.
-If you configure the xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter
Channel]
+If you configure the xref:components:eips:dead-letter-channel.adoc[Dead Letter
Channel]
to use `maximumRedeliveries = -1` then Camel will retry forever.
When you consume a message you can check the in message header
diff --git
a/docs/user-manual/modules/faq/pages/how-do-i-write-a-custom-processor-which-sends-multiple-messages.adoc
b/docs/user-manual/modules/faq/pages/how-do-i-write-a-custom-processor-which-sends-multiple-messages.adoc
index c9864ec..3c61ceb 100644
---
a/docs/user-manual/modules/faq/pages/how-do-i-write-a-custom-processor-which-sends-multiple-messages.adoc
+++
b/docs/user-manual/modules/faq/pages/how-do-i-write-a-custom-processor-which-sends-multiple-messages.adoc
@@ -1,7 +1,7 @@
= How do I write a custom Processor which sends multiple messages?
-You could use a xref:{eip-vc}:eips:split-eip.adoc[Splitter] or use multiple
-xref:{eip-vc}:eips:message-translator.adoc[Message Translator] instances in
your
+You could use a xref:components:eips:split-eip.adoc[Splitter] or use multiple
+xref:components:eips:message-translator.adoc[Message Translator] instances in
your
route.
Or you could write a custom processor which is injected with a
diff --git
a/docs/user-manual/modules/faq/pages/how-to-send-the-same-message-to-multiple-endpoints.adoc
b/docs/user-manual/modules/faq/pages/how-to-send-the-same-message-to-multiple-endpoints.adoc
index e485b62..4a32b14 100644
---
a/docs/user-manual/modules/faq/pages/how-to-send-the-same-message-to-multiple-endpoints.adoc
+++
b/docs/user-manual/modules/faq/pages/how-to-send-the-same-message-to-multiple-endpoints.adoc
@@ -1,12 +1,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:{eip-vc}:eips:multicast-eip.adoc[Multicast].
+should use xref:components: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:{eip-vc}:eips:multicast-eip.adoc[Multicast]. This is done by adding the
`multicast()`
+xref:components:eips:multicast-eip.adoc[Multicast]. This is done by adding the
`multicast()`
before the to type:
[source,java]
@@ -25,8 +25,8 @@ If you have a route such as:
from("activemq:queue:foo").to("seda:foo", "seda:bar");
----
-It is by default a xref:{eip-vc}:eips:pipeline-eip.adoc[pipeline] in Camel
(that is
-the opposite to xref:{eip-vc}:eips:multicast-eip.adoc[Multicast]). In the
above example
+It is by default a xref:components:eips:pipeline-eip.adoc[pipeline] in Camel
(that is
+the opposite to xref:components: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/faq/pages/how-to-use-a-dynamic-uri-in-to.adoc
b/docs/user-manual/modules/faq/pages/how-to-use-a-dynamic-uri-in-to.adoc
index 37c6486..a2b91b3 100644
--- a/docs/user-manual/modules/faq/pages/how-to-use-a-dynamic-uri-in-to.adoc
+++ b/docs/user-manual/modules/faq/pages/how-to-use-a-dynamic-uri-in-to.adoc
@@ -23,7 +23,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:ROOT:expression.adoc[Expression], such as
-the xref:{eip-vc}:eips:toD-eip.adoc[ToD] or
xref:{eip-vc}:eips:recipientList-eip.adoc[Recipient List] EIP pattern.
+the xref:components:eips:toD-eip.adoc[ToD] or
xref:components:eips:recipientList-eip.adoc[Recipient List] EIP pattern.
[TIP]
====
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 cf5c245..12cfe31 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
@@ -6,8 +6,8 @@ http://cxf.apache.org/[CXF] which defines a concept
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:requestReply-eip.adoc[InOut]),
+(xref:components:eips:event-message.adoc[InOnly]) or request-reply
+(xref:components: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.
@@ -54,7 +54,7 @@ public void process(Exchange exchange) throws Exception {
This seems intuitive and is what you would expect is the _right_
approach to change a message from a xref:ROOT:processor.adoc[Processor].
However there is an big issue -- the `getOut` method will create a new
-xref:{eip-vc}:eips:message.adoc[Message], which means any other information
+xref:components:eips:message.adoc[Message], which means any other information
from the IN message will not be propagated; which means you will lose
that data.
@@ -71,7 +71,7 @@ public void process(Exchange exchange) throws Exception {
}
----
-Well that is not all, a xref:{eip-vc}:eips:message.adoc[Message] can also
contain
+Well that is not all, a xref:components:eips:message.adoc[Message] can also
contain
attachments so to be sure you need to propagate those as well:
[source,java]
diff --git a/docs/user-manual/modules/faq/pages/what-is-a-router.adoc
b/docs/user-manual/modules/faq/pages/what-is-a-router.adoc
index f0e131c..0c937c2 100644
--- a/docs/user-manual/modules/faq/pages/what-is-a-router.adoc
+++ b/docs/user-manual/modules/faq/pages/what-is-a-router.adoc
@@ -3,20 +3,20 @@
We often talk about that Camel is a mediation and routing framework; so
what exactly is a router and what does it do?
-Basically a router just consumes xref:{eip-vc}:eips:message.adoc[Message]
exchanges
+Basically a router just consumes xref:components:eips:message.adoc[Message]
exchanges
from some xref:ROOT:endpoint.adoc[Endpoint], then sends them on to some other
xref:ROOT:endpoint.adoc[Endpoint] using some kind of
-xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise Integration
+xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
Integration
Patterns].
For example a router could implement the
-xref:{eip-vc}:eips:choice-eip.adoc[Content Based Router] pattern, to route
+xref:components:eips:choice-eip.adoc[Content Based Router] pattern, to route
from an endpoint to one or more destination endpoints using a
xref:ROOT:predicate.adoc[Predicate] based on the message content.
Typically a route or router consists of one or more consumers; either an
-xref:{eip-vc}:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer] or a
-xref:{eip-vc}:eips:polling-consumer.adoc[Polling Consumer] or possibly a
-xref:{eip-vc}:eips:transactional-client.adoc[Transactional Client]. Then there
are one
+xref:components:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer] or a
+xref:components:eips:polling-consumer.adoc[Polling Consumer] or possibly a
+xref:components:eips:transactional-client.adoc[Transactional Client]. Then
there are one
or more xref:ROOT:processor.adoc[Processor] instances which could send the
message to one or more endpoints.
diff --git a/docs/user-manual/modules/faq/pages/what-is-camel.adoc
b/docs/user-manual/modules/faq/pages/what-is-camel.adoc
index d82cf66..0f1c9a8 100644
--- a/docs/user-manual/modules/faq/pages/what-is-camel.adoc
+++ b/docs/user-manual/modules/faq/pages/what-is-camel.adoc
@@ -1,7 +1,7 @@
= What is Camel?
Apache Camel (TM) is a versatile open-source integration framework based on
-known xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[Enterprise
Integration
+known xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
Integration
Patterns].
Camel empowers you to define routing and mediation rules in a variety of
diff --git
a/docs/user-manual/modules/faq/pages/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc
b/docs/user-manual/modules/faq/pages/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc
index f9c4d7c..494242a 100644
---
a/docs/user-manual/modules/faq/pages/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc
+++
b/docs/user-manual/modules/faq/pages/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc
@@ -1,6 +1,6 @@
= Why can I not use when/otherwise in a Java Camel route?
-When using the xref:{eip-vc}:eips:choice-eip.adoc[Content Based Router] in
+When using the xref:components:eips:choice-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.
@@ -9,12 +9,12 @@ the following `when()` or `otherwise()` statement.
**Quick tip**
Use `.endChoice()` to return "back" to the
-xref:{eip-vc}:eips:choice-eip.adoc[Content Based Router].
+xref:components:eips:choice-eip.adoc[Content Based Router].
====
For example as shown in the route below where we use the
-xref:{eip-vc}:eips:loadBalance-eip.adoc[Load Balancer] inside the
-xref:{eip-vc}:eips:choice-eip.adoc[Content Based Router] in the first when:
+xref:components:eips:loadBalance-eip.adoc[Load Balancer] inside the
+xref:components:eips:choice-eip.adoc[Content Based Router] in the first when:
*Code will not compile*
@@ -28,7 +28,7 @@ from("direct:start")
.to("mock:result");
----
-Well the first issue is that the xref:{eip-vc}:eips:loadBalance-eip.adoc[Load
Balancer]
+Well the first issue is that the
xref:components: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:
@@ -58,10 +58,10 @@ xref:ROOT: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:{eip-vc}:eips:choice-eip.adoc[Content Based Router]. However that's not
+xref:components:eips:choice-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:{eip-vc}:eips:choice-eip.adoc[Content Based
+back to the scope of the xref:components:eips:choice-eip.adoc[Content Based
Router].
*Code compiles*
@@ -77,13 +77,13 @@ from("direct:start")
----
You only need to use `.endChoice()` when using certain
-xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[EIP]s which often have
additional
+xref:components:eips:enterprise-integration-patterns.adoc[EIP]s which often
have additional
methods to configure or as part of the
-xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[EIP] itself. For
example the
-xref:{eip-vc}:eips:split-eip.adoc[Splitter] EIP has a sub-route which denotes
the
+xref:components:eips:enterprise-integration-patterns.adoc[EIP] itself. For
example the
+xref:components: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:{eip-vc}:eips:choice-eip.adoc[Content Based Router]. Note
+to the xref:components:eips:choice-eip.adoc[Content Based Router]. Note
`.endChoice()` is *Since Camel 2.7*.
[[WhycanInotusewhenorotherwiseinaJavaCamelroute-Stillproblems]]
@@ -92,6 +92,6 @@ to the xref:{eip-vc}:eips:choice-eip.adoc[Content Based
Router]. Note
If there are still problems, then you can split your route into multiple
routes, and link them together using the
xref:components::direct-component.adoc[Direct]
component.
-There can be some combinations of
xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[EIP]s
+There can be some combinations of
xref:components:eips:enterprise-integration-patterns.adoc[EIP]s
that can hit limits in how far we can take the fluent builder DSL with
generics you can do in Java programming language (1.7 and below).
diff --git
a/docs/user-manual/modules/faq/pages/why-does-useoriginalmessage-with-error-handler-not-work-as-expected.adoc
b/docs/user-manual/modules/faq/pages/why-does-useoriginalmessage-with-error-handler-not-work-as-expected.adoc
index c90f540..aee6cc4 100644
---
a/docs/user-manual/modules/faq/pages/why-does-useoriginalmessage-with-error-handler-not-work-as-expected.adoc
+++
b/docs/user-manual/modules/faq/pages/why-does-useoriginalmessage-with-error-handler-not-work-as-expected.adoc
@@ -2,14 +2,14 @@
If you use the xref:ROOT:exception-clause.adoc[useOriginalMessage] option
from the Camel xref:ROOT:exception-clause.adoc[Error Handler] then it matters
-if you use this with
xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[EIP]s such as:
+if you use this with
xref:components:eips:enterprise-integration-patterns.adoc[EIP]s such as:
-* xref:{eip-vc}:eips:recipientList-eip.adoc[Recipient List]
-* xref:{eip-vc}:eips:split-eip.adoc[Splitter]
-* xref:{eip-vc}:eips:multicast-eip.adoc[Multicast]
+* xref:components:eips:recipientList-eip.adoc[Recipient List]
+* xref:components:eips:split-eip.adoc[Splitter]
+* xref:components:eips:multicast-eip.adoc[Multicast]
-Then the option `shareUnitOfWork` on these
xref:{eip-vc}:eips:enterprise-integration-patterns.adoc[EIP]s
+Then the option `shareUnitOfWork` on these
xref:components:eips:enterprise-integration-patterns.adoc[EIP]s
influence the message in use by the `useOriginalMessage` option.
-See more details at xref:{eip-vc}:eips:split-eip.adoc[Splitter] and further
below with
+See more details at xref:components:eips:split-eip.adoc[Splitter] and further
below with
the examples explaining this in more detail.
