This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new ffcb39f CAMEL-16861: Cleanup and update EIP docs
ffcb39f is described below
commit ffcb39fff734c6bff1d69107cec8c1fa0c077167
Author: Claus Ibsen <claus.ib...@gmail.com>
AuthorDate: Wed Sep 15 14:28:11 2021 +0200
CAMEL-16861: Cleanup and update EIP docs
---
.../docs/modules/eips/pages/aggregate-eip.adoc | 498 +++++++++++----------
.../org/apache/camel/model/aggregate.json | 4 +-
.../apache/camel/model/AggregateDefinition.java | 10 +-
3 files changed, 269 insertions(+), 243 deletions(-)
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/aggregate-eip.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/aggregate-eip.adoc
index 65b06dd..23425fe 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/aggregate-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/aggregate-eip.adoc
@@ -12,11 +12,10 @@ you to combine a number of messages together into a single
message.
image::eip/Aggregator.gif[image]
-A correlation xref:latest@manual:ROOT: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.
+The aggregator is one of the most complex EIP and has many features and
configurations.
+
+The logic for combing messages together is _correlated_ in buckets based on a
_correlation key_.
+Messages with the same correlation key is aggregated together, using an
`AggregationStrategy`.
== Aggregator options
@@ -37,8 +36,8 @@ The Aggregate EIP supports 27 options which are listed below:
| *timeoutCheckerExecutorService{zwsp}Ref* | 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. The value can either refer to a bean to lookup, or to lookup a
singleton bean by its type, or to create a new bean: Lookup bean - This is the
default behavior to lookup an existing bean by the bean id (value) reference by
type - Values can refer to singleton beans by their type in the registry by
prefixing with #type: syntax, eg #type:com.foo.MyClassType reference new class
- Values can refer to creating new [...]
-| *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
+| *strategyMethodName* | This option can be used to explicit declare the
method name to use, when using beans 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 beans 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. | | String
| *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 [...]
@@ -62,14 +61,15 @@ The aggregate EIP will always use a worker pool, that is
used to process all the
The worker pool is determined accordingly:
- If a custom `ExecutorService` has been configured, then this is used as
worker pool.
-- If `paralellelProcessing=true` then a _default_ worker pool (is 10 worker
threads by default) is created.
-However the thread pool size and other configurations can be configured using
_thread pool profiles_.
-- Otherwise a single threaded worker pool is created.
+- If `parallelProcessing=true` then a _default_ worker pool (is 10 worker
threads by default) is created.
+However, the thread pool size and other configurations can be configured using
_thread pool profiles_.
+- Otherwise, a single threaded worker pool is created.
+
+== Aggregating
-== About AggregationStrategy
+The `AggregationStrategy` is used for aggregating the old, and the new
exchanges together into a single exchange;
+that becomes the next old, when the next message is aggregated, and so forth.
-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
@@ -123,21 +123,99 @@ class ArrayListAggregationStrategy implements
AggregationStrategy {
}
----
-== About completion
+TIP: The `org.apache.camel.builder.AggregationStrategies` is a builder that can
+be used for creating commonly used aggregation strategies without having to
create a class.
+
+=== Aggregate by grouping exchanges
+
+In the route below we group all the exchanges together using
+`GroupedExchangeAggregationStrategy`:
+
+[source,java]
+----
+from("direct:start")
+ // aggregate all using same expression and group the
+ // exchanges so we get one single exchange containing all
+ // the others
+ .aggregate(new GroupedExchangeAggregationStrategy()).constant(true)
+ // wait for 0.5 seconds to aggregate
+ .completionTimeout(500L).to("mock:result");
+----
+
+As a result we have one outgoing `Exchange` being
+routed to 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.getMessage().getBody(List.class);
+----
+
+=== Aggregating into a List
+
+If you want to aggregate some value from the messages `<V>` into a `List<V>`
+then you can use the
+`org.apache.camel.processor.aggregate.AbstractListAggregationStrategy`
+abstract class.
+
+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:
+
+[source,java]
+----
+public class MyListOfNumbersStrategy extends
AbstractListAggregationStrategy<Integer> {
+
+ @Override
+ public Integer getValue(Exchange exchange) {
+ // the message body contains a number, so just return that as-is
+ return exchange.getIn().getBody(Integer.class);
+ }
+}
+----
+
+The `org.apache.camel.builder.AggregationStrategies` is a builder that can
+be used for creating commonly used aggregation strategies without having to
create a class.
+
+The previous example can also be built using the builder as shown:
+
+[source,java]
+----
+AggregationStrategy agg = AggregationStrategies.flexible(Integer.class)
+ .accumulateInCollection(ArrayList.class)
+ .pick(body());
+----
+
+=== Aggregating on timeout
+
+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.
+
+
+== Completion
When aggregation xref:latest@manual:ROOT:exchange.adoc[Exchange]s at some
point you need to
-indicate that the aggregated exchanges is complete, so they can be send
+indicate that the aggregated exchanges is complete, so they can be sent
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
+* _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
+* _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:latest@manual:ROOT:predicate.adoc[Predicate] when a new
+* _completionSize_ - Is a number indicating that after X aggregated
+exchanges its complete.
+* _completionPredicate_ - Runs a
xref:latest@manual:ROOT: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
@@ -145,148 +223,152 @@ completionPredicate is configured. The configured
aggregationStrategy can
override the `preComplete` method and will be used as
the completionPredicate in pre-complete check mode. See further below
for more details.
-* completionFromBatchConsumer - Special option for
+* _completionFromBatchConsumer_ - Special option for
xref:latest@manual:ROOT: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
+* _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.
+* _AggregateController_ - which allows to use an external source
(`AggregateController` implementation) 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
+All the different completions are per correlation key. 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.
+Completion is mandatory and must be configured on the aggregation.
-== Pre-completion mode
+=== Pre-completion mode
There can be use-cases where you want the incoming
xref:latest@manual:ROOT:exchange.adoc[Exchange] to determine if the
correlation group
should pre-complete, and then the incoming
-xref:latest@manual:ROOT:exchange.adoc[Exchange] is starting a new group from
scratch. o
-determine this the `AggregationStrategy` must override the `canPreComplete`
method
-which has to return `true`.
+xref:latest@manual:ROOT:exchange.adoc[Exchange] is starting a new group from
scratch.
+The pre-completion mode must be enabled by the `AggregationStrategy` by
overriding the `canPreComplete` method
+to return a `true` value.
+
+When pre completion is enabled then the `preComplete` method is invoked:
[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);
+/**
+ * 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
+If the `preComplete` method returns `true`, then the existing correlation
groups is
+completed (without aggregating the incoming exchange (`newExchange`).
+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
+known as pre-completion mode.
-* completionTimeout or completionInterval can also be used as fallback
+When the aggregation is in _pre-completion_ mode, then only the following
completions are in use:
+
+* _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
+* 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:others:leveldb.adoc[LevelDB], or
xref:components::sql-component.adoc[SQL Component] components.
-
-== Using TimeoutAwareAggregationStrategy
+your own `org.apache.camel.spi.AggregationRepository`.
-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.
+If you need persistent repository then Camel provides numerous
implementations, such as from the
+xref:components::caffeine-component.adoc[Caffeine],
+xref:components::cassandraql-component.adoc[CassandraQL],
+xref:components::ehcache-component.adoc[EHCache],
+xref:components::hazelcast-component.adoc[Hazelcast],
+xref:components::infinispan-component.adoc[Infinispan],
+xref:components::jcache-component.adoc[JCache],
+xref:components:others:leveldb.adoc[LevelDB],
+xref:components:others:redis.adoc[Redis],
+or xref:components::sql-component.adoc[SQL] components.
-== Using CompletionAwareAggregationStrategy
+=== 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.
+`onComplete` method when the aggregated `Exchange` is completed. This
+allows you to do any last minute custom logic such as to clean up 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
-== Completing current group decided from the AggregationStrategy
+The `AggregationStrategy` supports checking for the
-The `AggregationStrategy` can now included a property on the
-returned `Exchange` that contains a boolean to indicate if the current
+the exchange property (`Exchange.AGGREGATION_COMPLETE_CURRENT_GROUP`)
+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
+For example the following logic 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;
+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
-== Completing all previous group decided from the AggregationStrategy
+The `AggregationStrategy` checks an exchange property, from the returned
exchange,
+indicating if all previous groups should be completed.
-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
+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`.
+The following logic will complete all the
+previous groups, and start a new aggregation group.
+
+This is done by setting the property
`Exchange.AGGREGATION_COMPLETE_ALL_GROUPS` to `true`
+on the returned exchange.
[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;
- }
+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);
+ String body1 = oldExchange.getIn().getBody(String.class);
+ String body2 = newExchange.getIn().getBody(String.class);
- oldExchange.getIn().setBody(body1 + body2);
- return oldExchange;
- }
+ oldExchange.getIn().setBody(body1 + body2);
+ return oldExchange;
}
+}
----
-== Manually Force the Completion of All Aggregated Exchanges Immediately
+=== 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
@@ -298,19 +380,7 @@ 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
+=== Using a controller to force the aggregator to complete
The `org.apache.camel.processor.aggregate.AggregateController` allows
you to control the aggregate at runtime using Java or JMX API. This can
@@ -333,98 +403,70 @@ from("direct:start")
.to("mock:aggregated");
----
-Then there is API on AggregateController to force completion. For
-example to complete a group with key foo
+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.
+The returned value is the number of groups completed.
+A value of 1 is returned if the foo group existed, otherwise 0 is returned.
-There is also an api to complete all groups
+There is also a method to complete all groups:
[source,java]
----
int groups = controller.forceCompletionOfAllGroups();
----
-To configure this from XML DSL
+The controller can also be used in XML DSL using the `aggregateControllerRef`
to
+refer to a bean with the controller implementation, which is looked up in the
registry.
+
+When using Spring XML you can create the bean with `<bean>` as shown:
[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 GroupedExchangeAggregationStrategy
-
-In the route below we group all the exchanges together using
-`GroupedExchangeAggregationStrategy`:
-
-[source,java]
-----
-from("direct:start")
- // aggregate all using same expression and group the
- // exchanges so we get one single exchange containing all
- // the others
- .aggregate(new GroupedExchangeAggregationStrategy()).constant(true)
- // wait for 0.5 seconds to aggregate
- .completionTimeout(500L).to("mock:result");
+<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>
----
-As a result we have one outgoing `Exchange` being
-routed to the `"mock:result"` endpoint. The exchange is a holder
-containing all the incoming Exchanges.
+There is also JMX API on the aggregator which is available under the
processors node in the Camel JMX tree.
-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
+== Aggregating with Beans
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:
+You can use a bean for the logic and let Camel adapt to your
+bean. To use a bean 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 parameters are paired, so the first half is applied to the
+`oldExchange`, and the reminder half is for the `newExchange`.
+ Therefore, 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
+* optional, the 2nd parameter is a `Map` of the headers
+* optional, the 3rd parameter is a `Map` of the exchange properties
This convention is best explained with some examples.
@@ -435,35 +477,33 @@ the body of the `oldExchange`, and the 2nd is paired to
the body of the
[source,java]
----
public String append(String existing, String next) {
- return existing + 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
+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:
+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;
+ return existing + next;
}
----
-And finally if we have 6 parameters the we also have the properties of
-the Exchanges:
+And finally if we have 6 parameters, that includes the exchange properties:
[source,java]
----
public String append(String existing, Map existingHeaders, Map
existingProperties,
String next, Map nextHeaders, Map nextProperties) {
- return existing + next;
+ return existing + next;
}
----
-To use this with the Aggregate EIP we can use a
-POJO with the aggregate logic as follows:
+To use this with the aggregate EIP we can use a bean with the aggregate logic
as follows:
[source,java]
----
@@ -492,7 +532,7 @@ public void configure() throws Exception {
}
----
-We can also provide the bean type directly:
+We can also provide the bean class type directly:
[source,java]
----
@@ -530,7 +570,7 @@ public class MyBodyAppender {
}
----
-If you are using XML DSL then we need to declare a <bean> with the POJO:
+If you are using XML DSL then we need to declare a `<bean>` with the bean:
[source,xml]
----
@@ -556,45 +596,33 @@ to call:
</camelContext>
----
-When using XML DSL you must define the POJO as a <bean>.
+When using XML DSL you can also specify the bean class directly in
`strategyRef`
+using the `#class:` syntax as shown:
-== Aggregating when no data
+[source,xml]
+----
+<route>
+ <from uri="direct:start"/>
+ <aggregate strategyRef="#class:com.foo.MyBodyAppender"
strategyMethodName="append" completionSize="3">
+ <correlationExpression>
+ <constant>true</constant>
+ </correlationExpression>
+ <to uri="mock:result"/>
+ </aggregate>
+</route>
+----
-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:latest@manual:ROOT:exchange.adoc[Exchange]s then `oldExchange`
and
-`newExchange` parameters are both not null.
+You can use this in XML DSL when you are not using the classic Spring XML
files;
+where you use XML only for Camel routes.
-Example with Content Enricher EIP and no data
+=== Aggregating when 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`.
+When using bean as `AggregationStrategy`, then the method is
+*only* invoked when there is data to be aggregated, meaning that the message
body
+is not `null`. In cases where you want to have the method invoked, even when
there are no data (message body is `null`),
+then set the `strategyMethodAllowNull` to `true`.
-[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
+When using beans this can be configured a bit easier using the `beanAllowNull`
method
from `AggregationStrategies` as shown:
[source,java]
@@ -606,8 +634,8 @@ public void configure() throws Exception {
}
----
-Then the `append` method in the POJO would need to deal with the
-situation that `newExchange` can be null:
+Then the `append` method in the bean would need to deal with the
+situation that `newExchange` can be `null`:
[source,java]
----
@@ -625,17 +653,17 @@ public class MyBodyAppender {
----
In the example above we use the xref:content-enricher.adoc[Content Enricher]
-EIP using `pollEnrich`. The `newExchange` will be null in the
+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
+a timeout was hit after 1 second.
+
+So if we need to do special merge logic we would need to set
`setAllowNullNewExchange=true`.
+If we don't do this then on timeout 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:
+set it to `true` as shown below:
[source,xml]
----
@@ -655,17 +683,16 @@ set it to true as shown below:
</camelContext>
----
-== Different body types
+=== Aggregating with different body types
-When for example using `strategyMethodAllowNull` as true, then the
+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:
+`List<String>` that contains the name of the user. We could code a bean as
follows:
[source,java]
----
-public static final class MyUserAppender {
+public final class MyUserAppender {
public List addUsers(List names, User user) {
if (names == null) {
@@ -677,6 +704,5 @@ public static final class MyUserAppender {
}
----
-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.
+Notice that the return type is a `List` which we want to contain the name of
the users.
+The 1st parameter is the `List` of names, and the 2nd parameter is the
incoming `com.foo.User` type.
diff --git
a/core/camel-core-model/src/generated/resources/org/apache/camel/model/aggregate.json
b/core/camel-core-model/src/generated/resources/org/apache/camel/model/aggregate.json
index 0482dca..995e850 100644
---
a/core/camel-core-model/src/generated/resources/org/apache/camel/model/aggregate.json
+++
b/core/camel-core-model/src/generated/resources/org/apache/camel/model/aggregate.json
@@ -22,8 +22,8 @@
"timeoutCheckerExecutorServiceRef": { "kind": "attribute", "displayName":
"Timeout Checker Executor Service Ref", "required": false, "type": "string",
"javaType": "java.lang.String", "deprecated": false, "autowired": false,
"secret": false, "description": "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 t [...]
"aggregationRepositoryRef": { "kind": "attribute", "displayName":
"Aggregation Repository Ref", "required": false, "type": "string", "javaType":
"java.lang.String", "deprecated": false, "autowired": false, "secret": false,
"description": "Sets the custom aggregate repository to use. Will by default
use org.apache.camel.processor.aggregate.MemoryAggregationRepository" },
"strategyRef": { "kind": "attribute", "displayName": "Strategy Ref",
"required": false, "type": "string", "javaType": "java.lang.String",
"deprecated": false, "autowired": false, "secret": false, "description": "A
reference to lookup the AggregationStrategy in the Registry. The value can
either refer to a bean to lookup, or to lookup a singleton bean by its type, or
to create a new bean: Lookup bean - This is the default behavior to lookup an
existing bean by the bean id (value) refe [...]
- "strategyMethodName": { "kind": "attribute", "displayName": "Strategy
Method Name", "required": false, "type": "string", "javaType":
"java.lang.String", "deprecated": false, "autowired": false, "secret": false,
"description": "This option can be used to explicit declare the method name to
use, when using POJOs as the AggregationStrategy." },
- "strategyMethodAllowNull": { "kind": "attribute", "displayName": "Strategy
Method Allow Null", "required": false, "type": "boolean", "javaType":
"java.lang.Boolean", "deprecated": false, "autowired": false, "secret": false,
"defaultValue": false, "description": "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 Aggrega [...]
+ "strategyMethodName": { "kind": "attribute", "displayName": "Strategy
Method Name", "required": false, "type": "string", "javaType":
"java.lang.String", "deprecated": false, "autowired": false, "secret": false,
"description": "This option can be used to explicit declare the method name to
use, when using beans as the AggregationStrategy." },
+ "strategyMethodAllowNull": { "kind": "attribute", "displayName": "Strategy
Method Allow Null", "required": false, "type": "boolean", "javaType":
"java.lang.Boolean", "deprecated": false, "autowired": false, "secret": false,
"defaultValue": false, "description": "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 beans as the Aggrega [...]
"completionSize": { "kind": "attribute", "displayName": "Completion Size",
"required": false, "type": "integer", "javaType": "java.lang.Integer",
"deprecated": false, "autowired": false, "secret": false, "description":
"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 v [...]
"completionInterval": { "kind": "attribute", "displayName": "Completion
Interval", "required": false, "type": "duration", "javaType":
"java.lang.String", "deprecated": false, "autowired": false, "secret": false,
"description": "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." },
"completionTimeout": { "kind": "attribute", "displayName": "Completion
Timeout", "required": false, "type": "duration", "javaType":
"java.lang.String", "deprecated": false, "autowired": false, "secret": false,
"description": "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 [...]
diff --git
a/core/camel-core-model/src/main/java/org/apache/camel/model/AggregateDefinition.java
b/core/camel-core-model/src/main/java/org/apache/camel/model/AggregateDefinition.java
index c079a23..f8d1470 100644
---
a/core/camel-core-model/src/main/java/org/apache/camel/model/AggregateDefinition.java
+++
b/core/camel-core-model/src/main/java/org/apache/camel/model/AggregateDefinition.java
@@ -296,7 +296,7 @@ public class AggregateDefinition extends
OutputDefinition<AggregateDefinition>
}
/**
- * This option can be used to explicit declare the method name to use,
when using POJOs as the AggregationStrategy.
+ * This option can be used to explicit declare the method name to use,
when using beans as the AggregationStrategy.
*/
public void setAggregationStrategyMethodName(String strategyMethodName) {
this.strategyMethodName = strategyMethodName;
@@ -311,7 +311,7 @@ public class AggregateDefinition extends
OutputDefinition<AggregateDefinition>
}
/**
- * This option can be used to explicit declare the method name to use,
when using POJOs as the AggregationStrategy.
+ * This option can be used to explicit declare the method name to use,
when using beans as the AggregationStrategy.
*/
public void setStrategyMethodName(String strategyMethodName) {
this.strategyMethodName = strategyMethodName;
@@ -319,7 +319,7 @@ public class AggregateDefinition extends
OutputDefinition<AggregateDefinition>
/**
* 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
+ * true then null values is used as the oldExchange (at the very first
aggregation), when using beans as the
* AggregationStrategy.
*/
public void setStrategyMethodAllowNull(String strategyMethodAllowNull) {
@@ -888,7 +888,7 @@ public class AggregateDefinition extends
OutputDefinition<AggregateDefinition>
}
/**
- * Sets the method name to use when using a POJO as {@link
AggregationStrategy}.
+ * Sets the method name to use when using a bean as {@link
AggregationStrategy}.
*
* @param methodName the method name to call
* @return the builder
@@ -899,7 +899,7 @@ public class AggregateDefinition extends
OutputDefinition<AggregateDefinition>
}
/**
- * Sets allowing null when using a POJO as {@link AggregationStrategy}.
+ * Sets allowing null when using a bean as {@link AggregationStrategy}.
*
* @return the builder
*/
