You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by or...@apache.org on 2024/02/26 12:53:48 UTC
(camel) branch main updated (b5c9a0f4b5e -> 9eac735265f)
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a change to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
from b5c9a0f4b5e CAMEL-18858: camel-core - Mark route as created by Kamelet so we know this, so we can filter out in tooling and whereelse (kamelet is a blackbox)
new 3b964274406 CAMEL-20459: documentation fixes for the splitter EIP.
new 37adb2ee46c CAMEL-20459: documentation fixes for the step EIP.
new 7bb1d9dcdd1 CAMEL-20459: documentation fixes for the sticky EIP.
new 181c5dd9307 CAMEL-20459: documentation fixes for the stop EIP.
new de8b122591d CAMEL-20459: documentation fixes for the threads EIP.
new ac36bbc61d9 CAMEL-20459: documentation fixes for the throttle EIP.
new 867b4a36539 CAMEL-20459: documentation fixes for the to EIP.
new bbd4ea28d33 CAMEL-20459: documentation fixes for the toD EIP.
new 5780e44c98e CAMEL-20459: documentation fixes for the topic EIP.
new 2f1f758462d CAMEL-20459: documentation fixes for the transform EIP.
new 092bbfe8ba6 CAMEL-20459: documentation fixes for the unmarshal EIP.
new b831dbf8a4a CAMEL-20459: documentation fixes for the validate EIP.
new 8eb591a1fcf CAMEL-20459: documentation fixes for the weighted EIP.
new 9eac735265f CAMEL-20459: documentation fixes for the wireTap EIP.
The 14 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
.../main/docs/modules/eips/pages/split-eip.adoc | 86 +++++++++++-----------
.../src/main/docs/modules/eips/pages/step-eip.adoc | 8 +-
.../main/docs/modules/eips/pages/sticky-eip.adoc | 4 +-
.../src/main/docs/modules/eips/pages/stop-eip.adoc | 4 +-
.../main/docs/modules/eips/pages/threads-eip.adoc | 10 +--
.../main/docs/modules/eips/pages/throttle-eip.adoc | 16 ++--
.../src/main/docs/modules/eips/pages/to-eip.adoc | 6 +-
.../src/main/docs/modules/eips/pages/toD-eip.adoc | 56 +++++++-------
.../main/docs/modules/eips/pages/topic-eip.adoc | 15 +++-
.../docs/modules/eips/pages/transform-eip.adoc | 4 +-
.../docs/modules/eips/pages/unmarshal-eip.adoc | 17 +++--
.../main/docs/modules/eips/pages/validate-eip.adoc | 4 +-
.../main/docs/modules/eips/pages/weighted-eip.adoc | 18 +++--
.../main/docs/modules/eips/pages/wireTap-eip.adoc | 15 ++--
14 files changed, 143 insertions(+), 120 deletions(-)
(camel) 10/14: CAMEL-20459: documentation fixes for the transform EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 2f1f758462d9a3eea21e9724ae52e15a490c5197
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 13:08:59 2024 +0100
CAMEL-20459: documentation fixes for the transform EIP.
---
.../src/main/docs/modules/eips/pages/transform-eip.adoc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/transform-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/transform-eip.adoc
index 5067c5d86b6..d3b01d11284 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/transform-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/transform-eip.adoc
@@ -45,7 +45,7 @@ include::partial$eip-exchangeProperties.adoc[]
You can use a xref:transform-eip.adoc[Transform] which uses an
xref:manual::expression.adoc[Expression] to do the transformation:
-In the example below we prepend Hello to the message body using the
+In the example below, we prepend Hello to the message body using the
xref:components:languages:simple-language.adoc[Simple] language:
[tabs]
@@ -130,7 +130,7 @@ The given data type may reference a xref:manual::transformer.adoc[Transformer] t
Users may also specify `fromType` in order to reference a very specific transformation from a given data type to a given data type.
-== What is the difference between Transform and Set Body
+== What is the difference between Transform and Set Body?
The Transform EIP always sets the result on the OUT message body.
(camel) 13/14: CAMEL-20459: documentation fixes for the weighted EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 8eb591a1fcfc7ba2127669d09e37225a1b579c30
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 13:11:58 2024 +0100
CAMEL-20459: documentation fixes for the weighted EIP.
---
.../src/main/docs/modules/eips/pages/weighted-eip.adoc | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/weighted-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/weighted-eip.adoc
index 013d324203a..3c9510f165c 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/weighted-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/weighted-eip.adoc
@@ -7,7 +7,7 @@
:tabs-sync-option:
Weighted mode for xref:loadBalance-eip.adoc[Load Balancer] EIP.
-With this policy in case of failures the exchange will be tried on the next endpoint.
+With this policy in case of failures, the exchange will be tried on the next endpoint.
== Options
@@ -23,11 +23,16 @@ include::partial$eip-exchangeProperties.adoc[]
== Examples
-In this example we want to send the most message to the first endpoint, then the second, and only a few to the last.
+In this example, we want to send the most message to the first endpoint, then the second, and only a few to the last.
-The distribution ratio is 7 = 4 + 2 + 1.
-This means that for every 7 message then 4 goes to the 1st, 2 for the 2nd, and 1 for the last.
+The distribution ratio is `7 = 4 + 2 + 1`.
+This means that for every seventh message then 4 goes to the first, 2 for the second, and 1 for the last.
+[tabs]
+====
+
+Java::
++
[source,java]
----
from("direct:start")
@@ -38,8 +43,8 @@ from("direct:start")
.end();
----
-In XML you'll have a route like this:
-
+XML::
++
[source,xml]
----
<route>
@@ -52,3 +57,4 @@ In XML you'll have a route like this:
</loadBalance>
</route>
----
+====
\ No newline at end of file
(camel) 05/14: CAMEL-20459: documentation fixes for the threads EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit de8b122591de708b995ac0db7861d666a7379ecc
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 12:59:43 2024 +0100
CAMEL-20459: documentation fixes for the threads EIP.
---
.../src/main/docs/modules/eips/pages/threads-eip.adoc | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/threads-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/threads-eip.adoc
index 729e1d5c256..c3e82c3b9a8 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/threads-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/threads-eip.adoc
@@ -12,7 +12,7 @@ image::eip/MessagingAdapterIcon.gif[image]
Submit the message to a thread pool, which then is responsible for the continued routing of the message.
-In Camel this is implemented as the Threads EIP.
+In Camel, this is implemented as the Threads EIP.
== Options
@@ -28,7 +28,7 @@ include::partial$eip-exchangeProperties.adoc[]
== Using Threads EIP
-The example below will add a Thread pool with a pool size of 5 threads before sending to mock:result.
+The example below will add a Thread pool with a pool size of five threads before sending to `mock:result`.
[tabs]
====
@@ -124,13 +124,13 @@ IMPORTANT: The reject policy options `Discard` and `DiscardOldest` is deprecated
=== Default values
The Threads EIP uses the default values from the default xref:manual:ROOT:threading-model.adoc[Thread Pool Profile].
-If the profile has not been altered, then the default profile are as follows:
+If the profile has not been altered, then the default profile is as follows:
[width="100%",cols="25%,25%,50%",options="header",]
|===
| Option | Default | Description
-| *poolSize* | `10` | Sets the default core pool size (threads to keep minimum in pool)
-| *keepAliveTime* | `60` | Sets the default keep alive time (in seconds) for inactive threads
+| *poolSize* | `10` | Sets the default core pool size (minimum number of threads to keep in pool)
+| *keepAliveTime* | `60` | Sets the default keep-alive time (in seconds) for inactive threads
| *maxPoolSize* | `20` | Sets the default maximum pool size
| *maxQueueSize* | `1000` | Sets the default maximum number of tasks in the work queue. Use -1 for an unbounded queue.
| *allowCoreThreadTimeOut* | `true` | Sets default whether to allow core threads to timeout
(camel) 02/14: CAMEL-20459: documentation fixes for the step EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 37adb2ee46cc706846fb95c64f83c1b8640c8c51
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 12:56:58 2024 +0100
CAMEL-20459: documentation fixes for the step EIP.
---
.../src/main/docs/modules/eips/pages/step-eip.adoc | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/step-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/step-eip.adoc
index 51159c21617..53db9381c07 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/step-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/step-eip.adoc
@@ -15,9 +15,9 @@ With Camel, you can group your processing across multiple independent EIPs
which can then be chained together in a logical unit, called a _step_.
A step groups together the child processors into a single composite unit.
-This allows to capture metrics at a group level which can make management and monitoring
+This allows capturing metrics at a group level which can make management and monitoring
of Camel routes easier by using higher-level abstractions. You can also
-think this as a middle-level between the route and each individual processors in the routes.
+think this as a middle-level between the route and each processor in the routes.
You may want to do this when you have large routes and want to break up the routes into
logical steps.
@@ -59,7 +59,7 @@ from("activemq:SomeQueue")
As you can see this groups together `.bean("foo")` and `.to("activemq:OutputQueue")`
into a logical unit with the name foo.
-In XML you use the `<step>` tag:
+In XML, you use the `<step>` tag:
[source,xml]
----
@@ -112,6 +112,6 @@ XML::
=== JMX Management of Step EIP
-Each Step EIP is registered in JMX under the `type=steps` tree, which allows to monitor
+Each Step EIP is registered in JMX under the `type=steps` tree, which allows monitoring
all the steps in the CamelContext. It is also possible to dump statistics in XML format
by the `dumpStepStatsAsXml` operations on the `CamelContext` or `Route` mbeans.
(camel) 07/14: CAMEL-20459: documentation fixes for the to EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 867b4a36539bb246e422070aa8b952e5e5c3b40a
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 13:03:04 2024 +0100
CAMEL-20459: documentation fixes for the to EIP.
---
core/camel-core-engine/src/main/docs/modules/eips/pages/to-eip.adoc | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/to-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/to-eip.adoc
index 1ff47a8fdab..094396a6633 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/to-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/to-eip.adoc
@@ -38,13 +38,15 @@ include::partial$eip-exchangeProperties.adoc[]
== Different between To and ToD
The `to` is used for sending messages to a static xref:message-endpoint.adoc[endpoint].
-In other words `to` sends message only to the *same* endpoint.
+In other words `to` sends messages only to the *same* endpoint.
-The `toD` is used for sending message to a dynamic xref:message-endpoint.adoc[endpoint].
+The `toD` is used for sending messages to a dynamic xref:message-endpoint.adoc[endpoint].
The dynamic endpoint is evaluated _on-demand_ by an xref:manual:ROOT:expression.adoc[Expression].
By default, the xref:components:languages:simple-language.adoc[Simple] expression is used to compute
the dynamic endpoint URI.
+NOTE: the Java DSL also provides a `toF` EIP, which can be used to avoid concatenating route parameters and making the code harder to read.
+
== Using To
The following example route demonstrates the use of a xref:ROOT:file-component.adoc[File] consumer endpoint and a xref:ROOT:jms-component.adoc[JMS] producer endpoint,
(camel) 09/14: CAMEL-20459: documentation fixes for the topic EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 5780e44c98e44e176c1908fb61e2dac10ae4f735
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 13:07:50 2024 +0100
CAMEL-20459: documentation fixes for the topic EIP.
---
.../src/main/docs/modules/eips/pages/topic-eip.adoc | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/topic-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/topic-eip.adoc
index 2087c8e55d0..4f28ec3a80b 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/topic-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/topic-eip.adoc
@@ -7,7 +7,7 @@
:tabs-sync-option:
Topic mode for the xref:loadBalance-eip.adoc[Load Balancer] EIP.
-With this policy then all destination is selected.
+With this policy, then all destinations are selected.
== Options
@@ -24,8 +24,13 @@ include::partial$eip-exchangeProperties.adoc[]
== Examples
-In this example we send the message to all three endpoints:
+In this example, we send the message to all three endpoints:
+[tabs]
+====
+
+Java::
++
[source,java]
----
from("direct:start")
@@ -36,8 +41,8 @@ from("direct:start")
.end();
----
-In XML you'll have a route like this:
-
+XML::
++
[source,xml]
----
<route>
@@ -50,3 +55,5 @@ In XML you'll have a route like this:
</loadBalance>
</route>
----
+
+====
\ No newline at end of file
(camel) 01/14: CAMEL-20459: documentation fixes for the splitter EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 3b96427440608fd5407621b7a594899f014976ab
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 12:56:15 2024 +0100
CAMEL-20459: documentation fixes for the splitter EIP.
---
.../main/docs/modules/eips/pages/split-eip.adoc | 86 +++++++++++-----------
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/split-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/split-eip.adoc
index 84b3467a011..8d194ba1871 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/split-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/split-eip.adoc
@@ -12,7 +12,7 @@ image::eip/Sequencer.gif[image]
Use a Splitter to break out the composite message into a series of individual messages, each containing data related to one item.
-The http://www.enterpriseintegrationpatterns.com/patterns/messaging/Sequencer.html[Splitter] from the xref:enterprise-integration-patterns.adoc[EIP patterns] allows you split a message into a number of pieces and process them individually.
+The http://www.enterpriseintegrationpatterns.com/patterns/messaging/Sequencer.html[Splitter] from the xref:enterprise-integration-patterns.adoc[EIP patterns] allows you to split a message into a number of pieces and process them individually.
== Options
@@ -28,8 +28,8 @@ include::partial$eip-exchangeProperties.adoc[]
== Using Split
-The following example shows how to take a request from the direct:a endpoint,
-then split into sub messages, which each are sent to the direct:b endpoint.
+The following example shows how to take a request from the `direct:a` endpoint,
+then split into sub messages, which each are sent to the `direct:b` endpoint.
The example splits the message body using a tokenizer to split into lines
using the new-line character as separator.
@@ -116,18 +116,18 @@ from the message body.
The Split EIP will by default split the message body based on the value type:
-- `java.util.Collection` - splits by each element from the collection/list/set.
-- `java.util.Map` - splits by each `Map.Entry` from the map.
-- `Object[]` - splits the array by each element
-- `Iterator` - splits by the iterator
-- `Iterable` - splits by the iterable
-- `org.w3c.dom.NodeList` - splits the XML document by each element from the list
-- `String` - splits the string value by comma as separator
+- `java.util.Collection`: splits by each element from the collection/list/set.
+- `java.util.Map`: splits by each `Map.Entry` from the map.
+- `Object[]`: splits the array by each element
+- `Iterator`: splits by the iterator
+- `Iterable`: splits by the iterable
+- `org.w3c.dom.NodeList`: splits the XML document by each element from the list
+- `String`: splits the string value by comma as separator
-For any other type the message body is not split, and instead used _as-is_, meaning that
+For any other type, the message body is not split, and instead used _as-is_, meaning that
the Split EIP will be split into a single message (the same).
-To use this with the splitter you should _just_ use body as the expression:
+To use this with the splitter, you should _just_ use body as the expression:
[tabs]
====
@@ -142,7 +142,7 @@ from("direct:splitUsingBody")
XML::
+
-In XML you use xref:components:languages:simple-language.adoc[Simple] to refer to the message body:
+In XML, you use xref:components:languages:simple-language.adoc[Simple] to refer to the message body:
[source,xml]
----
@@ -204,8 +204,8 @@ thread that called the splitter, then make sure to enable the synchronous option
You may want to continue routing the exchange after the Split EIP. In Java DSL you need to use `end()`
to mark where split ends, and where other EIPs can be added to continue the route.
-In the example above then sending to mock:result happens after the Spllit EIP has finished.
-In other words the message should finish splitting the entire message before the message
+In the example above then sending to mock:result happens after the Split EIP has finished.
+In other words, the message should finish splitting the entire message before the message
continues.
[tabs]
@@ -301,8 +301,8 @@ input message and return as response; it's the aggregate method with 3 exchange
The Split EIP operates in two modes when splitting:
-- _default mode_ - The message is split into sub messages, which allows to know the total split size. However this causes all sub messages to be kept temporary in-memory.
-- _streaming mode_ - The message is split on-demand. This uses an iterator to keep track of the splitting index, but avoids loading all sub messages into memory. However, the total size cannot be know ahead of time.
+- _default mode_: The message is split into sub messages, which allows to know the total split size. However, this causes all sub messages to be kept temporary in-memory.
+- _streaming mode_: The message is split on-demand. This uses an iterator to keep track of the splitting index, but avoids loading all sub messages into memory. However, the total size cannot be known ahead of time.
=== Using streaming mode
@@ -361,7 +361,7 @@ XML::
----
====
-Then the custom bean could for example be implemented as follows:
+Then the custom bean could, for example, be implemented as follows:
[source,java]
----
@@ -379,7 +379,7 @@ public class MyCustomSplitter {
The bean should just return something that the splitter can work with when splitting, such as a `List` or `Iterator` etc.
-TIP: The bean method `splitMe` uses `Exchange` as parameter, however Camel supports
+TIP: The bean method `splitMe` uses `Exchange` as parameter, however, Camel supports
xref:manual:ROOT:bean-binding.adoc[Bean Parameter Binding], which allows using other parameters types instead.
=== Streaming big XML payloads
@@ -432,7 +432,7 @@ For example, you may have an XML payload structured as follows:
----
Now to split this big file using xref:components:languages:xpath-language.adoc[XPath]
-would cause the entire content to be loaded into memory. So instead we can use the
+would cause the entire content to be loaded into memory. So instead, we can use the
xref:components:languages:tokenize-language.adoc[Tokenize] language to do this as follows:
[tabs]
@@ -462,7 +462,7 @@ XML::
This will split the file using the tag name of the child nodes (more precisely speaking, the local name of the element without its namespace prefix if any),
which mean it will grab the content between the `<order>` and `</order>` tags (incl. the tags).
-So for example a split message would be structured as follows:
+So for example, a split message would be structured as follows:
[source,xml]
----
@@ -544,7 +544,7 @@ Having an input XML:
</m:orders>
----
-Each mode will result in the following tokens,
+Each mode will result in the following tokens:
[width="100%",cols="3,6",options="header"]
|===
@@ -583,10 +583,10 @@ or setting the extraction mode explicitly as
Note that this StAX based tokenizer uses StAX Location API and requires a StAX Reader implementation (such as Woodstox)
that correctly returns the offset position pointing to the beginning of each event triggering segment (the offset position
-of `<` at each start and end element event). If you use a StAX Reader which does not implement that API correctly
+of `<` at each start and end element event). If you use a StAX Reader which does not implement that API correctly,
it results in invalid XML snippets after the split.
-For example the snippet could be wrong terminated:
+For example, the snippet could be wrongly terminated:
[source,xml]
----
@@ -596,7 +596,7 @@ For example the snippet could be wrong terminated:
=== Splitting files by grouping N lines together
The xref:components:languages:tokenize-language.adoc[Tokenize] language
-can be used for grouping N parts together, for example to split big files into chunks of 1000 lines.
+can be used for grouping N parts together, for example, to split big files into chunks of 1000 lines.
Doing this is easy as the following example shows:
@@ -625,10 +625,10 @@ XML::
----
====
-The `group` value must be a positive number dictating how many elements to combine together in a group.
+The `group` value must be a positive number dictating how many elements to combine in a group.
Each part will be combined using the token.
-In the example above the message being sent to the activemq order queue, will contain 1000 lines,
+In the example above, the message being sent to the activemq order queue, will contain 1000 lines,
and each line separated by the token (which is a new line token).
The output when using the group option is always a `java.lang.String` type.
@@ -645,7 +645,7 @@ to build up the combined response message.
----
// this routes starts from the direct:start endpoint
// the body is then split based on @ separator
-// the splitter in Camel supports InOut as well and for that we need
+// the splitter in Camel supports InOut as well, and for that we need
// to be able to aggregate what response we need to send back, so we provide our
// own strategy with the class MyOrderStrategy.
from("direct:start")
@@ -655,8 +655,8 @@ from("direct:start")
// this is important to end the splitter route as we do not want to do more routing
// on each split message
.end()
- // after we have split and handled each message we want to send a single combined
- // response back to the original caller, so we let this bean build it for us
+ // after we have split and handled each message, we want to send a single combined
+ // response back to the original caller, so we let this bean build it for us,
// this bean will receive the result of the aggregate strategy: MyOrderStrategy
.to("bean:MyOrderService?method=buildCombinedResponse")
----
@@ -698,7 +698,7 @@ response can be returned to the waiting caller.
* This is our own order aggregation strategy where we can control
* how each split message should be combined. As we do not want to
* loos any message we copy from the new to the old to preserve the
- * order lines as long we process them
+ * order lines as we process them
*/
public static class MyOrderStrategy implements AggregationStrategy {
@@ -728,7 +728,7 @@ public static class MyOrderStrategy implements AggregationStrategy {
}
----
-So lets run the sample and see how it works.
+So let's run the sample and see how it works.
We send an Exchange to the direct:start endpoint containing a message body with the String value: `A@B@C`. The flow is:
@@ -749,14 +749,14 @@ Response to caller: Response[(id=1,item=A);(id=2,item=B);(id=3,item=C)]
The Splitter will by default continue to process
the entire Exchange even in case of one of the
-split message will throw an exception during routing.
+split messages will throw an exception during routing.
-For example if you have an Exchange with 1000 rows that you split.
-During processing of these split messages an exception is thrown at the 17th.
-What Camel does by default is to process the remainder 983 messages.
+For example, if you have an Exchange with 1000 rows that you split.
+During processing of these split messages, an exception is thrown at the 17th.
+What Camel does by default is to process the remainder of the 983 messages.
You have the chance to deal with the exception when aggregating using an `AggregationStrategy`.
-But sometimes you just want Camel to stop and let the exception be
+But sometimes you want Apache Camel to stop and let the exception be
propagated back, and let the Camel xref:manual:ROOT:error-handler.adoc[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
@@ -800,8 +800,8 @@ This means the Split EIP will stop after this, and not split anymore.
The Splitter will by default not share unit of work between the parent exchange and each split exchange.
This means each sub exchange has its own individual unit of work.
-For example, you need to split a big message, and regard that process as an atomic isolated operation
-that either is a success or failure. In case of a failure you want that big message to be moved into a dead letter queue.
+For example, you need to split a big message, and regard that process as an atomic-isolated operation
+that either is a success or failure. In case of a failure, you want that big message to be moved into a dead letter queue.
To support this use case, you would have to share the unit of work on the Splitter.
@@ -829,10 +829,10 @@ from("direct:line")
.to("mock:line");
----
-What would happen is that in case there is an exception thrown during splitting then
+What would happen is that in case there is an exception thrown during splitting, then
the error handler will kick in (yes error handling still applies for the sub messages).
-The error handler in this example is configured to retry up till 3 times.
+The error handler in this example is configured to retry up till three times.
And when a split message fails all redelivery attempts (its exhausted),
then this message is *not* moved into that dead letter queue.
@@ -883,7 +883,7 @@ Using this from XML DSL is just as easy as all you have to set is the `shareUnit
== See Also
-Because xref:multicast-eip.adoc[Multicast] EIP is baseline for
+Because xref:multicast-eip.adoc[Multicast] EIP is a baseline for
the xref:recipientList-eip.adoc[Recipient List] and Split EIPs,
-then you can find more information in those EIPs about features that is also available
+then you can find more information in those EIPs about features that are also available
with Split EIP.
(camel) 06/14: CAMEL-20459: documentation fixes for the throttle EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit ac36bbc61d97f99a4b8a419cd654c9fd123e5269
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 13:01:35 2024 +0100
CAMEL-20459: documentation fixes for the throttle EIP.
---
.../src/main/docs/modules/eips/pages/throttle-eip.adoc | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/throttle-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/throttle-eip.adoc
index dd65ba4dafb..dad4488dbc2 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/throttle-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/throttle-eip.adoc
@@ -10,7 +10,7 @@ How can I throttle messages to ensure that a specific endpoint does not get over
image::eip/MessagingAdapterIcon.gif[image]
-Use a Throttler that controls the rate how many or fast messages are flowing to the endpoint.
+Use a Throttler that controls the rate of how many or fast messages are flowing to the endpoint.
== Options
@@ -27,7 +27,7 @@ include::partial$eip-exchangeProperties.adoc[]
== Using Throttle
The below example will throttle messages received on seda:a before being sent to mock:result
-ensuring that a maximum of 3 messages are sent during a running 10-seconds window slot.
+ensuring that a maximum of 3 messages is sent during a running 10-second window slot.
[tabs]
====
@@ -69,10 +69,11 @@ YAML::
----
====
-To use 10-seconds window we set the `timePeriodMillis` to ten-thousand. The default value is 1000 (i.e. 1 second),
+To use 10-seconds window, we set the `timePeriodMillis` to ten-thousand.
+The default value is 1000 (i.e., 1 second),
meaning that setting just `throttle(3)` has the effect of setting the maximum number of requests per second.
-To throttle by 50 requests per second, would look like this:
+To throttle by 50 requests per second, it would look like this:
[tabs]
====
@@ -121,7 +122,7 @@ a xref:components:languages:constant-language.adoc[constant]. However, the expre
be dynamic, such as determined from a message header from the current `Exchange`.
At runtime Camel evaluates the expression and converts the result to a `java.lang.Long` type.
-In the example below we use a header from the message to determine the maximum requests per period.
+In the example below, we use a header from the message to determine the maximum requests per period.
If the header is absent, then the Throttler uses the old value. This allows you to only provide a header if the value is to be changed:
[tabs]
@@ -314,8 +315,9 @@ YAML::
----
====
-In the example above messages are throttled by the header with name region.
-So suppose there are regions for US, EMEA, and ASIA, then we have three different groups, that each
+In the example above, messages are throttled by the header with name region.
+So suppose there are regions for US, EMEA, and ASIA.
+Then we have three different groups that each
are throttled by 100 messages per second.
== Throttling Modes
(camel) 12/14: CAMEL-20459: documentation fixes for the validate EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit b831dbf8a4ae306779249030e238b7961d39eeb9
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 13:10:47 2024 +0100
CAMEL-20459: documentation fixes for the validate EIP.
---
.../src/main/docs/modules/eips/pages/validate-eip.adoc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/validate-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/validate-eip.adoc
index 9517266da21..f8943d71685 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/validate-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/validate-eip.adoc
@@ -6,7 +6,7 @@
:supportlevel: Stable
:tabs-sync-option:
-The Validate EIP uses an xref:manual::expression.adoc[Expression] or xref:manual::predicate.adoc[Predicate]
+The Validate EIP uses an xref:manual::expression.adoc[Expression] or a xref:manual::predicate.adoc[Predicate]
to validate the contents of a message.
image::eip/MessageSelectorIcon.gif[image]
@@ -85,7 +85,7 @@ from("file:inbox")
.to("bean:myServiceBean.processLine");
----
+
-You can also use validate together with the xref:components:languages:simple-language.adoc[Simple] language.
+You can also use `validate` together with the xref:components:languages:simple-language.adoc[Simple] language.
+
[source,java]
----
(camel) 11/14: CAMEL-20459: documentation fixes for the unmarshal EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 092bbfe8ba67d36479e1fb73820b5bf47419ded7
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 13:10:16 2024 +0100
CAMEL-20459: documentation fixes for the unmarshal EIP.
---
.../src/main/docs/modules/eips/pages/unmarshal-eip.adoc | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/unmarshal-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/unmarshal-eip.adoc
index 11c7a2296bb..a1384c5797f 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/unmarshal-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/unmarshal-eip.adoc
@@ -8,13 +8,13 @@ image::eip/MessageTranslator.gif[image]
Camel has support for message transformation using several techniques.
One such technique is xref:dataformats:index.adoc[Data Formats],
-where marshal and unmarshal comes from.
+where marshal and unmarshal come from.
-So in other words the xref:marshal-eip.adoc[Marshal] and xref:unmarshal-eip.adoc[Unmarshal] EIPs
+So in other words, the xref:marshal-eip.adoc[Marshal] and xref:unmarshal-eip.adoc[Unmarshal] EIPs
are used with xref:dataformats:index.adoc[Data Formats].
-- _Marshal_ - Transforms the message body (such as Java object) into a binary or textual format, ready to be wired over the network.
-- _Unmarshal_ - Transforms data in some binary or textual format (such as received over the network)
+- _Marshal_: Transforms the message body (such as Java object) into a binary or textual format, ready to be wired over the network.
+- _Unmarshal_: Transforms data in some binary or textual format (such as received over the network)
into a Java object; or some other representation according to the data format being used.
== Example
@@ -24,7 +24,8 @@ Each file is then transformed into Java Objects using xref:dataformats:jaxb-data
Then a xref:ROOT:bean-component.adoc[Bean] is invoked that takes in the Java object.
Then the reverse operation happens to transform the Java objects back into XML also via JAXB,
-but using the `marshal` operation. And finally the message is routed to a xref:ROOT:jms-component.adoc[JMS] queue.
+but using the `marshal` operation.
+And finally, the message is routed to a xref:ROOT:jms-component.adoc[JMS] queue.
[tabs]
====
@@ -72,7 +73,11 @@ YAML::
== Allow Null Body
-Sometimes, there are situations where `null` can be a normal value for the body of a message but `null` by default is not an accepted value to unmarshal. To workaround that, it is possible to allow `null` as value to a body to unmarshall using the option `allowNullBody` as shown in the next code snippets:
+Sometimes,
+there are situations where `null` can be a normal value for the body of a message but `null` by default is not an accepted value to unmarshal.
+To work around that,
+it is possible to allow `null` as value to a body to unmarshall
+using the option `allowNullBody` as shown in the next code snippets:
[tabs]
====
(camel) 04/14: CAMEL-20459: documentation fixes for the stop EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 181c5dd9307f099b8015156ac966e52a012ef00e
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 12:57:49 2024 +0100
CAMEL-20459: documentation fixes for the stop EIP.
---
core/camel-core-engine/src/main/docs/modules/eips/pages/stop-eip.adoc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/stop-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/stop-eip.adoc
index 69cb23fdca2..31ac5448d35 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/stop-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/stop-eip.adoc
@@ -6,7 +6,7 @@
:supportlevel: Stable
:tabs-sync-option:
-How can I stop continue routing a message?
+How can I stop routing a message?
image::eip/MessageExpirationIcon.gif[image]
@@ -27,7 +27,7 @@ include::partial$eip-exchangeProperties.adoc[]
== Using Stop
We want to stop routing a message if the message body contains the word Bye.
-In the xref:choice-eip.adoc[Content Based Router] below we use `stop` in such case.
+In the xref:choice-eip.adoc[Content-Based Router] below we use `stop` in such a case.
[tabs]
====
(camel) 14/14: CAMEL-20459: documentation fixes for the wireTap EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 9eac735265f8658e52c51f35d32b4ea55485899e
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 13:13:00 2024 +0100
CAMEL-20459: documentation fixes for the wireTap EIP.
---
.../src/main/docs/modules/eips/pages/wireTap-eip.adoc | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/wireTap-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/wireTap-eip.adoc
index 0524b54ca0e..65145d4bc5e 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/wireTap-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/wireTap-eip.adoc
@@ -39,8 +39,9 @@ copies could share objects from the original `Exchange`.
=== Using Wire Tap
-In the example below the exchange is wire tapped to the direct:tap route.
-This route delays the message 1 second before continuing. This is because
+In the example below, the exchange is wire tapped to the direct:tap route.
+This route delays message 1 second before continuing.
+This is because
it allows you to see that the tapped message is routed independently of the original
route, so that you would see log:result happens before log:tap
@@ -101,11 +102,11 @@ YAML::
=== Wire tapping with dynamic URIs
-For example to wire tap to a dynamic URI, then the URI
+For example, to wire tap to a dynamic URI, then the URI
uses the xref:components:languages:simple-language.adoc[Simple] language that
allows to construct dynamic URIs.
-For example to wire tap to a JMS queue where the header ID is part of the queue name:
+For example, to wire tap to a JMS queue where the header ID is part of the queue name:
[tabs]
====
@@ -147,16 +148,16 @@ YAML::
The WireTap uses a thread pool to process the
tapped messages. This thread pool will by default use the settings
-detailed at xref:manual::threading-model.adoc[Threading Model].
+detailed in the xref:manual::threading-model.adoc[Threading Model].
-In particular, when the pool is exhausted (with all threads utilized), further wiretaps
+In particular, when the pool is exhausted (with all threads used), further wiretaps
will be executed synchronously by the calling thread. To remedy this,
you can configure an explicit thread pool on the Wire Tap having either
a different rejection policy, a larger worker queue, or more worker threads.
== Wire tapping Streaming based messages
-If you Wire Tap a stream message body then you
+If you Wire Tap a stream message body, then you
should consider enabling xref:manual::stream-caching.adoc[Stream caching] to
ensure the message body can be read at each endpoint.
(camel) 08/14: CAMEL-20459: documentation fixes for the toD EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit bbd4ea28d3397804b8eef573066c640b6322c839
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 13:06:38 2024 +0100
CAMEL-20459: documentation fixes for the toD EIP.
---
.../src/main/docs/modules/eips/pages/toD-eip.adoc | 56 +++++++++++-----------
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/toD-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/toD-eip.adoc
index deb86ce0db9..4fd56d79efb 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/toD-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/toD-eip.adoc
@@ -38,17 +38,17 @@ include::partial$eip-exchangeProperties.adoc[]
== Different between To and ToD
The `to` is used for sending messages to a static xref:message-endpoint.adoc[endpoint].
-In other words `to` sends message only to the *same* endpoint.
+In other words `to` sends messages only to the *same* endpoint.
-The `toD` is used for sending message to a dynamic xref:message-endpoint.adoc[endpoint].
+The `toD` is used for sending messages to a dynamic xref:message-endpoint.adoc[endpoint].
The dynamic endpoint is evaluated _on-demand_ by an xref:manual::expression.adoc[Expression].
By default, the xref:languages:simple-language.adoc[Simple] expression is used to compute
the dynamic endpoint URI.
== Using ToD
-For example to send a message to an endpoint which is dynamic determined by a
-xref:message.adoc[message header] you can do as shown below:
+For example, to send a message to an endpoint which is dynamically determined by a
+xref:message.adoc[message header], you can do as shown below:
[tabs]
====
@@ -95,16 +95,16 @@ XML::
----
====
-In the example above we compute the dynamic endpoint with a prefix "mock:" and
-then the header foo is appended. So for example if the header foo has
+In the example above, we compute the dynamic endpoint with a prefix "mock:" and
+then the header foo is appended. So, for example, if the header foo has
value order, then the endpoint is computed as "mock:order".
=== Using other languages with toD
You can also use other languages such as xref:languages:xpath-language.adoc[XPath].
-Doing this requires to start with `language:` as shown below. If you do not
+Doing this requires starting with `language:` as shown below. If you do not
specify `language:` then the endpoint is a component name. And in some
-cases there is both a component and language with the same name such as
+ cases, there is both a component and language with the same name such as
xquery.
[tabs]
@@ -128,12 +128,12 @@ XML::
----
====
-=== Avoid creating endless dynamic endpoints which takes up resources
+=== Avoid creating endless dynamic endpoints that take up resources
When using dynamic computed endpoints with `toD` then you may compute a lot of dynamic endpoints,
which results in an overhead of resources in use, by each dynamic endpoint uri, and its associated producer.
-For example HTTP based endpoints where you may have dynamic values in URI parameters when calling the HTTP service, such as:
+For example, HTTP-based endpoints where you may have dynamic values in URI parameters when calling the HTTP service, such as:
[source,java]
----
@@ -141,8 +141,8 @@ from("direct:login")
.toD("http:myloginserver:8080/login?userid=${header.userName}");
----
-In the example above then the parameter `userid` is dynamic computed, and would result in one instance of endpoint and producer
-for each different userid. To avoid having too many dynamic endpoints you can configure `toD` to reduce its cache size, for example
+In the example above then the parameter `userid` is dynamically computed, and would result in one instance of endpoint and producer
+for each different userid. To avoid having too many dynamic endpoints you can configure `toD` to reduce its cache size, for example,
to use a cache size of 10:
[tabs]
@@ -168,13 +168,13 @@ XML::
IMPORTANT: this will only reduce the endpoint cache of the `toD` that has a chance
of being reused in case a message is routed with the same `userName` header. Therefore, reducing the cache size
-will not solve the _endless dynamic endpoint`s_ problem. Instead, you should use static endpoints with `to` and
+will not solve the _endless dynamic endpoint_ problem. Instead, you should use static endpoints with `to` and
provide the dynamic parts in Camel message headers (if possible).
==== Using static endpoints to avoid endless dynamic endpoints
-In the example above then the parameter `userid` is dynamic computed, and would result in one instance of endpoint and producer
-for each different userid. To avoid having too dynamic endpoints you use a single static endpoint and use headers to provide the dynamic parts:
+In the example above then the parameter `userid` is dynamically computed, and would result in one instance of endpoint and producer
+for each different userid. To avoid having too dynamic endpoints, you use a single static endpoint and use headers to provide the dynamic parts:
[source,java]
----
@@ -184,13 +184,13 @@ from("direct:login")
.toD("http:myloginserver:8080");
----
-However, you can use optimised components for `toD` that can _solve_ this out of the box,
+However, you can use optimized components for `toD` that can _solve_ this out of the box,
as documented next.
-=== Using optimised components with toD
+=== Using optimized components with toD
-A better solution would be if the HTTP component could be optimised to handle the variations of dynamic computed endpoint uris.
-This is with among the following components, which have been optimised for `toD`:
+A better solution would be if the HTTP component could be optimized to handle the variations of dynamic computed endpoint uris.
+This is with among the following components, which have been optimized for `toD`:
- camel-http
- camel-jetty
@@ -198,7 +198,7 @@ This is with among the following components, which have been optimised for `toD`
- camel-undertow
- camel-vertx-http
-A number of non-HTTP components has been optimised as well:
+A number of non-HTTP components has been optimized as well:
- camel-amqp
- camel-file
@@ -213,14 +213,14 @@ A number of non-HTTP components has been optimised as well:
For the optimisation to work, then:
-. The optimisation is detected and activated during startup of the Camel routes with `toD`.
+. The optimization is detected and activated during startup of the Camel routes with `toD`.
. The dynamic uri in `toD` must provide the component name as either static or resolved via xref:manual::using-propertyplaceholder.adoc[property placeholders].
. The supported components must be on the classpath.
-The HTTP based components will be optimised to use the same hostname:port for each endpoint, and the dynamic values
+The HTTP based components will be optimized to use the same hostname:port for each endpoint, and the dynamic values
for context-path and query parameters will be provided as headers:
-For example this route:
+For example, this route:
[source,java]
----
@@ -228,7 +228,7 @@ from("direct:login")
.toD("http:myloginserver:8080/login?userid=${header.userName}");
----
-Will essentially be optimised to (pseudo route):
+It Will essentially be optimized to (pseudo route):
[source,java]
----
@@ -241,18 +241,18 @@ from("direct:login")
----
Where _expression_ will be evaluated dynamically. Notice how the uri in `toD` is now static (`http:myloginserver:8080`).
-This optimisation allows Camel to reuse the same endpoint and its associated producer for all dynamic variations.
-This yields much lower resource overhead as the same http producer will be used for all the different variations of userid's.
+This optimization allows Camel to reuse the same endpoint and its associated producer for all dynamic variations.
+This yields much lower resource overhead as the same http producer will be used for all the different variations of `userids`.
[NOTE]
====
-When the optimised component is in use, then you cannot use the headers `Exchange.HTTP_PATH` and `Exchange.HTTP_QUERY`
+When the optimized component is in use, then you cannot use the headers `Exchange.HTTP_PATH` and `Exchange.HTTP_QUERY`
to provide dynamic values to override the uri in `toD`. If you want to use these headers, then use the plain `to` DSL instead.
In other words these headers are used internally by `toD` to carry the dynamic details of the endpoint.
====
In case of problems then you can turn on DEBUG logging level on `org.apache.camel.processor.SendDynamicProcessor` which will log
-during startup if `toD` was optimised, or if there was a failure loading the optimised component, with a stacktrace logged.
+during startup if `toD` was optimized, or if there was a failure loading the optimized component, with a stacktrace logged.
[source,text]
----
(camel) 03/14: CAMEL-20459: documentation fixes for the sticky EIP.
Posted by or...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 7bb1d9dcdd13760dda25ec79fc18d887f8cd2f5f
Author: Otavio Rodolfo Piske <an...@gmail.com>
AuthorDate: Mon Feb 26 12:57:22 2024 +0100
CAMEL-20459: documentation fixes for the sticky EIP.
---
.../src/main/docs/modules/eips/pages/sticky-eip.adoc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/sticky-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/sticky-eip.adoc
index 491be582bdf..f0fa4274595 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/sticky-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/sticky-eip.adoc
@@ -9,7 +9,7 @@
Sticky mode for the xref:loadBalance-eip.adoc[Load Balancer] EIP.
A stick mode means that a correlation key (calculated as xref:manual::expression.adoc[Expression])
-is used to determine the destination. This allows to route all messages with the same key to the same destination.
+is used to determine the destination. This allows routing all messages with the same key to the same destination.
== Options
@@ -25,7 +25,7 @@ include::partial$eip-exchangeProperties.adoc[]
== Examples
-In this case we are using the header myKey as correlation expression:
+In this case, we are using the header myKey as correlation expression:
[tabs]
====