You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by dj...@apache.org on 2020/03/13 01:14:09 UTC
[camel] 01/18: rearrange user-manual sources so they don't need
copying
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch issue-14698-rearrange-adocs
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 2ef4774b1e779d25dd59e304e50974f186195cf8
Author: David Jencks <dj...@apache.org>
AuthorDate: Wed Mar 11 14:50:27 2020 -0700
rearrange user-manual sources so they don't need copying
---
core/camel-core-engine/src/main/docs/antora.yml | 19 +
.../eips/pages}/aggregate-eip.adoc | 0
.../eips/pages}/batch-config-eip.adoc | 0
.../{eips => modules/eips/pages}/bean-eip.adoc | 0
.../{eips => modules/eips/pages}/choice-eip.adoc | 0
.../eips/pages}/circuitBreaker-eip.adoc | 0
.../eips/pages}/claimCheck-eip.adoc | 0
.../eips/pages}/content-based-router-eip.adoc | 0
.../eips/pages}/content-filter-eip.adoc | 0
.../eips/pages}/convertBodyTo-eip.adoc | 0
.../eips/pages}/customLoadBalancer-eip.adoc | 0
.../{eips => modules/eips/pages}/delay-eip.adoc | 0
.../eips/pages}/dynamic-router.adoc | 0
.../eips/pages}/dynamicRouter-eip.adoc | 0
.../{eips => modules/eips/pages}/enrich-eip.adoc | 0
.../eips/pages}/eventDrivenConsumer-eip.adoc | 0
.../{eips => modules/eips/pages}/failover-eip.adoc | 0
.../{eips => modules/eips/pages}/filter-eip.adoc | 0
.../{eips => modules/eips/pages}/from-eip.adoc | 0
.../{eips => modules/eips/pages}/hystrix-eip.adoc | 0
.../eips/pages}/hystrixConfiguration-eip.adoc | 0
.../eips/pages}/idempotentConsumer-eip.adoc | 0
.../{eips => modules/eips/pages}/inOnly-eip.adoc | 0
.../{eips => modules/eips/pages}/inOut-eip.adoc | 0
.../eips/pages}/loadBalance-eip.adoc | 0
.../docs/{eips => modules/eips/pages}/log-eip.adoc | 0
.../{eips => modules/eips/pages}/loop-eip.adoc | 0
.../{eips => modules/eips/pages}/marshal-eip.adoc | 0
.../eips/pages}/multicast-eip.adoc | 0
.../eips/pages}/onFallback-eip.adoc | 0
.../eips/pages}/otherwise-eip.adoc | 0
.../{eips => modules/eips/pages}/pipeline-eip.adoc | 0
.../eips/pages}/pollEnrich-eip.adoc | 0
.../{eips => modules/eips/pages}/process-eip.adoc | 0
.../{eips => modules/eips/pages}/random-eip.adoc | 0
.../eips/pages}/recipientList-eip.adoc | 0
.../eips/pages}/removeHeader-eip.adoc | 0
.../eips/pages}/removeHeaders-eip.adoc | 0
.../eips/pages}/removeProperties-eip.adoc | 0
.../eips/pages}/removeProperty-eip.adoc | 0
.../eips/pages}/requestReply-eip.adoc | 0
.../eips/pages}/resequence-eip.adoc | 0
.../eips/pages}/resilience4j-eip.adoc | 0
.../eips/pages}/resilience4jConfiguration-eip.adoc | 0
.../{eips => modules/eips/pages}/rollback-eip.adoc | 0
.../eips/pages}/roundRobin-eip.adoc | 0
.../eips/pages}/routingSlip-eip.adoc | 0
.../{eips => modules/eips/pages}/saga-eip.adoc | 0
.../{eips => modules/eips/pages}/sample-eip.adoc | 0
.../{eips => modules/eips/pages}/script-eip.adoc | 0
.../eips/pages}/serviceCall-eip.adoc | 0
.../{eips => modules/eips/pages}/setBody-eip.adoc | 0
.../eips/pages}/setHeader-eip.adoc | 0
.../eips/pages}/setOutHeader-eip.adoc | 0
.../eips/pages}/setProperty-eip.adoc | 0
.../{eips => modules/eips/pages}/sort-eip.adoc | 0
.../{eips => modules/eips/pages}/split-eip.adoc | 0
.../{eips => modules/eips/pages}/step-eip.adoc | 0
.../{eips => modules/eips/pages}/sticky-eip.adoc | 0
.../{eips => modules/eips/pages}/stop-eip.adoc | 0
.../eips/pages}/stream-config-eip.adoc | 0
.../{eips => modules/eips/pages}/threads-eip.adoc | 0
.../{eips => modules/eips/pages}/throttle-eip.adoc | 0
.../docs/{eips => modules/eips/pages}/to-eip.adoc | 0
.../docs/{eips => modules/eips/pages}/toD-eip.adoc | 0
.../{eips => modules/eips/pages}/topic-eip.adoc | 0
.../eips/pages}/transform-eip.adoc | 0
.../eips/pages}/unmarshal-eip.adoc | 0
.../{eips => modules/eips/pages}/validate-eip.adoc | 0
.../{eips => modules/eips/pages}/weighted-eip.adoc | 0
.../{eips => modules/eips/pages}/when-eip.adoc | 0
.../{eips => modules/eips/pages}/wireTap-eip.adoc | 0
core/camel-core-languages/src/main/docs/antora.yml | 19 +
.../languages/pages}/constant-language.adoc | 0
.../pages}/exchangeProperty-language.adoc | 0
.../languages/pages}/file-language.adoc | 0
.../languages/pages}/header-language.adoc | 0
.../languages/pages}/ref-language.adoc | 0
.../languages/pages}/simple-language.adoc | 0
.../languages/pages}/tokenize-language.adoc | 0
core/camel-xml-jaxp/src/main/docs/antora.yml | 19 +
.../languages/pages}/xtokenize-language.adoc | 0
.../modules/ROOT/pages/constant-language.adoc | 75 --
.../ROOT/pages/exchangeProperty-language.adoc | 61 --
.../modules/ROOT/pages/file-language.adoc | 295 -------
.../modules/ROOT/pages/header-language.adoc | 45 --
.../modules/ROOT/pages/ref-language.adoc | 58 --
.../modules/ROOT/pages/simple-language.adoc | 885 ---------------------
.../modules/ROOT/pages/tokenize-language.adoc | 40 -
.../modules/ROOT/pages/xtokenize-language.adoc | 32 -
docs/gulpfile.js | 52 +-
docs/user-manual/modules/ROOT/nav.adoc | 150 ++--
.../modules/ROOT/pages/aggregate-eip.adoc | 673 ----------------
.../modules/ROOT/pages/batch-config-eip.adoc | 19 -
docs/user-manual/modules/ROOT/pages/bean-eip.adoc | 97 ---
.../user-manual/modules/ROOT/pages/choice-eip.adoc | 77 --
.../modules/ROOT/pages/circuitBreaker-eip.adoc | 62 --
.../modules/ROOT/pages/claimCheck-eip.adoc | 273 -------
.../modules/ROOT/pages/constant-language.adoc | 75 --
.../ROOT/pages/content-based-router-eip.adoc | 80 --
.../modules/ROOT/pages/content-filter-eip.adoc | 66 --
.../modules/ROOT/pages/convertBodyTo-eip.adoc | 16 -
.../modules/ROOT/pages/customLoadBalancer-eip.adoc | 82 --
docs/user-manual/modules/ROOT/pages/delay-eip.adoc | 173 ----
.../modules/ROOT/pages/dynamicRouter-eip.adoc | 159 ----
.../user-manual/modules/ROOT/pages/enrich-eip.adoc | 198 -----
.../ROOT/pages/eventDrivenConsumer-eip.adoc | 59 --
.../ROOT/pages/exchangeProperty-language.adoc | 61 --
.../modules/ROOT/pages/failover-eip.adoc | 47 --
.../modules/ROOT/pages/file-language.adoc | 295 -------
.../user-manual/modules/ROOT/pages/filter-eip.adoc | 101 ---
docs/user-manual/modules/ROOT/pages/from-eip.adoc | 38 -
.../modules/ROOT/pages/header-language.adoc | 45 --
.../modules/ROOT/pages/hystrix-eip.adoc | 150 ----
.../ROOT/pages/hystrixConfiguration-eip.adoc | 44 -
.../modules/ROOT/pages/idempotentConsumer-eip.adoc | 45 --
.../user-manual/modules/ROOT/pages/inOnly-eip.adoc | 17 -
docs/user-manual/modules/ROOT/pages/inOut-eip.adoc | 17 -
.../modules/ROOT/pages/loadBalance-eip.adoc | 251 ------
docs/user-manual/modules/ROOT/pages/log-eip.adoc | 204 -----
docs/user-manual/modules/ROOT/pages/loop-eip.adoc | 171 ----
.../modules/ROOT/pages/marshal-eip.adoc | 45 --
.../modules/ROOT/pages/multicast-eip.adoc | 145 ----
.../modules/ROOT/pages/onFallback-eip.adoc | 84 --
.../modules/ROOT/pages/otherwise-eip.adoc | 62 --
.../modules/ROOT/pages/pipeline-eip.adoc | 97 ---
.../modules/ROOT/pages/pollEnrich-eip.adoc | 124 ---
.../modules/ROOT/pages/process-eip.adoc | 101 ---
.../user-manual/modules/ROOT/pages/random-eip.adoc | 8 -
.../modules/ROOT/pages/recipientList-eip.adoc | 375 ---------
.../modules/ROOT/pages/ref-language.adoc | 58 --
.../modules/ROOT/pages/removeHeader-eip.adoc | 40 -
.../modules/ROOT/pages/removeHeaders-eip.adoc | 26 -
.../modules/ROOT/pages/removeProperties-eip.adoc | 47 --
.../modules/ROOT/pages/removeProperty-eip.adoc | 46 --
.../modules/ROOT/pages/requestReply-eip.adoc | 49 --
.../modules/ROOT/pages/resequence-eip.adoc | 242 ------
.../modules/ROOT/pages/resilience4j-eip.adoc | 150 ----
.../ROOT/pages/resilience4jConfiguration-eip.adoc | 7 -
.../modules/ROOT/pages/rollback-eip.adoc | 242 ------
.../modules/ROOT/pages/roundRobin-eip.adoc | 36 -
.../modules/ROOT/pages/routingSlip-eip.adoc | 113 ---
docs/user-manual/modules/ROOT/pages/saga-eip.adoc | 455 -----------
.../user-manual/modules/ROOT/pages/sample-eip.adoc | 85 --
.../user-manual/modules/ROOT/pages/script-eip.adoc | 76 --
.../modules/ROOT/pages/serviceCall-eip.adoc | 619 --------------
.../modules/ROOT/pages/setBody-eip.adoc | 40 -
.../modules/ROOT/pages/setHeader-eip.adoc | 48 --
.../modules/ROOT/pages/setOutHeader-eip.adoc | 50 --
.../modules/ROOT/pages/setProperty-eip.adoc | 48 --
.../modules/ROOT/pages/simple-language.adoc | 885 ---------------------
docs/user-manual/modules/ROOT/pages/sort-eip.adoc | 70 --
docs/user-manual/modules/ROOT/pages/split-eip.adoc | 703 ----------------
docs/user-manual/modules/ROOT/pages/step-eip.adoc | 99 ---
.../user-manual/modules/ROOT/pages/sticky-eip.adoc | 46 --
docs/user-manual/modules/ROOT/pages/stop-eip.adoc | 23 -
.../modules/ROOT/pages/stream-config-eip.adoc | 20 -
.../modules/ROOT/pages/threads-eip.adoc | 52 --
.../modules/ROOT/pages/throttle-eip.adoc | 84 --
docs/user-manual/modules/ROOT/pages/to-eip.adoc | 90 ---
docs/user-manual/modules/ROOT/pages/toD-eip.adoc | 221 -----
.../modules/ROOT/pages/tokenize-language.adoc | 40 -
docs/user-manual/modules/ROOT/pages/topic-eip.adoc | 36 -
.../modules/ROOT/pages/transform-eip.adoc | 13 -
.../modules/ROOT/pages/unmarshal-eip.adoc | 44 -
.../modules/ROOT/pages/validate-eip.adoc | 74 --
.../modules/ROOT/pages/weighted-eip.adoc | 44 -
docs/user-manual/modules/ROOT/pages/when-eip.adoc | 62 --
.../modules/ROOT/pages/wireTap-eip.adoc | 208 -----
.../modules/ROOT/pages/xtokenize-language.adoc | 32 -
170 files changed, 162 insertions(+), 11547 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/antora.yml b/core/camel-core-engine/src/main/docs/antora.yml
new file mode 100644
index 0000000..18fe9ae
--- /dev/null
+++ b/core/camel-core-engine/src/main/docs/antora.yml
@@ -0,0 +1,19 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+name: manual
+version: latest
diff --git a/core/camel-core-engine/src/main/docs/eips/aggregate-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/aggregate-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/aggregate-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/aggregate-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/batch-config-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/batch-config-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/batch-config-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/batch-config-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/bean-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/bean-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/bean-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/bean-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/choice-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/choice-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/choice-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/choice-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/circuitBreaker-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/circuitBreaker-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/circuitBreaker-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/circuitBreaker-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/claimCheck-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/claimCheck-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/claimCheck-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/claimCheck-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/content-based-router-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/content-based-router-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/content-based-router-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/content-based-router-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/content-filter-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/content-filter-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/content-filter-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/content-filter-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/convertBodyTo-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/convertBodyTo-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/convertBodyTo-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/convertBodyTo-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/customLoadBalancer-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/customLoadBalancer-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/customLoadBalancer-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/customLoadBalancer-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/delay-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/delay-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/delay-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/delay-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/dynamic-router.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/dynamic-router.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/dynamic-router.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/dynamic-router.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/dynamicRouter-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/dynamicRouter-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/dynamicRouter-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/dynamicRouter-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/enrich-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/enrich-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/enrich-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/enrich-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/eventDrivenConsumer-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/eventDrivenConsumer-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/eventDrivenConsumer-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/eventDrivenConsumer-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/failover-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/failover-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/failover-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/failover-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/filter-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/filter-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/filter-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/filter-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/from-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/from-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/from-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/from-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/hystrix-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/hystrix-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/hystrix-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/hystrix-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/hystrixConfiguration-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/hystrixConfiguration-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/hystrixConfiguration-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/hystrixConfiguration-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/idempotentConsumer-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/idempotentConsumer-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/idempotentConsumer-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/idempotentConsumer-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/inOnly-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/inOnly-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/inOnly-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/inOnly-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/inOut-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/inOut-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/inOut-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/inOut-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/loadBalance-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/loadBalance-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/loadBalance-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/loadBalance-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/log-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/log-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/log-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/log-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/loop-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/loop-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/loop-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/loop-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/marshal-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/marshal-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/marshal-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/marshal-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/multicast-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/multicast-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/multicast-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/multicast-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/onFallback-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/onFallback-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/onFallback-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/onFallback-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/otherwise-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/otherwise-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/otherwise-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/otherwise-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/pipeline-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/pipeline-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/pipeline-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/pipeline-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/pollEnrich-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/pollEnrich-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/pollEnrich-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/pollEnrich-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/process-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/process-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/process-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/process-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/random-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/random-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/random-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/random-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/recipientList-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/recipientList-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/recipientList-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/recipientList-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/removeHeader-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/removeHeader-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/removeHeader-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/removeHeader-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/removeHeaders-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/removeHeaders-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/removeHeaders-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/removeHeaders-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/removeProperties-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/removeProperties-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/removeProperties-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/removeProperties-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/removeProperty-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/removeProperty-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/removeProperty-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/removeProperty-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/requestReply-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/requestReply-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/resequence-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/resequence-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/resequence-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/resequence-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/resilience4j-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/resilience4j-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/resilience4j-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/resilience4j-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/resilience4jConfiguration-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/resilience4jConfiguration-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/resilience4jConfiguration-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/resilience4jConfiguration-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/rollback-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/rollback-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/rollback-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/rollback-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/roundRobin-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/roundRobin-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/roundRobin-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/roundRobin-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/routingSlip-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/routingSlip-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/routingSlip-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/routingSlip-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/saga-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/saga-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/saga-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/saga-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/sample-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/sample-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/sample-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/sample-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/script-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/script-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/script-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/script-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/serviceCall-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/serviceCall-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/serviceCall-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/serviceCall-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/setBody-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/setBody-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/setBody-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/setBody-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/setHeader-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/setHeader-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/setHeader-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/setHeader-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/setOutHeader-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/setOutHeader-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/setOutHeader-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/setOutHeader-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/setProperty-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/setProperty-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/setProperty-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/setProperty-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/sort-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/sort-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/sort-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/sort-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/split-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/split-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/split-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/split-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/step-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/step-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/step-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/step-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/sticky-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/sticky-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/sticky-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/sticky-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/stop-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/stop-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/stop-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/stop-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/stream-config-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/stream-config-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/stream-config-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/stream-config-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/threads-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/threads-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/threads-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/threads-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/throttle-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/throttle-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/throttle-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/throttle-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/to-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/to-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/to-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/to-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/toD-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/toD-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/toD-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/toD-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/topic-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/topic-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/topic-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/topic-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/transform-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/transform-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/transform-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/transform-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/unmarshal-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/unmarshal-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/unmarshal-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/unmarshal-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/validate-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/validate-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/validate-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/validate-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/weighted-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/weighted-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/weighted-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/weighted-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/when-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/when-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/when-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/when-eip.adoc
diff --git a/core/camel-core-engine/src/main/docs/eips/wireTap-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/wireTap-eip.adoc
similarity index 100%
rename from core/camel-core-engine/src/main/docs/eips/wireTap-eip.adoc
rename to core/camel-core-engine/src/main/docs/modules/eips/pages/wireTap-eip.adoc
diff --git a/core/camel-core-languages/src/main/docs/antora.yml b/core/camel-core-languages/src/main/docs/antora.yml
new file mode 100644
index 0000000..18fe9ae
--- /dev/null
+++ b/core/camel-core-languages/src/main/docs/antora.yml
@@ -0,0 +1,19 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+name: manual
+version: latest
diff --git a/core/camel-core-languages/src/main/docs/constant-language.adoc b/core/camel-core-languages/src/main/docs/modules/languages/pages/constant-language.adoc
similarity index 100%
rename from core/camel-core-languages/src/main/docs/constant-language.adoc
rename to core/camel-core-languages/src/main/docs/modules/languages/pages/constant-language.adoc
diff --git a/core/camel-core-languages/src/main/docs/exchangeProperty-language.adoc b/core/camel-core-languages/src/main/docs/modules/languages/pages/exchangeProperty-language.adoc
similarity index 100%
rename from core/camel-core-languages/src/main/docs/exchangeProperty-language.adoc
rename to core/camel-core-languages/src/main/docs/modules/languages/pages/exchangeProperty-language.adoc
diff --git a/core/camel-core-languages/src/main/docs/file-language.adoc b/core/camel-core-languages/src/main/docs/modules/languages/pages/file-language.adoc
similarity index 100%
rename from core/camel-core-languages/src/main/docs/file-language.adoc
rename to core/camel-core-languages/src/main/docs/modules/languages/pages/file-language.adoc
diff --git a/core/camel-core-languages/src/main/docs/header-language.adoc b/core/camel-core-languages/src/main/docs/modules/languages/pages/header-language.adoc
similarity index 100%
rename from core/camel-core-languages/src/main/docs/header-language.adoc
rename to core/camel-core-languages/src/main/docs/modules/languages/pages/header-language.adoc
diff --git a/core/camel-core-languages/src/main/docs/ref-language.adoc b/core/camel-core-languages/src/main/docs/modules/languages/pages/ref-language.adoc
similarity index 100%
rename from core/camel-core-languages/src/main/docs/ref-language.adoc
rename to core/camel-core-languages/src/main/docs/modules/languages/pages/ref-language.adoc
diff --git a/core/camel-core-languages/src/main/docs/simple-language.adoc b/core/camel-core-languages/src/main/docs/modules/languages/pages/simple-language.adoc
similarity index 100%
rename from core/camel-core-languages/src/main/docs/simple-language.adoc
rename to core/camel-core-languages/src/main/docs/modules/languages/pages/simple-language.adoc
diff --git a/core/camel-core-languages/src/main/docs/tokenize-language.adoc b/core/camel-core-languages/src/main/docs/modules/languages/pages/tokenize-language.adoc
similarity index 100%
rename from core/camel-core-languages/src/main/docs/tokenize-language.adoc
rename to core/camel-core-languages/src/main/docs/modules/languages/pages/tokenize-language.adoc
diff --git a/core/camel-xml-jaxp/src/main/docs/antora.yml b/core/camel-xml-jaxp/src/main/docs/antora.yml
new file mode 100644
index 0000000..18fe9ae
--- /dev/null
+++ b/core/camel-xml-jaxp/src/main/docs/antora.yml
@@ -0,0 +1,19 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+name: manual
+version: latest
diff --git a/core/camel-xml-jaxp/src/main/docs/xtokenize-language.adoc b/core/camel-xml-jaxp/src/main/docs/modules/languages/pages/xtokenize-language.adoc
similarity index 100%
rename from core/camel-xml-jaxp/src/main/docs/xtokenize-language.adoc
rename to core/camel-xml-jaxp/src/main/docs/modules/languages/pages/xtokenize-language.adoc
diff --git a/docs/components/modules/ROOT/pages/constant-language.adoc b/docs/components/modules/ROOT/pages/constant-language.adoc
deleted file mode 100644
index a8ef0e0..0000000
--- a/docs/components/modules/ROOT/pages/constant-language.adoc
+++ /dev/null
@@ -1,75 +0,0 @@
-[[constant-language]]
-= Constant Language
-:page-source: core/camel-core-languages/src/main/docs/constant-language.adoc
-
-*Since Camel 1.5*
-
-The Constant Expression Language is really just a way to specify
-constant strings as a type of expression.
-
-[NOTE]
-====
-This is a fixed constant value that is only set once during starting up the route,
-do not use this if you want dynamic values during routing.
-====
-
-== Constant Options
-
-
-// language options: START
-The Constant language supports 1 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
-
-
-== Example usage
-
-The setHeader element of the Spring DSL can utilize a constant
-expression like:
-
-[source,xml]
-----
-<route>
- <from uri="seda:a"/>
- <setHeader name="theHeader">
- <constant>the value</constant>
- </setHeader>
- <to uri="mock:b"/>
-</route>
-----
-
-in this case, the Message coming from the seda:a
-Endpoint will have 'theHeader' header set to the
-constant value 'the value'.
-
-And the same example using Java DSL:
-
-[source,java]
-----
-from("seda:a")
- .setHeader("theHeader", constant("the value"))
- .to("mock:b");
-----
-
-== Loading constant from external resource
-
-You can externalize the constant and have Camel load it from a resource
-such as `"classpath:"`, `"file:"`, or `"http:"`. +
- This is done using the following syntax: `"resource:scheme:location"`,
-eg to refer to a file on the classpath you can do:
-
-[source,java]
-----
-.setHeader("myHeader").constant("resource:classpath:constant.txt")
-----
-
-== Dependencies
-
-The Constant language is part of *camel-core*.
diff --git a/docs/components/modules/ROOT/pages/exchangeProperty-language.adoc b/docs/components/modules/ROOT/pages/exchangeProperty-language.adoc
deleted file mode 100644
index c6c0a60..0000000
--- a/docs/components/modules/ROOT/pages/exchangeProperty-language.adoc
+++ /dev/null
@@ -1,61 +0,0 @@
-[[exchangeProperty-language]]
-= ExchangeProperty Language
-:page-source: core/camel-core-languages/src/main/docs/exchangeProperty-language.adoc
-
-*Since Camel 2.0*
-
-The ExchangeProperty Expression Language allows you to extract values of
-named exchange properties.
-
-== Exchange Property Options
-
-// language options: START
-The ExchangeProperty language supports 1 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
-
-== Example usage
-
-The recipientList element of the Spring DSL can utilize a
-exchangeProperty expression like:
-
-In this case, the list of recipients are contained in the property
-'myProperty'.
-
-[source,xml]
-----
-<route>
- <from uri="direct:a" />
- <recipientList>
- <exchangeProperty>myProperty</exchangeProperty>
- </recipientList>
-</route>
-----
-
-And the same example in Java DSL:
-
-[source,java]
-----
-from("direct:a").recipientList(exchangeProperty("myProperty"));
-----
-
-And with a slightly different syntax where you use the builder to the
-fullest (i.e. avoid using parameters but using stacked operations,
-notice that exchangeProperty is not a parameter but a stacked method
-call)
-
-[source,java]
-----
-from("direct:a").recipientList().exchangeProperty("myProperty");
-----
-
-== Dependencies
-
-The ExchangeProperty language is part of *camel-core*.
\ No newline at end of file
diff --git a/docs/components/modules/ROOT/pages/file-language.adoc b/docs/components/modules/ROOT/pages/file-language.adoc
deleted file mode 100644
index 88bfa2c..0000000
--- a/docs/components/modules/ROOT/pages/file-language.adoc
+++ /dev/null
@@ -1,295 +0,0 @@
-[[file-language]]
-= File Language
-:page-source: core/camel-core-languages/src/main/docs/file-language.adoc
-
-*Since Camel 1.1*
-
-The file language is merged with
-xref:simple-language.adoc[Simple] language which means you can use all the file
-syntax directly within the simple language.
-
-The File Expression Language is an extension to the
-xref:simple-language.adoc[Simple] language, adding file related capabilities.
-These capabilities are related to common use cases working with file
-path and names. The goal is to allow expressions to be used with the
-File and FTP components for setting
-dynamic file patterns for both consumer and producer.
-
-== File Language options
-
-// language options: START
-The File language supports 2 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| resultType | | String | Sets the class name of the result type (type from output)
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
-
-== Syntax
-
-This language is an *extension* to the xref:simple-language.adoc[Simple] language
-so the xref:simple-language.adoc[Simple] syntax applies also. So the table below
-only lists the additional. +
- As opposed to xref:simple-language.adoc[Simple] language
-xref:file-language.adoc[File Language] also supports
-xref:constant-language.adoc[Constant] expressions so you can enter a fixed
-filename.
-
-All the file tokens use the same expression name as the method on the
-`java.io.File` object, for instance `file:absolute` refers to the
-`java.io.File.getAbsolute()` method. Notice that not all expressions are
-supported by the current Exchange. For instance the xref:components::ftp-component.adoc[FTP]
-component supports some of the options, where as the
-File component supports all of them.
-
-
-[width="100%",cols="10%,10%,10%,10%,10%,25%,25%",options="header",]
-|===
-|Expression |Type |File Consumer |File Producer |FTP Consumer |FTP Producer |Description
-
-|file:name |String |yes |no |yes |no |refers to the file name (is relative to the starting directory, see note
-below)
-
-|file:name.ext |String |yes |no |yes |no |refers to the file extension only
-
-|file:name.ext.single |String |yes |no |yes |no |refers to the file extension. If the file
-extension has mutiple dots, then this expression strips and only returns
-the last part.
-
-|file:name.noext |String |yes |no |yes |no |refers to the file name with no extension (is relative to the starting
-directory, see note below)
-
-|file:name.noext.single |String |yes |no |yes |no |refers to the file name with no extension (is
-relative to the starting directory, see note below). If the file
-extension has multiple dots, then this expression strips only the last
-part, and keep the others.
-
-|file:onlyname |String |yes |no |yes |no |refers to the file name only with no leading paths.
-
-|file:onlyname.noext |String |yes |no |yes |no |refers to the file name only with no extension and with no leading
-paths.
-
-|file:onlyname.noext.single |String |yes |no |yes |no |refers to the file name only with no extension and
-with no leading paths. If the file extension has multiple dots, then
-this expression strips only the last part, and keep the others.
-
-|file:ext |String |yes |no |yes |no |refers to the file extension only
-
-|file:parent |String |yes |no |yes |no |refers to the file parent
-
-|file:path |String |yes |no |yes |no |refers to the file path
-
-|file:absolute |Boolean |yes |no |no |no |refers to whether the file is regarded as absolute or relative
-
-|file:absolute.path |String |yes |no |no |no |refers to the absolute file path
-
-|file:length |Long |yes |no |yes |no |refers to the file length returned as a Long type
-
-|file:size |Long |yes |no |yes |no |refers to the file length returned as a Long type
-
-|file:modified |Date |yes |no |yes |no |Refers to the file last modified returned as a Date type
-
-|date:_command:pattern_ |String |yes |yes |yes |yes |for date formatting using the `java.text.SimpleDateFormat` patterns. Is
-an *extension* to the xref:simple-language.adoc[Simple] language. Additional
-command is: *file* (consumers only) for the last modified timestamp of
-the file. Notice: all the commands from the xref:simple-language.adoc[Simple]
-language can also be used.
-|===
-
-== File token example
-
-=== Relative paths
-
-We have a `java.io.File` handle for the file `hello.txt` in the
-following *relative* directory: `.\filelanguage\test`. And we configure
-our endpoint to use this starting directory `.\filelanguage`. The file
-tokens will return as:
-
-[width="100%",cols="50%,50%",options="header",]
-|===
-|Expression |Returns
-
-|file:name |test\hello.txt
-
-|file:name.ext |txt
-
-|file:name.noext |test\hello
-
-|file:onlyname |hello.txt
-
-|file:onlyname.noext |hello
-
-|file:ext |txt
-
-|file:parent |filelanguage\test
-
-|file:path |filelanguage\test\hello.txt
-
-|file:absolute |false
-
-|file:absolute.path |\workspace\camel\camel-core\target\filelanguage\test\hello.txt
-|===
-
-=== Absolute paths
-
-We have a `java.io.File` handle for the file `hello.txt` in the
-following *absolute* directory:
-`\workspace\camel\camel-core\target\filelanguage\test`. And we configure
-out endpoint to use the absolute starting directory
-`\workspace\camel\camel-core\target\filelanguage`. The file tokens will
-return as:
-
-[width="100%",cols="50%,50%",options="header",]
-|===
-|Expression |Returns
-
-|file:name |test\hello.txt
-
-|file:name.ext |txt
-
-|file:name.noext |test\hello
-
-|file:onlyname |hello.txt
-
-|file:onlyname.noext |hello
-
-|file:ext |txt
-
-|file:parent |\workspace\camel\camel-core\target\filelanguage\test
-
-|file:path |\workspace\camel\camel-core\target\filelanguage\test\hello.txt
-
-|file:absolute |true
-
-|file:absolute.path |\workspace\camel\camel-core\target\filelanguage\test\hello.txt
-|===
-
-== Samples
-
-You can enter a fixed xref:constant-language.adoc[Constant] expression such as
-`myfile.txt`:
-
-[source]
-----
-fileName="myfile.txt"
-----
-
-Lets assume we use the file consumer to read files and want to move the
-read files to backup folder with the current date as a sub folder. This
-can be archieved using an expression like:
-
-[source]
-----
-fileName="backup/${date:now:yyyyMMdd}/${file:name.noext}.bak"
-----
-
-relative folder names are also supported so suppose the backup folder
-should be a sibling folder then you can append .. as:
-
-[source]
-----
-fileName="../backup/${date:now:yyyyMMdd}/${file:name.noext}.bak"
-----
-
-As this is an extension to the xref:simple-language.adoc[Simple] language we have
-access to all the goodies from this language also, so in this use case
-we want to use the in.header.type as a parameter in the dynamic
-expression:
-
-[source]
-----
-fileName="../backup/${date:now:yyyyMMdd}/type-${in.header.type}/backup-of-${file:name.noext}.bak"
-----
-
-If you have a custom Date you want to use in the expression then Camel
-supports retrieving dates from the message header.
-
-[source]
-----
-fileName="orders/order-${in.header.customerId}-${date:in.header.orderDate:yyyyMMdd}.xml"
-----
-
-And finally we can also use a bean expression to invoke a POJO class
-that generates some String output (or convertible to String) to be used:
-
-[source]
-----
-fileName="uniquefile-${bean:myguidgenerator.generateid}.txt"
-----
-
-And of course all this can be combined in one expression where you can
-use the xref:file-language.adoc[File Language], xref:file-language.adoc[Simple]
-and the xref:components::bean-component.adoc[Bean] language in one combined expression. This
-is pretty powerful for those common file path patterns.
-
-== Using Spring PropertyPlaceholderConfigurer together with the File component
-
-In Camel you can use the xref:file-language.adoc[File Language] directly
-from the xref:simple-language.adoc[Simple] language which makes a
-Content Based Router easier to do in
-Spring XML, where we can route based on file extensions as shown below:
-
-[source,xml]
-----
-<from uri="file://input/orders"/>
- <choice>
- <when>
- <simple>${file:ext} == 'txt'</simple>
- <to uri="bean:orderService?method=handleTextFiles"/>
- </when>
- <when>
- <simple>${file:ext} == 'xml'</simple>
- <to uri="bean:orderService?method=handleXmlFiles"/>
- </when>
- <otherwise>
- <to uri="bean:orderService?method=handleOtherFiles"/>
- </otherwise>
- </choice>
-----
-
-If you use the `fileName` option on the File endpoint
-to set a dynamic filename using the xref:file-language.adoc[File Language] then make sure you +
- use the alternative syntax to avoid
-clashing with Springs `PropertyPlaceholderConfigurer`.
-
-*bundle-context.xml*
-
-[source,xml]
-----
-<bean id="propertyPlaceholder" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
- <property name="location" value="classpath:bundle-context.cfg" />
-</bean>
-
-<bean id="sampleRoute" class="SampleRoute">
- <property name="fromEndpoint" value="${fromEndpoint}" />
- <property name="toEndpoint" value="${toEndpoint}" />
-</bean>
-----
-
-*bundle-context.cfg*
-
-[source]
-----
-fromEndpoint=activemq:queue:test
-toEndpoint=file://fileRoute/out?fileName=test-$simple{date:now:yyyyMMdd}.txt
-----
-
-Notice how we use the $simple\{ } syntax in the `toEndpoint` above. +
- If you don't do this, there is a clash and Spring will throw an
-exception like
-
-[source,java]
-----------------------------------------------------------------------------------------------------
-org.springframework.beans.factory.BeanDefinitionStoreException:
-Invalid bean definition with name 'sampleRoute' defined in class path resource [bundle-context.xml]:
-Could not resolve placeholder 'date:now:yyyyMMdd'
-----------------------------------------------------------------------------------------------------
-
-== Dependencies
-
-The File language is part of *camel-core*.
diff --git a/docs/components/modules/ROOT/pages/header-language.adoc b/docs/components/modules/ROOT/pages/header-language.adoc
deleted file mode 100644
index c2134f4..0000000
--- a/docs/components/modules/ROOT/pages/header-language.adoc
+++ /dev/null
@@ -1,45 +0,0 @@
-[[header-language]]
-= Header Language
-:page-source: core/camel-core-languages/src/main/docs/header-language.adoc
-
-*Since Camel 1.5*
-
-The Header Expression Language allows you to extract values of named
-headers.
-
-== Header Options
-
-// language options: START
-The Header language supports 1 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
-
-== Example usage
-
-The recipientList element of the Spring DSL can utilize a header
-expression like:
-
-In this case, the list of recipients are contained in the header
-'myHeader'.
-
-And the same example in Java DSL:
-
-And with a slightly different syntax where you use the builder to the
-fullest (i.e. avoid using parameters but using stacked operations,
-notice that header is not a parameter but a stacked method call)
-
-[source,java]
-----
-from("direct:a").recipientList().header("myHeader");
-----
-
-== Dependencies
-
-The Header language is part of *camel-core*.
\ No newline at end of file
diff --git a/docs/components/modules/ROOT/pages/ref-language.adoc b/docs/components/modules/ROOT/pages/ref-language.adoc
deleted file mode 100644
index 0b86da1..0000000
--- a/docs/components/modules/ROOT/pages/ref-language.adoc
+++ /dev/null
@@ -1,58 +0,0 @@
-[[ref-language]]
-= Ref Language
-:page-source: core/camel-core-languages/src/main/docs/ref-language.adoc
-
-*Since Camel 2.8*
-
-The Ref Expression Language is really just a way to lookup a custom
-Expression or Predicate from the Registry.
-
-This is particular useable in XML DSLs.
-
-== Ref Language options
-
-// language options: START
-The Ref language supports 1 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
-
-== Example usage
-
-The Splitter in XML DSL can utilize a custom
-expression using `<ref>` like:
-
-[source,xml]
-----
-<bean id="myExpression" class="com.mycompany.MyCustomExpression"/>
-
-<route>
- <from uri="seda:a"/>
- <split>
- <ref>myExpression</ref>
- <to uri="mock:b"/>
- </split>
-</route>
-----
-
-in this case, the Message coming from the seda:a
-Endpoint will be splitted using a custom
-Expression which has the id `myExpression` in the
-Registry.
-
-And the same example using Java DSL:
-
-[source,java]
-----
-from("seda:a").split().ref("myExpression").to("seda:b");
-----
-
-== Dependencies
-
-The Ref language is part of *camel-core*.
\ No newline at end of file
diff --git a/docs/components/modules/ROOT/pages/simple-language.adoc b/docs/components/modules/ROOT/pages/simple-language.adoc
deleted file mode 100644
index c135562..0000000
--- a/docs/components/modules/ROOT/pages/simple-language.adoc
+++ /dev/null
@@ -1,885 +0,0 @@
-[[simple-language]]
-= Simple Language
-:page-source: core/camel-core-languages/src/main/docs/simple-language.adoc
-
-*Since Camel 1.1*
-
-The Simple Expression Language was a really simple language when it was
-created, but has since grown more powerful. It is primarily intended for
-being a really small and simple language for evaluating
-Expressions and Predicates
-without requiring any new dependencies or knowledge of
-xref:components::xpath-language.adoc[XPath]; so it is ideal for testing in camel-core. The
-idea was to cover 95% of the common use cases when you need a little bit
-of expression based script in your Camel routes.
-
-However for much more complex use cases you are generally recommended to
-choose a more expressive and powerful language such as:
-
-* xref:components::groovy-language.adoc[Groovy]
-* xref:components::spel-language.adoc[SpEL]
-* xref:components::mvel-component.adoc[MVEL]
-* xref:components::ognl-language.adoc[OGNL]
-
-The simple language uses `${body`} placeholders for complex expressions
-where the expression contains constant literals. The $\{ } placeholders
-can be omitted if the expression is only the token itself.
-
-[TIP]
-====
-*Alternative syntax*
-
-You can also use the alternative syntax which
-uses `$simple{ }` as placeholders. This can be used in situations to avoid clashes when using for example
-Spring property placeholder together with Camel.
-====
-
-== Simple Language options
-
-// language options: START
-The Simple language supports 2 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| resultType | | String | Sets the class name of the result type (type from output)
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
-
-== Variables
-
-[width="100%",cols="10%,10%,80%",options="header",]
-|=======================================================================
-|Variable |Type |Description
-
-|camelId |String |the CamelContext name
-
-|camelContext.*OGNL* |Object |the CamelContext invoked using a Camel OGNL expression.
-
-|exchange |Exchange |the Exchange
-
-|exchange.*OGNL* |Object |the Exchange invoked using a Camel
-OGNL expression.
-
-|exchangeId |String |the exchange id
-
-|id |String |the input message id
-
-|body |Object |the input body
-
-|in.body |Object |*deprecated* the input body
-
-|body.*OGNL* |Object |the input body invoked using a Camel OGNL expression.
-
-|in.body.*OGNL* |Object |*deprecated* the input body invoked using a Camel OGNL expression.
-
-|bodyAs(_type_) |Type |Converts the body to the given type determined by its
-classname. The converted body can be null.
-
-|bodyAs(_type_).*OGNL* |Object |Converts the body to the given type determined by its
-classname and then invoke methods using a Camel OGNL expression. The
-converted body can be null.
-
-|bodyOneLine | String | Converts the body to a String and removes all line-breaks so the string is in one line.
-
-|mandatoryBodyAs(_type_) |Type |Converts the body to the given type determined by its
-classname, and expects the body to be not null.
-
-|mandatoryBodyAs(_type_).*OGNL* |Object |Converts the body to the given type determined by its
-classname and then invoke methods using a Camel OGNL expression.
-
-|header.foo |Object |refer to the input foo header
-
-|header:foo |Object |refer to the input foo header
-
-|header[foo] |Object |refer to the input foo header
-
-|headers.foo |Object |refer to the input foo header
-
-|headers:foo |Object |refer to the input foo header
-
-|headers[foo] |Object |refer to the input foo header
-
-|in.header.foo |Object |*deprecated* refer to the input foo header
-
-|in.header:foo |Object |*deprecated* refer to the input foo header
-
-|in.header[foo] |Object |*deprecated* refer to the input foo header
-
-|in.headers.foo |Object |*deprecated* refer to the input foo header
-
-|in.headers:foo |Object |*deprecated* refer to the input foo header
-
-|in.headers[foo] |Object |*deprecated* refer to the input foo header
-
-|header.foo[bar] |Object |regard input foo header as a map and perform lookup on the
-map with bar as key
-
-|in.header.foo[bar] |Object |*deprecated* regard input foo header as a map and perform lookup on the
-map with bar as key
-
-|in.headers.foo[bar] |Object |*deprecated* regard input foo header as a map and perform lookup on the
-map with bar as key
-
-|header.foo.*OGNL* |Object |refer to the input foo header and invoke its value using a
-Camel OGNL expression.
-
-|in.header.foo.*OGNL* |Object |*deprecated* refer to the input foo header and invoke its value using a
-Camel OGNL expression.
-
-|in.headers.foo.*OGNL* |Object |*deprecated* refer to the input foo header and invoke its value using a
-Camel OGNL expression.
-
-|headerAs(_key_,_type_) |Type |converts the header to the given type determined by its
-classname
-
-|headers |Map |refer to the input headers
-
-|in.headers |Map |*deprecated* refer to the input headers
-
-|exchangeProperty.foo |Object |refer to the foo property on the exchange
-
-|exchangeProperty[foo] |Object |refer to the foo property on the exchange
-
-|exchangeProperty.foo.*OGNL* |Object |refer to the foo property on the exchange and invoke its
-value using a Camel OGNL expression.
-
-|sys.foo |String |refer to the JVM system property
-
-|sysenv.foo |String |refer to the system environment variable
-
-|env.foo |String |refer to the system environment variable
-
-|exception |Object |refer to the exception object on the exchange, is *null* if
-no exception set on exchange. Will fallback and grab caught exceptions
-(`Exchange.EXCEPTION_CAUGHT`) if the Exchange has any.
-
-|exception.*OGNL* |Object |refer to the exchange exception invoked using a Camel OGNL
-expression object
-
-|exception.message |String |refer to the exception.message on the exchange, is *null* if no
-exception set on exchange. Will fallback and grab caught exceptions
-(`Exchange.EXCEPTION_CAUGHT`) if the Exchange has any.
-
-|exception.stacktrace |String |refer to the exception.stracktrace on the exchange, is
-*null* if no exception set on exchange. Will fallback and grab caught
-exceptions (`Exchange.EXCEPTION_CAUGHT`) if the Exchange has any.
-
-|date:_command_ |Date |evaluates to a Date object.
-Supported commands are: *now* for current timestamp, *in.header.xxx* or
-*header.xxx* to use the Date object header with the key xxx.
-*exchangeProperty.xxx* to use the Date object in the exchange property with the key xxx.
-*file* for the last modified timestamp of the file (available with a File consumer).
-Command accepts offsets such as: *now-24h* or *in.header.xxx+1h* or even *now+1h30m-100*.
-
-|date:_command:pattern_ |String |Date formatting using `java.text.SimpleDateFormat` patterns.
-
-|date-with-timezone:_command:timezone:pattern_ |String |Date formatting using `java.text.SimpleDateFormat` timezones and patterns.
-
-|bean:_bean expression_ |Object |Invoking a bean expression using the xref:components::bean-component.adoc[Bean] language.
-Specifying a method name you must use dot as separator. We also support
-the ?method=methodname syntax that is used by the xref:components::bean-component.adoc[Bean]
-component. Camel will by default lookup a bean by the given name. However if you need to refer
-to a bean class (such as calling a static method) then you can prefix with type, such as `bean:type:fqnClassName`.
-
-|`properties:key:default` |String |Lookup a property with the given key. If the key does
-not exists or has no value, then an optional default value can be
-specified.
-
-|routeId |String |Returns the id of the current route the
-Exchange is being routed.
-
-|stepId |String |Returns the id of the current step the
-Exchange is being routed.
-
-|threadName |String |Returns the name of the current thread. Can be used for
-logging purpose.
-
-|hostname |String |Returns the local hostname (may be empty if not possible to resolve).
-
-|ref:xxx |Object |To lookup a bean from the Registry with
-the given id.
-
-|type:name.field |Object |To refer to a type or field by its FQN name. To refer to a
-field you can append .FIELD_NAME. For example you can refer to the
-constant field from Exchange as: `org.apache.camel.Exchange.FILE_NAME`
-
-|null |null |represents a *null*
-
-|random_(value)_ |Integer |returns a random Integer between 0 (included) and _value_
-(excluded)
-
-|random_(min,max)_ |Integer |returns a random Integer between _min_ (included) and
-_max_ (excluded)
-
-|collate(group) |List |The collate function iterates the message body and groups
-the data into sub lists of specified size. This can be used with the
-Splitter EIP to split a message body and group/batch
-the splitted sub message into a group of N sub lists. This method works
-similar to the collate method in Groovy.
-
-|skip(number) |Iterator |The skip function iterates the message body and skips
-the first number of items. This can be used with the
-Splitter EIP to split a message body and skip the first N number of items.
-
-|messageHistory |String |The message history of the current exchange how it has
-been routed. This is similar to the route stack-trace message history
-the error handler logs in case of an unhandled exception.
-
-|messageHistory(false) |String |As messageHistory but without the exchange details (only
-includes the route strack-trace). This can be used if you do not want to
-log sensitive data from the message itself.
-|=======================================================================
-
-== OGNL expression support
-
-INFO:Camel's OGNL support is for invoking methods only. You cannot access
-fields. Camel support accessing the length field of Java arrays.
-
-
-The xref:simple-language.adoc[Simple] and xref:simple-language.adoc[Bean] language now
-supports a Camel OGNL notation for invoking beans in a chain like
-fashion. Suppose the Message IN body contains a POJO which has a `getAddress()`
-method.
-
-Then you can use Camel OGNL notation to access the address object:
-
-[source,java]
---------------------------------
-simple("${body.address}")
-simple("${body.address.street}")
-simple("${body.address.zip}")
---------------------------------
-
-Camel understands the shorthand names for getters, but you can invoke
-any method or use the real name such as:
-
-[source,java]
---------------------------------------
-simple("${body.address}")
-simple("${body.getAddress.getStreet}")
-simple("${body.address.getZip}")
-simple("${body.doSomething}")
---------------------------------------
-
-You can also use the null safe operator (`?.`) to avoid NPE if for
-example the body does NOT have an address
-
-[source,java]
-----------------------------------
-simple("${body?.address?.street}")
-----------------------------------
-
-It is also possible to index in `Map` or `List` types, so you can do:
-
-[source,java]
----------------------------
-simple("${body[foo].name}")
----------------------------
-
-To assume the body is `Map` based and lookup the value with `foo` as
-key, and invoke the `getName` method on that value.
-
-If the key has space, then you *must* enclose the key with quotes, for
-example 'foo bar':
-
-[source,java]
----------------------------------
-simple("${body['foo bar'].name}")
----------------------------------
-
-You can access the `Map` or `List` objects directly using their key name
-(with or without dots) :
-
-[source,java]
-------------------------------
-simple("${body[foo]}")
-simple("${body[this.is.foo]}")
-------------------------------
-
-Suppose there was no value with the key `foo` then you can use the null
-safe operator to avoid the NPE as shown:
-
-[source,java]
-----------------------------
-simple("${body[foo]?.name}")
-----------------------------
-
-You can also access `List` types, for example to get lines from the
-address you can do:
-
-[source,java]
-----------------------------------
-simple("${body.address.lines[0]}")
-simple("${body.address.lines[1]}")
-simple("${body.address.lines[2]}")
-----------------------------------
-
-There is a special `last` keyword which can be used to get the last
-value from a list.
-
-[source,java]
--------------------------------------
-simple("${body.address.lines[last]}")
--------------------------------------
-
-And to get the 2nd last you can subtract a number, so we can use
-`last-1` to indicate this:
-
-[source,java]
----------------------------------------
-simple("${body.address.lines[last-1]}")
----------------------------------------
-
-And the 3rd last is of course:
-
-[source,java]
----------------------------------------
-simple("${body.address.lines[last-2]}")
----------------------------------------
-
-And you can call the size method on the list with
-
-[source,java]
-------------------------------------
-simple("${body.address.lines.size}")
-------------------------------------
-
-Camel supports the length field for Java arrays as well, eg:
-
-[source,java]
----------------------------------------------------
-String[] lines = new String[]{"foo", "bar", "cat"};
-exchange.getIn().setBody(lines);
-
-simple("There are ${body.length} lines")
----------------------------------------------------
-
-And yes you can combine this with the operator support as shown below:
-
-[source,java]
-------------------------------------
-simple("${body.address.zip} > 1000")
-------------------------------------
-
-== Operator support
-
-The parser is limited to only support a single operator.
-
-To enable it the left value must be enclosed in $\{ }. The syntax is:
-
-[source]
---------------------------
-${leftValue} OP rightValue
---------------------------
-
-Where the `rightValue` can be a String literal enclosed in `' '`,
-`null`, a constant value or another expression enclosed in $\{ }.
-
-IMPORTANT: There *must* be spaces around the operator.
-
-Camel will automatically type convert the rightValue type to the
-leftValue type, so it is able to eg. convert a string into a numeric so
-you can use > comparison for numeric values.
-
-The following operators are supported:
-
-[width="100%",cols="50%,50%",options="header",]
-|===
-|Operator |Description
-
-|== |equals
-
-|=~ |equals ignore case (will ignore case when comparing String values)
-
-|> |greater than
-
-|>= |greater than or equals
-
-|< |less than
-
-|<= |less than or equals
-
-|!= |not equals
-
-|!=~ |not equals ignore case (will ignore case when comparing String values)
-
-|contains |For testing if contains in a string based value
-
-|!contains |For testing if not contains in a string based value
-
-|~~ |For testing if contains by ignoring case sensitivity in a string based value
-
-|!~~ |For testing if not contains by ignoring case sensitivity in a string based value
-
-|regex |For matching against a given regular expression pattern defined as a
-String value
-
-|!regex |For not matching against a given regular expression pattern defined as a
-String value
-
-|in |For matching if in a set of values, each element must be separated by
-comma. If you want to include an empty value, then it must be defined using double comma, eg ',,bronze,silver,gold', which
-is a set of four values with an empty value and then the three medals.
-
-|!in |For matching if not in a set of values, each element must be separated
-by comma. If you want to include an empty value, then it must be defined using double comma, eg ',,bronze,silver,gold', which
-is a set of four values with an empty value and then the three medals.
-
-|is |For matching if the left hand side type is an instanceof the value.
-
-|!is |For matching if the left hand side type is not an instanceof the value.
-
-|range |For matching if the left hand side is within a range of values defined
-as numbers: `from..to`..
-
-|!range |For matching if the left hand side is not within a range of values
-defined as numbers: `from..to`. .
-
-|startsWith |For testing if the left hand side string starts
-with the right hand string.
-
-|endsWith |For testing if the left hand side string ends with
-the right hand string.
-|===
-
-And the following unary operators can be used:
-
-[width="100%",cols="50%,50%",options="header",]
-|===
-|Operator |Description
-
-|++ |To increment a number by one. The left hand side must be a
-function, otherwise parsed as literal.
-
-|-- |To decrement a number by one. The left hand side must be a
-function, otherwise parsed as literal.
-
-|\ |To escape a value, eg \$, to indicate a $ sign.
-Special: Use \n for new line, \t for tab, and \r for carriage return.
-*Notice:* Escaping is *not* supported using the
-xref:file-language.adoc[File Language]. *Notice:* The escape character is not supported, use the
-following three special escaping instead.
-
-|\n |To use newline character.
-
-|\t |To use tab character.
-
-|\r |To use carriage return character.
-
-|\} |To use the } character as text
-|===
-
-And the following logical operators can be used to group expressions:
-
-[width="100%",cols="50%,50%",options="header",]
-|===
-|Operator |Description
-
-|&& |The logical and operator is used to group two expressions.
-
-| \|\| |The logical or operator is used to group two expressions.
-|===
-
-The syntax for AND is:
-
-[source]
-----------------------------------------------------------
-${leftValue} OP rightValue && ${leftValue} OP rightValue
-----------------------------------------------------------
-
-And the syntax for OR is:
-
-[source]
----------------------------------------------------------
-${leftValue} OP rightValue || ${leftValue} OP rightValue
----------------------------------------------------------
-
-Some examples:
-
-[source,java]
-----
-// exact equals match
-simple("${in.header.foo} == 'foo'")
-
-// ignore case when comparing, so if the header has value FOO this will match
-simple("${in.header.foo} =~ 'foo'")
-
-// here Camel will type convert '100' into the type of in.header.bar and if it is an Integer '100' will also be converter to an Integer
-simple("${in.header.bar} == '100'")
-
-simple("${in.header.bar} == 100")
-
-// 100 will be converter to the type of in.header.bar so we can do > comparison
-simple("${in.header.bar} > 100")
-----
-
-=== Comparing with different types
-
-When you compare with different types such as String and int, then you
-have to take a bit care. Camel will use the type from the left hand side
-as 1st priority. And fallback to the right hand side type if both values
-couldn't be compared based on that type. +
- This means you can flip the values to enforce a specific type. Suppose
-the bar value above is a String. Then you can flip the equation:
-
-[source,java]
-----
-simple("100 < ${in.header.bar}")
-----
-
-which then ensures the int type is used as 1st priority.
-
-This may change in the future if the Camel team improves the binary
-comparison operations to prefer numeric types over String based. It's
-most often the String type which causes problem when comparing with
-numbers.
-
-[source,java]
-----
-// testing for null
-simple("${in.header.baz} == null")
-
-// testing for not null
-simple("${in.header.baz} != null")
-----
-
-And a bit more advanced example where the right value is another
-expression
-
-[source,java]
-----
-simple("${in.header.date} == ${date:now:yyyyMMdd}")
-
-simple("${in.header.type} == ${bean:orderService?method=getOrderType}")
-----
-
-And an example with contains, testing if the title contains the word
-Camel
-
-[source,java]
-----
-simple("${in.header.title} contains 'Camel'")
-----
-
-And an example with regex, testing if the number header is a 4 digit
-value:
-
-[source,java]
-----
-simple("${in.header.number} regex '\\d{4}'")
-----
-
-And finally an example if the header equals any of the values in the
-list. Each element must be separated by comma, and no space around. +
- This also works for numbers etc, as Camel will convert each element
-into the type of the left hand side.
-
-[source,java]
-----
-simple("${in.header.type} in 'gold,silver'")
-----
-
-And for all the last 3 we also support the negate test using not:
-
-[source,java]
-----
-simple("${in.header.type} !in 'gold,silver'")
-----
-
-And you can test if the type is a certain instance, eg for instance a
-String
-
-[source,java]
-----
-simple("${in.header.type} is 'java.lang.String'")
-----
-
-We have added a shorthand for all `java.lang` types so you can write it
-as:
-
-[source,java]
-----
-simple("${in.header.type} is 'String'")
-----
-
-Ranges are also supported. The range interval requires numbers and both
-from and end are inclusive. For instance to test whether a value is
-between 100 and 199:
-
-[source,java]
-----
-simple("${in.header.number} range 100..199")
-----
-
-Notice we use `..` in the range without spaces. It is based on the same
-syntax as Groovy.
-
-From *Camel 2.9* onwards the range value must be in single quotes
-
-[source,java]
-----
-simple("${in.header.number} range '100..199'")
-----
-
-=== Using Spring XML
-
-As the Spring XML does not have all the power as the Java DSL with all
-its various builder methods, you have to resort to use some other
-languages for testing with simple operators. Now you can do this with the simple
-language. In the sample below we want to test if the header is a widget
-order:
-
-[source,xml]
-----
-<from uri="seda:orders">
- <filter>
- <simple>${in.header.type} == 'widget'</simple>
- <to uri="bean:orderService?method=handleWidget"/>
- </filter>
-</from>
-----
-
-== Using and / or
-
-If you have two expressions you can combine them with the `&&` or `||`
-operator.
-
-For instance:
-
-[source,java]
------
-simple("${in.header.title} contains 'Camel' && ${in.header.type'} == 'gold'")
------
-
-And of course the `||` is also supported. The sample would be:
-
-[source,java]
------
-simple("${in.header.title} contains 'Camel' || ${in.header.type'} == 'gold'")
------
-
-*Notice:* Currently `&&` or `||` can only be used *once* in a simple
-language expression. This might change in the future. +
- So you *cannot* do:
-
-[source,java]
------
-simple("${in.header.title} contains 'Camel' && ${in.header.type'} == 'gold' && ${in.header.number} range 100..200")
------
-
-
-== Samples
-
-In the Spring XML sample below we filter based on a header value:
-
-[source,xml]
---------------------------------------------
-<from uri="seda:orders">
- <filter>
- <simple>${in.header.foo}</simple>
- <to uri="mock:fooOrders"/>
- </filter>
-</from>
---------------------------------------------
-
-The Simple language can be used for the predicate test above in the
-Message Filter pattern, where we test if the
-in message has a `foo` header (a header with the key `foo` exists). If
-the expression evaluates to *true* then the message is routed to the
-`mock:fooOrders` endpoint, otherwise the message is dropped.
-
-The same example in Java DSL:
-
-[source,java]
-----
-from("seda:orders")
- .filter().simple("${in.header.foo}")
- .to("seda:fooOrders");
-----
-
-You can also use the simple language for simple text concatenations such
-as:
-
-[source,java]
-----
-from("direct:hello")
- .transform().simple("Hello ${in.header.user} how are you?")
- .to("mock:reply");
-----
-
-Notice that we must use $\{ } placeholders in the expression now to
-allow Camel to parse it correctly.
-
-And this sample uses the date command to output current date.
-
-[source,java]
-----
-from("direct:hello")
- .transform().simple("The today is ${date:now:yyyyMMdd} and it is a great day.")
- .to("mock:reply");
-----
-
-And in the sample below we invoke the bean language to invoke a method
-on a bean to be included in the returned string:
-
-[source,java]
-----
-from("direct:order")
- .transform().simple("OrderId: ${bean:orderIdGenerator}")
- .to("mock:reply");
-----
-
-Where `orderIdGenerator` is the id of the bean registered in the
-Registry. If using Spring then it is the Spring bean
-id.
-
-If we want to declare which method to invoke on the order id generator
-bean we must prepend `.method name` such as below where we invoke the
-`generateId` method.
-
-[source,java]
-----
-from("direct:order")
- .transform().simple("OrderId: ${bean:orderIdGenerator.generateId}")
- .to("mock:reply");
-----
-
-We can use the `?method=methodname` option that we are familiar with the
-xref:components::bean-component.adoc[Bean] component itself:
-
-[source,java]
-----
-from("direct:order")
- .transform().simple("OrderId: ${bean:orderIdGenerator?method=generateId}")
- .to("mock:reply");
-----
-
-You can also convert the body to a given
-type, for example to ensure that it is a String you can do:
-
-[source,xml]
-----
-<transform>
- <simple>Hello ${bodyAs(String)} how are you?</simple>
-</transform>
-----
-
-There are a few types which have a shorthand notation, so we can use
-`String` instead of `java.lang.String`. These are:
-`byte[], String, Integer, Long`. All other types must use their FQN
-name, e.g. `org.w3c.dom.Document`.
-
-It is also possible to lookup a value from a header `Map`:
-
-[source,xml]
-----
-<transform>
- <simple>The gold value is ${header.type[gold]}</simple>
-</transform>
-----
-
-In the code above we lookup the header with name `type` and regard it as
-a `java.util.Map` and we then lookup with the key `gold` and return the
-value. If the header is not convertible to Map an exception is thrown. If the
-header with name `type` does not exist `null` is returned.
-
-You can nest functions, such as shown below:
-
-[source,xml]
-----
-<setHeader name="myHeader">
- <simple>${properties:${header.someKey}}</simple>
-</setHeader>
-----
-
-== Referring to constants or enums
-
-Suppose you have an enum for customers
-
-And in a Content Based Router we can use
-the xref:simple-language.adoc[Simple] language to refer to this enum, to check
-the message which enum it matches.
-
-== Using new lines or tabs in XML DSLs
-
-It is easier to specify new lines or tabs in
-XML DSLs as you can escape the value now
-
-[source,xml]
-----
-<transform>
- <simple>The following text\nis on a new line</simple>
-</transform>
-----
-
-== Leading and trailing whitespace handling
-
-The trim attribute of the expression can be
-used to control whether the leading and trailing whitespace characters
-are removed or preserved. The default value is true, which removes the
-whitespace characters.
-
-[source,xml]
-----
-<setBody>
- <simple trim="false">You get some trailing whitespace characters. </simple>
-</setBody>
-----
-
-== Setting result type
-
-You can now provide a result type to the xref:simple-language.adoc[Simple]
-expression, which means the result of the evaluation will be converted
-to the desired type. This is most usable to define types such as
-booleans, integers, etc.
-
-For example to set a header as a boolean type you can do:
-
-[source,java]
-----
-.setHeader("cool", simple("true", Boolean.class))
-----
-
-And in XML DSL
-
-[source,xml]
-----
-<setHeader name="cool">
- <!-- use resultType to indicate that the type should be a java.lang.Boolean -->
- <simple resultType="java.lang.Boolean">true</simple>
-</setHeader>
-----
-
-== Loading script from external resource
-
-You can externalize the script and have Camel load it from a resource
-such as `"classpath:"`, `"file:"`, or `"http:"`. +
- This is done using the following syntax: `"resource:scheme:location"`,
-eg to refer to a file on the classpath you can do:
-
-[source,java]
-----
-.setHeader("myHeader").simple("resource:classpath:mysimple.txt")
-----
-
-== Setting Spring beans to Exchange properties
-
-You can set a spring bean into an exchange property as shown below:
-
-[source,xml]
-----
-<bean id="myBeanId" class="my.package.MyCustomClass" />
-...
-<route>
- ...
- <setProperty name="monitoring.message">
- <simple>ref:myBeanId</simple>
- </setProperty>
- ...
-</route>
-----
-
diff --git a/docs/components/modules/ROOT/pages/tokenize-language.adoc b/docs/components/modules/ROOT/pages/tokenize-language.adoc
deleted file mode 100644
index bf1f30a..0000000
--- a/docs/components/modules/ROOT/pages/tokenize-language.adoc
+++ /dev/null
@@ -1,40 +0,0 @@
-[[tokenize-language]]
-= Tokenize Language
-:page-source: core/camel-core-languages/src/main/docs/tokenize-language.adoc
-
-*Since Camel 2.0*
-
-The tokenizer language is a built-in language in camel-core, which is
-most often used only with the Splitter EIP to split
-a message using a token-based strategy. +
-The tokenizer language is intended to tokenize text documents using a
-specified delimiter pattern. It can also be used to tokenize XML
-documents with some limited capability. For a truly XML-aware
-tokenization, the use of the XMLTokenizer
-language is recommended as it offers a faster, more efficient
-tokenization specifically for XML documents. For more details
-see Splitter.
-
-== Tokenize Options
-
-// language options: START
-The Tokenize language supports 11 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| token | | String | The (start) token to use as tokenizer, for example you can use the new line token. You can use simple language as the token to support dynamic tokens.
-| endToken | | String | The end token to use as tokenizer if using start/end token pairs. You can use simple language as the token to support dynamic tokens.
-| inheritNamespaceTagName | | String | To inherit namespaces from a root/parent tag name when using XML You can use simple language as the tag name to support dynamic names.
-| headerName | | String | Name of header to tokenize instead of using the message body.
-| regex | false | Boolean | If the token is a regular expression pattern. The default value is false
-| xml | false | Boolean | Whether the input is XML messages. This option must be set to true if working with XML payloads.
-| includeTokens | false | Boolean | Whether to include the tokens in the parts when using pairs The default value is false
-| group | | String | To group N parts together, for example to split big files into chunks of 1000 lines. You can use simple language as the group to support dynamic group sizes.
-| groupDelimiter | | String | Sets the delimiter to use when grouping. If this has not been set then token will be used as the delimiter.
-| skipFirst | false | Boolean | To skip the very first element
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
diff --git a/docs/components/modules/ROOT/pages/xtokenize-language.adoc b/docs/components/modules/ROOT/pages/xtokenize-language.adoc
deleted file mode 100644
index 14b35bf..0000000
--- a/docs/components/modules/ROOT/pages/xtokenize-language.adoc
+++ /dev/null
@@ -1,32 +0,0 @@
-[[xtokenize-language]]
-= XML Tokenize Language
-:page-source: core/camel-xml-jaxp/src/main/docs/xtokenize-language.adoc
-
-*Since Camel 2.14*
-
-The xml tokenizer language is a built-in language in camel-core, which
-is a truly XML-aware tokenizer that can be used with the Splitter as the
-conventional Tokenizer to efficiently and
-effectively tokenize XML documents. XMLTokenizer is capable of not only
-recognizing XML namespaces and hierarchical structures of the document
-but also more efficiently tokenizing XML documents than the conventional
-Tokenizer.
-
-For more details see Splitter.
-
-== XML Tokenizer Options
-
-// language options: START
-The XML Tokenize language supports 4 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| headerName | | String | Name of header to tokenize instead of using the message body.
-| mode | | String | The extraction mode. The available extraction modes are: i - injecting the contextual namespace bindings into the extracted token (default) w - wrapping the extracted token in its ancestor context u - unwrapping the extracted token to its child content t - extracting the text content of the specified element
-| group | | Integer | To group N parts together
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
\ No newline at end of file
diff --git a/docs/gulpfile.js b/docs/gulpfile.js
index 9a99f71..a6f529d 100644
--- a/docs/gulpfile.js
+++ b/docs/gulpfile.js
@@ -75,24 +75,26 @@ function createComponentImageSymlinks() {
.pipe(dest('components/modules/ROOT/assets/images/'));
}
-function deleteUserManualSymlinks() {
- return del(['user-manual/modules/ROOT/pages/*-eip.adoc', 'user-manual/modules/ROOT/pages/*-language.adoc']);
-}
-
-function createUserManualSymlinks() {
- return src(['../core/camel-base/src/main/docs/*.adoc', '../core/camel-core-languages/src/main/docs/*.adoc', '../core/camel-xml-jaxp/src/main/docs/*.adoc', '../core/camel-core-engine/src/main/docs/eips/*.adoc'])
- // Antora disabled symlinks, there is an issue open
- // https://gitlab.com/antora/antora/issues/188
- // to reinstate symlink support, until that's resolved
- // we'll simply copy over instead of creating symlinks
- // .pipe(symlink('user-manual/modules/ROOT/pages/', {
- // relativeSymlinks: true
- // }));
- // uncomment above .pipe() and remove the .pipe() below
- // when antora#188 is resolved
- .pipe(insertSourceAttribute())
- .pipe(dest('user-manual/modules/ROOT/pages/'));
-}
+// function deleteUserManualSymlinks() {
+// return del(['user-manual/modules/ROOT/pages/*-eip.adoc', 'user-manual/modules/ROOT/pages/*-language.adoc']);
+// }
+
+// NOTE! the single adoc at ../core/camel-base/src/main/docs/*.adoc doesn't appear to have generated content. Can it just be moved to the rest of the user manual?
+
+// function createUserManualSymlinks() {
+// return src(['../core/camel-base/src/main/docs/*.adoc', '../core/camel-core-languages/src/main/docs/*.adoc', '../core/camel-xml-jaxp/src/main/docs/*.adoc', '../core/camel-core-engine/src/main/docs/eips/*.adoc'])
+// // Antora disabled symlinks, there is an issue open
+// // https://gitlab.com/antora/antora/issues/188
+// // to reinstate symlink support, until that's resolved
+// // we'll simply copy over instead of creating symlinks
+// // .pipe(symlink('user-manual/modules/ROOT/pages/', {
+// // relativeSymlinks: true
+// // }));
+// // uncomment above .pipe() and remove the .pipe() below
+// // when antora#188 is resolved
+// .pipe(insertSourceAttribute())
+// .pipe(dest('user-manual/modules/ROOT/pages/'));
+// }
function titleFrom(file) {
const maybeName = /(?:=|#) (.*)/.exec(file.contents.toString())
@@ -122,7 +124,7 @@ function insertSourceAttribute() {
function createComponentNav() {
return src('component-nav.adoc.template')
.pipe(insertGeneratedNotice())
- .pipe(inject(src(['../core/camel-base/src/main/docs/*-component.adoc', '../core/camel-core-languages/src/main/docs/*-component.adoc', '../components/{*,*/*}/src/main/docs/*.adoc']).pipe(sort()), {
+ .pipe(inject(src(['../core/camel-base/src/main/docs/*-component.adoc', '../components/{*,*/*}/src/main/docs/*.adoc']).pipe(sort()), {
removeTags: true,
transform: (filename, file) => {
const filepath = path.basename(filename);
@@ -137,22 +139,22 @@ function createComponentNav() {
function createUserManualNav() {
return src('user-manual-nav.adoc.template')
.pipe(insertGeneratedNotice())
- .pipe(inject(src('../core/camel-base/src/main/docs/*.adoc').pipe(sort()), {
+ .pipe(inject(src('../core/camel-core-languages/src/main/docs/modules/languages/pages/*.adoc').pipe(sort()), {
removeTags: true,
name: 'languages',
transform: (filename, file) => {
const filepath = path.basename(filename);
const title = titleFrom(file);
- return ` ** xref:${filepath}[${title}]`;
+ return ` ** xref:languages:${filepath}[${title}]`;
}
}))
- .pipe(inject(src('../core/camel-core-engine/src/main/docs/eips/*.adoc').pipe(sort()), {
+ .pipe(inject(src('../core/camel-core-engine/src/main/docs/modules/eips/pages/*.adoc').pipe(sort()), {
removeTags: true,
name: 'eips',
transform: (filename, file) => {
const filepath = path.basename(filename);
const title = titleFrom(file);
- return ` ** xref:${filepath}[${title}]`;
+ return ` ** xref:eips:${filepath}[${title}]`;
}
}))
.pipe(rename('nav.adoc'))
@@ -196,8 +198,8 @@ function createComponentExamples() {
const symlinks = parallel(
series(deleteComponentSymlinks, createComponentSymlinks),
- series(deleteComponentImageSymlinks, createComponentImageSymlinks),
- series(deleteUserManualSymlinks, createUserManualSymlinks)
+ series(deleteComponentImageSymlinks, createComponentImageSymlinks)
+ // series(deleteUserManualSymlinks, createUserManualSymlinks)
);
const nav = parallel(createComponentNav, createUserManualNav);
const examples = series(deleteExamples, createUserManualExamples, createComponentExamples);
diff --git a/docs/user-manual/modules/ROOT/nav.adoc b/docs/user-manual/modules/ROOT/nav.adoc
index 174090d..a0df097 100644
--- a/docs/user-manual/modules/ROOT/nav.adoc
+++ b/docs/user-manual/modules/ROOT/nav.adoc
@@ -52,79 +52,85 @@
** xref:spring.adoc[Spring support]
* xref:using-osgi-blueprint-with-camel.adoc[Using OSGi blueprint with Camel]
* Supported expression languages
- ** xref:properties-component.adoc[Properties Component]
+ ** xref:languages:constant-language.adoc[Constant Language]
+ ** xref:languages:exchangeProperty-language.adoc[ExchangeProperty Language]
+ ** xref:languages:file-language.adoc[File Language]
+ ** xref:languages:header-language.adoc[Header Language]
+ ** xref:languages:ref-language.adoc[Ref Language]
+ ** xref:languages:simple-language.adoc[Simple Language]
+ ** xref:languages:tokenize-language.adoc[Tokenize Language]
* xref:enterprise-integration-patterns.adoc[Enterprise Integration Patterns]
- ** xref:aggregate-eip.adoc[Aggregate EIP]
- ** xref:batch-config-eip.adoc[Batch-config EIP]
- ** xref:bean-eip.adoc[Bean EIP]
- ** xref:choice-eip.adoc[Choice EIP]
- ** xref:circuitBreaker-eip.adoc[CircuitBreaker EIP]
- ** xref:claimCheck-eip.adoc[Claim Check EIP]
- ** xref:content-based-router-eip.adoc[Content Based Router]
- ** xref:content-filter-eip.adoc[Content Filter]
- ** xref:convertBodyTo-eip.adoc[Convert Body To EIP]
- ** xref:customLoadBalancer-eip.adoc[Custom Load Balancer EIP]
- ** xref:delay-eip.adoc[Delay EIP]
- ** xref:dynamic-router.adoc[Dynamic Router]
- ** xref:dynamicRouter-eip.adoc[Dynamic Router EIP]
- ** xref:enrich-eip.adoc[Enrich EIP]
- ** xref:eventDrivenConsumer-eip.adoc[Event Driven Consumer]
- ** xref:failover-eip.adoc[Failover EIP]
- ** xref:filter-eip.adoc[Filter EIP]
- ** xref:from-eip.adoc[From EIP]
- ** xref:hystrix-eip.adoc[Hystrix EIP]
- ** xref:hystrixConfiguration-eip.adoc[Hystrix Configuration EIP]
- ** xref:idempotentConsumer-eip.adoc[Idempotent Consumer EIP]
- ** xref:inOnly-eip.adoc[In Only EIP]
- ** xref:inOut-eip.adoc[In Out EIP]
- ** xref:loadBalance-eip.adoc[Load Balance EIP]
- ** xref:log-eip.adoc[Log EIP]
- ** xref:loop-eip.adoc[Loop EIP]
- ** xref:marshal-eip.adoc[Marshal EIP]
- ** xref:multicast-eip.adoc[Multicast EIP]
- ** xref:onFallback-eip.adoc[On Fallback EIP]
- ** xref:otherwise-eip.adoc[Otherwise EIP]
- ** xref:pipeline-eip.adoc[Pipeline EIP]
- ** xref:pollEnrich-eip.adoc[Poll Enrich EIP]
- ** xref:process-eip.adoc[Process EIP]
- ** xref:random-eip.adoc[Random EIP]
- ** xref:recipientList-eip.adoc[Recipient List EIP]
- ** xref:removeHeader-eip.adoc[Remove Header EIP]
- ** xref:removeHeaders-eip.adoc[Remove Headers EIP]
- ** xref:removeProperties-eip.adoc[Remove Properties EIP]
- ** xref:removeProperty-eip.adoc[Remove Property EIP]
- ** xref:requestReply-eip.adoc[Request Reply]
- ** xref:resequence-eip.adoc[Resequence EIP]
- ** xref:resilience4j-eip.adoc[Resilience4j EIP]
- ** xref:resilience4jConfiguration-eip.adoc[Resilience4j Configuration EIP]
- ** xref:rollback-eip.adoc[Rollback EIP]
- ** xref:roundRobin-eip.adoc[Round Robin EIP]
- ** xref:routingSlip-eip.adoc[Routing Slip EIP]
- ** xref:saga-eip.adoc[Saga EIP]
- ** xref:sample-eip.adoc[Sample EIP]
- ** xref:script-eip.adoc[Script EIP]
- ** xref:serviceCall-eip.adoc[Service Call EIP]
- ** xref:setBody-eip.adoc[Set Body EIP]
- ** xref:setHeader-eip.adoc[Set Header EIP]
- ** xref:setOutHeader-eip.adoc[Set Out Header EIP (deprecated)]
- ** xref:setProperty-eip.adoc[Set Property EIP]
- ** xref:sort-eip.adoc[Sort EIP]
- ** xref:split-eip.adoc[Split EIP]
- ** xref:step-eip.adoc[Step EIP]
- ** xref:sticky-eip.adoc[Sticky EIP]
- ** xref:stop-eip.adoc[Stop EIP]
- ** xref:stream-config-eip.adoc[Stream-config EIP]
- ** xref:threads-eip.adoc[Threads EIP]
- ** xref:throttle-eip.adoc[Throttle EIP]
- ** xref:to-eip.adoc[To EIP]
- ** xref:toD-eip.adoc[To D EIP]
- ** xref:topic-eip.adoc[Topic EIP]
- ** xref:transform-eip.adoc[Transform EIP]
- ** xref:unmarshal-eip.adoc[Unmarshal EIP]
- ** xref:validate-eip.adoc[Validate EIP]
- ** xref:weighted-eip.adoc[Weighted EIP]
- ** xref:when-eip.adoc[When EIP]
- ** xref:wireTap-eip.adoc[Wire Tap EIP]
+ ** xref:eips:aggregate-eip.adoc[Aggregate EIP]
+ ** xref:eips:batch-config-eip.adoc[Batch-config EIP]
+ ** xref:eips:bean-eip.adoc[Bean EIP]
+ ** xref:eips:choice-eip.adoc[Choice EIP]
+ ** xref:eips:circuitBreaker-eip.adoc[CircuitBreaker EIP]
+ ** xref:eips:claimCheck-eip.adoc[Claim Check EIP]
+ ** xref:eips:content-based-router-eip.adoc[Content Based Router]
+ ** xref:eips:content-filter-eip.adoc[Content Filter]
+ ** xref:eips:convertBodyTo-eip.adoc[Convert Body To EIP]
+ ** xref:eips:customLoadBalancer-eip.adoc[Custom Load Balancer EIP]
+ ** xref:eips:delay-eip.adoc[Delay EIP]
+ ** xref:eips:dynamic-router.adoc[Dynamic Router]
+ ** xref:eips:dynamicRouter-eip.adoc[Dynamic Router EIP]
+ ** xref:eips:enrich-eip.adoc[Enrich EIP]
+ ** xref:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer]
+ ** xref:eips:failover-eip.adoc[Failover EIP]
+ ** xref:eips:filter-eip.adoc[Filter EIP]
+ ** xref:eips:from-eip.adoc[From EIP]
+ ** xref:eips:hystrix-eip.adoc[Hystrix EIP]
+ ** xref:eips:hystrixConfiguration-eip.adoc[Hystrix Configuration EIP]
+ ** xref:eips:idempotentConsumer-eip.adoc[Idempotent Consumer EIP]
+ ** xref:eips:inOnly-eip.adoc[In Only EIP]
+ ** xref:eips:inOut-eip.adoc[In Out EIP]
+ ** xref:eips:loadBalance-eip.adoc[Load Balance EIP]
+ ** xref:eips:log-eip.adoc[Log EIP]
+ ** xref:eips:loop-eip.adoc[Loop EIP]
+ ** xref:eips:marshal-eip.adoc[Marshal EIP]
+ ** xref:eips:multicast-eip.adoc[Multicast EIP]
+ ** xref:eips:onFallback-eip.adoc[On Fallback EIP]
+ ** xref:eips:otherwise-eip.adoc[Otherwise EIP]
+ ** xref:eips:pipeline-eip.adoc[Pipeline EIP]
+ ** xref:eips:pollEnrich-eip.adoc[Poll Enrich EIP]
+ ** xref:eips:process-eip.adoc[Process EIP]
+ ** xref:eips:random-eip.adoc[Random EIP]
+ ** xref:eips:recipientList-eip.adoc[Recipient List EIP]
+ ** xref:eips:removeHeader-eip.adoc[Remove Header EIP]
+ ** xref:eips:removeHeaders-eip.adoc[Remove Headers EIP]
+ ** xref:eips:removeProperties-eip.adoc[Remove Properties EIP]
+ ** xref:eips:removeProperty-eip.adoc[Remove Property EIP]
+ ** xref:eips:requestReply-eip.adoc[Request Reply]
+ ** xref:eips:resequence-eip.adoc[Resequence EIP]
+ ** xref:eips:resilience4j-eip.adoc[Resilience4j EIP]
+ ** xref:eips:resilience4jConfiguration-eip.adoc[Resilience4j Configuration EIP]
+ ** xref:eips:rollback-eip.adoc[Rollback EIP]
+ ** xref:eips:roundRobin-eip.adoc[Round Robin EIP]
+ ** xref:eips:routingSlip-eip.adoc[Routing Slip EIP]
+ ** xref:eips:saga-eip.adoc[Saga EIP]
+ ** xref:eips:sample-eip.adoc[Sample EIP]
+ ** xref:eips:script-eip.adoc[Script EIP]
+ ** xref:eips:serviceCall-eip.adoc[Service Call EIP]
+ ** xref:eips:setBody-eip.adoc[Set Body EIP]
+ ** xref:eips:setHeader-eip.adoc[Set Header EIP]
+ ** xref:eips:setOutHeader-eip.adoc[Set Out Header EIP (deprecated)]
+ ** xref:eips:setProperty-eip.adoc[Set Property EIP]
+ ** xref:eips:sort-eip.adoc[Sort EIP]
+ ** xref:eips:split-eip.adoc[Split EIP]
+ ** xref:eips:step-eip.adoc[Step EIP]
+ ** xref:eips:sticky-eip.adoc[Sticky EIP]
+ ** xref:eips:stop-eip.adoc[Stop EIP]
+ ** xref:eips:stream-config-eip.adoc[Stream-config EIP]
+ ** xref:eips:threads-eip.adoc[Threads EIP]
+ ** xref:eips:throttle-eip.adoc[Throttle EIP]
+ ** xref:eips:to-eip.adoc[To EIP]
+ ** xref:eips:toD-eip.adoc[To D EIP]
+ ** xref:eips:topic-eip.adoc[Topic EIP]
+ ** xref:eips:transform-eip.adoc[Transform EIP]
+ ** xref:eips:unmarshal-eip.adoc[Unmarshal EIP]
+ ** xref:eips:validate-eip.adoc[Validate EIP]
+ ** xref:eips:weighted-eip.adoc[Weighted EIP]
+ ** xref:eips:when-eip.adoc[When EIP]
+ ** xref:eips:wireTap-eip.adoc[Wire Tap EIP]
* Frequently asked questions
** xref:faq/can-i-get-commercial-support.adoc[Can I get commercial support?]
** xref:faq/does-camel-work-on-ibms-jdk.adoc[Does Camel work on IBM's JDK?]
diff --git a/docs/user-manual/modules/ROOT/pages/aggregate-eip.adoc b/docs/user-manual/modules/ROOT/pages/aggregate-eip.adoc
deleted file mode 100644
index e129a26..0000000
--- a/docs/user-manual/modules/ROOT/pages/aggregate-eip.adoc
+++ /dev/null
@@ -1,673 +0,0 @@
-[[aggregate-eip]]
-= Aggregate EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/aggregate-eip.adoc
-
-The
-http://www.enterpriseintegrationpatterns.com/Aggregator.html[Aggregator]
-from the xref:enterprise-integration-patterns.adoc[EIP patterns] allows
-you to combine a number of messages together into a single message.
-
-image::eip/Aggregator.gif[image]
-
-A correlation xref:expression.adoc[Expression] is used to determine the
-messages which should be aggregated together. If you want to aggregate
-all messages into a single message, just use a constant expression. An
-AggregationStrategy is used to combine all the message exchanges for a
-single correlation key into a single message exchange.
-
-== Aggregator options
-
-// eip options: START
-The Aggregate EIP supports 27 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *correlationExpression* | *Required* The expression used to calculate the correlation key to use for aggregation. The Exchange which has the same correlation key is aggregated together. If the correlation key could not be evaluated an Exception is thrown. You can disable this by using the ignoreBadCorrelationKeys option. | | NamespaceAware Expression
-| *completionPredicate* | A Predicate to indicate when an aggregated exchange is complete. If this is not specified and the AggregationStrategy object implements Predicate, the aggregationStrategy object will be used as the completionPredicate. | | NamespaceAware Expression
-| *completionTimeoutExpression* | Time in millis that an aggregated exchange should be inactive before its complete (timeout). This option can be set as either a fixed value or using an Expression which allows you to evaluate a timeout dynamically - will use Long as result. If both are set Camel will fallback to use the fixed value if the Expression result was null or 0. You cannot use this option together with completionInterval, only one of the two can be used. By default the timeout c [...]
-| *completionSizeExpression* | Number of messages aggregated before the aggregation is complete. This option can be set as either a fixed value or using an Expression which allows you to evaluate a size dynamically - will use Integer as result. If both are set Camel will fallback to use the fixed value if the Expression result was null or 0. | | NamespaceAware Expression
-| *optimisticLockRetryPolicy* | Allows to configure retry settings when using optimistic locking. | | OptimisticLockRetry PolicyDefinition
-| *parallelProcessing* | When aggregated are completed they are being send out of the aggregator. This option indicates whether or not Camel should use a thread pool with multiple threads for concurrency. If no custom thread pool has been specified then Camel creates a default pool with 10 concurrent threads. | false | Boolean
-| *optimisticLocking* | Turns on using optimistic locking, which requires the aggregationRepository being used, is supporting this by implementing org.apache.camel.spi.OptimisticLockingAggregationRepository. | false | Boolean
-| *executorServiceRef* | If using parallelProcessing you can specify a custom thread pool to be used. In fact also if you are not using parallelProcessing this custom thread pool is used to send out aggregated exchanges as well. | | String
-| *timeoutCheckerExecutor ServiceRef* | If using either of the completionTimeout, completionTimeoutExpression, or completionInterval options a background thread is created to check for the completion for every aggregator. Set this option to provide a custom thread pool to be used rather than creating a new thread for every aggregator. | | String
-| *aggregationRepositoryRef* | Sets the custom aggregate repository to use Will by default use org.apache.camel.processor.aggregate.MemoryAggregationRepository | | String
-| *strategyRef* | A reference to lookup the AggregationStrategy in the Registry. Configuring an AggregationStrategy is required, and is used to merge the incoming Exchange with the existing already merged exchanges. At first call the oldExchange parameter is null. On subsequent invocations the oldExchange contains the merged exchanges and newExchange is of course the new incoming Exchange. | | String
-| *strategyMethodName* | This option can be used to explicit declare the method name to use, when using POJOs as the AggregationStrategy. | | String
-| *strategyMethodAllowNull* | If this option is false then the aggregate method is not used for the very first aggregation. If this option is true then null values is used as the oldExchange (at the very first aggregation), when using POJOs as the AggregationStrategy. | false | Boolean
-| *completionSize* | Number of messages aggregated before the aggregation is complete. This option can be set as either a fixed value or using an Expression which allows you to evaluate a size dynamically - will use Integer as result. If both are set Camel will fallback to use the fixed value if the Expression result was null or 0. | | Integer
-| *completionInterval* | A repeating period in millis by which the aggregator will complete all current aggregated exchanges. Camel has a background task which is triggered every period. You cannot use this option together with completionTimeout, only one of them can be used. | | Long
-| *completionTimeout* | Time in millis that an aggregated exchange should be inactive before its complete (timeout). This option can be set as either a fixed value or using an Expression which allows you to evaluate a timeout dynamically - will use Long as result. If both are set Camel will fallback to use the fixed value if the Expression result was null or 0. You cannot use this option together with completionInterval, only one of the two can be used. By default the timeout checker run [...]
-| *completionTimeoutChecker Interval* | Interval in millis that is used by the background task that checks for timeouts (org.apache.camel.TimeoutMap). By default the timeout checker runs every second. The timeout is an approximation and there is no guarantee that the a timeout is triggered exactly after the timeout value. It is not recommended to use very low timeout values or checker intervals. | 1000 | Long
-| *completionFromBatchConsumer* | Enables the batch completion mode where we aggregate from a org.apache.camel.BatchConsumer and aggregate the total number of exchanges the org.apache.camel.BatchConsumer has reported as total by checking the exchange property org.apache.camel.Exchange#BATCH_COMPLETE when its complete. This option cannot be used together with discardOnAggregationFailure. | false | Boolean
-| *completionOnNewCorrelation Group* | Enables completion on all previous groups when a new incoming correlation group. This can for example be used to complete groups with same correlation keys when they are in consecutive order. Notice when this is enabled then only 1 correlation group can be in progress as when a new correlation group starts, then the previous groups is forced completed. | false | Boolean
-| *eagerCheckCompletion* | Use eager completion checking which means that the completionPredicate will use the incoming Exchange. As opposed to without eager completion checking the completionPredicate will use the aggregated Exchange. | false | Boolean
-| *ignoreInvalidCorrelation Keys* | If a correlation key cannot be successfully evaluated it will be ignored by logging a DEBUG and then just ignore the incoming Exchange. | false | Boolean
-| *closeCorrelationKeyOn Completion* | Closes a correlation key when its complete. Any late received exchanges which has a correlation key that has been closed, it will be defined and a ClosedCorrelationKeyException is thrown. | | Integer
-| *discardOnCompletionTimeout* | Discards the aggregated message on completion timeout. This means on timeout the aggregated message is dropped and not sent out of the aggregator. | false | Boolean
-| *discardOnAggregationFailure* | Discards the aggregated message when aggregation failed (an exception was thrown from AggregationStrategy. This means the partly aggregated message is dropped and not sent out of the aggregator. This option cannot be used together with completionFromBatchConsumer. | false | Boolean
-| *forceCompletionOnStop* | Indicates to complete all current aggregated exchanges when the context is stopped | false | Boolean
-| *completeAllOnStop* | Indicates to wait to complete all current and partial (pending) aggregated exchanges when the context is stopped. This also means that we will wait for all pending exchanges which are stored in the aggregation repository to complete so the repository is empty before we can stop. You may want to enable this when using the memory based aggregation repository that is memory based only, and do not store data on disk. When this option is enabled, then the aggregator is [...]
-| *aggregateControllerRef* | To use a org.apache.camel.processor.aggregate.AggregateController to allow external sources to control this aggregator. | | String
-|===
-// eip options: END
-
-== About AggregationStrategy
-
-The `AggregationStrategy` is used for aggregating the old (lookup by its
-correlation id) and the new exchanges together into a single exchange.
-Possible implementations include performing some kind of combining or
-delta processing, such as adding line items together into an invoice or
-just using the newest exchange and removing old exchanges such as for
-state tracking or market data prices; where old values are of little
-use.
-
-Notice the aggregation strategy is a mandatory option and must be
-provided to the aggregator.
-
-IMPORTANT: In the aggregate method, do not create a new exchange instance to return,
-instead return either the old or new exchange from the input parameters;
-favor returning the old exchange whenever possible.
-
-Here are a few example `AggregationStrategy` implementations that should
-help you create your own custom strategy.
-
-[source,java]
-----
-//simply combines Exchange String body values using '+' as a delimiter
-class StringAggregationStrategy implements AggregationStrategy {
-
- public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
- if (oldExchange == null) {
- return newExchange;
- }
-
- String oldBody = oldExchange.getIn().getBody(String.class);
- String newBody = newExchange.getIn().getBody(String.class);
- oldExchange.getIn().setBody(oldBody + "+" + newBody);
- return oldExchange;
- }
-}
-
-//simply combines Exchange body values into an ArrayList<Object>
-class ArrayListAggregationStrategy implements AggregationStrategy {
-
- public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
- Object newBody = newExchange.getIn().getBody();
- ArrayList<Object> list = null;
- if (oldExchange == null) {
- list = new ArrayList<Object>();
- list.add(newBody);
- newExchange.getIn().setBody(list);
- return newExchange;
- } else {
- list = oldExchange.getIn().getBody(ArrayList.class);
- list.add(newBody);
- return oldExchange;
- }
- }
-}
-----
-
-== About completion
-
-When aggregation xref:exchange.adoc[Exchange]s at some point you need to
-indicate that the aggregated exchanges is complete, so they can be send
-out of the aggregator. Camel allows you to indicate completion in
-various ways as follows:
-
-* completionTimeout - Is an inactivity timeout in which is triggered if
-no new exchanges have been aggregated for that particular correlation
-key within the period.
-* completionInterval - Once every X period all the current aggregated
-exchanges are completed.
-* completionSize - Is a number indicating that after X aggregated
-exchanges it's complete.
-* completionPredicate - Runs a xref:predicate.adoc[Predicate] when a new
-exchange is aggregated to determine if we are complete or not.
-The configured aggregationStrategy can implement the
-Predicate interface and will be used as the completionPredicate if no
-completionPredicate is configured. The configured aggregationStrategy can
-implement `PreCompletionAwareAggregationStrategy` and will be used as
-the completionPredicate in pre-complete check mode. See further below
-for more details.
-* completionFromBatchConsumer - Special option for
-xref:batch-consumer.adoc[Batch Consumer] which allows you to complete
-when all the messages from the batch has been aggregated.
-* forceCompletionOnStop - Indicates to complete all current
-aggregated exchanges when the context is stopped
-* Using a `AggregateController` - which allows to use an
-external source to complete groups or all groups. This can be done using
-Java or JMX API.
-
-Notice that all the completion ways are per correlation key. And you can
-combine them in any way you like. It's basically the first which
-triggers that wins. So you can use a completion size together with a
-completion timeout. Only completionTimeout and completionInterval cannot
-be used at the same time.
-
-Notice the completion is a mandatory option and must be provided to the
-aggregator. If not provided Camel will thrown an Exception on startup.
-
-== Pre-completion mode
-
-There can be use-cases where you want the incoming
-xref:exchange.adoc[Exchange] to determine if the correlation group
-should pre-complete, and then the incoming
-xref:exchange.adoc[Exchange] is starting a new group from scratch. To
-determine this the `AggregationStrategy` can
-implement `PreCompletionAwareAggregationStrategy` which has
-a `preComplete` method:
-
-[source,java]
-----
- /**
- * Determines if the aggregation should complete the current group, and start a new group, or the aggregation
- * should continue using the current group.
- *
- * @param oldExchange the oldest exchange (is <tt>null</tt> on first aggregation as we only have the new exchange)
- * @param newExchange the newest exchange (can be <tt>null</tt> if there was no data possible to acquire)
- * @return <tt>true</tt> to complete current group and start a new group, or <tt>false</tt> to keep using current
- */
- boolean preComplete(Exchange oldExchange, Exchange newExchange);
-----
-
-If the preComplete method returns true, then the existing groups is
-completed (without aggregating the incoming exchange (newExchange). And
-then the newExchange is used to start the correlation group from scratch
-so the group would contain only that new incoming exchange. This is
-known as pre-completion mode. And when the aggregation is in
-pre-completion mode, then only the following completions are in use
-
-* aggregationStrategy must
-implement `PreCompletionAwareAggregationStrategy` xxx
-* completionTimeout or completionInterval can also be used as fallback
-completions
-* any other completion are not used (such as by size, from batch
-consumer etc)
-* eagerCheckCompletion is implied as true, but the option has no effect
-
-== Persistent AggregationRepository
-
-The aggregator provides a pluggable repository which you can implement
-your own `org.apache.camel.spi.AggregationRepository`. +
- If you need persistent repository then you can use either Camel
-xref:components::leveldb.adoc[LevelDB], or xref:components::sql-component.adoc[SQL Component] components.
-
-== Using TimeoutAwareAggregationStrategy
-
-If your aggregation strategy implements
-`TimeoutAwareAggregationStrategy`, then Camel will invoke the `timeout`
-method when the timeout occurs. Notice that the values for index and
-total parameters will be -1, and the timeout parameter will be provided
-only if configured as a fixed value. You must *not* throw any exceptions
-from the `timeout` method.
-
-== Using CompletionAwareAggregationStrategy
-
-If your aggregation strategy implements
-`CompletionAwareAggregationStrategy`, then Camel will invoke the
-`onComplete` method when the aggregated Exchange is completed. This
-allows you to do any last minute custom logic such as to cleanup some
-resources, or additional work on the exchange as it's now completed. +
- You must *not* throw any exceptions from the `onCompletion` method.
-
-== Completing current group decided from the AggregationStrategy
-
-The `AggregationStrategy` can now included a property on the
-returned `Exchange` that contains a boolean to indicate if the current
-group should be completed. This allows to overrule any existing
-completion predicates / sizes / timeouts etc, and complete the group.
-
-For example the following logic (from an unit test) will complete the
-group if the message body size is larger than 5. This is done by setting
-the exchange property `Exchange.AGGREGATION_COMPLETE_CURRENT_GROUP` to `true`.
-
-[source,java]
-----
- public final class MyCompletionStrategy implements AggregationStrategy {
- @Override
- public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
- if (oldExchange == null) {
- return newExchange;
- }
- String body = oldExchange.getIn().getBody(String.class) + "+"
- + newExchange.getIn().getBody(String.class);
- oldExchange.getIn().setBody(body);
- if (body.length() >= 5) {
- oldExchange.setProperty(Exchange.AGGREGATION_COMPLETE_CURRENT_GROUP, true);
- }
- return oldExchange;
- }
- }
-----
-
-
-== Completing all previous group decided from the AggregationStrategy
-
-The `AggregationStrategy` can now included a property on the
-returned `Exchange` that contains a boolean to indicate if all previous
-groups should be completed. This allows to overrule any existing
-completion predicates / sizes / timeouts etc, and complete all the existing
-previous group.
-
-For example the following logic (from an unit test) will complete all the
-previous group when a new aggregation group is started. This is done by
-setting the property `Exchange.AGGREGATION_COMPLETE_ALL_GROUPS` to `true`.
-
-[source,java]
-----
- public final class MyCompletionStrategy implements AggregationStrategy {
- @Override
- public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
- if (oldExchange == null) {
- // we start a new correlation group, so complete all previous groups
- newExchange.setProperty(Exchange.AGGREGATION_COMPLETE_ALL_GROUPS, true);
- return newExchange;
- }
-
- String body1 = oldExchange.getIn().getBody(String.class);
- String body2 = newExchange.getIn().getBody(String.class);
-
- oldExchange.getIn().setBody(body1 + body2);
- return oldExchange;
- }
- }
-----
-
-== Manually Force the Completion of All Aggregated Exchanges Immediately
-
-You can manually trigger completion of all current aggregated exchanges
-by sending an exchange containing the exchange property
-`Exchange.AGGREGATION_COMPLETE_ALL_GROUPS` set to `true`. The message is
-considered a signal message only, the message headers/contents will not
-be processed otherwise.
-
-You can alternatively set the exchange property
-`Exchange.AGGREGATION_COMPLETE_ALL_GROUPS_INCLUSIVE` to `true` to trigger
-completion of all groups after processing the current message.
-
-== Using a List<V> in AggregationStrategy
-
-If you want to aggregate some value from the messages `<V>` into a `List<V>`
-then we have added a
-`org.apache.camel.processor.aggregate.AbstractListAggregationStrategy`
-abstract class that makes this easier. The completed
-Exchange that is sent out of the aggregator will contain the `List<V>` in
-the message body.
-
-For example to aggregate a `List<Integer>` you can extend this class as
-shown below, and implement the `getValue` method:
-
-== Using AggregateController
-
-The `org.apache.camel.processor.aggregate.AggregateController` allows
-you to control the aggregate at runtime using Java or JMX API. This can
-be used to force completing groups of exchanges, or query its current
-runtime statistics.
-
-The aggregator provides a default implementation if no custom have been
-configured, which can be accessed using `getAggregateController()` method.
-Though it may be easier to configure a controller in the route using
-`aggregateController` as shown below:
-
-[source,java]
-----
-private AggregateController controller = new DefaultAggregateController();
-
-from("direct:start")
- .aggregate(header("id"), new MyAggregationStrategy())
- .completionSize(10).id("myAggregator")
- .aggregateController(controller)
- .to("mock:aggregated");
-----
-
-Then there is API on AggregateController to force completion. For
-example to complete a group with key foo
-
-[source,java]
-----
-int groups = controller.forceCompletionOfGroup("foo");
-----
-
-The number return would be the number of groups completed. In this case
-it would be 1 if the foo group existed and was completed. If foo does
-not exists then 0 is returned.
-
-There is also an api to complete all groups
-
-[source,java]
-----
-int groups = controller.forceCompletionOfAllGroups();
-----
-
-To configure this from XML DSL
-
-[source,xml]
-----
-<bean id="myController" class="org.apache.camel.processor.aggregate.DefaultAggregateController"/>
-
- <camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <aggregate strategyRef="myAppender" completionSize="10"
- aggregateControllerRef="myController">
- <correlationExpression>
- <header>id</header>
- </correlationExpression>
- <to uri="mock:result"/>
- </aggregate>
- </route>
- </camelContext>
-----
-
-There is also JMX API on the aggregator which is available under the
-processors node in the Camel JMX tree.
-
-== Using GroupedExchanges
-
-In the route below we group all the exchanges together using
-`groupExchanges()`:
-
-[source,java]
-----
-from("direct:start")
- // aggregate all using same expression
- .aggregate(constant(true))
- // wait for 0.5 seconds to aggregate
- .completionTimeout(500L)
- // group the exchanges so we get one single exchange containing all the others
- .groupExchanges()
- .to("mock:result");
-----
-
-As a result we have one outgoing `Exchange` being
-routed the `"mock:result"` endpoint. The exchange is a holder
-containing all the incoming Exchanges.
-
-The output of the aggregator will then contain the exchanges grouped
-together in a list as shown below:
-
-[source,java]
-----
-List<Exchange> grouped = exchange.getIn().getBody(List.class);
-----
-
-== Using POJOs as AggregationStrategy
-
-To use the `AggregationStrategy` you had to implement the
-`org.apache.camel.AggregationStrategy` interface,
-which means your logic would be tied to the Camel API.
-You can use a POJO for the logic and let Camel adapt to your
-POJO. To use a POJO a convention must be followed:
-
-* there must be a public method to use
-* the method must not be void
-* the method can be static or non-static
-* the method must have 2 or more parameters
-* the parameters is paired so the first 50% is applied to the
-`oldExchange` and the reminder 50% is for the `newExchange`
-* .. meaning that there must be an equal number of parameters, eg 2, 4,
-6 etc.
-
-The paired methods is expected to be ordered as follows:
-
-* the first parameter is the message body
-* the 2nd parameter is a Map of the headers
-* the 3rd parameter is a Map of the Exchange properties
-
-This convention is best explained with some examples.
-
-In the method below, we have only 2 parameters, so the 1st parameter is
-the body of the `oldExchange`, and the 2nd is paired to the body of the
-`newExchange`:
-
-[source,java]
-----
-public String append(String existing, String next) {
- return existing + next;
-}
-----
-
-In the method below, we have only 4 parameters, so the 1st parameter is
-the body of the `oldExchange`, and the 2nd is the Map of the
-`oldExchange` headers, and the 3rd is paired to the body of the `newExchange`,
-and the 4th parameter is the Map of the `newExchange` headers:
-
-[source,java]
-----
-public String append(String existing, Map existingHeaders, String next, Map nextHeaders) {
- return existing + next;
-}
-----
-
-And finally if we have 6 parameters the we also have the properties of
-the Exchanges:
-
-[source,java]
-----
-public String append(String existing, Map existingHeaders, Map existingProperties,
- String next, Map nextHeaders, Map nextProperties) {
- return existing + next;
-}
-----
-
-To use this with the Aggregate EIP we can use a
-POJO with the aggregate logic as follows:
-
-[source,java]
-----
-public class MyBodyAppender {
-
- public String append(String existing, String next) {
- return next + existing;
- }
-
-}
-----
-
-And then in the Camel route we create an instance of our bean, and then
-refer to the bean in the route using `bean` method from
-`org.apache.camel.builder.AggregationStrategies` as shown:
-
-[source,java]
-----
-private MyBodyAppender appender = new MyBodyAppender();
-
-public void configure() throws Exception {
- from("direct:start")
- .aggregate(constant(true), AggregationStrategies.bean(appender, "append"))
- .completionSize(3)
- .to("mock:result");
-}
-----
-
-We can also provide the bean type directly:
-
-[source,java]
-----
-public void configure() throws Exception {
- from("direct:start")
- .aggregate(constant(true), AggregationStrategies.bean(MyBodyAppender.class, "append"))
- .completionSize(3)
- .to("mock:result");
-}
-----
-
-And if the bean has only one method we do not need to specify the name
-of the method:
-
-[source,java]
-----
-public void configure() throws Exception {
- from("direct:start")
- .aggregate(constant(true), AggregationStrategies.bean(MyBodyAppender.class))
- .completionSize(3)
- .to("mock:result");
-}
-----
-
-And the `append` method could be static:
-
-[source,java]
-----
-public class MyBodyAppender {
-
- public static String append(String existing, String next) {
- return next + existing;
- }
-
-}
-----
-
-If you are using XML DSL then we need to declare a <bean> with the POJO:
-
-[source,xml]
-----
-<bean id="myAppender" class="com.foo.MyBodyAppender"/>
-----
-
-And in the Camel route we use `strategyRef` to refer to the bean by its
-id, and the `strategyMethodName` can be used to define the method name
-to call:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <aggregate strategyRef="myAppender" strategyMethodName="append" completionSize="3">
- <correlationExpression>
- <constant>true</constant>
- </correlationExpression>
- <to uri="mock:result"/>
- </aggregate>
- </route>
-</camelContext>
-----
-
-When using XML DSL you must define the POJO as a <bean>.
-
-== Aggregating when no data
-
-By default when using POJOs as AggregationStrategy, then the method is
-*only* invoked when there is data to be aggregated (by default). You can
-use the option `strategyMethodAllowNull` to configure this. Where as
-without using POJOs then you may have `null` as `oldExchange` or
-`newExchange` parameters. For example the
-Aggregate EIP will invoke the
-`AggregationStrategy` with `oldExchange` as null, for the first
-Exchange incoming to the aggregator. And then for
-subsequent xref:exchange.adoc[Exchange]s then `oldExchange` and
-`newExchange` parameters are both not null.
-
-Example with Content Enricher EIP and no data
-
-Though with POJOs as `AggregationStrategy` we made this simpler and only
-call the method when `oldExchange` and `newExchange` is not null, as
-that would be the most common use-case. If you need to allow
-`oldExchange` or `newExchange` to be null, then you can configure this
-with the POJO using the `AggregationStrategyBeanAdapter` as shown below.
-On the bean adapter we call `setAllowNullNewExchange` to allow the new
-exchange to be `null`.
-
-[source,java]
-----
-public void configure() throws Exception {
- AggregationStrategyBeanAdapter myStrategy = new AggregationStrategyBeanAdapter(appender, "append");
- myStrategy.setAllowNullOldExchange(true);
- myStrategy.setAllowNullNewExchange(true);
-
- from("direct:start")
- .pollEnrich("seda:foo", 1000, myStrategy)
- .to("mock:result");
-}
-----
-
-This can be configured a bit easier using the `beanAllowNull` method
-from `AggregationStrategies` as shown:
-
-[source,java]
-----
-public void configure() throws Exception {
- from("direct:start")
- .pollEnrich("seda:foo", 1000, AggregationStrategies.beanAllowNull(appender, "append"))
- .to("mock:result");
-}
-----
-
-Then the `append` method in the POJO would need to deal with the
-situation that `newExchange` can be null:
-
-[source,java]
-----
-public class MyBodyAppender {
-
- public String append(String existing, String next) {
- if (next == null) {
- return "NewWasNull" + existing;
- } else {
- return existing + next;
- }
- }
-
-}
-----
-
-In the example above we use the xref:content-enricher.adoc[Content Enricher]
-EIP using `pollEnrich`. The `newExchange` will be null in the
-situation we could not get any data from the "seda:foo" endpoint, and
-therefore the timeout was hit after 1 second. So if we need to do some
-special merge logic we would need to set `setAllowNullNewExchange=true`,
-so the `append` method will be invoked. If we do not do that then when
-the timeout was hit, then the append method would normally not be
-invoked, meaning the xref:content-enricher.adoc[Content Enricher] did
-not merge/change the message.
-
-In XML DSL you would configure the `strategyMethodAllowNull` option and
-set it to true as shown below:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <aggregate strategyRef="myAppender"
- strategyMethodName="append"
- strategyMethodAllowNull="true"
- completionSize="3">
- <correlationExpression>
- <constant>true</constant>
- </correlationExpression>
- <to uri="mock:result"/>
- </aggregate>
- </route>
-</camelContext>
-----
-
-== Different body types
-
-When for example using `strategyMethodAllowNull` as true, then the
-parameter types of the message bodies does not have to be the same. For
-example suppose we want to aggregate from a `com.foo.User` type to a
-`List<String>` that contains the user name. We could code a POJO doing
-this as follows:
-
-[source,java]
-----
-public static final class MyUserAppender {
-
- public List addUsers(List names, User user) {
- if (names == null) {
- names = new ArrayList();
- }
- names.add(user.getName());
- return names;
- }
-}
-----
-
-Notice that the return type is a List which we want to contain the user
-names. The 1st parameter is the list of names, and then notice the 2nd
-parameter is the incoming `com.foo.User` type.
diff --git a/docs/user-manual/modules/ROOT/pages/batch-config-eip.adoc b/docs/user-manual/modules/ROOT/pages/batch-config-eip.adoc
deleted file mode 100644
index 4da0466..0000000
--- a/docs/user-manual/modules/ROOT/pages/batch-config-eip.adoc
+++ /dev/null
@@ -1,19 +0,0 @@
-[[batch-config-eip]]
-= Batch-config EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/batch-config-eip.adoc
-
-Batch-processing resequence EIP
-
-// eip options: START
-The Batch-config EIP supports 5 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *batchSize* | Sets the size of the batch to be re-ordered. The default size is 100. | 100 | Integer
-| *batchTimeout* | Sets the timeout for collecting elements to be re-ordered. The default timeout is 1000 msec. | 1000 | Long
-| *allowDuplicates* | Whether to allow duplicates. | false | Boolean
-| *reverse* | Whether to reverse the ordering. | false | Boolean
-| *ignoreInvalidExchanges* | Whether to ignore invalid exchanges | false | Boolean
-|===
-// eip options: END
diff --git a/docs/user-manual/modules/ROOT/pages/bean-eip.adoc b/docs/user-manual/modules/ROOT/pages/bean-eip.adoc
deleted file mode 100644
index eaf39c8..0000000
--- a/docs/user-manual/modules/ROOT/pages/bean-eip.adoc
+++ /dev/null
@@ -1,97 +0,0 @@
-[[bean-eip]]
-= Bean EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/bean-eip.adoc
-
-The Bean EIP binds beans to Camel message exchanges.
-
-== URI Format
-
-[source]
-----
-bean:beanID[?options]
-----
-
-Where *beanID* can be any string which is used to look up the bean in
-the xref:registry.adoc[Registry]
-
-== EIP options
-
-// eip options: START
-The Bean EIP supports 5 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *ref* | Sets a reference to a bean to use | | String
-| *method* | Sets the method name on the bean to use | | String
-| *beanType* | Sets the Class of the bean | | String
-| *cache* | *Deprecated* Use scope option instead. | | Boolean
-| *scope* | Scope of bean. See below for more details. | Singleton | String |
-|===
-// eip options: END
-
-=== Bean scope
-
-When using `singleton` scope (default) the bean is created or looked up only once and reused for the lifetime of the endpoint.
-The bean should be thread-safe in case concurrent threads is calling the bean at the same time.
-When using `request` scope the bean is created or looked up once per request (exchange). This can be used if you want to store state on a bean
-while processing a request and you want to call the same bean instance multiple times while processing the request.
-The bean does not have to be thread-safe as the instance is only called from the same request.
-When using `prototype` scope, then the bean will be looked up or created per call. However in case of lookup then this is delegated
-to the bean registry such as Spring or CDI (if in use), which depends on their configuration can act as either singleton or prototype scope.
-so when using `prototype` then this depends on the delegated registry.
-
-== Bean as endpoint
-
-Camel also supports invoking xref:components::bean-component.adoc[Bean] as an Endpoint. In the
-route below:
-
-What happens is that when the exchange is routed to the `myBean` Camel
-will use the xref:bean-binding.adoc[Bean Binding] to invoke the bean. +
- The source for the bean is just a plain POJO:
-
-Camel will use xref:bean-binding.adoc[Bean Binding] to invoke the
-`sayHello` method, by converting the Exchange's In body to the `String`
-type and storing the output of the method on the Exchange Out body.
-
-== Java DSL bean syntax
-
-Java DSL comes with syntactic sugar for the xref:components::bean-component.adoc[Bean]
-component. Instead of specifying the bean explicitly as the endpoint
-(i.e. `to("bean:beanName")`) you can use the following syntax:
-
-[source,java]
-----
-// Send message to the bean endpoint
-// and invoke method resolved using Bean Binding.
-from("direct:start").beanRef("beanName");
-
-// Send message to the bean endpoint
-// and invoke given method.
-from("direct:start").beanRef("beanName", "methodName");
-----
-
-Instead of passing name of the reference to the bean (so that Camel will
-lookup for it in the registry), you can specify the bean itself:
-
-[source,java]
-----
-// Send message to the given bean instance.
-from("direct:start").bean(new ExampleBean());
-
-// Explicit selection of bean method to be invoked.
-from("direct:start").bean(new ExampleBean(), "methodName");
-
-// Camel will create the instance of bean and cache it for you.
-from("direct:start").bean(ExampleBean.class);
-----
-
-== Bean binding
-
-How bean methods to be invoked are chosen (if they are not specified
-explicitly through the *method* parameter) and how parameter values are
-constructed from the xref:message.adoc[Message] are all defined by the
-xref:bean-binding.adoc[Bean Binding] mechanism which is used throughout
-all of the various xref:bean-integration.adoc[Bean Integration]
-mechanisms in Camel.
-
diff --git a/docs/user-manual/modules/ROOT/pages/choice-eip.adoc b/docs/user-manual/modules/ROOT/pages/choice-eip.adoc
deleted file mode 100644
index 922fdda..0000000
--- a/docs/user-manual/modules/ROOT/pages/choice-eip.adoc
+++ /dev/null
@@ -1,77 +0,0 @@
-[[choice-eip]]
-= Choice EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/choice-eip.adoc
-
-The
-http://www.enterpriseintegrationpatterns.com/ContentBasedRouter.html[Content
-Based Router] from the xref:enterprise-integration-patterns.adoc[EIP
-patterns] allows you to route messages to the correct destination based
-on the contents of the message exchanges.
-
-image::eip/ContentBasedRouter.gif[image]
-
-== Choice options
-
-// eip options: START
-The Choice EIP supports 2 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *whenClauses* | Sets the when clauses | | List
-| *otherwise* | Sets the otherwise node | | OtherwiseDefinition
-|===
-// eip options: END
-
-== Examples
-
-The following example shows how to route a request from an input
-*seda:a* endpoint to either *seda:b*, *seda:c* or *seda:d* depending on
-the evaluation of various xref:predicate.adoc[Predicate] expressions
-
-[source,java]
-----
-RouteBuilder builder = new RouteBuilder() {
- public void configure() {
- from("direct:a")
- .choice()
- .when(simple("${header.foo} == 'bar'"))
- .to("direct:b")
- .when(simple("${header.foo} == 'cheese'"))
- .to("direct:c")
- .otherwise()
- .to("direct:d");
- }
-};
-----
-
-[TIP]
-====
-See xref:faq/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc[Why
-can I not use when or otherwise in a Java Camel route] if you have
-problems with the Java DSL, accepting using `when` or `otherwise`.
-====
-
-And the same example using XML:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:a"/>
- <choice>
- <when>
- <simple>${header.foo} == 'bar'</simple>
- <to uri="direct:b"/>
- </when>
- <when>
- <simple>${header.foo} == 'cheese'</simple>
- <to uri="direct:c"/>
- </when>
- <otherwise>
- <to uri="direct:d"/>
- </otherwise>
- </choice>
- </route>
-</camelContext>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/circuitBreaker-eip.adoc b/docs/user-manual/modules/ROOT/pages/circuitBreaker-eip.adoc
deleted file mode 100644
index b3c13e3..0000000
--- a/docs/user-manual/modules/ROOT/pages/circuitBreaker-eip.adoc
+++ /dev/null
@@ -1,62 +0,0 @@
-[[circuitBreaker-eip]]
-= CircuitBreaker EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/circuitBreaker-eip.adoc
-
-The Circuit Breaker pattern is inspired by the real-world electrical circuit breaker,
-which is used to detect excessive current draw and fail fast to protect electrical equipment.
-The software-based circuit breaker works on the same notion, by encapsulating
-the operation and monitoring it for failures. The Circuit Breaker pattern operates in
-three states, as illustrated in the following figure:
-
-image::eip/CircuitBreaker.png[image]
-
-The states are as follows:
-
-* *Closed* — When operating successfully.
-* *Open* — When failure is detected and the breaker opens to short-circuit and fail
- fast. In this state, the circuit breaker avoids invoking the protected operation and
- avoids putting additional load on the struggling service.
-* *Half Open* — After a short period in the open state, an operation is attempted to
- see whether it can complete successfully, and depending on the outcome, it will
- transfer to either open or closed state.
-
-== Example
-
-Below is an example route showing a circuit breaker endpoint that protects against slow operation by falling back to the in-lined fallback route. By default the timeout request is just *1000ms* so the HTTP endpoint has to be fairly quick to succeed.
-[source,java]
-----
-from("direct:start")
- .circuitBreaker()
- .to("http://fooservice.com/slow")
- .onFallback()
- .transform().constant("Fallback message")
- .end()
- .to("mock:result");
-----
-
-And in XML DSL:
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <circuitBreaker>
- <to uri="http://fooservice.com/slow"/>
- <onFallback>
- <transform>
- <constant>Fallback message</constant>
- </transform>
- </onFallback>
- </circuitBreaker>
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-== CircuitBreaker Implementations
-
-Camel provides two implementations of this pattern:
-
-* xref:hystrix-eip.adoc[Hystrix] - Using the Netflix Hystrix implementation
-* xref:resilience4j-eip.adoc[Resilience4j] - Using the Resilience4j implementation
-
diff --git a/docs/user-manual/modules/ROOT/pages/claimCheck-eip.adoc b/docs/user-manual/modules/ROOT/pages/claimCheck-eip.adoc
deleted file mode 100644
index 6828830..0000000
--- a/docs/user-manual/modules/ROOT/pages/claimCheck-eip.adoc
+++ /dev/null
@@ -1,273 +0,0 @@
-[[claimCheck-eip]]
-= Claim Check EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/claimCheck-eip.adoc
-
-The http://www.enterpriseintegrationpatterns.com/patterns/messaging/StoreInLibrary.html[Claim Check] from the xref:enterprise-integration-patterns.adoc[EIP patterns]
-allows you to replace message content with a claim check (a unique key), which can be used to retrieve the message content at a later time.
-
-image::eip/StoreInLibrary.gif[image]
-
-It can also be useful in situations where you cannot trust the information with an outside party; in this case, you can use the Claim Check to hide the sensitive portions of data.
-
-[NOTE]
-====
-The Camel implementation of this EIP pattern stores the message content temporarily in an internal memory store.
-====
-
-// eip options: START
-The Claim Check EIP supports 5 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *operation* | *Required* The claim check operation to use. The following operations is supported: Get - Gets (does not remove) the claim check by the given key. GetAndRemove - Gets and remove the claim check by the given key. Set - Sets a new (will override if key already exists) claim check with the given key. Push - Sets a new claim check on the stack (does not use key). Pop - Gets the latest claim check from the stack (does not use key). | | ClaimCheckOperation
-| *key* | To use a specific key for claim check id (for dynamic keys use simple language syntax as the key). | | String
-| *filter* | Specified a filter to control what data gets merging data back from the claim check repository. The following syntax is supported: body - to aggregate the message body attachments - to aggregate all the message attachments headers - to aggregate all the message headers header:pattern - to aggregate all the message headers that matches the pattern. The pattern uses the following rules are applied in this order: exact match, returns true wildcard match (pattern ends with a and [...]
-| *strategyRef* | To use a custom AggregationStrategy instead of the default implementation. Notice you cannot use both custom aggregation strategy and configure data at the same time. | | String
-| *strategyMethodName* | This option can be used to explicit declare the method name to use, when using POJOs as the AggregationStrategy. | | String
-|===
-// eip options: END
-
-
-== Claim Check Operation
-
-When using this EIP you must specify the operation to use which can be of the following:
-
-* Get - Gets (does not remove) the claim check by the given key.
-* GetAndRemove - Gets and remove the claim check by the given key.
-* Set - Sets a new (will override if key already exists) claim check with the given key.
-* Push - Sets a new claim check on the stack (does not use key).
-* Pop - Gets the latest claim check from the stack (does not use key).
-
-When using the `Get`, `GetAndRemove`, or `Set` operation you must specify a key.
-These operations will then store and retrieve the data using this key. You can use this to store multiple data in different keys.
-
-The `Push` and `Pop` operations do *not* use a key but stores the data in a stack structure.
-
-
-== Filter what data to merge back
-
-The `filter` option is used to define what data to merge back when using the `Get` or `Pop` operation. When data is merged back
-then its merged using a `AggregationStrategy`. The default strategy uses the `filter` option to easily specify what data to merge back.
-
-The `filter` option takes a `String` value with the following syntax:
-
-* `body` = to aggregate the message body
-* `attachments` = to aggregate all the message attachments
-* `headers` = to aggregate all the message headers
-* `header:pattern` = to aggregate all the message headers that matches the pattern.
-
-The pattern rule supports wildcard and regular expression:
-
-* wildcard match (pattern ends with a `*` and the name starts with the pattern)
-* regular expression match
-
-You can specify multiple rules separated by comma.
-
-=== Basic filter examples
-
-For example to include the message body and all headers starting with _foo_:
-
-----
-body,header:foo*
-----
-
-To only merge back the message body:
-
-----
-body
-----
-
-To only merge back the message attachments:
-
-----
-attachments
-----
-
-To only merge back headers:
-
-----
-headers
-----
-
-To only merge back a header name foo:
-
-----
-header:foo
-----
-
-If the filter rule is specified as empty or as wildcard then everything is merged.
-
-Notice that when merging back data, then any existing data is overwritten, and any other existing data is preserved.
-
-=== Fine grained filtering with include and exclude pattern
-
-The syntax also supports the following prefixes which can be used to specify include,exclude, or remove
-
-* `+` = to include (which is the default mode)
-* `-` = to exclude (exclude takes precedence over include)
-* `--` = to remove (remove takes precedence)
-
-For example to skip the message body, and merge back everything else
-----
--body
-----
-
-Or to skip the message header foo, and merge back everything else
-----
--header:foo
-----
-
-You can also instruct to remove headers when merging data back, for example to remove all headers starting with _bar_:
-----
---headers:bar*
-----
-
-Note you cannot have both include (`+`) and exclude (`-`) `header:pattern` at the same time.
-
-== Dynamic keys
-
-The claim check key are static, but you can use the `simple` language syntax to define dynamic keys,
-for example to use a header from the message named `myKey`:
-
-[source,java]
-----
-from("direct:start")
- .to("mock:a")
- .claimCheck(ClaimCheckOperation.Set, "${header.myKey}")
- .transform().constant("Bye World")
- .to("mock:b")
- .claimCheck(ClaimCheckOperation.Get, "${header.myKey}")
- .to("mock:c")
- .transform().constant("Hi World")
- .to("mock:d")
- .claimCheck(ClaimCheckOperation.Get, "${header.myKey}")
- .to("mock:e");
-----
-
-
-== Java Examples
-
-The following example shows the `Push` and `Pop` operations in action;
-
-[source,java]
-----
-from("direct:start")
- .to("mock:a")
- .claimCheck(ClaimCheckOperation.Push)
- .transform().constant("Bye World")
- .to("mock:b")
- .claimCheck(ClaimCheckOperation.Pop)
- .to("mock:c");
-----
-
-For example if the message body from the beginning is `Hello World` then that data is pushed on the stack of the Claim Check EIP.
-And then the message body is transformed to `Bye World`, which is what `mock:b` endpoint receives. When we `Pop` from the Claim Check EIP
-then the original message body is retrieved and merged back so `mock:c` will retrieve the message body with `Hello World`.
-
-Here is an example using `Get` and `Set` operations, which uses the key `foo`:
-
-[source,java]
-----
-from("direct:start")
- .to("mock:a")
- .claimCheck(ClaimCheckOperation.Set, "foo")
- .transform().constant("Bye World")
- .to("mock:b")
- .claimCheck(ClaimCheckOperation.Get, "foo")
- .to("mock:c")
- .transform().constant("Hi World")
- .to("mock:d")
- .claimCheck(ClaimCheckOperation.Get, "foo")
- .to("mock:e");
-----
-
-Notice how we can `Get` the same data twice using the `Get` operation as it will not remove the data. If you only want
-to get the data once, you can use `GetAndRemove`.
-
-The last example shows how to use the `filter` option where we only want to get back header named `foo` or `bar`:
-
-[source,java]
-----
-from("direct:start")
- .to("mock:a")
- .claimCheck(ClaimCheckOperation.Push)
- .transform().constant("Bye World")
- .setHeader("foo", constant(456))
- .removeHeader("bar")
- .to("mock:b")
- // only merge in the message headers foo or bar
- .claimCheck(ClaimCheckOperation.Pop, null, "header:(foo|bar)")
- .to("mock:c");
-----
-
-== XML examples
-
-The following example shows the `Push` and `Pop` operations in action;
-
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <to uri="mock:a"/>
- <claimCheck operation="Push"/>
- <transform>
- <constant>Bye World</constant>
- </transform>
- <to uri="mock:b"/>
- <claimCheck operation="Pop"/>
- <to uri="mock:c"/>
-</route>
-----
-
-For example if the message body from the beginning is `Hello World` then that data is pushed on the stack of the Claim Check EIP.
-And then the message body is transformed to `Bye World`, which is what `mock:b` endpoint receives. When we `Pop` from the Claim Check EIP
-then the original message body is retrieved and merged back so `mock:c` will retrieve the message body with `Hello World`.
-
-Here is an example using `Get` and `Set` operations, which uses the key `foo`:
-
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <to uri="mock:a"/>
- <claimCheck operation="Set" key="foo"/>
- <transform>
- <constant>Bye World</constant>
- </transform>
- <to uri="mock:b"/>
- <claimCheck operation="Get" key="foo"/>
- <to uri="mock:c"/>
- <transform>
- <constant>Hi World</constant>
- </transform>
- <to uri="mock:d"/>
- <claimCheck operation="Get" key="foo"/>
- <to uri="mock:e"/>
-</route>
-----
-
-Notice how we can `Get` the same data twice using the `Get` operation as it will not remove the data. If you only want
-to get the data once, you can use `GetAndRemove`.
-
-The last example shows how to use the `filter` option where we only want to get back header named `foo` or `bar`:
-
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <to uri="mock:a"/>
- <claimCheck operation="Push"/>
- <transform>
- <constant>Bye World</constant>
- </transform>
- <setHeader name="foo">
- <constant>456</constant>
- </setHeader>
- <removeHeader headerName="bar"/>
- <to uri="mock:b"/>
- <!-- only merge in the message headers foo or bar -->
- <claimCheck operation="Pop" filter="header:(foo|bar)"/>
- <to uri="mock:c"/>
-</route>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/constant-language.adoc b/docs/user-manual/modules/ROOT/pages/constant-language.adoc
deleted file mode 100644
index a8ef0e0..0000000
--- a/docs/user-manual/modules/ROOT/pages/constant-language.adoc
+++ /dev/null
@@ -1,75 +0,0 @@
-[[constant-language]]
-= Constant Language
-:page-source: core/camel-core-languages/src/main/docs/constant-language.adoc
-
-*Since Camel 1.5*
-
-The Constant Expression Language is really just a way to specify
-constant strings as a type of expression.
-
-[NOTE]
-====
-This is a fixed constant value that is only set once during starting up the route,
-do not use this if you want dynamic values during routing.
-====
-
-== Constant Options
-
-
-// language options: START
-The Constant language supports 1 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
-
-
-== Example usage
-
-The setHeader element of the Spring DSL can utilize a constant
-expression like:
-
-[source,xml]
-----
-<route>
- <from uri="seda:a"/>
- <setHeader name="theHeader">
- <constant>the value</constant>
- </setHeader>
- <to uri="mock:b"/>
-</route>
-----
-
-in this case, the Message coming from the seda:a
-Endpoint will have 'theHeader' header set to the
-constant value 'the value'.
-
-And the same example using Java DSL:
-
-[source,java]
-----
-from("seda:a")
- .setHeader("theHeader", constant("the value"))
- .to("mock:b");
-----
-
-== Loading constant from external resource
-
-You can externalize the constant and have Camel load it from a resource
-such as `"classpath:"`, `"file:"`, or `"http:"`. +
- This is done using the following syntax: `"resource:scheme:location"`,
-eg to refer to a file on the classpath you can do:
-
-[source,java]
-----
-.setHeader("myHeader").constant("resource:classpath:constant.txt")
-----
-
-== Dependencies
-
-The Constant language is part of *camel-core*.
diff --git a/docs/user-manual/modules/ROOT/pages/content-based-router-eip.adoc b/docs/user-manual/modules/ROOT/pages/content-based-router-eip.adoc
deleted file mode 100644
index 761ac92..0000000
--- a/docs/user-manual/modules/ROOT/pages/content-based-router-eip.adoc
+++ /dev/null
@@ -1,80 +0,0 @@
-[[contentBasedRouter-eip]]
-= Content Based Router
-:page-source: core/camel-core-engine/src/main/docs/eips/content-based-router-eip.adoc
-
-The
-http://www.enterpriseintegrationpatterns.com/ContentBasedRouter.html[Content
-Based Router] from the xref:enterprise-integration-patterns.adoc[EIP
-patterns] allows you to route messages to the correct destination based
-on the contents of the message exchanges.
-
-image::eip/ContentBasedRouter.gif[image]
-
-The following example shows how to route a request from an input
-*seda:a* endpoint to either *seda:b*, *seda:c* or *seda:d* depending on
-the evaluation of various xref:predicate.adoc[Predicate] expressions
-
-== Using the xref:fluent-builders.adoc[Fluent Builders]
-
-[source,java]
-----
-RouteBuilder builder = new RouteBuilder() {
- public void configure() {
- errorHandler(deadLetterChannel("mock:error"));
-
- from("direct:a")
- .choice()
- .when(header("foo").isEqualTo("bar"))
- .to("direct:b")
- .when(header("foo").isEqualTo("cheese"))
- .to("direct:c")
- .otherwise()
- .to("direct:d");
- }
-};
-----
-
-[TIP]
-====
-See
-xref:faq/why-can-i-not-use-when-or-otherwise-in-a-java-camel-route.adoc[Why
-can I not use when or otherwise in a Java Camel route] if you have
-problems with the Java DSL, accepting using `when` or `otherwise`.
-====
-
-== Using the xref:spring-xml-extensions.adoc[Spring XML Extensions]
-
-[source,java]
-----
-<camelContext errorHandlerRef="errorHandler" xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:a"/>
- <choice>
- <when>
- <xpath>$foo = 'bar'</xpath>
- <to uri="direct:b"/>
- </when>
- <when>
- <xpath>$foo = 'cheese'</xpath>
- <to uri="direct:c"/>
- </when>
- <otherwise>
- <to uri="direct:d"/>
- </otherwise>
- </choice>
- </route>
-</camelContext>
-----
-
-For further examples of this pattern in use you could look at the
-https://github.com/apache/camel/blob/master/core/camel-core/src/test/java/org/apache/camel/processor/ChoiceTest.java[junit test case].
-
-[[ContentBasedRouter-UsingThisPattern]]
-== Using This Pattern
-
-If you would like to use this EIP Pattern then please read the
-xref:getting-started.adoc[Getting Started]. You may also find the
-xref:architecture.adoc[Architecture] useful particularly the description
-of xref:endpoint.adoc[Endpoint] and xref:uris.adoc[URIs]. Then you could
-try out some of the xref:examples.adoc[Examples] first before trying
-this pattern out.
diff --git a/docs/user-manual/modules/ROOT/pages/content-filter-eip.adoc b/docs/user-manual/modules/ROOT/pages/content-filter-eip.adoc
deleted file mode 100644
index b3cdb81..0000000
--- a/docs/user-manual/modules/ROOT/pages/content-filter-eip.adoc
+++ /dev/null
@@ -1,66 +0,0 @@
-[[ContentFilter-eip]]
-= Content Filter
-:page-source: core/camel-core-engine/src/main/docs/eips/content-filter-eip.adoc
-
-Camel supports the
-http://www.enterpriseintegrationpatterns.com/ContentFilter.html[Content
-Filter] from the
-xref:enterprise-integration-patterns.adoc[EIP patterns]
-using one of the following mechanisms in the routing logic to transform
-content from the inbound message.
-
-* xref:message-translator.adoc[Message Translator]
-* invoking a xref:bean-integration.adoc[Java bean]
-* xref:processor.adoc[Processor] object
-
-image::eip/ContentFilter.gif[image]
-
-A common way to filter messages is to use an
-xref:expression.adoc[Expression] in the xref:dsl.adoc[DSL] like
-xref:components::xquery-language.adoc[XQuery] or one of the supported
-xref:scripting-languages.adoc[Scripting Languages].
-
-== Using the xref:fluent-builders.adoc[Fluent Builders]
-
-Here is a simple example using the xref:dsl.adoc[DSL] directly
-
-In this example we add our own xref:processor.adoc[Processor]
-
-For further examples of this pattern in use you could look at one of the
-JUnit tests
-
-* https://github.com/apache/camel/blob/master/core/camel-core/src/test/java/org/apache/camel/processor/TransformTest.java[TransformTest]
-* https://github.com/apache/camel/blob/master/core/camel-core/src/test/java/org/apache/camel/processor/TransformViaDSLTest.java[TransformViaDSLTest]
-
-== Using Spring XML
-
-[source,xml]
-----
-<route>
- <from uri="activemq:Input"/>
- <bean ref="myBeanName" method="doTransform"/>
- <to uri="activemq:Output"/>
-</route>
-----
-
-You can also use XPath to filter out part of the message you are
-interested in:
-
-[source,xml]
-----
-<route>
- <from uri="activemq:Input"/>
- <setBody><xpath resultType="org.w3c.dom.Document">//foo:bar</xpath></setBody>
- <to uri="activemq:Output"/>
-</route>
-----
-
-[[ContentFilter-UsingThisPattern]]
-== Using This Pattern
-
-If you would like to use this EIP Pattern then please read the
-xref:getting-started.adoc[Getting Started], you may also find the
-xref:architecture.adoc[Architecture] useful particularly the description
-of xref:endpoint.adoc[Endpoint] and xref:uris.adoc[URIs]. Then you could
-try out some of the xref:examples.adoc[Examples] first before trying
-this pattern out.
diff --git a/docs/user-manual/modules/ROOT/pages/convertBodyTo-eip.adoc b/docs/user-manual/modules/ROOT/pages/convertBodyTo-eip.adoc
deleted file mode 100644
index f075792..0000000
--- a/docs/user-manual/modules/ROOT/pages/convertBodyTo-eip.adoc
+++ /dev/null
@@ -1,16 +0,0 @@
-[[convertBodyTo-eip]]
-= Convert Body To EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/convertBodyTo-eip.adoc
-
-The ConvertBodyTo EIP allows you to transform your body to a different type.
-
-// eip options: START
-The Convert Body To EIP supports 2 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *type* | *Required* The java type to convert to | | String
-| *charset* | To use a specific charset when converting | | String
-|===
-// eip options: END
diff --git a/docs/user-manual/modules/ROOT/pages/customLoadBalancer-eip.adoc b/docs/user-manual/modules/ROOT/pages/customLoadBalancer-eip.adoc
deleted file mode 100644
index 50d413e..0000000
--- a/docs/user-manual/modules/ROOT/pages/customLoadBalancer-eip.adoc
+++ /dev/null
@@ -1,82 +0,0 @@
-[[customLoadBalancer-eip]]
-= Custom Load Balancer EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/customLoadBalancer-eip.adoc
-
-This EIP allows you to use your own Load Balancer implementation
-
-// eip options: START
-The Custom Load Balancer EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *ref* | *Required* Refers to the custom load balancer to lookup from the registry | | String
-|===
-// eip options: END
-
-
-An example using Java DSL:
-[source,java]
-----
-from("direct:start")
- // using our custom load balancer
- .loadBalance(new MyLoadBalancer())
- .to("mock:x", "mock:y", "mock:z");
-----
-
-And the same example using XML DSL:
-[source,xml]
-----
-<!-- this is the implementation of our custom load balancer -->
-<bean id="myBalancer" class="org.apache.camel.processor.CustomLoadBalanceTest$MyLoadBalancer"/>
-
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <loadBalance>
- <!-- refer to my custom load balancer -->
- <custom ref="myBalancer"/>
- <!-- these are the endpoints to balancer -->
- <to uri="mock:x"/>
- <to uri="mock:y"/>
- <to uri="mock:z"/>
- </loadBalance>
- </route>
-</camelContext>
-----
-
-Notice in the XML DSL above we use `<custom>` which is only available in *Camel 2.8* onwards. In older releases you would have to do as follows instead:
-[source,xml]
-----
-<loadBalance ref="myBalancer">
- <!-- these are the endpoints to balancer -->
- <to uri="mock:x"/>
- <to uri="mock:y"/>
- <to uri="mock:z"/>
-</loadBalance>
-----
-
-To implement a custom load balancer you can extend some support classes such as `LoadBalancerSupport` and `SimpleLoadBalancerSupport`.
-The former supports the asynchronous routing engine, and the latter does not. Here is an example of a custom load balancer implementation:
-[source,java]
-----
-public static class MyLoadBalancer extends LoadBalancerSupport {
-
- public boolean process(Exchange exchange, AsyncCallback callback) {
- String body = exchange.getIn().getBody(String.class);
- try {
- if ("x".equals(body)) {
- getProcessors().get(0).process(exchange);
- } else if ("y".equals(body)) {
- getProcessors().get(1).process(exchange);
- } else {
- getProcessors().get(2).process(exchange);
- }
- } catch (Throwable e) {
- exchange.setException(e);
- }
- callback.done(true);
- return true;
- }
-}
-----
diff --git a/docs/user-manual/modules/ROOT/pages/delay-eip.adoc b/docs/user-manual/modules/ROOT/pages/delay-eip.adoc
deleted file mode 100644
index 20e524e..0000000
--- a/docs/user-manual/modules/ROOT/pages/delay-eip.adoc
+++ /dev/null
@@ -1,173 +0,0 @@
-[[delay-eip]]
-= Delay EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/delay-eip.adoc
-The Delayer Pattern allows you to delay the delivery of messages to some destination.
-
-== Options
-
-// eip options: START
-The Delay EIP supports 3 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *executorServiceRef* | Refers to a custom Thread Pool if asyncDelay has been enabled. | | String
-| *asyncDelayed* | Enables asynchronous delay which means the thread will not block while delaying. | true | Boolean
-| *callerRunsWhenRejected* | Whether or not the caller should run the task when it was rejected by the thread pool. Is by default true | true | Boolean
-|===
-// eip options: END
-
-[NOTE]
-====
-The expression is a value in millis to wait from the current time, so the expression should just be 3000.
-
-However you can use a long value for a fixed value to indicate the delay in millis.
-
-See the Spring DSL samples for Delayer.
-====
-
-[CAUTION]
-.Using Delayer in Java DSL
-===
-See this ticket: https://issues.apache.org/jira/browse/CAMEL-2654[https://issues.apache.org/jira/browse/CAMEL-2654]
-===
-
-== Samples
-
-The example below will delay all messages received on *seda:b* 1 second before sending them to *mock:result*.
-
-[source,java]
-----
-from("seda:b")
- .delay(1000)
- .to("mock:result");
-----
-
-You can just delay things a fixed amount of time from the point at which the delayer receives the message. For example to delay things 2 seconds
-
-[source,java]
-----
-delayer(2000)
-----
-
-The above assume that the delivery order is maintained and that the messages are delivered in delay order. If you want to reorder the messages based on delivery time, you can use the Resequencer with this pattern. For example
-
-[source,java]
-----
-from("activemq:someQueue")
- .resequencer(header("MyDeliveryTime"))
- .delay("MyRedeliveryTime")
- .to("activemq:aDelayedQueue");
-----
-
-You can of course use many different Expression languages such as XPath, XQuery, SQL or various Scripting Languages. For example to delay the message for the time period specified in the header, use the following syntax:
-
-[source,java]
-----
-from("activemq:someQueue")
- .delay(header("delayValue"))
- .to("activemq:aDelayedQueue");
-----
-
-And to delay processing using the Simple language you can use the following DSL:
-
-[source,java]
-----
-from("activemq:someQueue")
- .delay(simple("${body.delayProperty}"))
- .to("activemq:aDelayedQueue");
-----
-
-=== Spring DSL
-The sample below demonstrates the delay in Spring DSL:
-
-[source,xml]
-----
-<bean id="myDelayBean" class="org.apache.camel.processor.MyDelayCalcBean"/>
-<bean id="exchangeAwareBean" class="org.apache.camel.processor.ExchangeAwareDelayCalcBean"/>
-
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="seda:a"/>
- <delay>
- <header>MyDelay</header>
- </delay>
- <to uri="mock:result"/>
- </route>
- <route>
- <from uri="seda:b"/>
- <delay>
- <constant>1000</constant>
- </delay>
- <to uri="mock:result"/>
- </route>
- <route>
- <from uri="seda:c"/>
- <delay>
- <method ref="myDelayBean" method="delayMe"/>
- </delay>
- <to uri="mock:result"/>
- </route>
- <route>
- <from uri="seda:d"/>
- <delay>
- <method ref="exchangeAwareBean" method="delayMe"/>
- </delay>
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-== Asynchronous delaying
-
-You can let the Delayer use non blocking asynchronous delaying, which means Camel will use a scheduler to schedule a task to be executed in the future. The task will then continue routing. This allows the caller thread to not block and be able to service other messages etc.
-
-=== From Java DSL
-You use the `asyncDelayed()` to enable the async behavior.
-
-[source,java]
-----
-from("activemq:queue:foo")
- .delay(1000).asyncDelayed()
- .to("activemq:aDelayedQueue");
-----
-
-=== From Spring XML
-
-You use the `asyncDelayed="true"` attribute to enable the async behavior.
-
-[source,xml]
-----
-<route>
- <from uri="activemq:queue:foo"/>
- <delay asyncDelayed="true">
- <constant>1000</constant>
- </delay>
- <to uri="activemq:aDealyedQueue"/>
-</route>
-----
-
-== Creating a custom delay
-
-You can use an expression, such as calling a method on a bean, to determine when to send a message using something like this
-
-[source,java]
-----
-from("activemq:foo").
- delay().method("someBean", "computeDelay").
- to("activemq:bar");
-----
-
-then the bean would look like this...
-
-[source,java]
-----
-public class SomeBean {
- public long computeDelay() {
- long delay = 0;
- // use java code to compute a delay value in millis
- return delay;
- }
-}
-----
-
diff --git a/docs/user-manual/modules/ROOT/pages/dynamicRouter-eip.adoc b/docs/user-manual/modules/ROOT/pages/dynamicRouter-eip.adoc
deleted file mode 100644
index 6f04383..0000000
--- a/docs/user-manual/modules/ROOT/pages/dynamicRouter-eip.adoc
+++ /dev/null
@@ -1,159 +0,0 @@
-[[dynamicRouter-eip]]
-= Dynamic Router EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/dynamicRouter-eip.adoc
-
-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.
-
-image::eip/DynamicRouter.gif[image]
-
-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.
-===
-
-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 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 [...]
-|===
-// 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
-
-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 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.
-
-=== 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 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.
- }
-}
-----
diff --git a/docs/user-manual/modules/ROOT/pages/enrich-eip.adoc b/docs/user-manual/modules/ROOT/pages/enrich-eip.adoc
deleted file mode 100644
index e2a9eb9..0000000
--- a/docs/user-manual/modules/ROOT/pages/enrich-eip.adoc
+++ /dev/null
@@ -1,198 +0,0 @@
-[[enrich-eip]]
-= Enrich EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/enrich-eip.adoc
-
-Camel supports the Content Enricher from the EIP patterns using a Message Translator, an arbitrary Processor in the routing logic, or using the enrich DSL element to enrich the message.
-
-image::eip/DataEnricher.gif[image]
-
-TIP: See the `cacheSize` option for more details on _how much cache_ to use depending on how many or few unique endpoints are used.
-
-// eip options: START
-The Enrich EIP supports 7 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *strategyRef* | Refers to an AggregationStrategy to be used to merge the reply from the external service, into a single outgoing message. By default Camel will use the reply from the external service as outgoing message. | | String
-| *strategyMethodName* | This option can be used to explicit declare the method name to use, when using POJOs as the AggregationStrategy. | | String
-| *strategyMethodAllowNull* | If this option is false then the aggregate method is not used if there was no data to enrich. If this option is true then null values is used as the oldExchange (when no data to enrich), when using POJOs as the AggregationStrategy. | false | Boolean
-| *aggregateOnException* | If this option is false then the aggregate method is not used if there was an exception thrown while trying to retrieve the data to enrich from the resource. Setting this option to true allows end users to control what to do if there was an exception in the aggregate method. For example to suppress the exception or set a custom message body etc. | false | Boolean
-| *shareUnitOfWork* | Shares the org.apache.camel.spi.UnitOfWork with the parent and the resource exchange. Enrich will by default not share unit of work between the parent exchange and the resource exchange. This means the resource exchange has its own individual unit of work. | false | Boolean
-| *cacheSize* | Sets the maximum size used by the org.apache.camel.spi.ProducerCache which is used to cache and reuse producer 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 discarded after use. This reduc [...]
-| *ignoreInvalidEndpoint* | Ignore the invalidate endpoint exception when try to create a producer with that endpoint | false | Boolean
-|===
-// eip options: END
-
-== Content enrichment using a Message Translator or a Processor
-
-You can use Templating to consume a message from one destination, transform it with something like Velocity or XQuery, and then send it on to another destination. For example using InOnly (one way messaging)
-
-== Samples
-
-[source,java]
-----
-from("activemq:My.Queue").
- to("velocity:com/acme/MyResponse.vm").
- to("activemq:Another.Queue");
-----
-
-If you want to use InOut (request-reply) semantics to process requests on the *My.Queue* queue on ActiveMQ with a template generated response, then sending responses back to the JMSReplyTo Destination you could use this:
-
-[source,java]
-----
-from("activemq:My.Queue").
- to("velocity:com/acme/MyResponse.vm");
-----
-
-Here is a simple example using the DSL directly to transform the message body
-
-[source,java]
-----
-from("direct:start").setBody(body().append(" World!")).to("mock:result");
-----
-
-In this example we add our own Processor using explicit Java code
-
-[source,java]
-----
-from("direct:start").process(new Processor() {
- public void process(Exchange exchange) {
- Message in = exchange.getIn();
- in.setBody(in.getBody(String.class) + " World!");
- }
-}).to("mock:result");
-----
-
-Finally we can use Bean Integration to use any Java method on any bean to act as the transformer
-
-[source,java]
-----
-from("activemq:My.Queue").
- beanRef("myBeanName", "myMethodName").
- to("activemq:Another.Queue");
-----
-
-=== Using Spring XML
-
-[source,xml]
-----
-<route>
- <from uri="activemq:Input"/>
- <bean ref="myBeanName" method="doTransform"/>
- <to uri="activemq:Output"/>
-</route>
-----
-
-== Content enrichment using the enrich DSL element
-
-Camel comes with flavor `enrich` as a choice of content enricher in the DSL.
-The other one is `pollEnrich`
-
-`enrich` uses a Producer to obtain the additional data. It is usually used for Request Reply messaging, for instance to invoke an external web service.
-
-Both `enrich` and `pollEnrich` supports dynamic endpoints that uses an Expression to compute the uri, which allows to use data from the current Exchange.
-
-=== Enrich example using Java
-
-[source,java]
-----
-AggregationStrategy aggregationStrategy = ...
-
-from("direct:start")
- .enrich("direct:resource", aggregationStrategy)
- .to("direct:result");
-
-from("direct:resource")
-...
-----
-
-The content enricher (`enrich`) retrieves additional data from a _resource endpoint_ in order to enrich an incoming message (contained in the _original exchange_).
-An aggregation strategy is used to combine the original exchange and the _resource exchange_. The first parameter of the `AggregationStrategy.aggregate(Exchange, Exchange)` method corresponds to the original exchange, the second parameter the resource exchange.
-The results from the resource endpoint are stored in the resource exchange's out-message. Here's an example template for implementing an aggregation strategy:
-
-[source,java]
-----
-public class ExampleAggregationStrategy implements AggregationStrategy {
-
- public Exchange aggregate(Exchange original, Exchange resource) {
- Object originalBody = original.getIn().getBody();
- Object resourceResponse = resource.getIn().getBody();
- Object mergeResult = ... // combine original body and resource response
- if (original.getPattern().isOutCapable()) {
- original.getOut().setBody(mergeResult);
- } else {
- original.getIn().setBody(mergeResult);
- }
- return original;
- }
-
-}
-----
-
-Using this template the original exchange can be of any pattern. The resource exchange created by the enricher is always an in-out exchange.
-
-=== Enrich example using XML
-
-[source,xml]
-----
-<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <enrich strategyRef="aggregationStrategy">
- <constant>direct:resource</constant>
- </enrich>
- <to uri="direct:result"/>
- </route>
- <route>
- <from uri="direct:resource"/>
- ...
- </route>
-</camelContext>
-
-<bean id="aggregationStrategy" class="..." />
-----
-
-== Aggregation strategy is optional
-The aggregation strategy is optional. If you do not provide it Camel will by default just use the body obtained from the resource.
-[source,java]
-----
-from("direct:start")
- .enrich("direct:resource")
- .to("direct:result");
-----
-
-In the route above the message sent to the direct:result endpoint will contain the output from the direct:resource as we do not use any custom aggregation.
-
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <enrich>
- <constant>direct:resource</constant>
- </enrich>
- <to uri="direct:result"/>
-</route>
-----
-
-== Using dynamic uris
-
-Both `enrich` and `pollEnrich` supports using dynamic uris computed based on information from the current Exchange. For example to enrich from a HTTP endpoint where the header with key orderId is used as part of the content-path of the HTTP url:
-[source,java]
-----
-from("direct:start")
- .enrich().simple("http:myserver/${header.orderId}/order")
- .to("direct:result");
-----
-
-And in XML DSL
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <enrich>
- <simple>http:myserver/${header.orderId}/order</simple>
- </enrich>
- <to uri="direct:result"/>
-</route>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/eventDrivenConsumer-eip.adoc b/docs/user-manual/modules/ROOT/pages/eventDrivenConsumer-eip.adoc
deleted file mode 100644
index af93dbd..0000000
--- a/docs/user-manual/modules/ROOT/pages/eventDrivenConsumer-eip.adoc
+++ /dev/null
@@ -1,59 +0,0 @@
-[[eventDrivenConsumer-eip]]
-= Event Driven Consumer
-:page-source: core/camel-core-engine/src/main/docs/eips/eventDrivenConsumer-eip.adoc
-
-Camel supports the
-http://www.enterpriseintegrationpatterns.com/EventDrivenConsumer.html[Event Driven Consumer]
-from the
-xref:enterprise-integration-patterns.adoc[EIP patterns].
-The default consumer model is event based (i.e. asynchronous)
-as this means that the Camel container can then manage pooling,
-threading and concurrency for you in a declarative manner.
-
-image::eip/EventDrivenConsumerSolution.gif[image]
-
-The Event Driven Consumer is implemented by consumers implementing the
-http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/Processor.html[Processor]
-interface which is invoked by the xref:message-endpoint.adoc[Message Endpoint]
-when a xref:message.adoc[Message] is available for processing.
-
-[[eventDrivenConsumer-Example]]
-== Example
-
-The following demonstrates a
-http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/Processor.html[Processor]
-defined in the Camel xref:registry.adoc[Registry] which is
-invoked when an event occurs from a xref:components::jms-component.adoc[JMS] queue.
-
-*Using the xref:fluent-builders.adoc[Fluent Builders]*
-
-[source,java]
-----
-from("jms:queue:foo")
- .processRef("processor");
-----
-
-**Using the xref:spring-xml-extensions.adoc[Spring XML Extensions]**
-
-[source,xml]
-----
-<route>
- <from uri="jms:queue:foo"/>
- <to uri="processor"/>
-</route>
-----
-
-For more details see:
-
-* xref:message.adoc[Message]
-* xref:message-endpoint.adoc[Message Endpoint]
-
-[[eventDrivenConsumer-UsingThisPattern]]
-== Using This Pattern
-
-If you would like to use this EIP Pattern then please read the
-xref:getting-started.adoc[Getting Started], you may also find the
-xref:architecture.adoc[Architecture] useful particularly the description
-of xref:endpoint.adoc[Endpoint] and xref:uris.adoc[URIs]. Then you could
-try out some of the xref:examples.adoc[Examples] first before trying
-this pattern out.
diff --git a/docs/user-manual/modules/ROOT/pages/exchangeProperty-language.adoc b/docs/user-manual/modules/ROOT/pages/exchangeProperty-language.adoc
deleted file mode 100644
index c6c0a60..0000000
--- a/docs/user-manual/modules/ROOT/pages/exchangeProperty-language.adoc
+++ /dev/null
@@ -1,61 +0,0 @@
-[[exchangeProperty-language]]
-= ExchangeProperty Language
-:page-source: core/camel-core-languages/src/main/docs/exchangeProperty-language.adoc
-
-*Since Camel 2.0*
-
-The ExchangeProperty Expression Language allows you to extract values of
-named exchange properties.
-
-== Exchange Property Options
-
-// language options: START
-The ExchangeProperty language supports 1 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
-
-== Example usage
-
-The recipientList element of the Spring DSL can utilize a
-exchangeProperty expression like:
-
-In this case, the list of recipients are contained in the property
-'myProperty'.
-
-[source,xml]
-----
-<route>
- <from uri="direct:a" />
- <recipientList>
- <exchangeProperty>myProperty</exchangeProperty>
- </recipientList>
-</route>
-----
-
-And the same example in Java DSL:
-
-[source,java]
-----
-from("direct:a").recipientList(exchangeProperty("myProperty"));
-----
-
-And with a slightly different syntax where you use the builder to the
-fullest (i.e. avoid using parameters but using stacked operations,
-notice that exchangeProperty is not a parameter but a stacked method
-call)
-
-[source,java]
-----
-from("direct:a").recipientList().exchangeProperty("myProperty");
-----
-
-== Dependencies
-
-The ExchangeProperty language is part of *camel-core*.
\ No newline at end of file
diff --git a/docs/user-manual/modules/ROOT/pages/failover-eip.adoc b/docs/user-manual/modules/ROOT/pages/failover-eip.adoc
deleted file mode 100644
index 0b66117..0000000
--- a/docs/user-manual/modules/ROOT/pages/failover-eip.adoc
+++ /dev/null
@@ -1,47 +0,0 @@
-[[failover-eip]]
-= Failover EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/failover-eip.adoc
-
-Failover Load Balancer, with this policy in case of failures the exchange will be tried on the next endpoint.
-
-== Options
-
-// eip options: START
-The Failover EIP supports 4 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *exception* | A list of class names for specific exceptions to monitor. If no exceptions is configured then all exceptions is monitored | | List
-| *roundRobin* | Whether or not the failover load balancer should operate in round robin mode or not. If not, then it will always start from the first endpoint when a new message is to be processed. In other words it restart from the top for every message. If round robin is enabled, then it keeps state and will continue with the next endpoint in a round robin fashion. You can also enable sticky mode together with round robin, if so then it will pick the last known good endpoint to use wh [...]
-| *sticky* | Whether or not the failover load balancer should operate in sticky mode or not. If not, then it will always start from the first endpoint when a new message is to be processed. In other words it restart from the top for every message. If sticky is enabled, then it keeps state and will continue with the last known good endpoint. You can also enable sticky mode together with round robin, if so then it will pick the last known good endpoint to use when starting the load balanci [...]
-| *maximumFailoverAttempts* | A value to indicate after X failover attempts we should exhaust (give up). Use -1 to indicate never give up and continuously try to failover. Use 0 to never failover. And use e.g. 3 to failover at most 3 times before giving up. his option can be used whether or not roundRobin is enabled or not. | -1 | Integer
-|===
-// eip options: END
-
-== Examples
-
-In this case we are using the header test as correlation expression:
-
-[source,java]
-----
-from("direct:start")
- .loadBalance()
- .failover(MyException.class)
- .to("seda:x", "seda:y", "seda:z");
-----
-
-In XML you'll have a route like this
-
-[source,xml]
-----
-<from uri="direct:start"/>
- <loadBalance>
- <failover>
- <exception>com.example.camel.MyException</exception>
- </failover>
- <to uri="seda:x"/>
- <to uri="seda:y"/>
- <to uri="seda:z"/>
- </loadBalance>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/file-language.adoc b/docs/user-manual/modules/ROOT/pages/file-language.adoc
deleted file mode 100644
index 88bfa2c..0000000
--- a/docs/user-manual/modules/ROOT/pages/file-language.adoc
+++ /dev/null
@@ -1,295 +0,0 @@
-[[file-language]]
-= File Language
-:page-source: core/camel-core-languages/src/main/docs/file-language.adoc
-
-*Since Camel 1.1*
-
-The file language is merged with
-xref:simple-language.adoc[Simple] language which means you can use all the file
-syntax directly within the simple language.
-
-The File Expression Language is an extension to the
-xref:simple-language.adoc[Simple] language, adding file related capabilities.
-These capabilities are related to common use cases working with file
-path and names. The goal is to allow expressions to be used with the
-File and FTP components for setting
-dynamic file patterns for both consumer and producer.
-
-== File Language options
-
-// language options: START
-The File language supports 2 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| resultType | | String | Sets the class name of the result type (type from output)
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
-
-== Syntax
-
-This language is an *extension* to the xref:simple-language.adoc[Simple] language
-so the xref:simple-language.adoc[Simple] syntax applies also. So the table below
-only lists the additional. +
- As opposed to xref:simple-language.adoc[Simple] language
-xref:file-language.adoc[File Language] also supports
-xref:constant-language.adoc[Constant] expressions so you can enter a fixed
-filename.
-
-All the file tokens use the same expression name as the method on the
-`java.io.File` object, for instance `file:absolute` refers to the
-`java.io.File.getAbsolute()` method. Notice that not all expressions are
-supported by the current Exchange. For instance the xref:components::ftp-component.adoc[FTP]
-component supports some of the options, where as the
-File component supports all of them.
-
-
-[width="100%",cols="10%,10%,10%,10%,10%,25%,25%",options="header",]
-|===
-|Expression |Type |File Consumer |File Producer |FTP Consumer |FTP Producer |Description
-
-|file:name |String |yes |no |yes |no |refers to the file name (is relative to the starting directory, see note
-below)
-
-|file:name.ext |String |yes |no |yes |no |refers to the file extension only
-
-|file:name.ext.single |String |yes |no |yes |no |refers to the file extension. If the file
-extension has mutiple dots, then this expression strips and only returns
-the last part.
-
-|file:name.noext |String |yes |no |yes |no |refers to the file name with no extension (is relative to the starting
-directory, see note below)
-
-|file:name.noext.single |String |yes |no |yes |no |refers to the file name with no extension (is
-relative to the starting directory, see note below). If the file
-extension has multiple dots, then this expression strips only the last
-part, and keep the others.
-
-|file:onlyname |String |yes |no |yes |no |refers to the file name only with no leading paths.
-
-|file:onlyname.noext |String |yes |no |yes |no |refers to the file name only with no extension and with no leading
-paths.
-
-|file:onlyname.noext.single |String |yes |no |yes |no |refers to the file name only with no extension and
-with no leading paths. If the file extension has multiple dots, then
-this expression strips only the last part, and keep the others.
-
-|file:ext |String |yes |no |yes |no |refers to the file extension only
-
-|file:parent |String |yes |no |yes |no |refers to the file parent
-
-|file:path |String |yes |no |yes |no |refers to the file path
-
-|file:absolute |Boolean |yes |no |no |no |refers to whether the file is regarded as absolute or relative
-
-|file:absolute.path |String |yes |no |no |no |refers to the absolute file path
-
-|file:length |Long |yes |no |yes |no |refers to the file length returned as a Long type
-
-|file:size |Long |yes |no |yes |no |refers to the file length returned as a Long type
-
-|file:modified |Date |yes |no |yes |no |Refers to the file last modified returned as a Date type
-
-|date:_command:pattern_ |String |yes |yes |yes |yes |for date formatting using the `java.text.SimpleDateFormat` patterns. Is
-an *extension* to the xref:simple-language.adoc[Simple] language. Additional
-command is: *file* (consumers only) for the last modified timestamp of
-the file. Notice: all the commands from the xref:simple-language.adoc[Simple]
-language can also be used.
-|===
-
-== File token example
-
-=== Relative paths
-
-We have a `java.io.File` handle for the file `hello.txt` in the
-following *relative* directory: `.\filelanguage\test`. And we configure
-our endpoint to use this starting directory `.\filelanguage`. The file
-tokens will return as:
-
-[width="100%",cols="50%,50%",options="header",]
-|===
-|Expression |Returns
-
-|file:name |test\hello.txt
-
-|file:name.ext |txt
-
-|file:name.noext |test\hello
-
-|file:onlyname |hello.txt
-
-|file:onlyname.noext |hello
-
-|file:ext |txt
-
-|file:parent |filelanguage\test
-
-|file:path |filelanguage\test\hello.txt
-
-|file:absolute |false
-
-|file:absolute.path |\workspace\camel\camel-core\target\filelanguage\test\hello.txt
-|===
-
-=== Absolute paths
-
-We have a `java.io.File` handle for the file `hello.txt` in the
-following *absolute* directory:
-`\workspace\camel\camel-core\target\filelanguage\test`. And we configure
-out endpoint to use the absolute starting directory
-`\workspace\camel\camel-core\target\filelanguage`. The file tokens will
-return as:
-
-[width="100%",cols="50%,50%",options="header",]
-|===
-|Expression |Returns
-
-|file:name |test\hello.txt
-
-|file:name.ext |txt
-
-|file:name.noext |test\hello
-
-|file:onlyname |hello.txt
-
-|file:onlyname.noext |hello
-
-|file:ext |txt
-
-|file:parent |\workspace\camel\camel-core\target\filelanguage\test
-
-|file:path |\workspace\camel\camel-core\target\filelanguage\test\hello.txt
-
-|file:absolute |true
-
-|file:absolute.path |\workspace\camel\camel-core\target\filelanguage\test\hello.txt
-|===
-
-== Samples
-
-You can enter a fixed xref:constant-language.adoc[Constant] expression such as
-`myfile.txt`:
-
-[source]
-----
-fileName="myfile.txt"
-----
-
-Lets assume we use the file consumer to read files and want to move the
-read files to backup folder with the current date as a sub folder. This
-can be archieved using an expression like:
-
-[source]
-----
-fileName="backup/${date:now:yyyyMMdd}/${file:name.noext}.bak"
-----
-
-relative folder names are also supported so suppose the backup folder
-should be a sibling folder then you can append .. as:
-
-[source]
-----
-fileName="../backup/${date:now:yyyyMMdd}/${file:name.noext}.bak"
-----
-
-As this is an extension to the xref:simple-language.adoc[Simple] language we have
-access to all the goodies from this language also, so in this use case
-we want to use the in.header.type as a parameter in the dynamic
-expression:
-
-[source]
-----
-fileName="../backup/${date:now:yyyyMMdd}/type-${in.header.type}/backup-of-${file:name.noext}.bak"
-----
-
-If you have a custom Date you want to use in the expression then Camel
-supports retrieving dates from the message header.
-
-[source]
-----
-fileName="orders/order-${in.header.customerId}-${date:in.header.orderDate:yyyyMMdd}.xml"
-----
-
-And finally we can also use a bean expression to invoke a POJO class
-that generates some String output (or convertible to String) to be used:
-
-[source]
-----
-fileName="uniquefile-${bean:myguidgenerator.generateid}.txt"
-----
-
-And of course all this can be combined in one expression where you can
-use the xref:file-language.adoc[File Language], xref:file-language.adoc[Simple]
-and the xref:components::bean-component.adoc[Bean] language in one combined expression. This
-is pretty powerful for those common file path patterns.
-
-== Using Spring PropertyPlaceholderConfigurer together with the File component
-
-In Camel you can use the xref:file-language.adoc[File Language] directly
-from the xref:simple-language.adoc[Simple] language which makes a
-Content Based Router easier to do in
-Spring XML, where we can route based on file extensions as shown below:
-
-[source,xml]
-----
-<from uri="file://input/orders"/>
- <choice>
- <when>
- <simple>${file:ext} == 'txt'</simple>
- <to uri="bean:orderService?method=handleTextFiles"/>
- </when>
- <when>
- <simple>${file:ext} == 'xml'</simple>
- <to uri="bean:orderService?method=handleXmlFiles"/>
- </when>
- <otherwise>
- <to uri="bean:orderService?method=handleOtherFiles"/>
- </otherwise>
- </choice>
-----
-
-If you use the `fileName` option on the File endpoint
-to set a dynamic filename using the xref:file-language.adoc[File Language] then make sure you +
- use the alternative syntax to avoid
-clashing with Springs `PropertyPlaceholderConfigurer`.
-
-*bundle-context.xml*
-
-[source,xml]
-----
-<bean id="propertyPlaceholder" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
- <property name="location" value="classpath:bundle-context.cfg" />
-</bean>
-
-<bean id="sampleRoute" class="SampleRoute">
- <property name="fromEndpoint" value="${fromEndpoint}" />
- <property name="toEndpoint" value="${toEndpoint}" />
-</bean>
-----
-
-*bundle-context.cfg*
-
-[source]
-----
-fromEndpoint=activemq:queue:test
-toEndpoint=file://fileRoute/out?fileName=test-$simple{date:now:yyyyMMdd}.txt
-----
-
-Notice how we use the $simple\{ } syntax in the `toEndpoint` above. +
- If you don't do this, there is a clash and Spring will throw an
-exception like
-
-[source,java]
-----------------------------------------------------------------------------------------------------
-org.springframework.beans.factory.BeanDefinitionStoreException:
-Invalid bean definition with name 'sampleRoute' defined in class path resource [bundle-context.xml]:
-Could not resolve placeholder 'date:now:yyyyMMdd'
-----------------------------------------------------------------------------------------------------
-
-== Dependencies
-
-The File language is part of *camel-core*.
diff --git a/docs/user-manual/modules/ROOT/pages/filter-eip.adoc b/docs/user-manual/modules/ROOT/pages/filter-eip.adoc
deleted file mode 100644
index effb4a4..0000000
--- a/docs/user-manual/modules/ROOT/pages/filter-eip.adoc
+++ /dev/null
@@ -1,101 +0,0 @@
-[[filter-eip]]
-= Filter EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/filter-eip.adoc
-
-The http://www.enterpriseintegrationpatterns.com/Filter.html[Message
-Filter] from the xref:enterprise-integration-patterns.adoc[EIP patterns]
-allows you to filter messages
-
-image::eip/MessageFilter.gif[image]
-
-The following example shows how to create a Message Filter route
-consuming messages from an endpoint called *queue:a*, which if the
-xref:predicate.adoc[Predicate] is true will be dispatched to *queue:b*
-
-== EIP options
-
-// eip options: START
-The Filter EIP has no options.
-// eip options: END
-
-== Samples
-
-Here is a little example in Java DSL:
-
-[source,java]
-----
-from("direct:a")
- .filter(simple("${header.foo} == 'bar'"))
- .to("direct:b");
-----
-
-You can use many different languages as the predicate, such as XPath:
-[source,java]
-----
-from("direct:start").
- filter().xpath("/person[@name='James']").
- to("mock:result");
-----
-
-Here is another example of using a bean to define the filter behavior
-
-[source,java]
-----
-from("direct:start")
- .filter().method(MyBean.class, "isGoldCustomer")
- .to("mock:gold")
- .end()
- .to("mock:all");
-
-public static class MyBean {
- public boolean isGoldCustomer(@Header("level") String level) {
- return level.equals("gold");
- }
-}
-----
-
-And the example in XML:
-
-[source,xml]
-----
-<bean id="myBean" class="com.foo.MyBean"/>
-
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:a"/>
- <filter>
- <method ref="myBean" method="isGoldCustomer"/>
- <to uri="direct:b"/>
- </filter>
- </route>
-</camelContext>
-----
-
-
-== Using stop
-
-Stop is a bit different than a message filter as it will filter out all
-messages and end the route entirely (filter only applies to its child
-processor). Stop is convenient to use in a
-xref:content-based-router-eip.adoc[Content Based Router] when you for
-example need to stop further processing in one of the predicates.
-
-In the example below we do not want to route messages any further that
-has the word `Bye` in the message body. Notice how we prevent this in
-the when predicate by using the `.stop()`.
-
-== Knowing if Exchange was filtered or not
-
-The xref:filter-eip.adoc[Message Filter] EIP will add a property on
-the xref:exchange.adoc[Exchange] that states if it was filtered or not.
-
-The property has the key `Exchange.FILTER_MATCHED`, which has the String
-value of `CamelFilterMatched`. Its value is a boolean indicating `true`
-or `false`. If the value is `true` then the xref:exchange.adoc[Exchange]
-was routed in the filter block. This property will be visible within the
-xref:filter-eip.adoc[Message Filter] block who's
-xref:predicate.adoc[Predicate] matches (value set to `true`), and to the
-steps immediately following the xref:filter-eip.adoc[Message Filter]
-with the value set based on the results of the last
-xref:filter-eip.adoc[Message Filter] xref:predicate.adoc[Predicate]
-evaluated.
diff --git a/docs/user-manual/modules/ROOT/pages/from-eip.adoc b/docs/user-manual/modules/ROOT/pages/from-eip.adoc
deleted file mode 100644
index 255ed88..0000000
--- a/docs/user-manual/modules/ROOT/pages/from-eip.adoc
+++ /dev/null
@@ -1,38 +0,0 @@
-[[from-eip]]
-= From EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/from-eip.adoc
-Starting point for a Camel route that starts a route with a given endpoint. The endpoint can be from one of the many Camel https://github.com/apache/camel/tree/master/components[Components]. The component creates Camel exchanges from their respective sources and puts them into the route.
-
-== Options
-
-// eip options: START
-The From EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *uri* | *Required* Sets the URI of the endpoint to use | | String
-|===
-// eip options: END
-
-== Samples
-
-Start a route with the File endpoint. Each file in the directory creates an exchange that is put into the camel route.
-
-A camel route is started using from inside the configure method of the class *RouteBuilder*
-
-[source,java]
-----
-from("file:c:/in")
-----
-
-And examples in Spring XML Schema:
-
-The route is defined inside a CamelContext.
-
-[source,xml]
-----
-<route>
- <from uri="file:c:/in" />
-</route>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/header-language.adoc b/docs/user-manual/modules/ROOT/pages/header-language.adoc
deleted file mode 100644
index c2134f4..0000000
--- a/docs/user-manual/modules/ROOT/pages/header-language.adoc
+++ /dev/null
@@ -1,45 +0,0 @@
-[[header-language]]
-= Header Language
-:page-source: core/camel-core-languages/src/main/docs/header-language.adoc
-
-*Since Camel 1.5*
-
-The Header Expression Language allows you to extract values of named
-headers.
-
-== Header Options
-
-// language options: START
-The Header language supports 1 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
-
-== Example usage
-
-The recipientList element of the Spring DSL can utilize a header
-expression like:
-
-In this case, the list of recipients are contained in the header
-'myHeader'.
-
-And the same example in Java DSL:
-
-And with a slightly different syntax where you use the builder to the
-fullest (i.e. avoid using parameters but using stacked operations,
-notice that header is not a parameter but a stacked method call)
-
-[source,java]
-----
-from("direct:a").recipientList().header("myHeader");
-----
-
-== Dependencies
-
-The Header language is part of *camel-core*.
\ No newline at end of file
diff --git a/docs/user-manual/modules/ROOT/pages/hystrix-eip.adoc b/docs/user-manual/modules/ROOT/pages/hystrix-eip.adoc
deleted file mode 100644
index fa4e0b3..0000000
--- a/docs/user-manual/modules/ROOT/pages/hystrix-eip.adoc
+++ /dev/null
@@ -1,150 +0,0 @@
-[[hystrix-eip]]
-= Hystrix EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/hystrix-eip.adoc
-
-The Hystrix EIP provides integration with Netflix https://github.com/Netflix/Hystrix[Hystrix] to be used as circuit breaker in the Camel routes. Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.
-
-
-[NOTE]
-====
-Camel provides the Circuit Breaker EIP in the route model, which allows to plugin different implementations.
-Hystrix is one such implementation.
-====
-
-Maven users will need to add the following dependency to their pom.xml to use this EIP:
-
-[source,xml]
-----
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-hystrix</artifactId>
- <version>x.x.x</version><!-- use the same version as your Camel core version -->
-</dependency>
-----
-
-== Configuration options
-
-// eip options: START
-The Hystrix EIP supports 2 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *hystrixConfiguration* | Configures the Hystrix EIP Use end when configuration is complete, to return back to the Hystrix EIP. | | HystrixConfigurationDefinition
-| *hystrixConfigurationRef* | Refers to a Hystrix configuration to use for configuring the Hystrix EIP. | | String
-|===
-// eip options: END
-
-See xref:hystrixConfiguration-eip.adoc[Hystrix Configuration] for all the configuration options on Hystrix EIP.
-
-== Samples
-
-Below is an example route showing an Hystrix endpoint that protects against slow operation by falling back to the in-lined fallback route. By default the timeout request is just *1000ms* so the HTTP endpoint has to be fairly quick to succeed.
-[source,java]
-----
-from("direct:start")
- .circuitBreaker()
- .to("http://fooservice.com/slow")
- .onFallback()
- .transform().constant("Fallback message")
- .end()
- .to("mock:result");
-----
-
-And in XML DSL:
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <circuitBreaker>
- <to uri="http://fooservice.com/slow"/>
- <onFallback>
- <transform>
- <constant>Fallback message</constant>
- </transform>
- </onFallback>
- </circuitBreaker>
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-== Configuring Hystrix
-
-You can fine-tune Hystrix by the many xref:hystrixConfiguration-eip.adoc[Hystrix Configuration] options.
-For example to use a 2 second execution timeout, you can do as follows:
-
-[source,java]
-----
-from("direct:start")
- .circuitBreaker()
- // use 2 second timeout
- .hystrixConfiguration().executionTimeoutInMilliseconds(2000).end()
- .log("Hystrix processing start: ${threadName}")
- .toD("direct:${body}")
- .log("Hystrix processing end: ${threadName}")
- .end()
- .log("After Hystrix ${body}");
-----
-
-And in XML:
-
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <circuitBreaker>
- <hystrixConfiguration executionTimeoutInMilliseconds="2000"/>
- <log message="Hystrix processing start: ${threadName}"/>
- <toD uri="direct:${body}"/>
- <log message="Hystrix processing end: ${threadName}"/>
- </circuitBreaker>
- <log message="After Hystrix: ${body}"/>
-</route>
-----
-
-== Fallback
-
-See xref:onFallback-eip.adoc[onFallback].
-
-== Other examples
-
-You can find an example with the source code: https://github.com/apache/camel-spring-boot/tree/master/examples/camel-example-spring-boot-hystrix[camel-example-spring-boot-hystrix].
-
-== Using Hystrix with Spring Boot
-
-See the xref:components::hystrix.adoc[Hystrix Component].
-
-== Camel's Error Handler and Circuit Breaker EIP
-
-By default the Circuit Breaker EIP handles errors by itself. This means if the circuit breaker is open and
-the message fails, then Camel's error handler is not reacting also.
-However, you can enable Camels error handler with circuit breaker by enabling the `inheritErrorHandler` option, as shown:
-
-[source,java]
-----
-// Camel's error handler that will attempt to redeliver the message 3 times
-errorHandler(deadLetterChannel("mock:dead").maximumRedeliveries(3).redeliveryDelay(0));
-
-from("direct:start")
- .to("log:start")
- // turn on Camel's error handler on circuit breaker so Camel can do redeliveries
- .circuitBreaker().inheritErrorHandler(true)
- .to("mock:a")
- .throwException(new IllegalArgumentException("Forced"))
- .end()
- .to("log:result")
- .to("mock:result");
-----
-
-This example is from an unit test, where you can see the Circuit Breaker EIP block has been hardcoded
-to always fail by throwing an exception. Because the `inheritErrorHandler` has been enabled,
-then Camel's error handler will attempt to call the Circuit Breaker EIP block again.
-
-That means the `mock:a` endpoint will receive the message again, and a total of 1 + 3 = 4 message
-(first time + 3 redeliveries).
-
-If we turn off the `inheritErrorHandler` option (default) then the Circuit Breaker EIP will only be
-executed once because it handled the error itself.
-
diff --git a/docs/user-manual/modules/ROOT/pages/hystrixConfiguration-eip.adoc b/docs/user-manual/modules/ROOT/pages/hystrixConfiguration-eip.adoc
deleted file mode 100644
index 1e294e8..0000000
--- a/docs/user-manual/modules/ROOT/pages/hystrixConfiguration-eip.adoc
+++ /dev/null
@@ -1,44 +0,0 @@
-[[hystrixConfiguration-eip]]
-= Hystrix Configuration EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/hystrixConfiguration-eip.adoc
-
-
-// eip options: START
-The Hystrix Configuration EIP supports 31 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *groupKey* | Sets the group key to use. The default value is CamelHystrix. | CamelHystrix | String
-| *threadPoolKey* | Sets the thread pool key to use. Will by default use the same value as groupKey has been configured to use. | CamelHystrix | String
-| *circuitBreakerEnabled* | Whether to use a HystrixCircuitBreaker or not. If false no circuit-breaker logic will be used and all requests permitted. This is similar in effect to circuitBreakerForceClosed() except that continues tracking metrics and knowing whether it should be open/closed, this property results in not even instantiating a circuit-breaker. | true | Boolean
-| *circuitBreakerError ThresholdPercentage* | Error percentage threshold (as whole number such as 50) at which point the circuit breaker will trip open and reject requests. It will stay tripped for the duration defined in circuitBreakerSleepWindowInMilliseconds; The error percentage this is compared against comes from HystrixCommandMetrics.getHealthCounts(). | 50 | Integer
-| *circuitBreakerForceClosed* | If true the HystrixCircuitBreaker#allowRequest() will always return true to allow requests regardless of the error percentage from HystrixCommandMetrics.getHealthCounts(). The circuitBreakerForceOpen() property takes precedence so if it set to true this property does nothing. | false | Boolean
-| *circuitBreakerForceOpen* | If true the HystrixCircuitBreaker.allowRequest() will always return false, causing the circuit to be open (tripped) and reject all requests. This property takes precedence over circuitBreakerForceClosed(); | false | Boolean
-| *circuitBreakerRequestVolume Threshold* | Minimum number of requests in the metricsRollingStatisticalWindowInMilliseconds() that must exist before the HystrixCircuitBreaker will trip. If below this number the circuit will not trip regardless of error percentage. | 20 | Integer
-| *circuitBreakerSleepWindow InMilliseconds* | The time in milliseconds after a HystrixCircuitBreaker trips open that it should wait before trying requests again. | 5000 | Integer
-| *executionIsolationSemaphore MaxConcurrentRequests* | Number of concurrent requests permitted to HystrixCommand.run(). Requests beyond the concurrent limit will be rejected. Applicable only when executionIsolationStrategy == SEMAPHORE. | 20 | Integer
-| *executionIsolationStrategy* | What isolation strategy HystrixCommand.run() will be executed with. If THREAD then it will be executed on a separate thread and concurrent requests limited by the number of threads in the thread-pool. If SEMAPHORE then it will be executed on the calling thread and concurrent requests limited by the semaphore count. | THREAD | String
-| *executionIsolationThread InterruptOnTimeout* | Whether the execution thread should attempt an interrupt (using Future#cancel) when a thread times out. Applicable only when executionIsolationStrategy() == THREAD. | true | Boolean
-| *executionTimeoutIn Milliseconds* | Time in milliseconds at which point the command will timeout and halt execution. If executionIsolationThreadInterruptOnTimeout == true and the command is thread-isolated, the executing thread will be interrupted. If the command is semaphore-isolated and a HystrixObservableCommand, that command will get unsubscribed. | 1000 | Integer
-| *executionTimeoutEnabled* | Whether the timeout mechanism is enabled for this command | true | Boolean
-| *fallbackIsolationSemaphore MaxConcurrentRequests* | Number of concurrent requests permitted to HystrixCommand.getFallback(). Requests beyond the concurrent limit will fail-fast and not attempt retrieving a fallback. | 10 | Integer
-| *fallbackEnabled* | Whether HystrixCommand.getFallback() should be attempted when failure occurs. | true | Boolean
-| *metricsHealthSnapshot IntervalInMilliseconds* | Time in milliseconds to wait between allowing health snapshots to be taken that calculate success and error percentages and affect HystrixCircuitBreaker.isOpen() status. On high-volume circuits the continual calculation of error percentage can become CPU intensive thus this controls how often it is calculated. | 500 | Integer
-| *metricsRollingPercentile BucketSize* | Maximum number of values stored in each bucket of the rolling percentile. This is passed into HystrixRollingPercentile inside HystrixCommandMetrics. | 10 | Integer
-| *metricsRollingPercentile Enabled* | Whether percentile metrics should be captured using HystrixRollingPercentile inside HystrixCommandMetrics. | true | Boolean
-| *metricsRollingPercentile WindowInMilliseconds* | Duration of percentile rolling window in milliseconds. This is passed into HystrixRollingPercentile inside HystrixCommandMetrics. | 10000 | Integer
-| *metricsRollingPercentile WindowBuckets* | Number of buckets the rolling percentile window is broken into. This is passed into HystrixRollingPercentile inside HystrixCommandMetrics. | 6 | Integer
-| *metricsRollingStatistical WindowInMilliseconds* | This property sets the duration of the statistical rolling window, in milliseconds. This is how long metrics are kept for the thread pool. The window is divided into buckets and rolls by those increments. | 10000 | Integer
-| *metricsRollingStatistical WindowBuckets* | Number of buckets the rolling statistical window is broken into. This is passed into HystrixRollingNumber inside HystrixCommandMetrics. | 10 | Integer
-| *requestLogEnabled* | Whether HystrixCommand execution and events should be logged to HystrixRequestLog. | true | Boolean
-| *corePoolSize* | Core thread-pool size that gets passed to java.util.concurrent.ThreadPoolExecutor#setCorePoolSize(int) | 10 | Integer
-| *maximumSize* | Maximum thread-pool size that gets passed to ThreadPoolExecutor#setMaximumPoolSize(int). This is the maximum amount of concurrency that can be supported without starting to reject HystrixCommands. Please note that this setting only takes effect if you also set allowMaximumSizeToDivergeFromCoreSize | 10 | Integer
-| *keepAliveTime* | Keep-alive time in minutes that gets passed to {link ThreadPoolExecutor#setKeepAliveTime(long, TimeUnit)} | 1 | Integer
-| *maxQueueSize* | Max queue size that gets passed to BlockingQueue in HystrixConcurrencyStrategy.getBlockingQueue(int) This should only affect the instantiation of a threadpool - it is not eliglible to change a queue size on the fly. For that, use queueSizeRejectionThreshold(). | -1 | Integer
-| *queueSizeRejectionThreshold* | Queue size rejection threshold is an artificial max size at which rejections will occur even if maxQueueSize has not been reached. This is done because the maxQueueSize of a BlockingQueue can not be dynamically changed and we want to support dynamically changing the queue size that affects rejections. This is used by HystrixCommand when queuing a thread for execution. | 5 | Integer
-| *threadPoolRollingNumber StatisticalWindowIn Milliseconds* | Duration of statistical rolling window in milliseconds. This is passed into HystrixRollingNumber inside each HystrixThreadPoolMetrics instance. | 10000 | Integer
-| *threadPoolRollingNumber StatisticalWindowBuckets* | Number of buckets the rolling statistical window is broken into. This is passed into HystrixRollingNumber inside each HystrixThreadPoolMetrics instance. | 10 | Integer
-| *allowMaximumSizeToDiverge FromCoreSize* | Allows the configuration for maximumSize to take effect. That value can then be equal to, or higher, than coreSize | false | Boolean
-|===
-// eip options: END
diff --git a/docs/user-manual/modules/ROOT/pages/idempotentConsumer-eip.adoc b/docs/user-manual/modules/ROOT/pages/idempotentConsumer-eip.adoc
deleted file mode 100644
index cc379e1..0000000
--- a/docs/user-manual/modules/ROOT/pages/idempotentConsumer-eip.adoc
+++ /dev/null
@@ -1,45 +0,0 @@
-[[idempotentConsumer-eip]]
-= Idempotent Consumer EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/idempotentConsumer-eip.adoc
-
-The
-http://www.enterpriseintegrationpatterns.com/IdempotentReceiver.html[Idempotent
-Consumer] from the xref:enterprise-integration-patterns.adoc[EIP
-patterns] is used to filter out duplicate messages.
-
-The Idempotent Consumer essentially acts like a
-xref:filter-eip.adoc[Message Filter] to filter out duplicates.
-
-Camel will add the message id eagerly to the repository to detect
-duplication also for Exchanges currently in progress.
- On completion Camel will remove the message id from the repository if
-the Exchange failed, otherwise it stays there.
-
-Camel provides the following Idempotent Consumer implementations:
-
-* MemoryIdempotentRepository
-* xref:components::file-component.adoc[FileIdempotentRepository]
-* xref:components::hazelcast.adoc[HazelcastIdempotentRepository]
-* xref:components::sql-component.adoc[JdbcMessageIdRepository]
-* xref:components::jpa-component.adoc[JpaMessageIdRepository]
-* xref:components::infinispan-component.adoc[InfinispanIdempotentRepository]
-* xref:components::jcache-component.adoc[JCacheIdempotentRepository]
-* xref:spring.adoc[SpringCacheIdempotentRepository]
-* xref:components::ehcache-component.adoc[EhcacheIdempotentRepository]
-* xref:components::kafka-component.adoc[KafkaIdempotentRepository]
-
-== Options
-
-// eip options: START
-The Idempotent Consumer EIP supports 5 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *messageIdRepositoryRef* | *Required* Sets the reference name of the message id repository | | String
-| *eager* | Sets whether to eagerly add the key to the idempotent repository or wait until the exchange is complete. Eager is default enabled. | true | Boolean
-| *completionEager* | Sets whether to complete the idempotent consumer eager or when the exchange is done. If this option is true to complete eager, then the idempotent consumer will trigger its completion when the exchange reached the end of the block of the idempotent consumer pattern. So if the exchange is continued routed after the block ends, then whatever happens there does not affect the state. If this option is false (default) to not complete eager, then the idempotent consumer w [...]
-| *skipDuplicate* | Sets whether to skip duplicates or not. The default behavior is to skip duplicates. A duplicate message would have the Exchange property org.apache.camel.Exchange#DUPLICATE_MESSAGE set to a Boolean#TRUE value. A none duplicate message will not have this property set. | true | Boolean
-| *removeOnFailure* | Sets whether to remove or keep the key on failure. The default behavior is to remove the key on failure. | true | Boolean
-|===
-// eip options: END
diff --git a/docs/user-manual/modules/ROOT/pages/inOnly-eip.adoc b/docs/user-manual/modules/ROOT/pages/inOnly-eip.adoc
deleted file mode 100644
index b359088..0000000
--- a/docs/user-manual/modules/ROOT/pages/inOnly-eip.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-[[inOnly-eip]]
-= In Only EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/inOnly-eip.adoc
-
-The *inOnly:* EIP define an InOnly ExchangePattern.
-
-== EIP options
-
-// eip options: START
-The In Only EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *uri* | *Required* Sets the uri of the endpoint to send to. | | String
-|===
-// eip options: END
diff --git a/docs/user-manual/modules/ROOT/pages/inOut-eip.adoc b/docs/user-manual/modules/ROOT/pages/inOut-eip.adoc
deleted file mode 100644
index ff1b4ec..0000000
--- a/docs/user-manual/modules/ROOT/pages/inOut-eip.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-[[inOut-eip]]
-= In Out EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/inOut-eip.adoc
-
-The *inOut:* EIP define an InOut ExchangePattern.
-
-== EIP options
-
-// eip options: START
-The In Out EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *uri* | *Required* Sets the uri of the endpoint to send to. | | String
-|===
-// eip options: END
diff --git a/docs/user-manual/modules/ROOT/pages/loadBalance-eip.adoc b/docs/user-manual/modules/ROOT/pages/loadBalance-eip.adoc
deleted file mode 100644
index 512291e..0000000
--- a/docs/user-manual/modules/ROOT/pages/loadBalance-eip.adoc
+++ /dev/null
@@ -1,251 +0,0 @@
-[[loadBalance-eip]]
-= Load Balance EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/loadBalance-eip.adoc
-
-The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.
-
-== Built-in load balancing policies
-
-Camel provides the following policies out-of-the-box:
-
-[width="100%",cols="3,6",options="header"]
-|=======================================================================
-| Policy | Description
-| Round Robin | The exchanges are selected from in a round robin fashion. This is a well known and classic policy, which spreads the load evenly.
-| Random | A random endpoint is selected for each exchange.
-| Sticky | Sticky load balancing using an Expression to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS.
-| Topic | Topic which sends to all destinations (rather like JMS Topics)
-| Failover | In case of failures the exchange will be tried on the next endpoint.
-| Weighted Round-Robin |The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to the others. In addition to the weight, endpoint selection is then further refined using *round-robin* distribution based on weight.
-| Weighted Random |The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using *random* distribution based on weight.
-| Custom |The preferred way of using a custom Load Balancer is to use this policy, as the ref attribute is not supported anymore.
-|=======================================================================
-
-== Options
-
-// eip options: START
-The Load Balance EIP supports 2 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *loadBalancerType* | *Required* The load balancer to be used | | LoadBalancerDefinition
-| *inheritErrorHandler* | Sets whether or not to inherit the configured error handler. The default value is true. You can use this to disable using the inherited error handler for a given DSL such as a load balancer where you want to use a custom error handler strategy. | false | Boolean
-|===
-// eip options: END
-
-
-== Round Robin
-
-The round robin load balancer is not meant to work with failover, for that you should use the dedicated *failover* load balancer. The round robin load balancer will only change to next endpoint per message.
-The round robin load balancer is stateful as it keeps state of which endpoint to use next time.
-
-Here is a little example:
-
-[source,java]
-----
-from("direct:start")
- .loadBalance().roundRobin()
- .to("mock:x")
- .to("mock:y")
- .to("mock:z")
- .end() // end load balancer
-----
-
-And in XML:
-[source,xml]
-----
-<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <loadBalance>
- <roundRobin/>
- <to uri="mock:x"/>
- <to uri="mock:y"/>
- <to uri="mock:z"/>
- </loadBalance>
- </route>
-</camelContext>
-----
-
-The above example loads balance requests from *direct:start* to one of the available *mock endpoint* instances, in this case using a round robin policy.
-
-== Failover
-
-The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
-You can constrain the failover to activate only when one exception of a list you specify occurs. If you do not specify a list any exception will cause fail over to occur. This balancer uses the same strategy for matching exceptions as the Exception Clause does for the `onException`.
-
-[TIP]
-====
-**Enable stream caching if using streams:**
-
-If you use streaming then you should enable Stream caching when using the failover load balancer. This is needed so the stream can be re-read after failing over to the next processor.
-====
-
-Here is a sample to failover only if a IOException related exception was thrown:
-[source,java]
-----
-from("direct:start")
- // here we will load balance if IOException was thrown
- // any other kind of exception will result in the Exchange as failed
- // to failover over any kind of exception we can just omit the exception
- // in the failOver DSL
- .loadBalance().failover(IOException.class)
- .to("mock:x")
- .to("mock:y")
- .to("mock:z");
-----
-You can specify multiple exceptions to failover as the option is varargs, for instance:
-
-[source,java]
-----
-// enable maximum redelivery so failover can react
-errorHandler(defaultErrorHandler().maximumRedeliveries(5));
-
-from("direct:foo").
- loadBalance().failover(IOException.class, MyOtherException.class)
- .to("direct:a")
- .to("direct:b");
-----
-
-And in XML:
-
-Failover can also be used from Spring DSL and you configure it as:
-[source,xml]
-----
-<route errorHandlerRef="myErrorHandler">
- <from uri="direct:foo"/>
- <loadBalance>
- <failover>
- <exception>java.io.IOException</exception>
- <exception>com.mycompany.MyOtherException</exception>
- </failover>
- <to uri="direct:a"/>
- <to uri="direct:b"/>
- </loadBalance>
- </route>
-----
-
-== Using failover in round robin mode
-
-An example using Java DSL:
-[source,java]
-----
-from("direct:start")
- // Use failover load balancer in stateful round robin mode
- // which mean it will failover immediately in case of an exception
- // as it does NOT inherit error handler. It will also keep retrying as
- // its configured to newer exhaust.
- .loadBalance().failover(-1, false, true)
- .to("direct:bad")
- .to("direct:bad2")
- .to("direct:good")
- .to("direct:good2");
-----
-
-And the same example using Spring XML:
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <loadBalance>
- <!-- failover using stateful round robin,
- which will keep retrying forever those 4 endpoints until success.
- You can set the maximumFailoverAttempt to break out after X attempts -->
- <failover roundRobin="true"/>
- <to uri="direct:bad"/>
- <to uri="direct:bad2"/>
- <to uri="direct:good"/>
- <to uri="direct:good2"/>
- </loadBalance>
-</route>
-----
-
-[TIP]
-====
-*Disabled inheritErrorHandler*
-
-You can configure `inheritErrorHandler=false` if you want to failover to the next endpoint as fast as possible.
-By disabling the Error Handler you ensure it does not _intervene_ which allows the `failover` load balancer to handle failover asap.
-By also enabling `roundRobin` mode, then it will keep retrying until it success. You can then configure the `maximumFailoverAttempts` option to a high value to let it eventually exhaust (give up) and fail.
-====
-
-== Weighted Round-Robin and Random Load Balancing
-
-In many enterprise environments where server nodes of unequal processing power & performance characteristics are utilized to host services and processing endpoints, it is frequently necessary to distribute processing load based on their individual server capabilities so that some endpoints are not unfairly burdened with requests. Obviously simple round-robin or random load balancing do not alleviate problems of this nature. A Weighted Round-Robin and/or Weighted Random load balancer can [...]
-The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others. You can specify this as a positive processing weight for each server. A larger number indicates that the server can handle a larger load. The weight is utilized to determine the payload distribution ratio to different processing endpoints with respect to others.
-
-The parameters that can be used are
-
-[width="100%",cols="3,1,2,6",options="header"]
-|=======================================================================
-| Option | Type | Default | Description
-| roundRobin | boolean | false | The default value for round-robin is false. In the absence of this setting or parameter the load balancing algorithm used is random.
-| distributionRatio | String | none | The distributionRatio is a delimited String consisting on integer weights separated by delimiters for example "2,3,5". The distributionRatio must match the number of endpoints and/or processors specified in the load balancer list.
-| distributionRatioDelimiter | String | , | The distributionRatioDelimiter is the delimiter used to specify the distributionRatio. If this attribute is not specified a default delimiter "," is expected as the delimiter used for specifying the distributionRatio.
-|=======================================================================
-
-== Using Weighted round-robin & random load balancing
-
-An example using Java DSL:
-[source,java]
-----
-List<integer> distributionRatio = new ArrayList<integer>();
-distributionRatio.add(4);
-distributionRatio.add(2);
-distributionRatio.add(1);
-
-// round-robin
-from("direct:start")
- .loadBalance().weighted(true, distributionRatio)
- .to("mock:x", "mock:y", "mock:z");
-
-//random
-from("direct:start")
- .loadBalance().weighted(false, distributionRatio)
- .to("mock:x", "mock:y", "mock:z");
-----
-
-And the same example using Spring XML:
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <loadBalance>
- <weighted roundRobin="false"
- distributionRatio="4 2 1"/>
- <to uri="mock:x"/>
- <to uri="mock:y"/>
- <to uri="mock:z"/>
- </loadBalance>
-</route>
-----
-
-An example using Java DSL:
-[source,java]
-----
-// round-robin
-from("direct:start")
- .loadBalance().weighted(true, "4:2:1" distributionRatioDelimiter=":")
- .to("mock:x", "mock:y", "mock:z");
-
-//random
-from("direct:start")
- .loadBalance().weighted(false, "4,2,1")
- .to("mock:x", "mock:y", "mock:z");
-----
-
-And the same example using Spring XML:
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <loadBalance>
- <weighted roundRobin="false"
- distributionRatio="4-2-1" distributionRatioDelimiter="-" />
- <to uri="mock:x"/>
- <to uri="mock:y"/>
- <to uri="mock:z"/>
- </loadBalance>
-</route>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/log-eip.adoc b/docs/user-manual/modules/ROOT/pages/log-eip.adoc
deleted file mode 100644
index 18ecb14..0000000
--- a/docs/user-manual/modules/ROOT/pages/log-eip.adoc
+++ /dev/null
@@ -1,204 +0,0 @@
-[[log-eip]]
-= Log EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/log-eip.adoc
-
-How can I log the processing of a xref:message.adoc[Message]?
-
-Camel provides many ways to log the fact that you are processing a message. Here are just a few examples:
-* You can use the xref:components::log-component.adoc[Log] component which logs the Message content.
-* You can use the xref:tracer.adoc[Tracer] which trace logs message flow.
-* You can also use a xref:processor.adoc[Processor] or xref:bean-binding.adoc[Bean] and log from Java code.
-* You can use the log DSL.
-
-== Options
-
-// eip options: START
-The Log EIP supports 5 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *message* | *Required* Sets the log message (uses simple language) | | String
-| *loggingLevel* | Sets the logging level. The default value is INFO | INFO | LoggingLevel
-| *logName* | Sets the name of the logger | | String
-| *marker* | To use slf4j marker | | String
-| *loggerRef* | To refer to a custom logger instance to lookup from the registry. | | String
-|===
-// eip options: END
-
-
-=== Difference between log in the DSL and Log component
-The log DSL is much lighter and meant for logging human logs such as Starting to do ... etc. It can only log a message based on the Simple language. On the other hand Log component is a full fledged component which involves using endpoints and etc. The Log component is meant for logging the Message itself and you have many URI options to control what you would like to be logged.
-
-== Samples
-
-You can use the log DSL which allows you to use xref:simple-language.adoc[Simple] language to construct a dynamic message which gets logged.
-
-For example you can do
-
-[source,java]
-----
-from("direct:start")
- .log("Processing ${id}")
- .to("bean:foo");
-----
-
-Which will construct a String message at runtime using the Simple language. The log message will by logged at INFO level using the route id as the log name. By default a route is named route-1, route-2 etc. But you can use the routeId("myCoolRoute") to set a route name of choice.
-
-[TIP]
-====
-*Logging message body with streamed messages:*
-
-If the message body is stream based, then logging the message body, may cause the message body to be empty afterwards. See this FAQ. For streamed messages you can use Stream caching to allow logging the message body and be able to read the message body afterwards again.
-====
-
-The log DSL have overloaded methods to set the logging level and/or name as well.
-[source,java]
-----
-from("direct:start")
- .log(LoggingLevel.DEBUG, "Processing ${id}")
- .to("bean:foo");
-----
-
-and to set a logger name
-[source,java]
-----
-from("direct:start")
- .log(LoggingLevel.DEBUG, "com.mycompany.MyCoolRoute", "Processing ${id}")
- .to("bean:foo");
-----
-
-The logger instance may be used as well:
-[source,java]
-----
-from("direct:start")
- .log(LoggingLeven.DEBUG, org.slf4j.LoggerFactory.getLogger("com.mycompany.mylogger"), "Processing ${id}")
- .to("bean:foo");
-----
-
-For example you can use this to log the file name being processed if you consume files.
-[source,java]
-----
-from("file://target/files")
- .log(LoggingLevel.DEBUG, "Processing file ${file:name}")
- .to("bean:foo");
-----
-
-In Spring DSL it is also easy to use log DSL as shown below:
-[source,xml]
-----
-<route id="foo">
- <from uri="direct:foo"/>
- <log message="Got ${body}"/>
- <to uri="mock:foo"/>
-</route>
-----
-
-The log tag has attributes to set the message, loggingLevel and logName. For example:
-[source,xml]
-----
-<route id="baz">
- <from uri="direct:baz"/>
- <log message="Me Got ${body}" loggingLevel="FATAL" logName="com.mycompany.MyCoolRoute"/>
- <to uri="mock:baz"/>
-</route>
-----
-
-Since Camel *2.12.4/2.13.1* it is possible to reference logger instance. For example:
-[source,xml]
-----
-<bean id="myLogger" class="org.slf4j.LoggerFactory" factory-method="getLogger" xmlns="http://www.springframework.org/schema/beans">
- <constructor-arg value="com.mycompany.mylogger" />
-</bean>
-
-<route id="moo" xmlns="http://camel.apache.org/schema/spring">
- <from uri="direct:moo"/>
- <log message="Me Got ${body}" loggingLevel="INFO" loggerRef="myLogger"/>
- <to uri="mock:baz"/>
-</route>
-----
-
-=== Using Logger instance from the Registry
-
-If no logger name or logger instance is passed to log DSL,
- there is a Registry lookup performed to find single instance of org.slf4j.Logger.
- If such an instance is found, it is used instead of creating a new logger instance.
- If more instances are found, the behavior defaults to creating a new instance of logger.
-
-== Configuring log name globally
-
-By default the log name is the route id. If you want to use a different log name, you would need to configure the logName option. However if you have many logs and you want all of them to use the same log name, then you would need to set that logName option on all of them.
-
-You can configure a global log name that is used instead of the route id, eg
-[source,java]
-----
-camelContext.getGlobalOptions().put(Exchange.LOG_EIP_NAME, "com.foo.myapp");
-----
-
-And in XML
-[source,xml]
-----
-<camelContext ...>
- <properties>
- <property key="CamelLogEipName" value="com.foo.myapp"/>
- </properties>
-</camelContext>
-----
-
-== Using slf4j Marker
-
-You can specify a marker name in the DSL
-[source,xml]
-----
-<route id="baz">
- <from uri="direct:baz"/>
- <log loggingLevel="FATAL" logName="com.mycompany.MyCoolRoute" marker="myMarker"
- message="Me Got ${body}"/>
- <to uri="mock:baz"/>
-</route>
-----
-
-== Using log DSL in OSGi
-
-When using log DSL inside OSGi (e.g., in Karaf), the underlying logging mechanisms are provided by PAX logging. It searches for a bundle which invokes org.slf4j.LoggerFactory.getLogger() method and associates the bundle with the logger instance. Passing only logger name to log DSL results in associating camel-core bundle with the logger instance created.
-
-In some scenarios it is required that the bundle associated with logger should be the bundle which contains route definition. This is possible using provided logger instance both for Java DSL and Spring DSL (see the examples above).
-
-== Masking sensitive information like password
-
-You can enable security masking for logging by setting `logMask` flag to `true`.
-Note that this option also affects xref:components::log-component.adoc[Log] component.
-
-To enable mask in Java DSL at CamelContext level:
-[source,java]
-----
-camelContext.setLogMask(true);
-----
-
-And in XML:
-[source,java]
-----
-<camelContext logMask="true">
-...
-</camelContext>
-----
-
-You can also turn it on|off at route level. To enable mask in Java DSL at route level:
-[source,java]
-----
-from("direct:start").logMask()
- .log("Processing ${id}")
- .to("bean:foo");
-----
-
-And in XML:
-[source,java]
-----
-<route logMask="true">
-...
-</route>
-----
-
-`org.apache.camel.support.processor.DefaultMaskingFormatter` is used for the masking by default.
-If you want to use a custom masking formatter, put it into registry with the name `CamelCustomLogMask`.
-Note that the masking formatter must implement `org.apache.camel.spi.MaskingFormatter`.
diff --git a/docs/user-manual/modules/ROOT/pages/loop-eip.adoc b/docs/user-manual/modules/ROOT/pages/loop-eip.adoc
deleted file mode 100644
index b283763..0000000
--- a/docs/user-manual/modules/ROOT/pages/loop-eip.adoc
+++ /dev/null
@@ -1,171 +0,0 @@
-[[loop-eip]]
-= Loop EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/loop-eip.adoc
-
-The Loop allows for processing a message a number of times, possibly in a different way for each iteration. Useful mostly during testing.
-
-[NOTE]
-.Default mode
-===
-Notice by default the loop uses the same exchange throughout the looping. So the result from the previous iteration will be used for the next (eg Pipes and Filters). You can enable copy mode instead. See the options table for more details.
-===
-
-== Options
-
-// eip options: START
-The Loop EIP supports 2 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *copy* | If the copy attribute is true, a copy of the input Exchange is used for each iteration. That means each iteration will start from a copy of the same message. By default loop will loop the same exchange all over, so each iteration may have different message content. | false | Boolean
-| *doWhile* | Enables the while loop that loops until the predicate evaluates to false or null. | false | Boolean
-|===
-// eip options: END
-
-
-== Exchange properties
-
-For each iteration two properties are set on the Exchange. Processors can rely on these properties to process the Message in different ways.
-
-[width="100%",cols="3,6",options="header"]
-|===
-| Property | Description
-| CamelLoopSize | Total number of loops. This is not available if running the loop in while loop mode.
-| CamelLoopIndex | Index of the current iteration (0 based)
-|===
-
-== Samples
-The following example shows how to take a request from the *direct:x* endpoint, then send the message repetitively to *mock:result*. The number of times the message is sent is either passed as an argument to `loop()`, or determined at runtime by evaluating an expression. The expression *must* evaluate to an int, otherwise a `RuntimeCamelException` is thrown.
-
-Pass loop count as an argument
-[source,java]
-----
-from("direct:a")
- .loop(8)
- .to("mock:result");
-----
-
-Use expression to determine loop count
-[source,java]
-----
-from("direct:b")
- .loop(header("loop"))
- .to("mock:result");
-----
-
-Use expression to determine loop count
-[source,java]
-----
-from("direct:c")
- .loop(xpath("/hello/@times"))
- .to("mock:result");
-----
-
-And examples in XML:
-
-Pass loop count as an argument
-[source,xml]
-----
-<route>
- <from uri="direct:a"/>
- <loop>
- <constant>8</constant>
- <to uri="mock:result"/>
- </loop>
-</route>
-----
-
-Use expression to determine loop count
-[source,xml]
-----
-<route>
- <from uri="direct:b"/>
- <loop>
- <header>loop</header>
- <to uri="mock:result"/>
- </loop>
-</route>
-----
-
-== Using copy mode
-
-Now suppose we send a message to "direct:start" endpoint containing the letter A. +
-The output of processing this route will be that, each "mock:loop" endpoint will receive "AB" as message.
-
-[source,java]
-----
-from("direct:start")
- // instruct loop to use copy mode, which mean it will use a copy of the input exchange
- // for each loop iteration, instead of keep using the same exchange all over
- .loop(3).copy()
- .transform(body().append("B"))
- .to("mock:loop")
- .end() // end loop
- .to("mock:result");
-----
-
-However if we do *not* enable copy mode then "mock:loop" will receive "AB", "ABB", "ABBB", etc. messages.
-
-[source,java]
-----
-from("direct:start")
- // by default loop will keep using the same exchange so on the 2nd and 3rd iteration its
- // the same exchange that was previous used that are being looped all over
- .loop(3)
- .transform(body().append("B"))
- .to("mock:loop")
- .end() // end loop
- .to("mock:result");
-----
-
-The equivalent example in XML DSL in copy mode is as follows:
-
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <!-- enable copy mode for loop eip -->
- <loop copy="true">
- <constant>3</constant>
- <transform>
- <simple>${body}B</simple>
- </transform>
- <to uri="mock:loop"/>
- </loop>
- <to uri="mock:result"/>
-</route>
-----
-
-== Using while mode
-
-The loop can act like a while loop that loops until the expression evaluates to false or null. +
-For example the route below loops while the length of the message body is 5 or less characters. Notice that the DSL uses *loopDoWhile*.
-
-[source,java]
-----
-from("direct:start")
- .loopDoWhile(simple("${body.length} <= 5"))
- .to("mock:loop")
- .transform(body().append("A"))
- .end() // end loop
- .to("mock:result");
-----
-
-And the same example in XML:
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <loop doWhile="true">
- <simple>${body.length} <= 5</simple>
- <to uri="mock:loop"/>
- <transform>
- <simple>A${body}</simple>
- </transform>
- </loop>
- <to uri="mock:result"/>
-</route>
-----
-
-Notice in XML that the while loop is turned on using the *doWhile* attribute.
diff --git a/docs/user-manual/modules/ROOT/pages/marshal-eip.adoc b/docs/user-manual/modules/ROOT/pages/marshal-eip.adoc
deleted file mode 100644
index 4dd8a18..0000000
--- a/docs/user-manual/modules/ROOT/pages/marshal-eip.adoc
+++ /dev/null
@@ -1,45 +0,0 @@
-[[marshal-eip]]
-= Marshal EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/marshal-eip.adoc
-
-Marshalling is the opposite of unmarshalling, where a bean is marshalled into some binary or textual format for transmission over some transport via a Camel xref:components::index.adoc[Components]. Marshalling is used in the same way as unmarshalling above; in the xref:dsl.adoc[DSL] you can use a DataFormat instance, you can configure the DataFormat dynamically using the DSL or you can refer to a named instance of the format in the xref:registry.adoc[Registry].
-
-== Options
-
-// eip options: START
-The Marshal EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *dataFormatType* | *Required* The data format to be used | | DataFormatDefinition
-|===
-// eip options: END
-
-== Samples
-
-The following example unmarshals via serialization then marshals using a named JAXB data format to perform a kind of xref:message-translator.adoc[Message Translator].
-
-[source,java]
-----
-from("file://foo/bar").
- unmarshal().serialization().
- marshal("jaxb").
- to("activemq:Some.Queue");
-----
-
-[[DataFormat-UsingSpringXML]]
-=== Using Spring XML
-
-This example shows how to configure the data type just once and reuse it
-on multiple routes
-
-You can also define reusable data formats as Spring beans
-
-[source,xml]
---------------------------------------------------------
-<bean id="myJaxb" class="org.apache.camel.model.dataformat.JaxbDataFormat">
- <property name="prettyPrint" value="true"/>
- <property name="contextPath" value="org.apache.camel.example"/>
-</bean>
---------------------------------------------------------
diff --git a/docs/user-manual/modules/ROOT/pages/multicast-eip.adoc b/docs/user-manual/modules/ROOT/pages/multicast-eip.adoc
deleted file mode 100644
index 7090974..0000000
--- a/docs/user-manual/modules/ROOT/pages/multicast-eip.adoc
+++ /dev/null
@@ -1,145 +0,0 @@
-[[multicast-eip]]
-= Multicast EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/multicast-eip.adoc
-
-The Multicast EIP allows to route the same message to a number of endpoints
-and process them in a different way. The main difference between the
-Multicast and Splitter is that Splitter will split the message into
-several pieces but the Multicast will not modify the request message.
-
-== Options
-
-// eip options: START
-The Multicast EIP supports 12 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *parallelProcessing* | If enabled then sending messages to the multicasts occurs concurrently. Note the caller thread will still wait until all messages has been fully processed, before it continues. Its only the sending and processing the replies from the multicasts which happens concurrently. | false | Boolean
-| *strategyRef* | Refers to an AggregationStrategy to be used to assemble the replies from the multicasts, into a single outgoing message from the Multicast. By default Camel will use the last reply as the outgoing message. You can also use a POJO as the AggregationStrategy | | String
-| *strategyMethodName* | This option can be used to explicit declare the method name to use, when using POJOs as the AggregationStrategy. | | String
-| *strategyMethodAllowNull* | If this option is false then the aggregate method is not used if there was no data to enrich. If this option is true then null values is used as the oldExchange (when no data to enrich), when using POJOs as the AggregationStrategy | false | Boolean
-| *executorServiceRef* | Refers to a custom Thread Pool to be used for parallel processing. Notice if you set this option, then parallel processing is automatic implied, and you do not have to enable that option as well. | | String
-| *streaming* | If enabled then Camel will process replies out-of-order, eg in the order they come back. If disabled, Camel will process replies in the same order as defined by the multicast. | false | Boolean
-| *stopOnException* | Will now stop further processing if an exception or failure occurred during processing of an org.apache.camel.Exchange and the caused exception will be thrown. Will also stop if processing the exchange failed (has a fault message) or an exception was thrown and handled by the error handler (such as using onException). In all situations the multicast will stop further processing. This is the same behavior as in pipeline, which is used by the routing engine. The defau [...]
-| *timeout* | Sets a total timeout specified in millis, when using parallel processing. If the Multicast hasn't been able to send and process all replies within the given timeframe, then the timeout triggers and the Multicast breaks out and continues. Notice if you provide a TimeoutAwareAggregationStrategy then the timeout method is invoked before breaking out. If the timeout is reached with running tasks still remaining, certain tasks for which it is difficult for Camel to shut down in [...]
-| *onPrepareRef* | Uses the Processor when preparing the org.apache.camel.Exchange to be send. This can be used to deep-clone messages that should be send, or any custom logic needed before the exchange is send. | | String
-| *shareUnitOfWork* | Shares the org.apache.camel.spi.UnitOfWork with the parent and each of the sub messages. Multicast will by default not share unit of work between the parent exchange and each multicasted exchange. This means each sub exchange has its own individual unit of work. | false | Boolean
-| *parallelAggregate* | If enabled then the aggregate method on AggregationStrategy can be called concurrently. Notice that this would require the implementation of AggregationStrategy to be implemented as thread-safe. By default this is false meaning that Camel synchronizes the call to the aggregate method. Though in some use-cases this can be used to archive higher performance when the AggregationStrategy is implemented as thread-safe. | false | Boolean
-| *stopOnAggregateException* | If enabled, unwind exceptions occurring at aggregation time to the error handler when parallelProcessing is used. Currently, aggregation time exceptions do not stop the route processing when parallelProcessing is used. Enabling this option allows to work around this behavior. The default value is false for the sake of backward compatibility. | false | Boolean
-|===
-// eip options: END
-
-== Multicast example
-
-The following example shows how to take a request from the *direct:a*
-endpoint , then multicast these request to *direct:x*, *direct:y*,
-*direct:z*.
-
-== Using the fluent builder
-
-By default Multicast invokes each endpoint sequentially. If parallel
-processing is desired, simply use
-
-[source,java]
-----
-from("direct:a").multicast().parallelProcessing().to("direct:x", "direct:y", "direct:z");
-----
-
-In case of using InOut MEP, an AggregationStrategy is used for
-aggregating all reply messages. The default is to only use the latest
-reply message and discard any earlier replies. The aggregation strategy
-is configurable:
-
-[source,java]
-----
-from("direct:start")
- .multicast(new MyAggregationStrategy())
- .parallelProcessing().timeout(500).to("direct:a", "direct:b", "direct:c")
- .end()
- .to("mock:result");
-----
-
-[NOTE]
-====
-The Multicast, Recipient List, and Splitter EIPs have special support for using `AggregationStrategy` with
-access to the original input exchange. You may want to use this when you aggregate messages and
-there has been a failure in one of the messages, which you then want to enrich on the original
-input message and return as response; its the aggregate method with 3 exchange parameters.
-====
-
-== Stop processing in case of exception
-
-The mutlicast EIP will by default continue to process
-the entire exchange even in case one of the
-multicasted messages will thrown an exception during routing.
-For example if you want to multicast to 3 destinations and the 2nd
-destination fails by an exception. What Camel does by default is to
-process the remainder destinations. You have the chance to remedy or
-handle this in the `AggregationStrategy`.
-
-But sometimes you just want Camel to stop and let the exception be
-propagated back, and let the Camel error handler handle it. You can do
-this by specifying that it should stop in case of an
-exception occurred. This is done by the `stopOnException` option as
-shown below:
-
-[source,java]
-----
- from("direct:start")
- .multicast()
- .stopOnException().to("direct:foo", "direct:bar", "direct:baz")
- .end()
- .to("mock:result");
-
- from("direct:foo").to("mock:foo");
-
- from("direct:bar").process(new MyProcessor()).to("mock:bar");
-
- from("direct:baz").to("mock:baz");
-----
-
-And using XML DSL you specify it as follows:
-
-[source,xml]
-----
- <route>
- <from uri="direct:start"/>
- <multicast stopOnException="true">
- <to uri="direct:foo"/>
- <to uri="direct:bar"/>
- <to uri="direct:baz"/>
- </multicast>
- <to uri="mock:result"/>
- </route>
-
- <route>
- <from uri="direct:foo"/>
- <to uri="mock:foo"/>
- </route>
-
- <route>
- <from uri="direct:bar"/>
- <process ref="myProcessor"/>
- <to uri="mock:bar"/>
- </route>
-
- <route>
- <from uri="direct:baz"/>
- <to uri="mock:baz"/>
- </route>
-----
-
-== Using onPrepare to execute custom logic when preparing messages
-
-The multicast EIP will copy the source
-exchange and multicast each copy. However the copy
-is a shallow copy, so in case you have mutateable message bodies, then
-any changes will be visible by the other copied messages. If you want to
-use a deep clone copy then you need to use a custom `onPrepare` which
-allows you to do this using the processor
-interface.
-
-Notice the `onPrepare` can be used for any kind of custom logic which
-you would like to execute before the xref:exchange.adoc[Exchange] is
-being multicasted.
diff --git a/docs/user-manual/modules/ROOT/pages/onFallback-eip.adoc b/docs/user-manual/modules/ROOT/pages/onFallback-eip.adoc
deleted file mode 100644
index 54264ad..0000000
--- a/docs/user-manual/modules/ROOT/pages/onFallback-eip.adoc
+++ /dev/null
@@ -1,84 +0,0 @@
-[[onFallback-eip]]
-= On Fallback EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/onFallback-eip.adoc
-
-If you are using *onFallback* then that is intended to be local processing only where you can do a message transformation or call a bean or something as the fallback.
-
-If you need to call an external service over the network then you should use *onFallbackViaNetwork* that runs in another independent *HystrixCommand* that uses its own thread pool to not exhaust the first command.
-
-== Options
-
-// eip options: START
-The On Fallback EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *fallbackViaNetwork* | Whether the fallback goes over the network. If the fallback will go over the network it is another possible point of failure and so it also needs to be wrapped by a HystrixCommand. It is important to execute the fallback command on a separate thread-pool, otherwise if the main command were to become latent and fill the thread-pool this would prevent the fallback from running if the two commands share the same pool. | false | Boolean
-|===
-// eip options: END
-
-Hystrix has many options as listed in xref:hystrixConfiguration-eip.adoc[Hystrix Configuration].
-For example to set a higher timeout to *5* seconds, and also let the circuit breaker wait *10* seconds before attempting a request again when the state was tripped to be open.
-
-[source,java]
-----
-from("direct:start")
- .circuitBreaker()
- .hystrixConfiguration()
- .executionTimeoutInMilliseconds(5000)
- .circuitBreakerSleepWindowInMilliseconds(10000)
- .end() // end Hystrix configuration
- .to("http://fooservice.com/slow")
- .onFallback()
- .transform().constant("Fallback message")
- .end()
- .to("mock:result");
-----
-
-And in XML DSL:
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <circuitBreaker>
- <hystrixConfiguration executionTimeoutInMilliseconds="5000"
- circuitBreakerSleepWindowInMilliseconds="10000"/>
- <to uri="http://fooservice.com/slow"/>
- <onFallback>
- <transform>
- <constant>Fallback message</constant>
- </transform>
- </onFallback>
- </circuitBreaker>
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-You can also configure Hystrix globally and then refer to that configuration:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
-
- <!-- a shared config which you can refer to from all your Hystrix EIPs -->
- <hystrixConfiguration id="sharedConfig"
- executionTimeoutInMilliseconds="5000"
- circuitBreakerSleepWindowInMilliseconds="10000"/>
-
- <route>
- <from uri="direct:start"/>
- <circuitBreaker configurationRef="sharedConfig">
- <to uri="http://fooservice.com/slow"/>
- <onFallback>
- <transform>
- <constant>Fallback message</constant>
- </transform>
- </onFallback>
- </hystrix>
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/otherwise-eip.adoc b/docs/user-manual/modules/ROOT/pages/otherwise-eip.adoc
deleted file mode 100644
index 312be74..0000000
--- a/docs/user-manual/modules/ROOT/pages/otherwise-eip.adoc
+++ /dev/null
@@ -1,62 +0,0 @@
-[[otherwise-eip]]
-= Otherwise EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/otherwise-eip.adoc
-
-The Otherwise EIP is related to http://www.enterpriseintegrationpatterns.com/ContentBasedRouter.html[Content
-Based Router] from the xref:enterprise-integration-patterns.adoc[EIP
-patterns]
-
-image::eip/ContentBasedRouter.gif[image]
-
-== Options
-
-// eip options: START
-The Otherwise EIP has no options.
-// eip options: END
-
-== Examples
-
-The following example shows how to route a request from an input
-*direct:a* endpoint to either *direct:b*, *direct:c* or *direct:d* depending on
-the evaluation of various xref:predicate.adoc[Predicate] expressions
-
-[source,java]
-----
-RouteBuilder builder = new RouteBuilder() {
- public void configure() {
- from("direct:a")
- .choice()
- .when(simple("${header.foo} == 'bar'"))
- .to("direct:b")
- .when(simple("${header.foo} == 'cheese'"))
- .to("direct:c")
- .otherwise()
- .to("direct:d");
- }
-};
-----
-
-
-And the same example using XML:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:a"/>
- <choice>
- <when>
- <simple>${header.foo} == 'bar'</simple>
- <to uri="direct:b"/>
- </when>
- <when>
- <simple>${header.foo} == 'cheese'</simple>
- <to uri="direct:c"/>
- </when>
- <otherwise>
- <to uri="direct:d"/>
- </otherwise>
- </choice>
- </route>
-</camelContext>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/pipeline-eip.adoc b/docs/user-manual/modules/ROOT/pages/pipeline-eip.adoc
deleted file mode 100644
index e0c1cbd..0000000
--- a/docs/user-manual/modules/ROOT/pages/pipeline-eip.adoc
+++ /dev/null
@@ -1,97 +0,0 @@
-[[pipeline-eip]]
-= Pipeline EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/pipeline-eip.adoc
-
-Camel supports the http://www.enterpriseintegrationpatterns.com/PipesAndFilters.html[Pipes and Filters] from the xref:enterprise-integration-patterns.adoc[EIP patterns] in various ways.
-
-image::eip/PipesAndFilters.gif[image]
-
-With Camel you can split your processing across multiple independent
-xref:endpoint.adoc[Endpoint] instances which can then be chained
-together.
-
-== Options
-
-// eip options: START
-The Pipeline EIP has no options.
-// eip options: END
-
-[[pipeline-Examples]]
-== Examples
-
-You can create pipelines of logic using multiple
-xref:endpoint.adoc[Endpoint] or xref:message-translator.adoc[Message
-Translator] instances as follows
-
-Though pipeline is the default mode of operation when you specify
-multiple outputs in Camel. The opposite to pipeline is multicast; which
-fires the same message into each of its outputs. (See the example
-below).
-
-In Java you do:
-[source,java]
-----
-from("activemq:SomeQueue")
- .pipeline()
- .bean("foo")
- .bean("bar")
- .to("acitvemq:OutputQueueu");
-----
-
-The pipeline is the default mode, which can be omitted, and therefore you almost often write as:
-
-[source,java]
-----
-from("activemq:SomeQueue")
- .bean("foo")
- .bean("bar")
- .to("acitvemq:OutputQueueu");
-----
-
-In XML you can use the `<pipeline>` element
-
-[source,xml]
-----
-<route>
- <from uri="activemq:SomeQueue"/>
- <pipeline>
- <bean ref="foo"/>
- <bean ref="bar"/>
- <to uri="activemq:OutputQueue"/>
- </pipeline>
-</route>
-----
-
-In the above the pipeline element is actually unnecessary, you could use this:
-
-[source,xml]
-----
-<route>
- <from uri="activemq:SomeQueue"/>
- <bean ref="foo"/>
- <bean ref="bar"/>
- <to uri="activemq:OutputQueue"/>
-</route>
-----
-
-Its just a bit more explicit. However if you wish to use `<multicast/>` to
-avoid a pipeline - to send the same message into multiple pipelines -
-then the `<pipeline>` element comes into its own.
-
-[source,xml]
-----
-<route>
- <from uri="activemq:SomeQueue"/>
- <multicast>
- <pipeline>
- <bean ref="something"/>
- <to uri="log:Something"/>
- </pipeline>
- <pipeline>
- <bean ref="foo"/>
- <bean ref="bar"/>
- <to uri="activemq:OutputQueue"/>
- </pipeline>
- </multicast>
-</route>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/pollEnrich-eip.adoc b/docs/user-manual/modules/ROOT/pages/pollEnrich-eip.adoc
deleted file mode 100644
index 8b4d65b..0000000
--- a/docs/user-manual/modules/ROOT/pages/pollEnrich-eip.adoc
+++ /dev/null
@@ -1,124 +0,0 @@
-[[pollEnrich-eip]]
-= Poll Enrich EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/pollEnrich-eip.adoc
-
-Camel comes with flavor `pollEnrich` as a choice of content enricher in the DSL.
-The other one is `enrich`
-
-`pollEnrich` uses a Polling Consumer to obtain the additional data. It is usually used for Event Message messaging, for instance to read a file or download a FTP file.
-
-[NOTE]
-Good practice to use timeout value. By default Camel will use the receive. Which may block until there is a message available. It is therefore recommended to always provide a timeout value, to make this clear that we may wait for a message, until the timeout is hit.
-
-If there is no data then the `newExchange` in the aggregation strategy is `null`.
-
-You can pass in a timeout value that determines which method to use
-
-* if timeout is -1 or other negative number then `receive` is selected (*Important:* the `receive` method may block if there is no message)
-* if timeout is 0 then `receiveNoWait` is selected
-* otherwise `receive(timeout)` is selected
-
-The timeout values is in millis.
-
-`pollEnrich` does *not* access any data from the current Exchange which means when polling it cannot use any of the existing headers you may have set on the Exchange. For example you cannot set a filename in the `Exchange.FILE_NAME` header and use `pollEnrich` to consume only that file. For that you *must* set the filename in the endpoint URI.
-Both `enrich` and `pollEnrich` supports dynamic endpoints that uses an Expression to compute the uri, which allows to use data from the current Exchange. In other words all what is told above no longer apply and it just works.
-
-TIP: See the `cacheSize` option for more details on _how much cache_ to use depending on how many or few unique endpoints are used.
-
-== Content enrichment using pollEnrich
-The `pollEnrich` works just as the `enrich` however as it uses a Polling Consumer we have 3 methods when polling
-
-* `receive`
-* `receiveNoWait`
-* `receive(timeout)`
-
-== PollEnrich Options
-
-// eip options: START
-The Poll Enrich EIP supports 7 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *timeout* | Timeout in millis when polling from the external service. The timeout has influence about the poll enrich behavior. It basically operations in three different modes: negative value - Waits until a message is available and then returns it. Warning that this method could block indefinitely if no messages are available. 0 - Attempts to receive a message exchange immediately without waiting and returning null if a message exchange is not available yet. positive value - Attempts [...]
-| *strategyRef* | Refers to an AggregationStrategy to be used to merge the reply from the external service, into a single outgoing message. By default Camel will use the reply from the external service as outgoing message. | | String
-| *strategyMethodName* | This option can be used to explicit declare the method name to use, when using POJOs as the AggregationStrategy. | | String
-| *strategyMethodAllowNull* | If this option is false then the aggregate method is not used if there was no data to enrich. If this option is true then null values is used as the oldExchange (when no data to enrich), when using POJOs as the AggregationStrategy. | false | Boolean
-| *aggregateOnException* | If this option is false then the aggregate method is not used if there was an exception thrown while trying to retrieve the data to enrich from the resource. Setting this option to true allows end users to control what to do if there was an exception in the aggregate method. For example to suppress the exception or set a custom message body etc. | false | Boolean
-| *cacheSize* | Sets the maximum size used by the org.apache.camel.spi.ConsumerCache which is used to cache and reuse consumers 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 discarded after use. This redu [...]
-| *ignoreInvalidEndpoint* | Ignore the invalidate endpoint exception when try to create a producer with that endpoint | false | Boolean
-|===
-// eip options: END
-
-== PollEnrich Example
-
-In this example we enrich the message by loading the content from the file named inbox/data.txt.
-[source,java]
-----
-from("direct:start")
- .pollEnrich("file:inbox?fileName=data.txt")
- .to("direct:result");
-----
-
-And in XML DSL you do:
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <pollEnrich>
- <constant>file:inbox?fileName=data.txt</constant>
- </pollEnrich>
- <to uri="direct:result"/>
-</route>
-----
-
-If there is no file then the message is empty. We can use a timeout to either wait (potentially forever) until a file exists, or use a timeout to wait a certain period.
-
-For example to wait up to 5 seconds you can do:
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <pollEnrich timeout="5000">
- <constant>file:inbox?fileName=data.txt</constant>
- </pollEnrich>
- <to uri="direct:result"/>
-</route>
-----
-
-To use it as a consumer in the middle of a REST Get route downloading a file from AWS S3 as the response of an API call.
-[source,xml]
-----
-<rest path="/report">
- <description>Report REST API</description>
- <get uri="/{id}/payload">
- <route id="report-payload-download">
- <pollEnrich id="pollEnrich">
- <simple>aws-s3:xavier-dev?amazonS3Client=#s3client&deleteAfterRead=false&fileName=report-file.pdf</simple>
- </pollEnrich>
- </route>
- </get>
-</rest>
-----
-
-== Using dynamic uris
-
-Both `enrich` and `pollEnrich` supports using dynamic uris computed based on information from the current Exchange. For example to `pollEnrich` from an endpoint that uses a header to indicate a SEDA queue name:
-[source,java]
-----
-from("direct:start")
- .pollEnrich().simple("seda:${header.name}")
- .to("direct:result");
-----
-
-And in XML DSL
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <pollEnrich>
- <simple>seda:${header.name}</simple>
- </pollEnrich>
- <to uri="direct:result"/>
-</route>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/process-eip.adoc b/docs/user-manual/modules/ROOT/pages/process-eip.adoc
deleted file mode 100644
index 6b4c3c6..0000000
--- a/docs/user-manual/modules/ROOT/pages/process-eip.adoc
+++ /dev/null
@@ -1,101 +0,0 @@
-[[process-eip]]
-= Process EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/process-eip.adoc
-
-The http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/Processor.html[Processor] interface is used to implement consumers of message exchanges or to implement a xref:message-translator.adoc[Message Translator]
-
-== Options
-
-// eip options: START
-The Process EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *ref* | *Required* Reference to the Processor to lookup in the registry to use. | | String
-|===
-// eip options: END
-
-== Samples
-
-=== Using a processor in a route
-
-Once you have written a class which implements processor like this...
-
-[source,java]
-----
-public class MyProcessor implements Processor {
- public void process(Exchange exchange) throws Exception {
- // do something...
- }
-}
-----
-
-You can then easily use this inside a route by declaring the bean in
-Spring, say via the XML (or registering it in JNDI if that is your
-xref:registry.adoc[Registry])
-
-[source,xml]
---------------------------------------------------------
-<bean id="myProcessor" class="com.acme.MyProcessor"/>
---------------------------------------------------------
-
-Then in Camel you can do
-
-[source,java]
-----
-from("activemq:myQueue").to("myProcessor");
-----
-
-=== Using the process DSL
-
-In your route you can also use the `process` DSL syntax for invoking a
-processor.
-
-[source,java]
-----
-Processor myProcessor = new MyProcessor();
-...
-from("activemq:myQueue").process(myProcessor);
-----
-
-If you need to lookup the processor in the xref:registry.adoc[Registry]
-then you should use the *processRef* DSL:
-
-[source,java]
-----
-from("activemq:myQueue").processRef("myProcessor");
-----
-
-== Why use process when you can use to instead?
-
-The process can be used in routes as an anonymous inner class such:
-
-[source,java]
-----
- from("activemq:myQueue").process(new Processor() {
- public void process(Exchange exchange) throws Exception {
- String payload = exchange.getIn().getBody(String.class);
- // do something with the payload and/or exchange here
- exchange.getIn().setBody("Changed body");
- }
- }).to("activemq:myOtherQueue");
-----
-
-This is usable for quickly whirling up some code. If the code in the
-inner class gets a bit more complicated it is of course advised to
-refactor it into a separate class.
-
-== Turning your processor into a full Component
-
-There is a base class called
-http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/impl/ProcessorEndpoint.html[ProcessorEndpoint]
-which supports the full xref:endpoint.adoc[Endpoint] semantics given a
-Processor instance.
-
-So you just need to create a https://github.com/apache/camel/tree/master/components[Component] class by
-deriving from
-http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/impl/DefaultComponent.html[DefaultComponent]
-which returns instances of ProcessorEndpoint. For more details see
-xref:writing-components.adoc[Writing Components]
-
diff --git a/docs/user-manual/modules/ROOT/pages/random-eip.adoc b/docs/user-manual/modules/ROOT/pages/random-eip.adoc
deleted file mode 100644
index 87cdfa4..0000000
--- a/docs/user-manual/modules/ROOT/pages/random-eip.adoc
+++ /dev/null
@@ -1,8 +0,0 @@
-[[random-eip]]
-= Random EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/random-eip.adoc
-
-
-// eip options: START
-The Random EIP has no options.
-// eip options: END
diff --git a/docs/user-manual/modules/ROOT/pages/recipientList-eip.adoc b/docs/user-manual/modules/ROOT/pages/recipientList-eip.adoc
deleted file mode 100644
index eec1ef3..0000000
--- a/docs/user-manual/modules/ROOT/pages/recipientList-eip.adoc
+++ /dev/null
@@ -1,375 +0,0 @@
-[[recipientList-eip]]
-= Recipient List EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/recipientList-eip.adoc
-The http://www.enterpriseintegrationpatterns.com/RecipientList.html[Recipient List] from the EIP patterns allows you to route messages to a number of dynamically specified recipients.
-
-image::eip/RecipientList.gif[image]
-
-The recipients will receive a copy of the *same* Exchange, and Camel will execute them sequentially.
-
-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 Recipient List EIP supports 15 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *delimiter* | Delimiter used if the Expression returned multiple endpoints. Can be turned off using the value false. The default value is , | , | String
-| *parallelProcessing* | If enabled then sending messages to the recipients occurs concurrently. Note the caller thread will still wait until all messages has been fully processed, before it continues. Its only the sending and processing the replies from the recipients which happens concurrently. | false | Boolean
-| *strategyRef* | Sets a reference to the AggregationStrategy to be used to assemble the replies from the recipients, into a single outgoing message from the RecipientList. By default Camel will use the last reply as the outgoing message. You can also use a POJO as the AggregationStrategy | | String
-| *strategyMethodName* | This option can be used to explicit declare the method name to use, when using POJOs as the AggregationStrategy. | | String
-| *strategyMethodAllowNull* | If this option is false then the aggregate method is not used if there was no data to enrich. If this option is true then null values is used as the oldExchange (when no data to enrich), when using POJOs as the AggregationStrategy | false | Boolean
-| *executorServiceRef* | Refers to a custom Thread Pool to be used for parallel processing. Notice if you set this option, then parallel processing is automatic implied, and you do not have to enable that option as well. | | String
-| *stopOnException* | Will now stop further processing if an exception or failure occurred during processing of an org.apache.camel.Exchange and the caused exception will be thrown. Will also stop if processing the exchange failed (has a fault message) or an exception was thrown and handled by the error handler (such as using onException). In all situations the recipient list will stop further processing. This is the same behavior as in pipeline, which is used by the routing engine. The [...]
-| *ignoreInvalidEndpoints* | Ignore the invalidate endpoint exception when try to create a producer with that endpoint | false | Boolean
-| *streaming* | If enabled then Camel will process replies out-of-order, eg in the order they come back. If disabled, Camel will process replies in the same order as defined by the recipient list. | false | Boolean
-| *timeout* | Sets a total timeout specified in millis, when using parallel processing. If the Recipient List hasn't been able to send and process all replies within the given timeframe, then the timeout triggers and the Recipient List breaks out and continues. Notice if you provide a TimeoutAwareAggregationStrategy then the timeout method is invoked before breaking out. If the timeout is reached with running tasks still remaining, certain tasks for which it is difficult for Camel to shu [...]
-| *onPrepareRef* | Uses the Processor when preparing the org.apache.camel.Exchange to be send. This can be used to deep-clone messages that should be send, or any custom logic needed before the exchange is send. | | String
-| *shareUnitOfWork* | Shares the org.apache.camel.spi.UnitOfWork with the parent and each of the sub messages. Recipient List will by default not share unit of work between the parent exchange and each recipient exchange. This means each sub exchange has its own individual unit of work. | 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 recipient list, 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 [...]
-| *parallelAggregate* | If enabled then the aggregate method on AggregationStrategy can be called concurrently. Notice that this would require the implementation of AggregationStrategy to be implemented as thread-safe. By default this is false meaning that Camel synchronizes the call to the aggregate method. Though in some use-cases this can be used to archive higher performance when the AggregationStrategy is implemented as thread-safe. | false | Boolean
-| *stopOnAggregateException* | If enabled, unwind exceptions occurring at aggregation time to the error handler when parallelProcessing is used. Currently, aggregation time exceptions do not stop the route processing when parallelProcessing is used. Enabling this option allows to work around this behavior. The default value is false for the sake of backward compatibility. | false | Boolean
-|===
-// eip options: END
-
-
-[TIP]
-====
-You can use the RecipientList Annotation on a POJO to create a Dynamic Recipient List. For more details see the Bean Integration.
-====
-
-== Static Recipient List
-The following example shows how to route a request from an input *queue:a* endpoint to a static list of destinations
-
-[source,java]
-----
-from("jms:queue:a")
- .recipientList("direct:b,direct:c,direct:d");
-----
-
-And in XML:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="jms:queue:a"/>
- <recipientList>
- <constant>direct:b,direct:c,direct:d</constant>
- </recipientList>
- </route>
-</camelContext>
-----
-
-== Dynamic Recipient List
-Usually one of the main reasons for using the Recipient List pattern is that the list of recipients is dynamic and
-calculated at runtime. The following example demonstrates how to create a dynamic recipient list using an Expression
-(which in this case extracts a named header value dynamically) to calculate the list of endpoints which are either
-of type Endpoint or are converted to a String and then resolved using the endpoint URIs (separated by comma).
-
-[source,java]
-----
-from("jms:queue:a")
- .recipientList(header("foo"));
-----
-
-== Iteratable value
-The dynamic list of recipients that are defined in the header must be iterable such as:
-
-* `java.util.Collection`
-* `java.util.Iterator`
-* arrays
-* `org.w3c.dom.NodeList`
-* a single String with values separated by comma (the delimiter configured)
-* any other type will be regarded as a single value
-
-== Using delimiter in Spring XML
-In Spring DSL you can set the delimiter attribute for setting a delimiter to be used if the header value is a single String with multiple separated endpoints.
-By default Camel uses comma as delimiter, but this option lets you specify a custom delimiter to use instead.
-
-[source,xml]
-----
-<route>
- <from uri="direct:a"/>
- <!-- use semi-colon as a delimiter for String based values -->
- <recipientList delimiter=";">
- <header>myHeader</header>
- </recipientList>
-</route>
-----
-
-So if *myHeader* contains a `String` with the value `"activemq:queue:foo;activemq:topic:hello ; log:bar"` then Camel will split the `String` using the delimiter given in the XML that was comma, resulting into 3 endpoints to send to.
-You can use spaces between the endpoints as Camel will trim the value when it lookup the endpoint to send to.
-
-And in Java:
-[source,java]
-----
-from("direct:a")
- .recipientList(header("myHeader"), ";");
-----
-
-== Sending to multiple recipients in parallel
-The Recipient List now supports `parallelProcessing` that for example Splitter also supports.
-You can use it to use a thread pool to have concurrent tasks sending the Exchange to multiple recipients concurrently.
-
-[source,java]
-----
-from("direct:a")
- .recipientList(header("myHeader")).parallelProcessing();
-----
-
-And in XML it is an attribute on the recipient list tag.
-
-[source,xml]
-----
-<route>
- <from uri="direct:a"/>
- <recipientList parallelProcessing="true">
- <header>myHeader</header>
- </recipientList>
-</route>
-----
-
-=== Using custom thread pool
-A thread pool is only used for `parallelProcessing`. You supply your own custom thread pool via the `ExecutorServiceStrategy` (see Camel's Threading Model),
-the same way you would do it for the `aggregationStrategy`. By default Camel uses a thread pool with 10 threads (subject to change in future versions).
-
-== Stop continuing in case one recipient failed
-The Recipient List now supports `stopOnException` that for example Splitter also supports.
-You can use it to stop sending to any further recipients in case any recipient failed.
-
-[source,java]
-----
-from("direct:a")
- .recipientList(header("myHeader")).stopOnException();
-----
-
-And in XML its an attribute on the recipient list tag.
-
-[source,xml]
-----
-<route>
- <from uri="direct:a"/>
- <recipientList stopOnException="true">
- <header>myHeader</header>
- </recipientList>
-</route>
-----
-
-[NOTE]
-====
-You can combine parallelProcessing and stopOnException and have them both true.
-====
-
-== Ignore invalid endpoints
-The Recipient List now supports `ignoreInvalidEndpoints` (like the Routing Slip).
-You can use it to skip endpoints which are invalid.
-
-[source,java]
-----
-from("direct:a")
- .recipientList(header("myHeader")).ignoreInvalidEndpoints();
-----
-
-And in XML it is an attribute on the recipient list tag.
-
-[source,xml]
-----
-<route>
- <from uri="direct:a"/>
- <recipientList ignoreInvalidEndpoints="true">
- <header>myHeader</header>
- </recipientList>
-</route>
-----
-
-Then let us say the `myHeader` contains the following two endpoints `direct:foo,xxx:bar`.
-The first endpoint is valid and works. However the second one is invalid and will just be ignored.
-Camel logs at DEBUG level about it, so you can see why the endpoint was invalid.
-
-== Using custom AggregationStrategy
-You can now use your own `AggregationStrategy` with the Recipient List. However this is rarely needed.
-What it is good for is that in case you are using Request Reply messaging then the replies from the recipients can be aggregated.
-By default Camel uses `UseLatestAggregationStrategy` which just keeps that last received reply. If you must remember all the bodies that all the recipients sent back,
-then you can use your own custom aggregator that keeps those. It is the same principle as with the Aggregator EIP so check it out for details.
-
-[source,java]
-----
-from("direct:a")
- .recipientList(header("myHeader")).aggregationStrategy(new MyOwnAggregationStrategy())
- .to("direct:b");
-----
-
-And in XML it is again an attribute on the recipient list tag.
-
-[source,xml]
-----
-<route>
- <from uri="direct:a"/>
- <recipientList strategyRef="myStrategy">
- <header>myHeader</header>
- </recipientList>
- <to uri="direct:b"/>
-</route>
-
-<!-- bean with the custom aggregation strategy -->
-<bean id="myStrategy" class="com.mycompany.MyOwnAggregationStrategy"/>
-----
-
-[NOTE]
-====
-The Multicast, Recipient List, and Splitter EIPs have special support for using `AggregationStrategy` with
-access to the original input exchange. You may want to use this when you aggregate messages and
-there has been a failure in one of the messages, which you then want to enrich on the original
-input message and return as response; its the aggregate method with 3 exchange parameters.
-====
-
-== Knowing which endpoint when using custom AggregationStrategy
-
-When using a custom `AggregationStrategy` then the `aggregate` method is always invoked in sequential order
-(also if parallel processing is enabled) of the endpoints the Recipient List is using.
-However, Exchange has a property stored (key is `Exchange.RECIPIENT_LIST_ENDPOINT` with the uri of the Endpoint.
-So you know which endpoint you are aggregating from. The code block shows how to access this property in your Aggregator.
-
-[source,java]
-----
-@Override
-public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
- String uri = newExchange.getProperty(Exchange.RECIPIENT_LIST_ENDPOINT, String.class);
-}
-----
-
-== Using method call as recipient list
-You can use a Bean to provide the recipients, for example:
-
-[source,java]
-----
-from("activemq:queue:test")
- .recipientList().method(MessageRouter.class, "routeTo");
-----
-
-And then `MessageRouter` bean:
-
-[source,java]
-----
-public class MessageRouter {
-
- public String routeTo() {
- String queueName = "activemq:queue:test2";
- return queueName;
- }
-}
-----
-
-[CAUTION]
-When you use a Bean then do *not* use the `@RecipientList` annotation as this will in fact add yet another recipient list, so you end up having two. Do *not* do the following:
-[source,java]
-----
-public class MessageRouter {
-
- // do not use recipientList in the Camel route calling a bean with the @RecipientList annotation!
- @RecipientList
- public String routeTo() {
- String queueName = "activemq:queue:test2";
- return queueName;
- }
-}
-----
-
-You should only use the snippet above (using `@RecipientList`) if you just route to a Bean which you then want to act as a recipient list.
-So the original route can be changed to:
-
-[source,java]
-----
-from("activemq:queue:test").bean(MessageRouter.class, "routeTo");
-----
-
-Which then would invoke the routeTo method and detect that it is annotated with `@RecipientList` and then act accordingly as if it was a recipient list EIP.
-
-== Using timeout
-If you use `parallelProcessing` then you can configure a total `timeout` value in millis. Camel will then process the messages in parallel until the timeout is hit. This allows you to continue processing if one message consumer is slow. For example you can set a timeout value of 20 sec.
-
-[WARNING]
-.Tasks may keep running
-If the timeout is reached with running tasks still remaining, certain tasks for which it is difficult for Camel to shut down in a graceful manner may continue to run. So use this option with a bit of care. We may be able to improve this functionality in future Camel releases.
-
-For example in the unit test below you can see that we multicast the message to 3 destinations. We have a timeout of 2 seconds, which means only the last two messages can be completed within the timeframe. This means we will only aggregate the last two which yields a result aggregation which outputs "BC".
-
-[source,java]
-----
-from("direct:start")
- .multicast(new AggregationStrategy() {
- public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
- if (oldExchange == null) {
- return newExchange;
- }
-
- String body = oldExchange.getIn().getBody(String.class);
- oldExchange.getIn().setBody(body + newExchange.getIn().getBody(String.class));
- return oldExchange;
- }
- })
- .parallelProcessing().timeout(250).to("direct:a", "direct:b", "direct:c")
- // use end to indicate end of multicast route
- .end()
- .to("mock:result");
-
-from("direct:a").delay(1000).to("mock:A").setBody(constant("A"));
-
-from("direct:b").to("mock:B").setBody(constant("B"));
-
-from("direct:c").to("mock:C").setBody(constant("C"));
-----
-
-[NOTE]
-===
-*Timeout in other EIPs*
-
-This timeout feature is also supported by Splitter and both multicast and recipientList.
-===
-
-By default if a timeout occurs the `AggregationStrategy` is not invoked. However you can implement the `timeout` method:
-This allows you to deal with the timeout in the `AggregationStrategy` if you really need to.
-
-[NOTE]
-===
-*Timeout is total*
-
-The timeout is total, which means that after X time, Camel will aggregate the messages which have completed within the timeframe.
-The remainders will be cancelled. Camel will also only invoke the `timeout` method in the `TimeoutAwareAggregationStrategy` once, for the first index which caused the timeout.
-===
-
-== Using onPrepare to execute custom logic when preparing messages
-See details at the Multicast EIP
-
-== Using ExchangePattern in recipients
-
-The recipient list will by default use the current Exchange Pattern. Though one can imagine use-cases where one wants to send
-a message to a recipient using a different exchange pattern. For example you may have a route that initiates as an `InOnly` route,
-but want to use `InOut` exchange pattern with a recipient list. You can configure the exchange pattern directly in the
-recipient endpoints.
-
-For example in the route below we pick up new files (which will be started as `InOnly`) and then route to a recipient list.
-As we want to use `InOut` with the ActiveMQ (JMS) endpoint we can now specify this using the `exchangePattern=InOut` option.
-Then the response from the JMS request/reply will then be continued routed, and thus the response is what will be stored
-in as a file in the outbox directory.
-
-[source,java]
-----
-from("file:inbox")
- // the exchange pattern is InOnly initially when using a file route
- .recipientList().constant("activemq:queue:inbox?exchangePattern=InOut")
- .to("file:outbox");
-----
-
-[WARNING]
-====
-The recipient list will not alter the original exchange pattern. So in the example above the exchange pattern will still
-be `InOnly` when the message is routed to the `file:outbox endpoint`.
-If you want to alter the exchange pattern permanently then use the `.setExchangePattern` option.
-
-See more details at Request Reply and Event Message EIPs.
-====
diff --git a/docs/user-manual/modules/ROOT/pages/ref-language.adoc b/docs/user-manual/modules/ROOT/pages/ref-language.adoc
deleted file mode 100644
index 0b86da1..0000000
--- a/docs/user-manual/modules/ROOT/pages/ref-language.adoc
+++ /dev/null
@@ -1,58 +0,0 @@
-[[ref-language]]
-= Ref Language
-:page-source: core/camel-core-languages/src/main/docs/ref-language.adoc
-
-*Since Camel 2.8*
-
-The Ref Expression Language is really just a way to lookup a custom
-Expression or Predicate from the Registry.
-
-This is particular useable in XML DSLs.
-
-== Ref Language options
-
-// language options: START
-The Ref language supports 1 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
-
-== Example usage
-
-The Splitter in XML DSL can utilize a custom
-expression using `<ref>` like:
-
-[source,xml]
-----
-<bean id="myExpression" class="com.mycompany.MyCustomExpression"/>
-
-<route>
- <from uri="seda:a"/>
- <split>
- <ref>myExpression</ref>
- <to uri="mock:b"/>
- </split>
-</route>
-----
-
-in this case, the Message coming from the seda:a
-Endpoint will be splitted using a custom
-Expression which has the id `myExpression` in the
-Registry.
-
-And the same example using Java DSL:
-
-[source,java]
-----
-from("seda:a").split().ref("myExpression").to("seda:b");
-----
-
-== Dependencies
-
-The Ref language is part of *camel-core*.
\ No newline at end of file
diff --git a/docs/user-manual/modules/ROOT/pages/removeHeader-eip.adoc b/docs/user-manual/modules/ROOT/pages/removeHeader-eip.adoc
deleted file mode 100644
index f74d815..0000000
--- a/docs/user-manual/modules/ROOT/pages/removeHeader-eip.adoc
+++ /dev/null
@@ -1,40 +0,0 @@
-[[removeHeader-eip]]
-= Remove Header EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/removeHeader-eip.adoc
-The Remove Header EIP allows you to remove an header from your exchange.
-
-== Options
-
-// eip options: START
-The Remove Header EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *headerName* | *Required* Name of header to remove | | String
-|===
-// eip options: END
-
-== Samples
-
-[source,java]
-----
-from("seda:b")
- .removeHeader("myHeader")
- .to("mock:result");
-----
-
-=== Spring DSL
-The sample below demonstrates the delay in Spring DSL:
-
-[source,xml]
-----
-<route>
- <from uri="seda:b"/>
- <removeHeader>
- <constant>myHeader</constant>
- <removeHeader/>
- <to uri="mock:result"/>
-</route>
-
-----
diff --git a/docs/user-manual/modules/ROOT/pages/removeHeaders-eip.adoc b/docs/user-manual/modules/ROOT/pages/removeHeaders-eip.adoc
deleted file mode 100644
index 7caf885..0000000
--- a/docs/user-manual/modules/ROOT/pages/removeHeaders-eip.adoc
+++ /dev/null
@@ -1,26 +0,0 @@
-[[removeHeaders-eip]]
-= Remove Headers EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/removeHeaders-eip.adoc
-The Remove Headers EIP allows you to remove headers from your exchange.
-
-== Options
-
-// eip options: START
-The Remove Headers EIP supports 2 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *pattern* | *Required* Name or pattern of headers to remove. The pattern is matched in the following order: 1 = exact match 2 = wildcard (pattern ends with a and the name starts with the pattern) 3 = regular expression (all of above is case in-sensitive). | | String
-| *excludePattern* | Name or patter of headers to not remove. The pattern is matched in the following order: 1 = exact match 2 = wildcard (pattern ends with a and the name starts with the pattern) 3 = regular expression (all of above is case in-sensitive). | | String
-|===
-// eip options: END
-
-== Samples
-
-[source,java]
-----
-from("seda:b")
- .removeHeaders(map)
- .to("mock:result");
-----
diff --git a/docs/user-manual/modules/ROOT/pages/removeProperties-eip.adoc b/docs/user-manual/modules/ROOT/pages/removeProperties-eip.adoc
deleted file mode 100644
index 5365855..0000000
--- a/docs/user-manual/modules/ROOT/pages/removeProperties-eip.adoc
+++ /dev/null
@@ -1,47 +0,0 @@
-[[removeProperties-eip]]
-= Remove Properties EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/removeProperties-eip.adoc
-
-The RemoveProperties EIP allows you to remove Properties from you exchange.
-
-== Options
-
-// eip options: START
-The Remove Properties EIP supports 2 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *pattern* | *Required* Name or pattern of properties to remove. The pattern is matched in the following order: 1 = exact match 2 = wildcard (pattern ends with a and the name starts with the pattern) 3 = regular expression (all of above is case in-sensitive). | | String
-| *excludePattern* | Name or pattern of properties to not remove. The pattern is matched in the following order: 1 = exact match 2 = wildcard (pattern ends with a and the name starts with the pattern) 3 = regular expression (all of above is case in-sensitive). | | String
-|===
-// eip options: END
-
-== Examples
-
-The following example shows how to use the removeProperties EIP
-
-[source,java]
-----
-RouteBuilder builder = new RouteBuilder() {
- public void configure() {
- from("direct:a")
- .removeProperties("myProperty", "myProperty1")
- .to("direct:b");
- }
-};
-----
-
-
-And the same example using XML:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:a"/>
- <removeProperties pattern="myProperty*"/>
- <to uri="direct:b"/>
- </route>
-</camelContext>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/removeProperty-eip.adoc b/docs/user-manual/modules/ROOT/pages/removeProperty-eip.adoc
deleted file mode 100644
index 34dd5e1..0000000
--- a/docs/user-manual/modules/ROOT/pages/removeProperty-eip.adoc
+++ /dev/null
@@ -1,46 +0,0 @@
-[[removeProperty-eip]]
-= Remove Property EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/removeProperty-eip.adoc
-
-The RemoveProperty EIP allows you to remove a Property from your exchange.
-
-== Options
-
-// eip options: START
-The Remove Property EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *propertyName* | *Required* Name of property to remove | | String
-|===
-// eip options: END
-
-== Examples
-
-The following example shows how to use the Remove Property EIP
-
-[source,java]
-----
-RouteBuilder builder = new RouteBuilder() {
- public void configure() {
- from("direct:a")
- .removeProperty("myProperty")
- .to("direct:b");
- }
-};
-----
-
-
-And the same example using XML:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:a"/>
- <removeProperty propertyName="myProperty"/>
- <to uri="direct:b"/>
- </route>
-</camelContext>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/requestReply-eip.adoc b/docs/user-manual/modules/ROOT/pages/requestReply-eip.adoc
deleted file mode 100644
index 49db278..0000000
--- a/docs/user-manual/modules/ROOT/pages/requestReply-eip.adoc
+++ /dev/null
@@ -1,49 +0,0 @@
-[[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
-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]
-----
-jms:MyQueue?exchangePattern=InOut
-----
-
-You can specify the exchange pattern in DSL rule or Spring
-configuration.
-
diff --git a/docs/user-manual/modules/ROOT/pages/resequence-eip.adoc b/docs/user-manual/modules/ROOT/pages/resequence-eip.adoc
deleted file mode 100644
index ab2a9ba..0000000
--- a/docs/user-manual/modules/ROOT/pages/resequence-eip.adoc
+++ /dev/null
@@ -1,242 +0,0 @@
-[[resequence-eip]]
-= Resequence EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/resequence-eip.adoc
-
-The http://www.enterpriseintegrationpatterns.com/Resequencer.html[Resequencer] from the https://camel.apache.org/enterprise-integration-patterns.html[EIP patterns] allows you to reorganise messages based on some comparator. +
-By default in Camel we use an Expression to create the comparator; so that you can compare by a message header or the body or a piece of a message etc.
-
-image::eip/Resequencer.gif[image]
-
-== Options
-
-// eip options: START
-The Resequence EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *resequencerConfig* | To configure the resequencer in using either batch or stream configuration. Will by default use batch configuration. | | ResequencerConfig
-|===
-// eip options: END
-
-Camel supports two resequencing algorithms:
-
-* *Batch resequencing* collects messages into a batch, sorts the messages and sends them to their output.
-* *Stream resequencing* re-orders (continuous) message streams based on the detection of gaps between messages.
-
-By default the Resequencer does not support duplicate messages and will only keep the last message, in case a message arrives with the same message expression. However in the batch mode you can enable it to allow duplicates.
-
-== Batch Resequencing
-The following example shows how to use the batch-processing resequencer so that messages are sorted in order of the *body()* expression. That is messages are collected into a batch (either by a maximum number of messages per batch or using a timeout) then they are sorted in order and then sent out to their output.
-
-[source,java]
-----
-from("direct:start")
- .resequence().body()
- .to("mock:result");
-----
-
-This is equivalent to
-[source,java]
-----
-from("direct:start")
- .resequence(body()).batch()
- .to("mock:result");
-----
-
-The batch-processing resequencer can be further configured via the `size()` and `timeout()` methods.
-[source,java]
-----
-from("direct:start")
- .resequence(body()).batch().size(300).timeout(4000L)
- .to("mock:result")
-----
-
-This sets the batch size to 300 and the batch timeout to 4000 ms (by default, the batch size is 100 and the timeout is 1000 ms). Alternatively, you can provide a configuration object.
-
-[source,java]
-----
-from("direct:start")
- .resequence(body()).batch(new BatchResequencerConfig(300, 4000L))
- .to("mock:result")
-----
-
-So the above example will reorder messages from endpoint *direct:a* in order of their bodies, to the endpoint *mock:result*. +
-Typically you'd use a header rather than the body to order things; or maybe a part of the body. So you could replace this expression with
-
-[source,java]
-----
-resequence(header("mySeqNo"))
-----
-
-for example to reorder messages using a custom sequence number in the header `mySeqNo`. +
-You can of course use many different Expression languages such as XPath, XQuery, SQL or various Scripting Languages.
-
-And an example in XML
-
-[source,xml]
-----
-<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start" />
- <resequence>
- <simple>body</simple>
- <to uri="mock:result" />
- <!--
- batch-config can be ommitted for default (batch) resequencer settings
- -->
- <batch-config batchSize="300" batchTimeout="4000" />
- </resequence>
- </route>
-</camelContext>
-----
-
-== Allow Duplicates
-In the `batch` mode, you can now allow duplicates. In Java DSL there is a `allowDuplicates()` method and in Spring XML there is an `allowDuplicates=true` attribute on the `<batch-config/>` you can use to enable it.
-
-== Reverse
-In the `batch` mode, you can now reverse the expression ordering. By default the order is based on 0..9,A..Z, which would let messages with low numbers be ordered first, and thus also also outgoing first. In some cases you want to reverse order, which is now possible. +
-In Java DSL there is a `reverse()` method and in Spring XML there is an `reverse=true` attribute on the `<batch-config/>` you can use to enable it.
-
-== Resequence JMS messages based on JMSPriority
-It's now much easier to use the Resequencer to resequence messages from JMS queues based on JMSPriority. For that to work you need to use the two new options `allowDuplicates` and `reverse`.
-
-[source,java]
-----
-from("jms:queue:foo")
- // sort by JMSPriority by allowing duplicates (message can have same JMSPriority)
- // and use reverse ordering so 9 is first output (most important), and 0 is last
- // use batch mode and fire every 3th second
- .resequence(header("JMSPriority")).batch().timeout(3000).allowDuplicates().reverse()
- .to("mock:result");
-----
-
-Notice this is *only* possible in the `batch` mode of the Resequencer.
-
-== Ignore invalid exchanges
-
-The Resequencer EIP throws a `CamelExchangeException` if the incoming Exchange is not valid for the resequencer - ie. the expression cannot be evaluated, such as a missing header.
-You can use the option `ignoreInvalidExchanges` to ignore these exceptions which means the Resequencer will then skip the invalid Exchange.
-
-[source,java]
-----
-from("direct:start")
- .resequence(header("seqno")).batch().timeout(1000)
- // ignore invalid exchanges (they are discarded)
- .ignoreInvalidExchanges()
- .to("mock:result");
-----
-
-This option is available for both batch and stream resequencer.
-
-== Reject Old Exchanges
-
-This option can be used to prevent out of order messages from being sent regardless of the event that delivered messages downstream (capacity, timeout, etc). If enabled using `rejectOld()`, the Resequencer will throw a `MessageRejectedException` when an incoming Exchange is "older" (based on the Comparator) than the last delivered message. This provides an extra level of control with regards to delayed message ordering.
-
-[source,java]
-----
-from("direct:start")
- .onException(MessageRejectedException.class).handled(true).to("mock:error").end()
- .resequence(header("seqno")).stream().timeout(1000).rejectOld()
- .to("mock:result");
-----
-
-This option is available for the stream resequencer only.
-
-== Stream Resequencing
-The next example shows how to use the stream-processing resequencer. Messages are re-ordered based on their sequence numbers given by a seqnum header using gap detection and timeouts on the level of individual messages.
-
-[source,java]
-----
-from("direct:start").resequence(header("seqnum")).stream().to("mock:result");
-----
-
-The stream-processing resequencer can be further configured via the `capacity()` and `timeout()` methods.
-
-[source,java]
-----
-from("direct:start")
- .resequence(header("seqnum")).stream().capacity(5000).timeout(4000L)
- .to("mock:result")
-----
-
-This sets the resequencer's capacity to 5000 and the timeout to 4000 ms (by default, the capacity is 1000 and the timeout is 1000 ms). Alternatively, you can provide a configuration object.
-
-[source,java]
-----
-from("direct:start")
- .resequence(header("seqnum")).stream(new StreamResequencerConfig(5000, 4000L))
- .to("mock:result")
-----
-
-The stream-processing resequencer algorithm is based on the detection of gaps in a message stream rather than on a fixed batch size.
-Gap detection in combination with timeouts removes the constraint of having to know the number of messages of a sequence (i.e. the batch size) in advance. Messages must contain a unique sequence number for which a predecessor and a successor is known. For example a message with the sequence number 3 has a predecessor message with the sequence number 2 and a successor message with the sequence number 4. The message sequence 2,3,5 has a gap because the successor of 3 is missing. The resequ [...]
-
-If the maximum time difference between messages (with successor/predecessor relationship with respect to the sequence number) in a message stream is known, then the resequencer's timeout parameter should be set to this value. In this case it is guaranteed that all messages of a stream are delivered in correct order to the next processor. The lower the timeout value is compared to the out-of-sequence time difference the higher is the probability for out-of-sequence messages delivered by t [...]
-
-By default, the stream resequencer expects long sequence numbers but other sequence numbers types can be supported as well by providing a custom expression.
-
-[source,java]
-----
-public class MyFileNameExpression implements Expression {
-
- public String getFileName(Exchange exchange) {
- return exchange.getIn().getBody(String.class);
- }
-
- public Object evaluate(Exchange exchange) {
- // parser the file name with YYYYMMDD-DNNN pattern
- String fileName = getFileName(exchange);
- String[] files = fileName.split("-D");
- Long answer = Long.parseLong(files[0]) * 1000 + Long.parseLong(files[1]);
- return answer;
- }
-
- public <T> T evaluate(Exchange exchange, Class<T> type) {
- Object result = evaluate(exchange);
- return exchange.getContext().getTypeConverter().convertTo(type, result);
- }
-
-}
-
-from("direct:start")
- .resequence(new MyFileNameExpression()).stream().timeout(100).to("mock:result");
-----
-
-or custom comparator via the `comparator()` method
-
-[source,java]
-----
-ExpressionResultComparator<Exchange> comparator = new MyComparator();
-from("direct:start")
- .resequence(header("seqnum")).stream().comparator(comparator)
- .to("mock:result");
-----
-
-or via a `StreamResequencerConfig` object.
-
-[source,java]
-----
-ExpressionResultComparator<Exchange> comparator = new MyComparator();
-StreamResequencerConfig config = new StreamResequencerConfig(100, 1000L, comparator);
-
-from("direct:start")
- .resequence(header("seqnum")).stream(config)
- .to("mock:result");
-----
-
-And an example in XML
-
-[source,xml]
-----
-<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <resequence>
- <simple>in.header.seqnum</simple>
- <to uri="mock:result" />
- <stream-config capacity="5000" timeout="4000"/>
- </resequence>
- </route>
-</camelContext>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/resilience4j-eip.adoc b/docs/user-manual/modules/ROOT/pages/resilience4j-eip.adoc
deleted file mode 100644
index 239dd92..0000000
--- a/docs/user-manual/modules/ROOT/pages/resilience4j-eip.adoc
+++ /dev/null
@@ -1,150 +0,0 @@
-[[resilience4j-eip]]
-= Resilience4j EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/resilience4j-eip.adoc
-
-This component supports the Circuit Breaker EIP with the Resilience4j library.
-
-[NOTE]
-====
-Camel provides the Circuit Breaker EIP in the route model, which allows to plugin different implementations.
-Resilience4j is one such implementation.
-====
-
-Maven users will need to add the following dependency to their pom.xml to use this EIP:
-
-[source]
-----
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-resilience4j</artifactId>
- <version>x.x.x</version><!-- use the same version as your Camel core version -->
-</dependency>
-----
-
-== Configuration options
-
-// eip options: START
-The Hystrix EIP supports 2 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *resilienceConfiguration* | Configures the Resilience EIP Use end when configuration is complete, to return back to the Resilience EIP. | | ResilienceConfigurationDefinition
-| *resilienceConfigurationRef* | Refers to a Resilience configuration to use for configuring the Resilience EIP. | | String
-|===
-// eip options: END
-
-See xref:resilience4jConfiguration-eip.adoc[Resilience4j Configuration] for all the configuration options on Resilience Circuit Breaker.
-
-== Samples
-
-Below is an example route showing a Resilience endpoint that protects against a downstream HTTP operation by falling back to the in-lined fallback route.
-[source,java]
-----
-from("direct:start")
- .circuitBreaker()
- .to("http://fooservice.com/faulty")
- .onFallback()
- .transform().constant("Fallback message")
- .end()
- .to("mock:result");
-----
-
-And in XML DSL:
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <circuitBreaker>
- <to uri="http://fooservice.com/faulty"/>
- <onFallback>
- <transform>
- <constant>Fallback message</constant>
- </transform>
- </onFallback>
- </circuitBreaker>
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-== Configuring Resilience4j
-
-You can fine-tune Resilience4j by the many xref:resilience4jConfiguration-eip.adoc[Resilience4j Configuration] options.
-
-For example to use a 2 second execution timeout, you can do as follows:
-
-[source,java]
-----
-from("direct:start")
- .circuitBreaker()
- // use 2 second timeout
- .resilience4jConfiguration().timeoutEnabled(true).timeoutDuration(2000).end()
- .log("Resilience processing start: ${threadName}")
- .toD("direct:${body}")
- .log("Resilience processing end: ${threadName}")
- .end()
- .log("After Resilience ${body}");
-----
-
-And in XML:
-
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <circuitBreaker>
- <resilience4jConfiguration timeoutEnabled="true" timeoutDuration="2000"/>
- <log message="Resilience processing start: ${threadName}"/>
- <toD uri="direct:${body}"/>
- <log message="Resilience processing end: ${threadName}"/>
- </circuitBreaker>
- <log message="After Resilience: ${body}"/>
-</route>
-----
-
-== Fallback
-
-See xref:onFallback-eip.adoc[onFallback].
-
-== Other examples
-
-You can find an example with the source code: https://github.com/apache/camel-spring-boot/tree/master/examples/camel-example-spring-boot-resilience4j[camel-example-spring-boot-resilience4j].
-
-== Using Resilience4j with Spring Boot
-
-See the xref:components::resilience4j.adoc[Resilience4j Component].
-
-== Camel's Error Handler and Circuit Breaker EIP
-
-By default the Circuit Breaker EIP handles errors by itself. This means if the circuit breaker is open and
-the message fails, then Camel's error handler is not reacting also.
-However, you can enable Camels error handler with circuit breaker by enabling the `inheritErrorHandler` option, as shown:
-
-[source,java]
-----
-// Camel's error handler that will attempt to redeliver the message 3 times
-errorHandler(deadLetterChannel("mock:dead").maximumRedeliveries(3).redeliveryDelay(0));
-
-from("direct:start")
- .to("log:start")
- // turn on Camel's error handler on circuit breaker so Camel can do redeliveries
- .circuitBreaker().inheritErrorHandler(true)
- .to("mock:a")
- .throwException(new IllegalArgumentException("Forced"))
- .end()
- .to("log:result")
- .to("mock:result");
-----
-
-This example is from an unit test, where you can see the Circuit Breaker EIP block has been hardcoded
-to always fail by throwing an exception. Because the `inheritErrorHandler` has been enabled,
-then Camel's error handler will attempt to call the Circuit Breaker EIP block again.
-
-That means the `mock:a` endpoint will receive the message again, and a total of 1 + 3 = 4 message
-(first time + 3 redeliveries).
-
-If we turn off the `inheritErrorHandler` option (default) then the Circuit Breaker EIP will only be
-executed once because it handled the error itself.
-
diff --git a/docs/user-manual/modules/ROOT/pages/resilience4jConfiguration-eip.adoc b/docs/user-manual/modules/ROOT/pages/resilience4jConfiguration-eip.adoc
deleted file mode 100644
index 997ee11..0000000
--- a/docs/user-manual/modules/ROOT/pages/resilience4jConfiguration-eip.adoc
+++ /dev/null
@@ -1,7 +0,0 @@
-[[resilience4jConfiguration-eip]]
-= Resilience4j Configuration EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/resilience4jConfiguration-eip.adoc
-
-
-// eip options: START
-// eip options: END
diff --git a/docs/user-manual/modules/ROOT/pages/rollback-eip.adoc b/docs/user-manual/modules/ROOT/pages/rollback-eip.adoc
deleted file mode 100644
index 767fa07..0000000
--- a/docs/user-manual/modules/ROOT/pages/rollback-eip.adoc
+++ /dev/null
@@ -1,242 +0,0 @@
-[[rollback-eip]]
-= Rollback EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/rollback-eip.adoc
-Rollback might be needed if there is a transaction or transactional pieces in your design.
-
-Camel recommends supporting the
-http://www.enterpriseintegrationpatterns.com/TransactionalClient.html[Transactional
-Client] from the xref:enterprise-integration-patterns.adoc[EIP patterns]
-using spring transactions.
-
-image::eip/TransactionalClientSolution.gif[image]
-
-Transaction Oriented Endpoints like xref:components::jms-component.adoc[JMS] support using a
-transaction for both inbound and outbound message exchanges. Endpoints
-that support transactions will participate in the current transaction
-context that they are called from.
-
-Configuration of Redelivery
-
-The redelivery in transacted mode is *not* handled by Camel but by the
-backing system (the transaction manager). In such cases you should
-resort to the backing system how to configure the redelivery.
-
-You should use the
-http://camel.apache.org/maven/current/camel-spring/apidocs/org/apache/camel/spring/SpringRouteBuilder.html[SpringRouteBuilder]
-to setup the routes since you will need to setup the spring context with
-the TransactionTemplates that will define the transaction manager
-configuration and policies.
-
-For inbound endpoint to be transacted, they normally need to be
-configured to use a Spring PlatformTransactionManager. In the case of
-the JMS component, this can be done by looking it up in the spring
-context.
-
-You first define needed object in the spring configuration.
-
-[source,xml]
---------------------------------------------------------
-<bean id="jmsTransactionManager" class="org.springframework.jms.connection.JmsTransactionManager">
- <property name="connectionFactory" ref="jmsConnectionFactory" />
-</bean>
-<bean id="jmsConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
- <property name="brokerURL" value="tcp://localhost:61616"/>
-</bean>
---------------------------------------------------------
-
-Then you look them up and use them to create the JmsComponent.
-
-[source,java]
-----
-PlatformTransactionManager transactionManager = (PlatformTransactionManager) spring.getBean("jmsTransactionManager");
-ConnectionFactory connectionFactory = (ConnectionFactory) spring.getBean("jmsConnectionFactory");
-JmsComponent component = JmsComponent.jmsComponentTransacted(connectionFactory, transactionManager);
-component.getConfiguration().setConcurrentConsumers(1);
-ctx.addComponent("activemq", component);
-----
-
-== Options
-// eip options: START
-The Rollback EIP supports 3 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *markRollbackOnly* | Mark the transaction for rollback only (cannot be overruled to commit) | false | Boolean
-| *markRollbackOnlyLast* | Mark only last sub transaction for rollback only. When using sub transactions (if the transaction manager support this) | false | Boolean
-| *message* | Message to use in rollback exception | | String
-|===
-// eip options: END
-
-=== Transaction Policies
-
-Outbound endpoints will automatically enlist in the current transaction
-context. But what if you do not want your outbound endpoint to enlist in
-the same transaction as your inbound endpoint? The solution is to add a
-Transaction Policy to the processing route. You first have to define
-transaction policies that you will be using. The policies use a spring
-TransactionTemplate under the covers for declaring the transaction
-demarcation to use. So you will need to add something like the following
-to your spring xml:
-
-[source,xml]
---------------------------------------------------------
-<bean id="PROPAGATION_REQUIRED" class="org.apache.camel.spring.spi.SpringTransactionPolicy">
- <property name="transactionManager" ref="jmsTransactionManager"/>
-</bean>
-<bean id="PROPAGATION_REQUIRES_NEW" class="org.apache.camel.spring.spi.SpringTransactionPolicy">
- <property name="transactionManager" ref="jmsTransactionManager"/>
- <property name="propagationBehaviorName" value="PROPAGATION_REQUIRES_NEW"/>
-</bean>
---------------------------------------------------------
-
-Then in your
-http://camel.apache.org/maven/current/camel-spring/apidocs/org/apache/camel/spring/SpringRouteBuilder.html[SpringRouteBuilder],
-you just need to create new SpringTransactionPolicy objects for each of
-the templates.
-
-[source,java]
-----
-public void configure() {
- ...
- Policy required = bean(SpringTransactionPolicy.class, "PROPAGATION_REQUIRED"));
- Policy requirenew = bean(SpringTransactionPolicy.class, "PROPAGATION_REQUIRES_NEW"));
- ...
-}
-----
-Once created, you can use the Policy objects in your processing routes:
-
-[source,java]
-----
- // Send to bar in a new transaction
-from("activemq:queue:foo").policy(requirenew).to("activemq:queue:bar");
-// Send to bar without a transaction.
-from("activemq:queue:foo").policy(notsupported).to("activemq:queue:bar");
-----
-
-=== OSGi Blueprint
-
-If you are using xref:using-osgi-blueprint-with-camel.adoc[OSGi
-Blueprint] then you most likely have to explicit declare a policy and
-refer to the policy from the transacted in the route.
-
-[source,xml]
---------------------------------------------------------
-<bean id="required" class="org.apache.camel.spring.spi.SpringTransactionPolicy">
- <property name="transactionManager" ref="jmsTransactionManager"/>
- <property name="propagationBehaviorName" value="PROPAGATION_REQUIRED"/>
-</bean>
---------------------------------------------------------
-
-And then refer to "required" from the route:
-
-[source,xml]
---------------------------------------------------------
-<route>
- <from uri="activemq:queue:foo"/>
- <transacted ref="required"/>
- <to uri="activemq:queue:bar"/>
-</route>
---------------------------------------------------------
-
-== Database Sample
-
-In this sample we want to ensure that two endpoints is under transaction
-control. These two endpoints inserts data into a database. +
-The sample is in its full as a
-https://github.com/apache/camel/blob/master/components/camel-spring/src/test/java/org/apache/camel/spring/interceptor/TransactionalClientDataSourceMinimalConfigurationTest.java[unit
-test].
-
-First of all we setup the usual spring stuff in its configuration file.
-Here we have defined a DataSource to the HSQLDB and a most
-importantly the Spring DataSource TransactionManager that is doing the
-heavy lifting of ensuring our transactional policies. You are of course
-free to use any of the Spring based TransactionManager, eg. if you are
-in a full blown J2EE container you could use JTA or the WebLogic or
-WebSphere specific managers.
-
-As we use the new convention over configuration we do *not* need to
-configure a transaction policy bean, so we do not have any
-`PROPAGATION_REQUIRED` beans. All the beans needed to be configured is
-*standard* Spring beans only, eg. there are no Camel specific
-configuration at
-all.https://github.com/apache/camel/blob/master/components/camel-spring/src/test/resources/org/apache/camel/spring/interceptor/springTransactionalClientDataSourceMinimalConfiguration.xml[springTransactionalClientDataSourceMinimalConfiguration]Then
-we are ready to define our Camel routes. We have two routes: 1 for
-success conditions, and 1 for a forced rollback condition. +
-This is after all based on a unit test. Notice that we mark each route
-as transacted using the *transacted*
-tag.https://github.com/apache/camel/blob/master/components/camel-spring/src/test/resources/org/apache/camel/spring/interceptor/springTransactionalClientDataSourceMinimalConfiguration.xml[springTransactionalClientDataSourceMinimalConfiguration]That
-is all that is needed to configure a Camel route as being transacted.
-Just remember to use the *transacted* DSL. The rest is standard Spring
-XML to setup the transaction manager.
-
-== JMS Sample
-
-In this sample we want to listen for messages on a queue and process the
-messages with our business logic java code and send them along. Since
-its based on a https://github.com/apache/camel/blob/master/components/camel-jms/src/test/java/org/apache/camel/component/jms/tx/TransactionMinimalConfigurationTest.java[TransactionMinimalConfigurationTest.java] the destination is a mock endpoint.
-
-First we configure the standard Spring XML to declare a JMS connection
-factory, a JMS transaction manager and our ActiveMQ component that we
-use in our
-routing.https://github.com/apache/camel/blob/master/components/camel-jms/src/test/resources/org/apache/camel/component/jms/tx/TransactionMinimalConfigurationTest.xml[TransactionMinimalConfigurationTest.xml]And
-then we configure our routes. Notice that all we have to do is mark the
-route as transacted using the *transacted*
-tag.https://github.com/apache/camel/blob/master/components/camel-jms/src/test/resources/org/apache/camel/component/jms/tx/TransactionMinimalConfigurationTest.xml[TransactionMinimalConfigurationTest.xml]
-
-Transaction error handler
-
-When a route is marked as transacted using *transacted* Camel will
-automatic use the
-xref:transactionerrorhandler.adoc[TransactionErrorHandler] as
-xref:error-handler.adoc[Error Handler]. It supports basically the same
-feature set as the xref:defaulterrorhandler.adoc[DefaultErrorHandler],
-so you can for instance use xref:exception-clause.adoc[Exception Clause]
-as well.
-
-== Integration Testing with Spring
-
-An Integration Test here means a test runner class annotated
-`@RunWith(SpringJUnit4ClassRunner.class).`
-
-When following the Spring Transactions documentation it is tempting to
-annotate your integration test with `@Transactional` then seed your
-database before firing up the route to be tested and sending a message
-in. This is incorrect as Spring will have an in-progress transaction,
-and Camel will wait on this before proceeding, leading to the route
-timing out.
-
-Instead, remove the `@Transactional` annotation from the test method and
-seed the test data within a `TransactionTemplate` execution which will
-ensure the data is committed to the database before Camel attempts to
-pick up and use the transaction manager. A simple
-example https://github.com/rajivj2/example2/blob/master/src/test/java/com/example/NotificationRouterIT.java[can
-be found on GitHub].
-
-Spring's transactional model ensures each transaction is bound to one
-thread. A Camel route may invoke additional threads which is where the
-blockage may occur. This is not a fault of Camel but as the programmer
-you must be aware of the consequences of beginning a transaction in a
-test thread and expecting a separate thread created by your Camel route
-to be participate, which it cannot. You can, in your test, mock the
-parts that cause separate threads to avoid this issue.
-
-== Using multiple routes with different propagation behaviors
-
-Suppose you want to route a message through two routes and by which the
-2nd route should run in its own transaction. How do you do that? You use
-propagation behaviors for that where you configure it as follows:
-
-* The first route use `PROPAGATION_REQUIRED`
-* The second route use `PROPAGATION_REQUIRES_NEW`
-
-This is configured in the Spring XML
-file.https://github.com/apache/camel/blob/master/components/camel-spring/src/test/resources/org/apache/camel/spring/interceptor/MixedTransactionPropagationTest.xml[MixedTransactionPropagationTest.xml]Then
-in the routes you use transacted DSL to indicate which of these two
-propagations it
-uses.https://github.com/apache/camel/blob/master/components/camel-spring/src/test/java/org/apache/camel/spring/interceptor/MixedTransactionPropagationTest.java[MixedTransactionPropagationTest.java]Notice
-how we have configured the `onException` in the 2nd route to indicate in
-case of any exceptions we should handle it and just rollback this
-transaction. This is done using the `markRollbackOnlyLast` which tells
-Camel to only do it for the current transaction and not globally.
-
diff --git a/docs/user-manual/modules/ROOT/pages/roundRobin-eip.adoc b/docs/user-manual/modules/ROOT/pages/roundRobin-eip.adoc
deleted file mode 100644
index c988416..0000000
--- a/docs/user-manual/modules/ROOT/pages/roundRobin-eip.adoc
+++ /dev/null
@@ -1,36 +0,0 @@
-[[roundRobin-eip]]
-= Round Robin EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/roundRobin-eip.adoc
-
-Round Robin Load Balancer. With this Load Balancing policy, a random endpoint is selected for each exchange.
-
-== Options
-
-// eip options: START
-The Round Robin EIP has no options.
-// eip options: END
-
-== Examples
-
-In this case we are using the header test as correlation expression:
-
-[source,java]
-----
-from("direct:start")
- .loadBalance()
- .roundRobin()
- .to("seda:x", "seda:y", "seda:z");
-----
-
-In XML you'll have a route like this
-
-[source,xml]
-----
-<from uri="direct:start"/>
- <loadBalance>
- <roundRobin/>
- <to uri="seda:x"/>
- <to uri="seda:y"/>
- <to uri="seda:z"/>
- </loadBalance>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/routingSlip-eip.adoc b/docs/user-manual/modules/ROOT/pages/routingSlip-eip.adoc
deleted file mode 100644
index ca4e70d..0000000
--- a/docs/user-manual/modules/ROOT/pages/routingSlip-eip.adoc
+++ /dev/null
@@ -1,113 +0,0 @@
-[[routingSlip-eip]]
-= Routing Slip EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/routingSlip-eip.adoc
-The Routing Slip from the https://camel.apache.org/enterprise-integration-patterns.html[EIP patterns] allows you to route a message consecutively through a series of processing steps where the sequence of steps is not known at design time and can vary for each message.
-
-image::eip/RoutingTableSimple.gif[image]
-
-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 Routing Slip 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
-
-== Example
-The following route will take any messages sent to the Apache ActiveMQ queue SomeQueue and pass them into the Routing Slip pattern.
-
-[source,java]
----------------------
-from("activemq:SomeQueue")
- .routingSlip("aRoutingSlipHeader");
----------------------
-
-Messages will be checked for the existence of the `aRoutingSlipHeader` header.
-The value of this header should be a comma-delimited list of endpoint URIs you wish the message to be routed to.
-The Message will be routed in a pipeline fashion, i.e., one after the other. The Routing Slip sets 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.
-
-The Routing Slip will compute the slip *beforehand* which means, the slip is only computed once. If you need to compute the slip _on-the-fly_ then use the Dynamic Router pattern instead.
-
-== Configuration Options
-Here we set the header name and the URI delimiter to something different.
-
-#=== Using the Fluent Builders
-[source,java]
----------------------
-from("direct:c").routingSlip(header("aRoutingSlipHeader"), "#");
----------------------
-
-#=== Using the Spring XML Extensions
-
-[source,xml]
----------------------
-<camelContext id="buildRoutingSlip" xmlns="http://activemq.apache.org/camel/schema/spring">
- <route>
- <from uri="direct:c"/>
- <routingSlip uriDelimiter="#">
- <header>aRoutingSlipHeader</header>
- </routingSlip>
- </route>
-</camelContext>
----------------------
-
-== Ignore Invalid Endpoints
-
-The Routing Slip supports ignoreInvalidEndpoints which the Recipient List also supports. You can use it to skip endpoints which are invalid.
-[source,java]
----------------------
-from("direct:a")
- .routingSlip("myHeader")
- .ignoreInvalidEndpoints();
----------------------
-
-And in Spring XML its an attribute on the recipient list tag:
-
-[source,xml]
----------------------
-<route>
- <from uri="direct:a"/>
- <routingSlip ignoreInvalidEndpoints="true"/>
- <header>myHeader</header>
- </routingSlip>
-</route>
----------------------
-
-Then let's say the myHeader contains the following two endpoints direct:foo,xxx:bar. The first endpoint is valid and works. However the second endpoint is invalid and will just be ignored. Camel logs at INFO level, so you can see why the endpoint was invalid.
-
-== Expression Support
-
-The Routing Slip supports to take the expression parameter as the Recipient List does. You can tell Camel the expression that you want to use to get the routing slip.
-
-[source,java]
----------------------
-from("direct:a")
- .routingSlip(header("myHeader"))
- .ignoreInvalidEndpoints();
----------------------
-
-And in Spring XML its an attribute on the recipient list tag.
-[source,xml]
----------------------
-<route>
- <from uri="direct:a"/>
- <!--NOTE from Camel 2.4.0, you need to specify the expression element inside of the routingSlip element -->
- <routingSlip ignoreInvalidEndpoints="true">
- <header>myHeader</header>
- </routingSlip>
-</route>
----------------------
-
-== Further Examples
-For further examples of this pattern in use you could look at the routing slip test cases.
-
-== Using This Pattern
-If you would like to use this EIP Pattern then please read the Getting Started, you may also find the Architecture useful particularly the description of Endpoint and URIs. Then you could try out some of the Examples first before trying this pattern out.
diff --git a/docs/user-manual/modules/ROOT/pages/saga-eip.adoc b/docs/user-manual/modules/ROOT/pages/saga-eip.adoc
deleted file mode 100644
index 2a2d6cf..0000000
--- a/docs/user-manual/modules/ROOT/pages/saga-eip.adoc
+++ /dev/null
@@ -1,455 +0,0 @@
-[[saga-eip]]
-= Saga EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/saga-eip.adoc
-
-The Saga EIP provides a way to define a series of related actions in a Camel route that should be either completed successfully (*all of them*) or not-executed/compensated.
-Sagas implementations are able to coordinate *distributed services communicating using any transport* towards a globally *consistent outcome*.
-
-Although their main purpose is similar, Sagas are different from classical ACID distributed (XA) transactions because the status of the different participating services is guaranteed to be consistent
-only at the end of the Saga and not in any intermediate step (lack of isolation).
-
-Conversely, Sagas are suitable for many use cases where usage of distributed transactions is discouraged.
-For example, services participating in a Saga are allowed to use any kind of datastore: classical databases or even NoSQL non-transactional datastores.
-Sagas are also suitable for being used in stateless cloud services as they do not require a transaction log
-to be stored alongside the service.
-
-Differently from transactions, Sagas are also not required to be completed in a small amount of time, because they don't use database-level locks. They can live for a longer timespan: from few seconds to several days.
-The Saga EIP implementation based on the Microprofile sandbox spec (see camel-lra) is indeed called LRA that stands for "Long Running Action".
-It also supports coordination of external *heterogeneous services*, written with any language/technology and also running outside a JVM.
-
-Sagas don't use locks on data, instead they define the concept of "Compensating Action" that is an action that should be executed when the standard flow encounters an error,
-with the purpose of restoring the status that was present before the flow execution.
-Compensating actions can be declared in Camel routes using the Java or XML DSL and will be invoked by Camel only when needed (if the saga is cancelled due to an error).
-
-// eip options: START
-The Saga EIP supports 6 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *propagation* | Set the Saga propagation mode (REQUIRED, REQUIRES_NEW, MANDATORY, SUPPORTS, NOT_SUPPORTED, NEVER). | REQUIRED | SagaPropagation
-| *completionMode* | Determine how the saga should be considered complete. When set to AUTO, the saga is completed when the exchange that initiates the saga is processed successfully, or compensated when it completes exceptionally. When set to MANUAL, the user must complete or compensate the saga using the saga:complete or saga:compensate endpoints. | AUTO | SagaCompletionMode
-| *timeoutInMilliseconds* | Set the maximum amount of time for the Saga. After the timeout is expired, the saga will be compensated automatically (unless a different decision has been taken in the meantime). | | Long
-| *compensation* | The compensation endpoint URI that must be called to compensate all changes done in the route. The route corresponding to the compensation URI must perform compensation and complete without error. If errors occur during compensation, the saga service may call again the compensation URI to retry. | | SagaActionUri Definition
-| *completion* | The completion endpoint URI that will be called when the Saga is completed successfully. The route corresponding to the completion URI must perform completion tasks and terminate without error. If errors occur during completion, the saga service may call again the completion URI to retry. | | SagaActionUri Definition
-| *option* | Allows to save properties of the current exchange in order to re-use them in a compensation/completion callback route. Options are usually helpful e.g. to store and retrieve identifiers of objects that should be deleted in compensating actions. Option values will be transformed into input headers of the compensation/completion exchange. | | List
-| *sagaServiceRef* | Refers to the id to lookup in the registry for the specific CamelSagaService to use. | | String
-|===
-// eip options: END
-
-== Exchange properties
-The following properties are set on each Exchange that is participating to a Saga (normal actions, compensating actions and completions):
-
-[width="100%",cols="4m,2m,5",options="header"]
-|===
-| Property | Type | Description
-| `Long-Running-Action` | `String` | A globally unique identifier for the Saga that can be propagated to remote systems using transport-level headers (e.g. HTTP).
-|===
-
-== Saga Service Configuration
-The Saga EIP requires that a service implementing the interface `org.apache.camel.saga.CamelSagaService` is added to the Camel context.
-
-Camel currently supports the following Saga Services:
-
-* *InMemorySagaService*: it is a *basic* implementation of the Saga EIP that does not support advanced features (no remote context propagation, no consistency guarantee in case of application failure).
-* *LRASagaService*: it is a *fully-fledged* implementation of the Saga EIP based on Microprofile sandbox LRA specification that supports remote context propagation and provides consistency guarantees in case of application failure.
-
-=== Using the In-Memory Saga Service
-
-The in-memory Saga service is not recommended for production environments as it does not support persistence of the Saga status (it is kept only in-memory),
-so it cannot guarantee consistency of Sagas in case of application failure (e.g. JVM crash).
-
-Also, when using a in-memory Saga service, Saga contexts cannot be propagated to remote services using transport-level headers (it can be done with other implementations).
-
-Users that want to use the in-memory saga service should add the following code to customize the Camel context.
-
-[source,java]
-----
-context.addService(new org.apache.camel.impl.saga.InMemorySagaService());
-----
-
-The service belongs to the `camel-core` module.
-
-=== Using the LRA Saga Service
-
-The LRA Saga Service is an implementation based on the Microprofile sandbox LRA specification.
-It leverages a *external Saga coordinator* to control the execution of the various steps of the Saga.
-The proposed reference implementation for the LRA specification is the http://jbossts.blogspot.it/2017/12/narayana-lra-implementation-of-saga.html[Narayana LRA Coordinator].
-Users can follows instructions present on the Narayana website to *startup a remote instance of the coordinator*.
-
-The URL of the LRA coordinator is a required parameter of the Camel LRA service. The Camel application and the LRA service communicate using the HTTP protocol.
-
-In order to use the LRA Saga service, maven users will need to add the following dependency to their pom.xml
-
-[source,xml]
-----
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-lra</artifactId>
- <!-- use the same version as your Camel core version -->
- <version>x.y.z</version>
-</dependency>
-----
-
-A Camel REST context is also required to be present for the LRA implementation to work. You may add `camel-undertow` for example.
-
-[source,xml]
-----
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-undertow</artifactId>
- <!-- use the same version as your Camel core version -->
- <version>x.y.z</version>
-</dependency>
-----
-
-[NOTE]
-====
-The LRA implementation of the Saga EIP will add some web endpoints under the "/lra-participant" path.
-Those endpoints will be used by the LRA coordinator for calling back the application.
-====
-
-[source,java]
-----
-// Configure the LRA saga service
-org.apache.camel.service.lra.LRASagaService sagaService = new org.apache.camel.service.lra.LRASagaService();
-sagaService.setCoordinatorUrl("http://lra-service-host");
-sagaService.setLocalParticipantUrl("http://my-host-as-seen-by-lra-service:8080/context-path");
-
-// Add it to the Camel context
-context.addService(sagaService);
-----
-
-==== Using the LRA Saga Service in Spring Boot
-
-Spring Boot users can use a simplified configuration model for the LRA Saga Service. Maven users can
-include the *camel-lra-starter* module in their project:
-
-[source,xml]
-----
-<dependency>
- <groupId>org.apache.camel.springboot</groupId>
- <artifactId>camel-lra-starter</artifactId>
- <!-- use the same version as your Camel core version -->
- <version>x.y.z</version>
-</dependency>
-
-<dependency>
- <groupId>org.apache.camel.springboot</groupId>
- <artifactId>camel-undertow-starter</artifactId>
- <!-- use the same version as your Camel core version -->
- <version>x.y.z</version>
-</dependency>
-----
-
-Configuration can be done in the Spring Boot `application.yaml` file:
-
-.application.yaml
-[source,yaml]
-----
-camel:
- service:
- lra:
- enabled: true
- coordinator-url: http://lra-service-host
- local-participant-url: http://my-host-as-seen-by-lra-service:8080/context-path
-----
-
-Once done, the Saga EIP can be directly used inside Camel routes and it will use the LRA Saga Service under the hood.
-
-== Examples
-
-Suppose you want to place a new order and you have two distinct services in your system: one managing the orders and one managing the credit.
-Logically you can place a order if you have enough credit for it.
-
-With the Saga EIP you can model the _direct:buy_ route as a Saga composed of two distinct actions, one to create the order and one to take the credit.
-*Both actions must be executed, or none of them*: a order placed without credit can be considered a inconsistent outcome (as well as a payment without an order).
-
-[source,java]
-----
-from("direct:buy")
- .saga()
- .to("direct:newOrder")
- .to("direct:reserveCredit");
-----
-
-*That's it*. The buy action will not change for the rest of the examples. We'll just see different options that can be used to model the "New Order" and "Reserve Credit" actions in the following.
-
-[NOTE]
-====
-We have used a _direct_ endpoint to model the two actions since this example can be used with both implementations of the Saga service,
-but we could have used *http* or other kinds of endpoint with the LRA Saga service.
-====
-
-Both services called by the _direct:buy_ route can *participate to the Saga* and declare their compensating actions.
-
-[source,java]
-----
-from("direct:newOrder")
- .saga()
- .propagation(SagaPropagation.MANDATORY)
- .compensation("direct:cancelOrder")
- .transform().header(Exchange.SAGA_LONG_RUNNING_ACTION)
- .bean(orderManagerService, "newOrder")
- .log("Order ${body} created");
-----
-
-Here the propagation mode is set to _MANDATORY_ meaning that any exchange flowing in this route must be already part of a saga
-(and it is the case in this example, since the saga is created in the _direct:buy_ route).
-
-The _direct:newOrder_ route declares a compensating action that is called _direct:cancelOrder_, responsible for undoing the order in case the saga is cancelled.
-
-Each exchange always contains a `Exchange.SAGA_LONG_RUNNING_ACTION` header that here is used as id of the order.
-This is done in order to identify the order to delete in the corresponding compensating action, but it is not a requirement (options can be used as alternative solution).
-
-The compensating action of _direct:newOrder_ is _direct:cancelOrder_ and it's shown below:
-
-[source,java]
-----
-from("direct:cancelOrder")
- .transform().header(Exchange.SAGA_LONG_RUNNING_ACTION)
- .bean(orderManagerService, "cancelOrder")
- .log("Order ${body} cancelled");
-----
-
-It is called automatically by the Saga EIP implementation when the order should be cancelled.
-
-It should not terminate with error. In case an error is thrown in the _direct:cancelOrder_ route, the EIP implementation should
-periodically retry to execute the compensating action up to a certain limit.
-This means that *any compensating action must be idempotent*, so it should take into account that it may be triggered multiple times and should not fail in any case.
-
-If compensation cannot be done after all retries, a manual intervention process should be triggered by the Saga implementation.
-
-[NOTE]
-====
-It may happen that due to a delay in the execution of the _direct:newOrder_ route the Saga is cancelled by another party in the meantime (due to an error in a parallel route or a timeout at Saga level).
-
-So, when the compensating action _direct:cancelOrder_ is called, it may not find the Order record that should be cancelled.
-It is important, in order to guarantee full global consistency, that *any main action and its corresponding compensating action are commutative*,
-i.e. if compensation occurs before the main action it shoud have the same effect.
-
-Another possible approach, when using a commutative behavior is not possible,
-is to consistently fail in the compensating action until data produced by the main action is found (or the maximum number of retries is exhausted):
-this approach may work in many contexts, but it's *heuristic*.
-====
-
-The credit service may be implemented almost in the same way as the order service.
-
-[source,java]
-----
-// action
-from("direct:reserveCredit")
- .saga()
- .propagation(SagaPropagation.MANDATORY)
- .compensation("direct:refundCredit")
- .transform().header(Exchange.SAGA_LONG_RUNNING_ACTION)
- .bean(creditService, "reserveCredit")
- .log("Credit ${header.amount} reserved in action ${body}");
-
-// compensation
-from("direct:refundCredit")
- .transform().header(Exchange.SAGA_LONG_RUNNING_ACTION)
- .bean(creditService, "refundCredit")
- .log("Credit for action ${body} refunded");
-----
-
-Here the compensating action for a credit reservation is a refund.
-
-This completes the example. It can be run with both implementations of the Saga EIP, as it does not involve remote endpoints.
-
-Further options will be shown next.
-
-=== Handling Completion Events
-It is often required to do some processing when the Saga is completed. Compensation endpoints are invoked when something wrong happens and the Saga is cancelled.
-Equivalently, *completion endpoints* can be invoked to do further processing when the Saga is completed successfully.
-
-For example, in the order service above, we may need to know when the order is completed (and the credit reserved) to actually start preparing the order.
-We will not want to start to prepare the order if the payment is not done (unlike most modern CPUs that give you access to reserved memory before ensuring that you have rights to read it).
-
-This can be done easily with a modified version of the _direct:newOrder_ endpoint:
-
-
-[source,java]
-----
-from("direct:newOrder")
- .saga()
- .propagation(SagaPropagation.MANDATORY)
- .compensation("direct:cancelOrder")
- .completion("direct:completeOrder") // completion endpoint
- .transform().header(Exchange.SAGA_LONG_RUNNING_ACTION)
- .bean(orderManagerService, "newOrder")
- .log("Order ${body} created");
-
-// direct:cancelOrder is the same as in the previous example
-
-// called on successful completion
-from("direct:completeOrder")
- .transform().header(Exchange.SAGA_LONG_RUNNING_ACTION)
- .bean(orderManagerService, "findExternalId")
- .to("jms:prepareOrder")
- .log("Order ${body} sent for preparation");
-----
-
-When the Saga is completed, the order is sent to a JMS queue for preparation.
-
-Like compensating actions, also completion actions may be called multiple times by the Saga coordinator (especially in case of errors, like network errors).
-In this example, the service listening to the _prepareOrder_ JMS queue should be prepared to hold possible duplicates (see the Idempotent Consumer EIP for examples on how to handle duplicates).
-
-=== Using Custom Identifiers and Options
-The example shown so far use the `Exchange.SAGA_LONG_RUNNING_ACTION` as identifier for the resources (order and credit).
-This is not always a desired approach, as it may pollute the business logic and the data model.
-
-An alternative approach is to use Saga options to "register" custom identifiers.
-For example, the credit service may be refactored as follows:
-
-[source,java]
-----
-// action
-from("direct:reserveCredit")
- .bean(idService, "generateCustomId") // generate a custom Id and set it in the body
- .to("direct:creditReservation")
-
-// delegate action
-from("direct:creditReservation")
- .saga()
- .propagation(SagaPropagation.SUPPORTS)
- .option("CreditId", body()) // mark the current body as needed in the compensating action
- .compensation("direct:creditRefund")
- .bean(creditService, "reserveCredit")
- .log("Credit ${header.amount} reserved. Custom Id used is ${body}");
-
-// called only if the saga is cancelled
-from("direct:creditRefund")
- .transform(header("CreditId")) // retrieve the CreditId option from headers
- .bean(creditService, "refundCredit")
- .log("Credit for Custom Id ${body} refunded");
-----
-
-*Note how the previous listing is not using the `Exchange.SAGA_LONG_RUNNING_ACTION` header at all.*
-
-Since the _direct:creditReservation_ endpoint can be now called also from outside a Saga, the propagation mode can be set to *SUPPORTS*.
-
-*Multiple options* can be declared in a Saga route.
-
-=== Setting Timeouts
-Sagas are long running actions, but this does not mean that they should not have a bounded timeframe to execute.
-*Setting timeouts on Sagas is always a good practice* as it guarantees that a Saga does not remain stuck forever in the case of machine failure.
-
-[NOTE]
-====
-The Saga EIP implementation may have a default timeout set on all Sagas that don't specify it explicitly
-====
-
-When the timeout expires, the Saga EIP will decide to *cancel the Saga* (and compensate all participants), unless a different decision has been taken before.
-
-Timeouts can be set on Saga participants as follows:
-
-[source,java]
-----
-from("direct:newOrder")
- .saga()
- .timeout(1, TimeUnit.MINUTES) // newOrder requires that the saga is completed within 1 minute
- .propagation(SagaPropagation.MANDATORY)
- .compensation("direct:cancelOrder")
- .completion("direct:completeOrder")
- // ...
- .log("Order ${body} created");
-----
-
-All participants (e.g. credit service, order service) can set their own timeout. The minimum value of those timeouts is taken as timeout for the saga when they are composed together.
-
-A timeout can also be specified at saga level as follows:
-
-[source,java]
-----
-from("direct:buy")
- .saga()
- .timeout(5, TimeUnit.MINUTES) // timeout at saga level
- .to("direct:newOrder")
- .to("direct:reserveCredit");
-----
-
-=== Choosing Propagation
-In the examples above, we have used the _MANDATORY_ and _SUPPORTS_ propagation modes, but also the _REQUIRED_ propagation mode,
-that is the default propagation used when nothing else is specified.
-
-These propagation modes map 1:1 the equivalent modes used in transactional contexts. Here's a summary of their meaning:
-
-[width="100%",cols="2m,8",options="header"]
-|===
-| Propagation | Description
-| `REQUIRED` | Join the existing saga or create a new one if it does not exist.
-| `REQUIRES_NEW` | Always create a new saga. Suspend the old saga and resume it when the new one terminates.
-| `MANDATORY` | A saga must be already present. The existing saga is joined.
-| `SUPPORTS` | If a saga already exists, then join it.
-| `NOT_SUPPORTED` | If a saga already exists, it is suspended and resumed when the current block completes.
-| `NEVER` | The current block must never be invoked within a saga.
-|===
-
-=== Using Manual Completion (Advanced)
-When a Saga cannot be all executed in a synchronous way, but it requires e.g. communication with external services using asynchronous communication channels,
-the completion mode cannot be set to _AUTO_ (default), because the saga is not completed when the exchange that creates it is done.
-
-This is often the case for Sagas that have long execution times (hours, days). In these cases, the _MANUAL_ completion mode should be used.
-
-
-[source,java]
-----
-from("direct:mysaga")
- .saga()
- .completionMode(SagaCompletionMode.MANUAL)
- .completion("direct:finalize")
- .timeout(2, TimeUnit.HOURS)
- .to("seda:newOrder")
- .to("seda:reserveCredit");
-
-// Put here asynchronous processing for seda:newOrder and seda:reserveCredit
-// They will send asynchronous callbacks to seda:operationCompleted
-
-from("seda:operationCompleted") // an asynchronous callback
- .saga()
- .propagation(SagaPropagation.MANDATORY)
- .bean(controlService, "actionExecuted")
- .choice()
- .when(body().isEqualTo("ok"))
- .to("saga:complete") // complete the current saga manually (saga component)
- .end()
-
-// You can put here the direct:finalize endpoint to execute final actions
-----
-
-Setting the completion mode to _MANUAL_ means that the saga is not completed when the exchange is processed in the route _direct:mysaga_ but
-it will last longer (max duration is set to 2 hours).
-
-When both asynchronous actions are completed the saga is completed. The call to complete is done using the Camel Saga Component's _saga:complete_ endpoint.
-There's is a similar endpoint for manually compensating the Saga (_saga:compensate_).
-
-Apparently the addition of the saga markers do not add much value to the flow: it works also if you remove all Saga EIP configuration.
-But Sagas add a lot of value, since they guarantee that even in the presence of unexpected issues (servers crashing, messages are lost)
-there will always be a consistent outcome: order placed and credit reserved, or none of them changed.
-In particular, if the Saga is not completed within 2 hours, the compensation mechanism will take care of fixing the status.
-
-== XML Configuration
-
-Saga features are also available for users that want to use the XML configuration.
-
-The following snipped shows an example:
-
-[source,xml]
-----
-<route>
- <from uri="direct:start"/>
- <saga>
- <compensation uri="direct:compensation" />
- <completion uri="direct:completion" />
- <option optionName="myOptionKey">
- <constant>myOptionValue</constant>
- </option>
- <option optionName="myOptionKey2">
- <constant>myOptionValue2</constant>
- </option>
- </saga>
- <to uri="direct:action1" />
- <to uri="direct:action2" />
-</route>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/sample-eip.adoc b/docs/user-manual/modules/ROOT/pages/sample-eip.adoc
deleted file mode 100644
index 54a17df..0000000
--- a/docs/user-manual/modules/ROOT/pages/sample-eip.adoc
+++ /dev/null
@@ -1,85 +0,0 @@
-[[sample-eip]]
-= Sample EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/sample-eip.adoc
-
-A sampling throttler allows you to extract a sample of the exchanges from the traffic through a route. +
-It is configured with a sampling period during which only a single exchange is allowed to pass through. All other exchanges will be stopped.
-Will by default use a sample period of 1 seconds.
-
-== Options
-// eip options: START
-The Sample EIP supports 3 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *samplePeriod* | Sets the sample period during which only a single Exchange will pass through. | 1 | Long
-| *messageFrequency* | Sets the sample message count which only a single Exchange will pass through after this many received. | | Long
-| *units* | Sets the time units for the sample period, defaulting to seconds. | SECONDS | TimeUnit
-|===
-// eip options: END
-
-
-== Samples
-You use this EIP with the `sample` DSL as show in these samples.
-
-These samples also show how you can use the different syntax to configure the sampling period:
-
-[source,java]
-----
-from("direct:sample")
- .sample()
- .to("mock:result");
-
-from("direct:sample-configured")
- .sample(1, TimeUnit.SECONDS)
- .to("mock:result");
-
-from("direct:sample-configured-via-dsl")
- .sample().samplePeriod(1).timeUnits(TimeUnit.SECONDS)
- .to("mock:result");
-
-from("direct:sample-messageFrequency")
- .sample(10)
- .to("mock:result");
-
-from("direct:sample-messageFrequency-via-dsl")
- .sample().sampleMessageFrequency(5)
- .to("mock:result");
-----
-
-And the same example in Spring XML is:
-
-[source,xml]
-----
-<route>
- <from uri="direct:sample"/>
- <sample samplePeriod="1" units="seconds">
- <to uri="mock:result"/>
- </sample>
-</route>
-<route>
- <from uri="direct:sample-messageFrequency"/>
- <sample messageFrequency="10">
- <to uri="mock:result"/>
- </sample>
-</route>
-<route>
- <from uri="direct:sample-messageFrequency-via-dsl"/>
- <sample messageFrequency="5">
- <to uri="mock:result"/>
- </sample>
-</route>
-----
-
-And since it uses a default of 1 second you can omit this configuration in case you also want to use 1 second
-[source,xml]
-----
-<route>
- <from uri="direct:sample"/>
- <!-- will by default use 1 second period -->
- <sample>
- <to uri="mock:result"/>
- </sample>
-</route>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/script-eip.adoc b/docs/user-manual/modules/ROOT/pages/script-eip.adoc
deleted file mode 100644
index 4ee44f1..0000000
--- a/docs/user-manual/modules/ROOT/pages/script-eip.adoc
+++ /dev/null
@@ -1,76 +0,0 @@
-[[script-eip]]
-= Script EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/script-eip.adoc
-
-Is used to execute a script which does not change the message (by default).
-This is useful when you need to invoke some logic that are not in Java code such as JavaScript,
-Groovy or any of the other Languages. The message body is not changed (by default) however the scripting
-context has access to the current Exchange and can essentially change the message or headers directly.
-But the return value from the script is discarded and not used.
-If the return value should be used as a changed message body then use xref:message-translator.adoc[Message Translator] EIP instead.
-
-== Options
-
-// eip options: START
-The Script EIP has no options.
-// eip options: END
-
-== Samples
-The route below will read the file contents and validate them against a regular expression.
-
-[source,java]
-----
-from("file://inbox")
- .script().groovy("// some groovy code goes here")
- .to("bean:MyServiceBean.processLine");
-----
-
-And from XML its easy as well
-
-[source,xml]
-----
-<route>
- <from uri="file://inbox"/>
- <script>
- <groovy>// some groovy code goes here</groovy>
- </script>
- <beanRef ref="myServiceBean" method="processLine"/>
-</route>
-
-<bean id="myServiceBean" class="com.mycompany.MyServiceBean"/>
-----
-
-Mind that you can use _CDATA_ in XML if the groovy scrip uses `< >` etc
-
-[source,xml]
-----
-<route>
- <from uri="file://inbox"/>
- <script>
- <groovy><![CDATA[ some groovy script here that can be multiple lines and whatnot ]]></groovy>
- </script>
- <beanRef ref="myServiceBean" method="processLine"/>
-</route>
-
-<bean id="myServiceBean" class="com.mycompany.MyServiceBean"/>
-----
-
-== Using external script files
-You can refer to external script files instead of inlining the script.
-For example to load a groovy script from the classpath you need to prefix the value with `resource:` as shown:
-
-[source,xml]
-----
-<route>
- <from uri="file://inbox"/>
- <script>
- <groovy>resource:classpath:com/foo/myscript.groovy</groovy>
- </script>
- <beanRef ref="myServiceBean" method="processLine"/>
-</route>
-
-<bean id="myServiceBean" class="com.mycompany.MyServiceBean"/>
-----
-
-You can also refer to the script from the file system with `file:` instead of `classpath:`
-such as `file:/var/myscript.groovy`
diff --git a/docs/user-manual/modules/ROOT/pages/serviceCall-eip.adoc b/docs/user-manual/modules/ROOT/pages/serviceCall-eip.adoc
deleted file mode 100644
index 1444372..0000000
--- a/docs/user-manual/modules/ROOT/pages/serviceCall-eip.adoc
+++ /dev/null
@@ -1,619 +0,0 @@
-[[serviceCall-eip]]
-= Service Call EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/serviceCall-eip.adoc
-
-The Service Call EIP allows to call remote services in a distributed system.
-The service to call is looked up in a service registry of some sorts such as Kubernetes, Consul, Etcd, Zookeeper, DNS.
-The EIP separates the configuration of the service registry from the calling of the service.
-
-When calling a service you may just refer to the name of the service in the EIP as shown below:
-
-[source,java]
-----
-from("direct:start")
- .serviceCall("foo")
- .to("mock:result");
-----
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <serviceCall name="foo"/>
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-Camel will then:
-
-* search for a service call configuration from the Camel context and registry
-* lookup a service with the name ```foo``` from an external service registry
-* filter the servers
-* select the server to use
-* build a Camel URI using the chosen server info
-
-By default the Service Call EIP uses camel-http so assuming that the selected service instance runs on host ```myhost.com``` on port ```80```, the computed Camel URI will be:
-
-[source]
-----
-http:myhost.com:80
-----
-
-== Service Name to Camel URI Examples
-
-It is often needed to build more complex Camel URI which may include options or paths which is possible through different options:name: value
-
-The *service name* supports a limited uri like syntax, here some examples
-
-[width="100%",cols="25%a,75%a",options="header"]
-|===
-|Name |Resolution
-
-|foo | http://host:port
-|foo/path | http://host:port/path
-|foo/path?foo=bar | http://host:port/path?foo=bar
-|===
-
-[source,java]
-----
-from("direct:start")
- .serviceCall("foo/hello")
- .to("mock:result");
-----
-
-If you want to have more control over the uri construction, you can use the *uri* directive:
-
-[width="100%",cols="25%a,40%a,35%a",options="header"]
-|===
-|Name | URI | Resolution
-
-|foo | undertow:http://foo/hello | undertow:http://host:port/hello
-|foo | undertow:http://foo.host:foo.port/hello | undertow:http://host:port/hello
-|===
-
-[source,java]
-----
-from("direct:start")
- .serviceCall("foo", "undertow:http://foo/hello")
- .to("mock:result");
-----
-
-Advanced users can have full control over the uri construction through expressions:
-
-[source,java]
-----
-from("direct:start")
- .serviceCall()
- .name("foo")
- .expression()
- .simple("undertow:http://${header.CamelServiceCallServiceHost}:${header.CamelServiceCallServicePort}/hello");
-----
-
-== Options
-// eip options: START
-The Service Call EIP supports 14 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *name* | *Required* Sets the name of the service to use | | String
-| *uri* | The uri of the endpoint to send to. The uri can be dynamic computed using the org.apache.camel.language.simple.SimpleLanguage expression. | | String
-| *component* | The component to use. | http | String
-| *pattern* | Sets the optional ExchangePattern used to invoke this endpoint | | ExchangePattern
-| *configurationRef* | Refers to a ServiceCall configuration to use | | String
-| *serviceDiscoveryRef* | Sets a reference to a custom ServiceDiscovery to use. | | String
-| *serviceFilterRef* | Sets a reference to a custom ServiceFilter to use. | | String
-| *serviceChooserRef* | Sets a reference to a custom ServiceChooser to use. | | String
-| *loadBalancerRef* | Sets a reference to a custom ServiceLoadBalancer to use. | | String
-| *expressionRef* | Set a reference to a custom Expression to use. | | String
-| *serviceDiscovery Configuration* | *Required* Configures the ServiceDiscovery using the given configuration. | | ServiceCallService DiscoveryConfiguration
-| *serviceFilterConfiguration* | *Required* Configures the ServiceFilter using the given configuration. | | ServiceCallService FilterConfiguration
-| *loadBalancerConfiguration* | *Required* Configures the LoadBalancer using the given configuration. | | ServiceCallServiceLoad BalancerConfiguration
-| *expressionConfiguration* | *Required* Configures the Expression using the given configuration. | | ServiceCallExpression Configuration
-|===
-// eip options: END
-
-In addition to ref/binding configuration style you can leverage specific configuration DSL to customize specific options:
-
-== Static Service Discovery
-
-This service discovery implementation does not query any external services to find out the list of services associated to a named service but keep them in memory. Each service should be provided in the following form:
-
-[source]
-----
-[service@]host:port
-----
-
-[TIP]
-====
-The ``service`` part is used to discriminate against the services but if not provided it acts like a wildcard so each non named service will be returned whatever the service name is. This is useful if you have a single service so the service name is redundant.
-====
-
-[NOTE]
-====
-This implementation is provided by ``camel-core`` artifact.
-====
-
-Available options:
-
-[width="100%",cols="3,1m,6",options="header"]
-|===
-| Name | Java Type | Description
-| servers | String | A comma separated list of servers in the form: [service@]host:port,[service@]host2:port,[service@]host3:port
-|===
-
-[source,java]
-----
-from("direct:start")
- .serviceCall("foo")
- .staticServiceDiscovery()
- .servers("service1@host1:80,service1@host2:80")
- .servers("service2@host1:8080,service2@host2:8080,service2@host3:8080")
- .end()
- .to("mock:result");
-----
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <serviceCall name="foo">
- <staticServiceDiscovery>
- <servers>service1@host1:80,service1@host2:80</servers>
- <servers>service2@host1:8080,service2@host2:8080,service2@host3:8080</servers>
- </staticServiceDiscovery>
- </serviceCall
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-== Consul Service Discovery
-
-To leverage Consul for Service Discovery, maven users will need to add the following dependency to their pom.xml
-
-[source,xml]
-----
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-consul</artifactId>
- <!-- use the same version as your Camel core version -->
- <version>x.y.z</version>
-</dependency>
-----
-
-Available options:
-
-[width="100%",cols="3,1m,6",options="header"]
-|===
-| Name | Java Type | Description
-| url | String | The Consul agent URL
-| datacenter | String | The data center
-| aclToken | String | Sets the ACL token to be used with Consul
-| userName | String | Sets the username to be used for basic authentication
-| password | String | Sets the password to be used for basic authentication
-| connectTimeoutMillis | Long | Connect timeout for OkHttpClient
-| readTimeoutMillis | Long | Read timeout for OkHttpClient
-| writeTimeoutMillis | Long | Write timeout for OkHttpClient
-|===
-
-And example in Java
-
-[source,java]
-----
-from("direct:start")
- .serviceCall("foo")
- .consulServiceDiscovery()
- .url("http://consul-cluster:8500")
- .datacenter("neverland")
- .end()
- .to("mock:result");
-----
-
-== DNS Service Discovery
-
-To leverage DNS for Service Discovery, maven users will need to add the following dependency to their pom.xml
-
-[source,xml]
-----
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-dns</artifactId>
- <!-- use the same version as your Camel core version -->
- <version>x.y.z</version>
-</dependency>
-----
-
-Available options:
-
-[width="100%",cols="3,1m,6",options="header"]
-|===
-| Name | Java Type | Description
-| proto | String | The transport protocol of the desired service, default "_tcp"
-| domain | String | The user name to use for basic authentication
-|===
-
-Example in Java:
-
-[source,java]
-----
-from("direct:start")
- .serviceCall("foo")
- .dnsServiceDiscovery("my.domain.com")
- .to("mock:result");
-----
-
-And in XML:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <serviceCall name="foo">
- <dnsServiceDiscovery domain="my.domain.com"/>
- </serviceCall>
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-== Etcd Service Discovery
-
-To leverage Etcd for Service Discovery, maven users will need to add the following dependency to their pom.xml
-
-[source,xml]
-----
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-etcd</artifactId>
- <!-- use the same version as your Camel core version -->
- <version>x.y.z</version>
-</dependency>
-----
-
-Available options:
-
-[width="100%",cols="3,1m,6",options="header"]
-|===
-| Name | Java Type | Description
-| uris | String | The URIs the client can connect to
-| userName | String | The user name to use for basic authentication
-| password | String | The password to use for basic authentication
-| timeout | Long | To set the maximum time an action could take to complete
-| servicePath | String | The path to look for for service discovery, default "/services"
-| type | String | To set the discovery type, valid values are "on-demand" and "watch"
-|===
-
-Example in Java
-----
-from("direct:start")
- .serviceCall("foo")
- .etcdServiceDiscovery()
- .uris("http://etcd1:4001,http://etcd2:4001")
- .servicePath("/camel/services")
- .end()
- .to("mock:result");
-----
-
-And in XML
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <serviceCall name="foo">
- <etcdServiceDiscovery uris="http://etcd1:4001,http://etcd2:4001" servicePath="/camel/services"/>
- </serviceCall>
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-== Kubernetes Service Discovery
-
-To leverage Kubernetes for Service Discovery, maven users will need to add the following dependency to their pom.xml
-
-[source,xml]
-----
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-kubernetes</artifactId>
- <!-- use the same version as your Camel core version -->
- <version>x.y.z</version>
-</dependency>
-----
-
-Available options:
-
-[width="100%",cols="3,1m,6",options="header"]
-|===
-| Name | Java Type | Description
-| lookup | String | How to perform service lookup. Possible values: client, dns, environment
-| apiVersion | String | Kubernetes API version when using client lookup
-| caCertData | String | Sets the Certificate Authority data when using client lookup
-| caCertFile | String | Sets the Certificate Authority data that are loaded from the file when using client lookup
-| clientCertData | String | Sets the Client Certificate data when using client lookup
-| clientCertFile | String | Sets the Client Certificate data that are loaded from the file when using client lookup
-| clientKeyAlgo | String | Sets the Client Keystore algorithm, such as RSA when using client lookup
-| clientKeyData | String | Sets the Client Keystore data when using client lookup
-| clientKeyFile | String | Sets the Client Keystore data that are loaded from the file when using client lookup
-| clientKeyPassphrase | String | Sets the Client Keystore passphrase when using client lookup
-| dnsDomain | String | Sets the DNS domain to use for dns lookup
-| namespace | String | The Kubernetes namespace to use. By default the namespace's name is taken from the environment variable KUBERNETES_MASTER
-| oauthToken | String | Sets the OAUTH token for authentication (instead of username/password) when using client lookup
-| username | String | Sets the username for authentication when using client lookup
-| password | String | Sets the password for authentication when using client lookup
-| trustCerts | Boolean | Sets whether to turn on trust certificate check when using client lookup
-|===
-
-Example in Java
-[source,java]
-----
-from("direct:start")
- .serviceCall("foo")
- .kubernetesServiceDiscovery()
- .lookup("dns")
- .namespace("myNamespace")
- .dnsDomain("my.domain.com")
- .end()
- .to("mock:result");
-----
-
-And in XML
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <serviceCall name="foo">
- <kubernetesServiceDiscovery lookup="dns" namespace="myNamespace" dnsDomain="my.domain.com"/>
- </serviceCall>
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-== Blacklist Service Filter
-
-This service filter implementation removes the listed services from those found by the service discovery.
-Each service should be provided in the following form:
-
-[source]
-----
-[service@]host:port
-----
-
-[NOTE]
-====
-The services are removed if they fully match
-====
-
-Available options:
-
-[width="100%",cols="3,1m,6",options="header"]
-|===
-| Name | Java Type | Description
-| servers | String | A comma separated list of servers to blacklist: [service@]host:port,[service@]host2:port,[service@]host3:port
-|===
-
-Example in Java
-[source,java]
-----
-from("direct:start")
- .serviceCall("foo")
- .staticServiceDiscovery()
- .servers("service1@host1:80,service1@host2:80")
- .servers("service2@host1:8080,service2@host2:8080,service2@host3:8080")
- .end()
- .blacklistFilter()
- .servers("service2@host2:8080")
- .end()
- .to("mock:result");
-----
-
-And in XML
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <serviceCall name="foo">
- <staticServiceDiscovery>
- <servers>service1@host1:80,service1@host2:80</servers>
- <servers>service2@host1:8080,service2@host2:8080,service2@host3:8080</servers>
- </staticServiceDiscovery>
- <blacklistServiceFilter>
- <servers>service2@host2:8080</servers>
- </blacklistServiceFilter>
- </serviceCall
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-== Load Balancer
-
-The Service Call EIP comes with its own Load Balancer which is istantiated by default if a custom is not configured and
-glues Service Discovery, Service Filer, Service Chooser and Service Expression together to load balance requests among the available services.
-
-If you need a more sophisticate load balancer you can use Ribbon by adding camel-ribbon to the mix,
-maven users will need to add the following dependency to their pom.xml
-
-[source,xml]
-----
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-ribbon</artifactId>
- <!-- use the same version as your Camel core version -->
- <version>x.y.z</version>
-</dependency>
-----
-
-Available options:
-
-[width="100%",cols="3,1m,6",options="header"]
-|===
-| Name | Java Type | Description
-| clientName | String | The Ribbon client name
-| properties | List<PropertyDefinition> | Custom client config properties
-|===
-
-To leverage Ribbon, it is required to explicit enable it:
-
-Java example
-
-[source,java]
-----
-from("direct:start")
- .serviceCall("foo")
- .ribbonLoadBalancer()
- .to("mock:result");
-----
-
-And in XML
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <serviceCall name="foo">
- <ribbonLoadBalancer/>
- </serviceCall>
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-You can configure Ribbon key programmatic using `RibbonConfiguration`:
-
-[source,java]
-----
-RibbonConfiguration configuration = new RibbonConfiguration();
-configuration.addProperty("listOfServers", "localhost:9090,localhost:9091");
-
-from("direct:start")
- .serviceCall("foo")
- .loadBalancer(new RibbonServiceLoadBalancer(configuration))
- .to("mock:result");
-----
-
-Or leveraging XML specific configuration:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:start"/>
- <serviceCall name="foo">
- <ribbonLoadBalancer>
- <properties key="listOfServers" value="localhost:9090,localhost:9091"/>
- </ribbonLoadBalancer>
- </serviceCall>
- <to uri="mock:result"/>
- </route>
-</camelContext>
-----
-
-== Shared configurations
-
-The Service Call EIP can be configured straight on the route definition or through shared configurations,
-here an example with two configurations registered in the Camel Context:
-
-[source,java]
-----
-ServiceCallConfigurationDefinition globalConf = new ServiceCallConfigurationDefinition();
-globalConf.setServiceDiscovery(
- name -> Arrays.asList(
- new DefaultServiceDefinition(name, "my.host1.com", 8080),
- new DefaultServiceDefinition(name, "my.host2.com", 443))
-);
-globalConf.setServiceChooser(
- list -> list.get(ThreadLocalRandom.current().nextInt(list.size()))
-);
-
-ServiceCallConfigurationDefinition httpsConf = new ServiceCallConfigurationDefinition();
-httpsConf.setServiceFilter(
- list -> list.stream().filter(s -> s.getPort() == 443).collect(toList())
-);
-
-getContext().setServiceCallConfiguration(globalConf);
-getContext().addServiceCallConfiguration("https", httpsConf);
-----
-
-Each Service Call definition and configuration will inherit from the `globalConf` which can be seen as default configuration,
-then you can reference the `httpsConf` in your route as follow:
-
-[source,java]
-----
-from("direct:start")
- .serviceCall()
- .name("foo")
- .serviceCallConfiguration("https")
- .end()
- .to("mock:result");
-----
-
-This route will leverages the service discovery and service chooser from `globalConf` and the service filter from `httpsConf`
-but you can override any of them if needed straight on the route:
-
-[source,java]
-----
-from("direct:start")
- .serviceCall()
- .name("foo")
- .serviceCallConfiguration("https")
- .serviceChooser(list -> list.get(0))
- .end()
- .to("mock:result");
-----
-
-== Spring Boot support
-
-In a Spring-Boot application you can externalize most of the configuration options:
-
-[source,properties]
-.application.properties
-----
-# this can be configured stright tot he route and it has been included to show
-# property placeholders support
-service.name = foo
-
-# this property is not mandatory and it has been included to show how to configure
-# the service discovery implementation provided by camel-consul
-camel.cloud.consul.service-discovery.url = http://localhost:8500
-
-# Add a static list of servers for the service named foo
-camel.cloud.service-discovery.services[foo] = host1.static:8080,host2.static:8080
-----
-
-[source,java]
-.Routes
-----
-@Component
-public class MyRouteBuilder implements RouteBuilder {
- @Override
- public void configure() throws Exception {
- from("direct:start")
- .serviceCall("{{service.name}}");
- }
-}
-----
-
-== Spring Cloud support
-
-If you are using Camel in an application based on Spring Cloud, you can leverage Spring Cloud service discovery and load balancing capabilities by adding the Spring Cloud related dependencies (i.e. spring-cloud-consul, spring-cloud-kubernetes) as any Spring Boot/Cloud application in addition to Camel's own camel-spring-cloud dependency.
-
-[source,xml]
-----
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-spring-cloud dependency</artifactId>
- <!-- use the same version as your Camel core version -->
- <version>x.y.z</version>
-</dependency>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/setBody-eip.adoc b/docs/user-manual/modules/ROOT/pages/setBody-eip.adoc
deleted file mode 100644
index 12e789c..0000000
--- a/docs/user-manual/modules/ROOT/pages/setBody-eip.adoc
+++ /dev/null
@@ -1,40 +0,0 @@
-[[setBody-eip]]
-= Set Body EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/setBody-eip.adoc
-
-The SetBody EIP allows you to set the body of your exchange.
-
-== Options
-
-// eip options: START
-The Set Body EIP has no options.
-// eip options: END
-
-== Examples
-
-The following example shows how to use the SetBody EIP
-
-[source,java]
-----
-RouteBuilder builder = new RouteBuilder() {
- public void configure() {
- from("direct:a")
- .setBody(constant("test"))
- .to("direct:b");
- }
-};
-----
-
-
-And the same example using XML:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:a"/>
- <setBody><constant>test</constant></setBody>
- <to uri="direct:b"/>
- </route>
-</camelContext>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/setHeader-eip.adoc b/docs/user-manual/modules/ROOT/pages/setHeader-eip.adoc
deleted file mode 100644
index fdee774..0000000
--- a/docs/user-manual/modules/ROOT/pages/setHeader-eip.adoc
+++ /dev/null
@@ -1,48 +0,0 @@
-[[setHeader-eip]]
-= Set Header EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/setHeader-eip.adoc
-
-The SetHeader EIP allows you to set and header on your exchange.
-
-== Options
-
-// eip options: START
-The Set Header EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *name* | *Required* Name of message header to set a new value The simple language can be used to define a dynamic evaluated header name to be used. Otherwise a constant name will be used. | | String
-|===
-// eip options: END
-
-== Examples
-
-The following example shows how to use the SetHeader EIP
-
-[source,java]
-----
-RouteBuilder builder = new RouteBuilder() {
- public void configure() {
- from("direct:a")
- .setHeader("myHeader", constant("test"))
- .to("direct:b");
- }
-};
-----
-
-
-And the same example using XML:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:a"/>
- <setHeader name="myHeader">
- <constant>test</constant>
- </setHeader>
- <to uri="direct:b"/>
- </route>
-</camelContext>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/setOutHeader-eip.adoc b/docs/user-manual/modules/ROOT/pages/setOutHeader-eip.adoc
deleted file mode 100644
index afb1ad9..0000000
--- a/docs/user-manual/modules/ROOT/pages/setOutHeader-eip.adoc
+++ /dev/null
@@ -1,50 +0,0 @@
-[[setOutHeader-eip]]
-= Set Out Header EIP (deprecated)
-:page-source: core/camel-core-engine/src/main/docs/eips/setOutHeader-eip.adoc
-== Set Header EIP
-
-This EIP is deprecated.
-The SetOutHeader EIP allows you to set an header on the out message of your exchange.
-
-== Options
-
-// eip options: START
-The Set Out Header EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *headerName* | *Required* Name of message header to set a new value | | String
-|===
-// eip options: END
-
-== Examples
-
-The following example shows how to use the SetOutHeader EIP
-
-[source,java]
-----
-RouteBuilder builder = new RouteBuilder() {
- public void configure() {
- from("direct:a")
- .setOutHeader("myHeader", constant("test"))
- .to("direct:b");
- }
-};
-----
-
-
-And the same example using XML:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:a"/>
- <setOutHeader headerName="myHeader">
- <constant>test</constant>
- </setOutHeader>
- <to uri="direct:b"/>
- </route>
-</camelContext>
-----
\ No newline at end of file
diff --git a/docs/user-manual/modules/ROOT/pages/setProperty-eip.adoc b/docs/user-manual/modules/ROOT/pages/setProperty-eip.adoc
deleted file mode 100644
index b71a9a1..0000000
--- a/docs/user-manual/modules/ROOT/pages/setProperty-eip.adoc
+++ /dev/null
@@ -1,48 +0,0 @@
-[[setProperty-eip]]
-= Set Property EIP
-:page-source: core/camel-core-engine/src/main/docs/eips/setProperty-eip.adoc
-
-The SetProperty EIP allows you to set a property on your exchange.
-
-== Options
-
-// eip options: START
-The Set Property EIP supports 1 options which are listed below:
-
-[width="100%",cols="2,5,^1,2",options="header"]
-|===
-| Name | Description | Default | Type
-| *name* | *Required* Name of exchange property to set a new value. The simple language can be used to define a dynamic evaluated exchange property name to be used. Otherwise a constant name will be used. | | String
-|===
-// eip options: END
-
-== Examples
-
-The following example shows how to use the SetProperty EIP
-
-[source,java]
-----
-RouteBuilder builder = new RouteBuilder() {
- public void configure() {
- from("direct:a")
- .setProperty("myProperty", constant("test"))
- .to("direct:b");
- }
-};
-----
-
-
-And the same example using XML:
-
-[source,xml]
-----
-<camelContext xmlns="http://camel.apache.org/schema/spring">
- <route>
- <from uri="direct:a"/>
- <setProperty name="myProperty">
- <constant>test</constant>
- </setProperty>
- <to uri="direct:b"/>
- </route>
-</camelContext>
-----
diff --git a/docs/user-manual/modules/ROOT/pages/simple-language.adoc b/docs/user-manual/modules/ROOT/pages/simple-language.adoc
deleted file mode 100644
index c135562..0000000
--- a/docs/user-manual/modules/ROOT/pages/simple-language.adoc
+++ /dev/null
@@ -1,885 +0,0 @@
-[[simple-language]]
-= Simple Language
-:page-source: core/camel-core-languages/src/main/docs/simple-language.adoc
-
-*Since Camel 1.1*
-
-The Simple Expression Language was a really simple language when it was
-created, but has since grown more powerful. It is primarily intended for
-being a really small and simple language for evaluating
-Expressions and Predicates
-without requiring any new dependencies or knowledge of
-xref:components::xpath-language.adoc[XPath]; so it is ideal for testing in camel-core. The
-idea was to cover 95% of the common use cases when you need a little bit
-of expression based script in your Camel routes.
-
-However for much more complex use cases you are generally recommended to
-choose a more expressive and powerful language such as:
-
-* xref:components::groovy-language.adoc[Groovy]
-* xref:components::spel-language.adoc[SpEL]
-* xref:components::mvel-component.adoc[MVEL]
-* xref:components::ognl-language.adoc[OGNL]
-
-The simple language uses `${body`} placeholders for complex expressions
-where the expression contains constant literals. The $\{ } placeholders
-can be omitted if the expression is only the token itself.
-
-[TIP]
-====
-*Alternative syntax*
-
-You can also use the alternative syntax which
-uses `$simple{ }` as placeholders. This can be used in situations to avoid clashes when using for example
-Spring property placeholder together with Camel.
-====
-
-== Simple Language options
-
-// language options: START
-The Simple language supports 2 options, which are listed below.
-
-
-
-[width="100%",cols="2,1m,1m,6",options="header"]
-|===
-| Name | Default | Java Type | Description
-| resultType | | String | Sets the class name of the result type (type from output)
-| trim | true | Boolean | Whether to trim the value to remove leading and trailing whitespaces and line breaks
-|===
-// language options: END
-
-== Variables
-
-[width="100%",cols="10%,10%,80%",options="header",]
-|=======================================================================
-|Variable |Type |Description
-
-|camelId |String |the CamelContext name
-
-|camelContext.*OGNL* |Object |the CamelContext invoked using a Camel OGNL expression.
-
-|exchange |Exchange |the Exchange
-
-|exchange.*OGNL* |Object |the Exchange invoked using a Camel
-OGNL expression.
-
-|exchangeId |String |the exchange id
-
-|id |String |the input message id
-
-|body |Object |the input body
-
-|in.body |Object |*deprecated* the input body
-
-|body.*OGNL* |Object |the input body invoked using a Camel OGNL expression.
-
-|in.body.*OGNL* |Object |*deprecated* the input body invoked using a Camel OGNL expression.
-
-|bodyAs(_type_) |Type |Converts the body to the given type determined by its
-classname. The converted body can be null.
-
-|bodyAs(_type_).*OGNL* |Object |Converts the body to the given type determined by its
-classname and then invoke methods using a Camel OGNL expression. The
-converted body can be null.
-
-|bodyOneLine | String | Converts the body to a String and removes all line-breaks so the string is in one line.
-
-|mandatoryBodyAs(_type_) |Type |Converts the body to the given type determined by its
-classname, and expects the body to be not null.
-
-|mandatoryBodyAs(_type_).*OGNL* |Object |Converts the body to the given type determined by its
-classname and then invoke methods using a Camel OGNL expression.
-
-|header.foo |Object |refer to the input foo header
-
-|header:foo |Object |refer to the input foo header
-
-|header[foo] |Object |refer to the input foo header
-
-|headers.foo |Object |refer to the input foo header
-
-|headers:foo |Object |refer to the input foo header
-
-|headers[foo] |Object |refer to the input foo header
-
-|in.header.foo |Object |*deprecated* refer to the input foo header
-
-|in.header:foo |Object |*deprecated* refer to the input foo header
-
-|in.header[foo] |Object |*deprecated* refer to the input foo header
-
-|in.headers.foo |Object |*deprecated* refer to the input foo header
-
-|in.headers:foo |Object |*deprecated* refer to the input foo header
-
-|in.headers[foo] |Object |*deprecated* refer to the input foo header
-
-|header.foo[bar] |Object |regard input foo header as a map and perform lookup on the
-map with bar as key
-
-|in.header.foo[bar] |Object |*deprecated* regard input foo header as a map and perform lookup on the
-map with bar as key
-
-|in.headers.foo[bar] |Object |*deprecated* regard input foo header as a map and perform lookup on the
-map with bar as key
-
-|header.foo.*OGNL* |Object |refer to the input foo header and invoke its value using a
-Camel OGNL expression.
-
-|in.header.foo.*OGNL* |Object |*deprecated* refer to the input foo header and invoke its value using a
-Camel OGNL expression.
-
-|in.headers.foo.*OGNL* |Object |*deprecated* refer to the input foo header and invoke its value using a
-Camel OGNL expression.
-
-|headerAs(_key_,_type_) |Type |converts the header to the given type determined by its
-classname
-
-|headers |Map |refer to the input headers
-
-|in.headers |Map |*deprecated* refer to the input headers
-
-|exchangeProperty.foo |Object |refer to the foo property on the exchange
-
-|exchangeProperty[foo] |Object |refer to the foo property on the exchange
-
-|exchangeProperty.foo.*OGNL* |Object |refer to the foo property on the exchange and invoke its
-value using a Camel OGNL expression.
-
-|sys.foo |String |refer to the JVM system property
-
-|sysenv.foo |String |refer to the system environment variable
-
-|env.foo |String |refer to the system environment variable
-
-|exception |Object |refer to the exception object on the exchange, is *null* if
-no exception set on exchange. Will fallback and grab caught exceptions
-(`Exchange.EXCEPTION_CAUGHT`) if the Exchange has any.
-
... 2802 lines suppressed ...