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 05b8ae35f473f729ce7458e711146fea44e3da33 Author: Otavio Rodolfo Piske <[email protected]> AuthorDate: Wed Sep 4 08:35:32 2024 +0200 CAMEL-21040: fixed grammar, typos and other issues in the route documentation --- .../modules/ROOT/pages/route-configuration.adoc | 54 +++++----- .../modules/ROOT/pages/route-controller.adoc | 16 +-- .../modules/ROOT/pages/route-policy.adoc | 24 ++--- .../modules/ROOT/pages/route-reload.adoc | 22 ++-- .../modules/ROOT/pages/route-template.adoc | 115 +++++++++++---------- 5 files changed, 117 insertions(+), 114 deletions(-) diff --git a/docs/user-manual/modules/ROOT/pages/route-configuration.adoc b/docs/user-manual/modules/ROOT/pages/route-configuration.adoc index db99c1dab88..79f5b3de18a 100644 --- a/docs/user-manual/modules/ROOT/pages/route-configuration.adoc +++ b/docs/user-manual/modules/ROOT/pages/route-configuration.adoc @@ -2,15 +2,15 @@ Camel 3.12 introduces route configuration which is used for separating configurations from the routes. This can be used in situations such as configuring different error handling across a set of routes. -In previous versions of Camel this was more cumbersome to do, as you would either have +In previous versions of Camel, this was more cumbersome to do, as you would either have to copy the same configuration to a set of routes or rely on global error handling configuration. Now you can configure a number of route configurations, and then specify on each route which configuration to use (you can use match by ids, wildcards, and regular expression). -The route configuration is supported by all DSL's, so useable by: Java, XML, Groovy, Kotlin and so forth. +The route configuration is supported by all DSLs, so usable by: Java, XML, Groovy, Kotlin and so forth. -In the route configuration you can setup common strategies for: +In the route configuration, you can set up common strategies for: - xref:error-handler.adoc[Error Handler] - xref:exception-clause.adoc[OnException] @@ -37,10 +37,10 @@ public class MyJavaErrorHandler extends RouteConfigurationBuilder { ---- NOTE: The `RouteConfigurationBuilder` uses `configuration` as the method where the configuration is coded. -This is on purpose not to use the `configure` method which the regular Java DSL `RouteBuilder` +This is on purpose, so as not to use the `configure` method which the regular Java DSL `RouteBuilder` uses for coding Camel routes. -In the example above, then there is only one route configuration which has been assigned the ID _javaError_. +In the example above, then there is only one route configuration that has been assigned the ID `_javaError_`. This ID allows us to refer to this configuration later when you want to assign which routes are using the configuration. This configuration is a basic configuration that just catches and handles all exceptions and logs a WARN message. @@ -70,7 +70,7 @@ public class MyJavaRouteBuilder extends RouteBuilder { } ---- -In the `routeConfigurationId` the configuration to use is specified by the ID, eg _javaError_. +In the `routeConfigurationId` the configuration to use is specified by the ID, eg `_javaError_`. Multiple configurations can be assigned (separated by comma), such as: @@ -79,20 +79,22 @@ Multiple configurations can be assigned (separated by comma), such as: .routeConfigurationId("javaError,myAudit") ---- -The route configurations supports matching by: +The route configuration supports matching by: - exact ID name. This is the sample we have seen above. - wildcard - regular expression. -Wildcards are text ending with a *; they are matched when the configuration ID starts with the specified text followed by any characters. For instance, you can do: +Wildcards are text ending with a `*`. +They are matched when the configuration ID starts with the specified text followed by any characters. +For instance, you can do: [source,java] ---- .routeConfigurationId("java*,myAudit") ---- -Here we use wildcard in _java*_ which means any configuration whose ID starts with java is a match. +Here we use wildcard in `_java*_` which means any configuration whose ID starts with java is a match. Match by regular expression is just like match by wildcard but using regex instead. @@ -101,7 +103,7 @@ Match by regular expression is just like match by wildcard but using regex inste .routeConfigurationId(".*error.*") ---- -Here we want to match any configuration whose ID contains _error_. +Here we want to match any configuration whose ID contains `_error_`. === Adding route configurations to CamelContext @@ -137,7 +139,7 @@ Route configurations are either given an explicit unique ID, or the configuratio A _nameless_ configuration is used as default/fallback configuration, for routes which have *NOT* been explicitly assigned route configurations. -Suppose you have one _nameless_ configuration and another named _retryError_: +Suppose you have one _nameless_ configuration and another named `_retryError_`: [source,java] ---- @@ -167,14 +169,14 @@ And the following two routes: .to("jms:beer"); ---- -In the example above, the _cheese_ route has no route configurations assigned, so the route +In the example above, the `_cheese_` route has no route configurations assigned, so the route will use the default configuration, which in case of an exception will log a warning. -The _beer_ route on the other hand has the route configuration _retryError_ assigned, and this -configuration will in case of an exception retry up to 5 times and then if still an error +The `_beer_` route on the other hand has the route configuration `_retryError_` assigned, and this +configuration will in case of an exception retry up to five times and then if still an error then fail and rollback. -If you add more routes, then those routes can also be assigned the _retryError_ configuration +If you add more routes, then those routes can also be assigned the `_retryError_` configuration if they should also retry in case of error. === Route Configuration with Error Handler @@ -196,17 +198,17 @@ public class MyJavaErrorHandler extends RouteConfigurationBuilder { } ---- -In the example above, the _nameless_ configuration has an error handler with a dead letter queue. -And the route configuration with id _retryError_ does not, and instead it will attempt -to retry the failing message up till 5 times before giving up (exhausted). Because this -route configuration does not have any error handler assigned, then Camel will use the default error handler. +In the example above, the `_nameless_` configuration has an error handler with a dead letter queue. +And the route configuration with id `_retryError_` does not, and instead it will attempt +to retry the failing message up till five times before giving up (exhausted). +Because this route configuration does not have any error handler assigned, then Camel will use the default error handler. IMPORTANT: Routes that have a local error handler defined, will always use this error handler, -instead of the error handler from route configurations. A route can only have 1 error handler. +instead of the error handler from route configurations. A route can only have one error handler. == Route Configuration in XML -When using XML DSL then you can code your route configurations in XML files as shown below: +When using XML DSL, then you can code your route configurations in XML files as shown below: [source,xml] ---- @@ -230,12 +232,12 @@ And in the XML routes you can assign which configurations to use: </route> ---- -In this example the route is assigned the _xmlError_ route configuration by the exact ID. +In this example, the route is assigned the `_xmlError_` route configuration by the exact ID. == Route Configuration in YAML -When using YAML DSL then you can code your route configurations in YAML files as shown below: +When using YAML DSL, then you can code your route configurations in YAML files as shown below: [source,yaml] ---- @@ -274,7 +276,7 @@ And in the YAML routes you can assign which configurations to use: message: "Error from yaml" ---- -In this example the route is assigned the _yamlError_ route configuration by the exact ID. +In this example, the route is assigned the `_yamlError_` route configuration by the exact ID. == Mixing DSLs @@ -318,14 +320,14 @@ Then from `<camelContext>` you can refer to these XML snippets by their ids: </camelContext> ---- -In this example the route is assigned the _xmlError_ route configuration by the exact ID. +In this example, the route is assigned the `_xmlError_` route configuration by the exact ID. == Packaging route configurations in reusable JARs You can package common route configurations into JARs which you can then use together with your Camel applications, by adding the JARs as dependencies to the classpath (such as in Maven pom.xml file). -This allows for example to use a _common practice_ among your Camel applications. +This allows, for example, to use a _common practice_ among your Camel applications. == Logging Summary diff --git a/docs/user-manual/modules/ROOT/pages/route-controller.adoc b/docs/user-manual/modules/ROOT/pages/route-controller.adoc index ea0b3c10620..1efe37ba362 100644 --- a/docs/user-manual/modules/ROOT/pages/route-controller.adoc +++ b/docs/user-manual/modules/ROOT/pages/route-controller.adoc @@ -120,18 +120,18 @@ You can configure the `SupervisingRouteController` using the following options: [width="100%",cols="10%,20%,70%",options="header",] |======================================================================= | Option | Default | Description -| Enabled | `false` | To enable using supervising route controller which allows Camel to startup and then the controller takes care of starting the routes in a safe manner. This can be used when you want to startup Camel despite a route may otherwise fail fast during startup and cause Camel to fail to startup as well. By delegating the route startup to the supervising route controller then its manages the startup using a background thread. The controller allows to be configured with vari [...] +| Enabled | `false` | To enable using supervising route controller which allows Camel to start up, and then, the controller takes care of starting the routes in a safe manner. This can be used when you want to startup Camel despite a route may otherwise fail fast during startup and cause Camel to fail to startup as well. By delegating the route startup to the supervising route controller then its manages the startup using a background thread. The controller allows to be configured with v [...] | InitialDelay | | Initial delay in milliseconds before the route controller starts, after CamelContext has been started. -| BackOffDelay | `2000` | Backoff delay in millis when restarting a route that failed to startup. +| BackOffDelay | `2000` | Backoff delay in milliseconds when restarting a route that failed to startup. | BackOffMaxAttempts | | Backoff maximum number of attempts to restart a route that failed to startup. When this threshold has been exceeded then the controller will give up attempting to restart the route, and the route will remain as stopped. Will by default attempt forever. -| BackOffMaxDelay | | Backoff maximum delay in millis when restarting a route that failed to startup. -| BackOffMaxElapsedTime | | Backoff maximum elapsed time in millis, after which the backoff should be considered exhausted and no more attempts should be made. +| BackOffMaxDelay | | Backoff maximum delay in milliseconds when restarting a route that failed to startup. +| BackOffMaxElapsedTime | | Backoff maximum elapsed time in milliseconds, after which the backoff should be considered exhausted and no more attempts should be made. | BackOffMultiplier | 1.0 | Backoff multiplier to use for exponential backoff. This is used to extend the delay between restart attempts. -| IncludeRoutes | | Pattern for filtering routes to be included as supervised. The pattern is matching on route id, and endpoint uri for the route. Multiple patterns can be separated by comma. For example to include all kafka routes, you can say kafka:. And to include routes with specific route ids myRoute,myOtherRoute. The pattern supports wildcards and uses the matcher from org.apache.camel.support.PatternHelper#matchPattern. -| ExcludeRoutes | | Pattern for filtering routes to be excluded as supervised. The pattern is matching on route id, and endpoint uri for the route. Multiple patterns can be separated by comma. For example to exclude all JMS routes, you can say jms:. And to exclude routes with specific route ids mySpecialRoute,myOtherSpecialRoute. The pattern supports wildcards and uses the matcher from org.apache.camel.support.PatternHelper#matchPattern. +| IncludeRoutes | | Pattern for filtering routes to be included as supervised. The pattern is matched on route id, and endpoint uri for the route. Multiple patterns can be separated by comma. For example, to include all kafka routes, you can say `kafka:`. And to include routes with specific route ids `_myRoute,myOtherRoute_`. The pattern supports wildcards and uses the matcher from `org.apache.camel.support.PatternHelper#matchPattern`. +| ExcludeRoutes | | Pattern for filtering routes to be excluded as supervised. The pattern is matched on route id, and endpoint uri for the route. Multiple patterns can be separated by comma. For example, to exclude all JMS routes, you can say `jms:`. And to exclude routes with specific route ids `_mySpecialRoute,myOtherSpecialRoute_`. The pattern supports wildcards and uses the matcher from `org.apache.camel.support.PatternHelper#matchPattern`. | ThreadPoolSize | `1` | The number of threads used by the route controller scheduled thread pool that are used for restarting routes. The pool uses 1 thread by default, but you can increase this to allow the controller to concurrently attempt to restart multiple routes in case more than one route has problems starting. -| UnhealthyOnExhausted | `true` | Whether to mark the route as unhealthy (down) when all restarting attempts (backoff) have failed and the route is not successfully started and the route manager is giving up. If setting this to false will make health checks ignore this problem and allow to report the Camel application as UP. -| UnhealthyOnRestarting | `true` | Whether to mark the route as unhealthy (down) when the route failed to initially start, and is being controlled for restarting (backoff). If setting this to false will make health checks ignore this problem and allow to report the Camel application as UP. +| UnhealthyOnExhausted | `true` | Whether to mark the route as unhealthy (down) when all restarting attempts (backoff) have failed and the route is not successfully started and the route manager is giving up. If setting this to `false` will make health checks ignore this problem and allow to report the Camel application as UP. +| UnhealthyOnRestarting | `true` | Whether to mark the route as unhealthy (down) when the route failed to initially start, and is being controlled for restarting (backoff). If setting this to false will make health checks ignore this problem and allow reporting the Camel application as UP. |======================================================================= IMPORTANT: The `UnhealthyOnExhausted` and `UnhealthyOnRestarting` options are default `false` in Camel 4.6 or older. diff --git a/docs/user-manual/modules/ROOT/pages/route-policy.adoc b/docs/user-manual/modules/ROOT/pages/route-policy.adoc index db0a7aa39b7..984d7079cda 100644 --- a/docs/user-manual/modules/ROOT/pages/route-policy.adoc +++ b/docs/user-manual/modules/ROOT/pages/route-policy.adoc @@ -31,9 +31,9 @@ example. Camel provides the following policies out of the box: * `org.apache.camel.throttling.ThrottlingInflightRoutePolicy` - a throttling -based policy that automatic suspends/resumes route(s) based on metrics +based policy that automatically suspends/resumes route(s) based on metrics from the current in flight exchanges. You can use this to dynamically -throttle e.g. a xref:components::jms-component.adoc[JMS] consumer, to avoid it consuming too + throttle, e.g. a xref:components::jms-component.adoc[JMS] consumer, to avoid it consuming too fast. * `org.apache.camel.throttling.ThrottlingExceptionRoutePolicy` - a throttling @@ -48,7 +48,7 @@ xref:components::quartz-component.adoc[Quartz] component). == SuspendableService -If you want to dynamic suspend/resume routes then it is advised to +If you want to dynamic suspend/resume routes, then it is advised to use `SuspendableService` as it allows for fine-grained suspend and resume operations. @@ -59,7 +59,7 @@ xref:exchange.adoc[Exchange] is complete, which means that it requires at least one xref:exchange.adoc[Exchange] to be complete before it _works_. -The throttling inflight route policy has the following options: +The throttling in flight route policy has the following options: [width="100%",cols="10%,10%,80%",options="header",] |=== @@ -67,11 +67,11 @@ The throttling inflight route policy has the following options: |Option |Default |Description |`scope` |`Route` |A scope for either `Route` or `Context` which defines if the current -number of inflight exchanges is context based or for that particular +number of in flight exchanges is context based or for that particular route. |`maxInflightExchanges` |`1000` |The maximum threshold when the throttling will start to suspend the -route if the current number of inflight exchanges is higher than this +route if the current number of in flight exchanges is higher than this value. |`resumePercentOfMax` |`70` |A percentage `0..100` which defines when the throttling should resume @@ -86,14 +86,14 @@ again in case it has been suspended. The `ThrottlingInflightRoutePolicy` compared to xref:components:eips:throttle-eip.adoc[Throttler] EIP is that it does *not* block during -throttling. It does throttling that is approximate based, meaning that -its more coarse grained and not explicit precise as the +throttling. Its throttling is approximate-based, meaning that +its coarser grained and not explicitly precise as the xref:components:eips:throttle-eip.adoc[Throttler] EIP. The xref:components:eips:throttle-eip.adoc[Throttler] EIP can be much more accurate and only allow a specific number of messages being -passed per a given time unit. Also the `ThrottlingInflightRoutePolicy` -is based its metrics on number of inflight exchanges where as +passed per a given time unit. Also, the `ThrottlingInflightRoutePolicy` +is based its metrics on number of in flight exchanges whereas xref:components:eips:throttle-eip.adoc[Throttler] EIP is based on number o messages per time unit. @@ -149,7 +149,7 @@ a `org.apache.camel.spi.RoutePolicyFactory` as a factory for creating a `RoutePolicy` instance for each route. This can be used when you want to use the same kind of route policy for all or some routes. -With the factory you only need to configure this once, and every route created will +With the factory, you only need to configure this once, and every route created will have the policy assigned. There is API on `CamelContext` to add a factory, as shown below @@ -167,7 +167,7 @@ And from XML DSL you just define a `<bean>` with the factory, and Camel will aut ---------------------------------------------------------------------- You can have as many route policy factories as you want, so if you have two factories, -you can just add them both as shown: +you can add them both as shown: [source,java] ---------------------------------------------------------- diff --git a/docs/user-manual/modules/ROOT/pages/route-reload.adoc b/docs/user-manual/modules/ROOT/pages/route-reload.adoc index 3bbb89093e2..ea2ea97ae9c 100644 --- a/docs/user-manual/modules/ROOT/pages/route-reload.adoc +++ b/docs/user-manual/modules/ROOT/pages/route-reload.adoc @@ -3,7 +3,7 @@ The route reload functionality in Camel is capable of watching a directory folder for file changes, and then automatic trigger reload of the running routes in the Camel application. -This functionality is intended for development purposes, and not for production use. +This functionality is intended for development purposes and not for production use. NOTE: This feature is not supported when using Camel Quarkus, as you should be using the hot-reloading functionality that comes with Quarkus instead. This functionality @@ -12,7 +12,7 @@ can also reload Java source code changes and much more. == Using route reloading You cannot watch for file changes in the Java classpath. It is only possible to watch -for file changes in the file system (i.e. using `file` and not `classpath`). +for file changes in the file system (i.e., using `file` and not `classpath`). The route reloading can be configured in Java or with Spring Boot, Quarkus in the following way: @@ -58,19 +58,19 @@ You can configure the `RouteWatcherReloadStrategy` using the following options: [width="100%",cols="2,5,^1,2",options="header"] |======================================================================= | Name | Description | Default | Type -| routesReloadDirectory | Directory to scan for route changes. Camel cannot scan the classpath, so this must be configured to a file directory. Development with Maven as build tool, you can configure the directory to be src/main/resources to scan for Camel routes in XML or YAML files. | src/main/resources/camel | String -| routesReloadDirectoryRecursive | Whether the directory to scan should include sub-directories. Depending on the number of sub-directories, then this can cause the JVM to startup slower as Camel uses the JDK file-watch service to scan for file changes. | false | boolean -| routesReloadEnabled | Used for enabling automatic routes reloading. If enabled then Camel will watch for file changes in the given reload directory, and trigger reloading routes if files are changed. | false | boolean -| routesReloadPattern | Used for inclusive filtering of routes from directories. Typical used for specifying to accept routes in XML or YAML files. The default pattern is \*.yaml,*.xml Multiple patterns can be specified separated by comma. | \*.yaml,*.xml | String -| routesReloadRemoveAllRoutes | When reloading routes should all existing routes be stopped and removed. By default, Camel will stop and remove all existing routes before reloading routes. This ensures that only the reloaded routes will be active. If disabled then only routes with the same route id is updated, and any existing routes are continued to run. | true | boolean +| `routesReloadDirectory` | Directory to scan for route changes. Camel cannot scan the classpath, so this must be configured to a file directory. Development with Maven as build tool, you can configure the directory to be `src/main/resources` to scan for Camel routes in XML or YAML files. | `src/main/resources/camel` | String +| `routesReloadDirectoryRecursive` | Whether the directory to scan should include subdirectories. Depending on the number of sub-directories, then this can cause the JVM to start up slower as Camel uses the JDK file-watch service to scan for file changes. | `false` | boolean +| `routesReloadEnabled` | Used for enabling automatic routes reloading. If enabled, then Camel will watch for file changes in the given reload directory, and trigger reloading routes if files are changed. | `false` | boolean +| `routesReloadPattern` | Used for inclusive filtering of routes from directories. Typical used for specifying to accept routes in XML or YAML files. The default pattern is \*.yaml,*.xml Multiple patterns can be specified separated by comma. | `\*.yaml,*.xml` | String +| `routesReloadRemoveAllRoutes` | When reloading routes should all existing routes be stopped and removed. By default, Camel will stop and remove all existing routes before reloading routes. This ensures that only the reloaded routes will be active. If disabled, then only routes with the same route id are updated, and any existing routes are continued to run. | `true` | boolean |======================================================================= === Must use route id's -When using route reload then it is recommended to assign id's to your routes, so Camel -knows exactly which routes have been updated. This is necessary because Camel -must stop the existing routes from running, before they can be updated. +When using route reload, then it is recommended to assign id's to your routes, so Camel +knows exactly which routes have been updated. +This is necessary because Apache Camel must stop the existing routes from running before they can be updated. And adding new routes is therefore possible as they would have a new unique route id specified. @@ -78,7 +78,7 @@ And adding new routes is therefore possible as they would have a new unique rout See related xref:context-reload.adoc[]. -See the following examples that comes with live reloading enabled: +See the following examples that come with live reloading enabled: - https://github.com/apache/camel-examples/tree/main/main-xml[camel-examples/examples/main-xml] - https://github.com/apache/camel-examples/tree/main/main-yaml[camel-examples/examples/main-yaml] diff --git a/docs/user-manual/modules/ROOT/pages/route-template.adoc b/docs/user-manual/modules/ROOT/pages/route-template.adoc index fbb9339f46d..fc94648f986 100644 --- a/docs/user-manual/modules/ROOT/pages/route-template.adoc +++ b/docs/user-manual/modules/ROOT/pages/route-template.adoc @@ -6,7 +6,7 @@ route templates are parameterized routes. _Route template_ + _input parameters_ => _route_ -From a route template you can create one or more routes. +From a route template, you can create one or more routes. == Defining route templates in the DSL @@ -70,15 +70,15 @@ And in XML DSL </routeTemplates> ---- -In the examples above there was one route template, but you can define as many as you want. +In the examples above, there was one route template, but you can define as many as you want. Each template must have a unique id. The template parameters are used for defining the parameters -the template accepts. As you can see there are 3 parameters: name, greeting, and myPeriod. The first two -parameters are mandatory, whereas myPeriod is optional as it has a default value of 3s. +the template accepts. As you can see, there are three parameters: `_name_`, `_greeting_`, and `_myPeriod_`. The first two +parameters are mandatory, whereas `_myPeriod_` is optional as it has a default value of 3s. The template parameters are then used in the route as regular property placeholders with the `{{ }}` syntax. Notice how we use `{\{name}}` and `{\{greeting}}` in the timer endpoint and the simple language. -The route can of course also use regular property placeholders as well. +The route can, of course, use regular property placeholders as well. Now imagine there was a property placeholder with the name greeting: [source,properties] @@ -86,7 +86,7 @@ Now imagine there was a property placeholder with the name greeting: greeting = Davs ---- -Then Camel would normally have used this value `Davs` when creating the route. However as the route template +Then Camel would normally have used this value `Davs` when creating the route. However, as the route template has defined a template parameter with the same name `greeting` then a value must be provided when creating routes from the template. @@ -113,7 +113,7 @@ TemplatedRouteBuilder.builder(context, "myTemplate") .add(); ---- -And in Java DSL +And in Java DSL: [source,java] ---- @@ -126,7 +126,7 @@ templatedRoute("myTemplate") .parameter("myPeriod", "5s"); ---- -And in Spring XML DSL +And in Spring XML DSL: [source,xml] ---- @@ -143,7 +143,7 @@ And in Spring XML DSL </camelContext> ---- -And in XML DSL +And in XML DSL: [source,xml] ---- @@ -160,7 +160,7 @@ And in XML DSL </templatedRoutes> ---- -And in YAML DSL +And in YAML DSL: [source,yaml] ---- @@ -201,7 +201,7 @@ TemplatedRouteBuilder.builder(context, "myTemplate") .add(); ---- -And in Java DSL +And in Java DSL: [source,java] ---- @@ -212,7 +212,7 @@ templatedRoute("myTemplate") .parameter("myPeriod", "5s"); ---- -And in Spring XML DSL +And in Spring XML DSL: [source,xml] ---- @@ -225,7 +225,7 @@ And in Spring XML DSL </camelContext> ---- -And in XML DSL +And in XML DSL: [source,xml] ---- @@ -238,7 +238,7 @@ And in XML DSL </templatedRoutes> ---- -And in YAML DSL +And in YAML DSL: [source,yaml] ---- @@ -256,10 +256,10 @@ And in YAML DSL === Using template parameters with Java DSL simple builder -When using Java DSL and simple language then beware that you should +When using Java DSL and simple language, then beware that you should not use the _simple fluent builder_ when defining the simple expressions/predicates. -For example given the following route template in Java DSL: +For example, given the following route template in Java DSL: [source,java] ---- @@ -291,10 +291,10 @@ Instead, the simple expression should be a literal String value _only_ as follow === Using hardcoded node IDs in route templates -If route templates contains hardcoded node IDs then routes created from templates will use the same IDs -and therefore if 2 or more routes are created from the same template, you will have _duplicate id detected_ error. +If route templates contain hardcoded node IDs, then routes created from templates will use the same IDs. +Therefore, if two or more routes are created from the same template, you will have _duplicate id detected_ error. -Given the route template below, then it has hardcoded ID (_new-order_) in node calling the http services. +Given the route template below, then it has hardcoded ID (`_new-order_`) in node calling the http services. [source,java] ---- @@ -311,11 +311,11 @@ public class MyRouteTemplates extends RouteBuilder { } ---- -When creating routes from templates, you can then provide a _prefix_ which are used for all node IDs. +When creating routes from templates, you can then provide a _prefix_ which is used for all node IDs. This allows to create 2 or more routes without _duplicate id_ errors. -For example in the following we create a new route _myCoolRoute_ from the _myTemplate_ template, and -use a prefix of _web_. +For example in the following, we create a new route `_myCoolRoute_` from the `_myTemplate_` template, and +use a prefix of `_web_`. And in Java DSL @@ -337,7 +337,7 @@ templatedRoute("orderTemplate") .parameter("queue", "order.ftp"); ---- -And in Spring XML DSL +And in Spring XML DSL: [source,xml] ---- @@ -348,7 +348,7 @@ And in Spring XML DSL </camelContext> ---- -And in XML DSL +And in XML DSL: [source,xml] ---- @@ -359,7 +359,7 @@ And in XML DSL </templatedRoutes> ---- -And in YAML DSL +And in YAML DSL: [source,yaml] ---- @@ -374,10 +374,10 @@ And in YAML DSL == Binding beans to route template -The route template allows to bind beans which is local scoped and only used as part of creating routes from the template. -This allows to use the same template to create multiple routes, where beans are local (private) for each created route. +The route template allows binding beans that are locally scoped and only used as part of creating routes from the template. +This allows using the same template to create multiple routes, where beans are local (private) for each created route. -For example given the following route template where we use `templateBean` to setup the local bean as shown: +For example, given the following route template where we use `templateBean` to set up the local bean as shown: [source,java] ---- @@ -393,27 +393,27 @@ routeTemplate("s3template") ---- The template has two parameters to specify the AWS region and the S3 bucket. To connect to S3 -then a `software.amazon.awssdk.services.s3.S3Client` bean is needed. +then a `software.amazon.awssdk.services.s3.S3Client` bean is necessary. -To create this bean we specify this with the `templateBean` DSL where we specify the bean id as `myClient`. -The type of the bean can be specified (`S3Client.class`) however it is optional +To create this bean, we specify this with the `templateBean` DSL where we specify the bean id as `myClient`. +The type of the bean can be specified (`S3Client.class`), however, it is optional (can be used if you need to let beans be discovered by type and not by name). -This ensures that the code creating the bean is executed later ( when Camel is creating a route from the template), +This ensures that the code creating the bean is executed later (when Camel is creating a route from the template), then the code must be specified as a _supplier_. Because we want during creation of the bean access to template parameters, -we use a Camel `BeanSupplier` which gives access to `RouteTemplateContext` that is the _rtc_ variable in the code above. +we use a Camel `BeanSupplier` which gives access to `RouteTemplateContext` that is the `_rtc_` variable in the code above. IMPORTANT: The local bean with id `myClient` *must* be referred to using Camel's property placeholder syntax, eg `{\{myClient}}` in the route template, as shown above with the _to_ endpoint. This is because the local bean must be made unique and Camel will internally re-assign the bean id to use a unique id instead of `myClient`. And this is done with the help of the property placeholder functionality. -If multiple routes are created from this template, then each of the created routes, have their own -S3Client bean created. +If multiple routes are created from this template, then each of the created routes have their own +`S3Client` bean created. === Binding beans to route templates from template builder -The `TemplatedRouteBuilder` also allows to bind local beans (which allows to specify those beans) when +The `TemplatedRouteBuilder` also allows to bind local beans (which allows specifying those beans) when creating routes from existing templates. Suppose the route template below is defined in XML: @@ -434,7 +434,7 @@ Suppose the route template below is defined in XML: The template has no bean bindings for `#{\{myClient}}` which would be required for creating the template. When creating routes form the template via `TemplatedRouteBuilder` then you can provide the bean binding -if you desire the bean to be local scoped (not shared with others): +if you desire the bean to be locally scoped (not shared with others): [source,java] ---- @@ -451,7 +451,7 @@ TemplatedRouteBuilder.builder(context, "s3template") As you can see the binding is similar to when using `templateBean` directly in the route template. -And in Java DSL +And in Java DSL: [source,java] ---- @@ -466,7 +466,7 @@ templatedRoute("s3template") ---- <1> Note that the third parameter of the `bean` method is not directly the bean but rather a factory method that will be used to create the bean, here we use a lambda expression as factory method. -And in XML DSL +And in XML DSL: [source,xml] ---- @@ -486,7 +486,7 @@ And in XML DSL ---- <1> For non-Java DSL, in case of a complex bean factory, you can still rely on a language like `groovy` to define your bean factory inside a `script` element. -And in YAML DSL +And in YAML DSL: [source,yaml] ---- @@ -526,7 +526,7 @@ TemplatedRouteBuilder.builder(context, "s3template") .add(); ---- -And in Java DSL +And in Java DSL: [source,java] ---- @@ -544,12 +544,12 @@ a new route is created from the route template. However, the latter gives freedo === Binding beans to route templates using bean types You can create a local bean by referring to a fully qualified class name which Camel will use to create -a new local bean instance. When using this the created bean is created via default constructor of the class. +a new local bean instance. When using this, the created bean is created via default constructor of the class. The bean instance can be configured with properties via getter/setter style. The previous example with creating the AWS S3Client would not support this kind as this uses _fluent builder_ pattern (not getter/setter). -TIP: In *Camel 4.6* onwards you can also use constructor arguments for beans +TIP: In *Camel 4.6* onwards, you can also use constructor arguments for beans So suppose we have a class as follows: @@ -583,7 +583,7 @@ routeTemplate("barTemplate") .to("bean:{{myBar}}") ---- -With Java DSL you can also refer to the bean class using type safe way: +With Java DSL, you can also refer to the bean class using type safe way: [source,java] ---- @@ -619,9 +619,9 @@ In XML DSL you would do: === Binding beans to route templates using scripting languages You can use scripting languages like groovy, java, mvel to create the bean. -This allows to define route templates with the scripting language built-in (such as groovy). +This allows defining route templates with the scripting language built-in (such as groovy). -For example creating the AWS S3 client can be done as shown in Java (with inlined groovy code): +For example, creating the AWS S3 client can be done as shown in Java (with inlined groovy code): [source,java] ---- @@ -685,7 +685,7 @@ The route template in XML DSL can then also use groovy language to create the be </camelContext> ---- -Notice how the groovy code can be inlined directly in the route template in XML also. Of course you can also externalize +Notice how the groovy code can be inlined directly in the route template in XML also. Of course, you can also externalize the bean creation code to an external file, by using `resource:` as prefix: [source,xml] @@ -711,11 +711,11 @@ The languages supported are: |=== | Type | Description | bean | Calling a method on a Java class to create the bean. -| groovy | Using groovy script to create the bean. -| java | Java code which are runtime compiled (using jOOR library) to create the bean. -| mvel | To use Mvel template script to create the bean. +| groovy | Using a groovy script to create the bean. +| java | Java code which is runtime compiled (using jOOR library) to create the bean. +| mvel | To use a Mvel template script to create the bean. | ognl | To use OGNL template script to create the bean. -| _name_ | To use a 3rd party language by the given _name_ to create the bean. +| _name_ | To use a third-party language by the given `_name_` to create the bean. |=== Camel will bind `RouteTemplateContext` as the root object with name `rtc` when evaluating the script. @@ -764,7 +764,7 @@ then you can call this method from the route template in XML DSL: </camelContext> ---- -The method signature of createS3Client must then have 1 parameter for the `RouteTemplateContext` as shown: +The method signature of createS3Client must then have one parameter for the `RouteTemplateContext` as shown: [source,java] ---- @@ -833,11 +833,11 @@ routeTemplate("myTemplate") The route templates can be dumped as XML from the `ManagedCamelContextMBean` MBean via the `dumpRouteTemplatesAsXml` operation. -== Creating routes from properties file +== Creating routes from a properties file When using `camel-main` you can specify the parameters for route templates in `application.properties` file. -For example given the route template below (from a `RouteBuilder` class): +For example, given the route template below (from a `RouteBuilder` class): [source,java] ---- @@ -866,10 +866,11 @@ camel.route-template[1].result=cheese The SPI interface `org.apache.camel.spi.RouteTemplateParameterSource` can be used to implement custom sources that are used during startup of Camel to create routes via the templates with parameters from the custom source(s). -For example a custom source can be implemented to read parameters from a shared database that Camel uses during startup -to create routes. This allows to externalize these parameters and as well to easily add more routes with varying parameters. +For example, a custom source can be implemented to read parameters from a shared database that Camel uses during startup +to create routes. +This allows externalizing these parameters and as well to easily add more routes with varying parameters. -To let Camel discover custom sources then register the source into the Camel registry. +To let Camel discover custom sources, then register the source into the Camel registry. == See Also
