diff --git a/docs/src/reference/docbook/router.xml b/docs/src/reference/docbook/router.xml
index cfaa8b91d4..656cc0e971 100644
--- a/docs/src/reference/docbook/router.xml
+++ b/docs/src/reference/docbook/router.xml
@@ -42,7 +42,7 @@
HeaderValueRouter
A HeaderValueRouter will send Messages to the channel based on the individual header value mappings.
- When HeaderValueRouter is created it is initialized with the name of the header to be evaluated, using constructor-arg.
+ When HeaderValueRouter is created it is initialized with the name of the header to be evaluated.
The value of the header could be one of two things:
1. Arbitrary value
@@ -51,47 +51,37 @@
2. Channel name
- If arbitrary value, then a channelResolver should be provided to map header values to channel names.
- The example below uses MapBasedChannelResolver to set up a map of header values to channel names.
-
-
-
-
-
-
-
-
-
-
-]]>
- If channelResolver is not specified, then the header value will be treated as a channel name
- making configuration much simpler, where no channelResolver needs to be specified.
-
-
-
-]]>
+ If arbitrary then additional mapping of these header values to channel names is required, otherwise no additional configuration is needed.
- Similar to the PayloadTypeRouter, configuration of HeaderValueRouter is also supported via namespace support provided by Spring Integration (see ).
- The example below demonstrates two types of namespace-based configuration of HeaderValueRouter which are equivalent to the ones above using Spring Integration namespace support:
+ Similar to the PayloadTypeRouter, configuration of HeaderValueRouter is
+ also supported with the simple namespace-based XML configuration.
+ The example below demonstrates two types of namespace-based configuration of HeaderValueRouter.
- 1. Configuration where mapping of header values to channels is required
+ 1. Configuration where mapping of header values to channels is required
]]>
- 2. Configuration where mapping of header values is not required if header values themselves represent the channel names
+
+ Obviously during the resolution process this router may encounter resolution failures, thus resulting in
+ exception. If you want to suppress such resolution failures and send all messages to the
+ default output channel (i.e., identified with default-output-channel attribute) you may do so by setting
+ ignore-channel-name-resolution-failures to true. This particular attribute may sound confusing when compared with
+ the default-output-channel. So just to clarify, the default-output-channel handles messages where routing
+ information can not be determined. However, in the above scenario route has determined successfully but the
+ resolution of that route failed and that is why we need an extra attribute to let Spring Integration know that it is
+ OK to suppress resolution failures and treat such route as undetermined thus routing messages to the default-output-channel
+
+
+ 2. Configuration where mapping of header values to channel names
+ is not required since header values themselves represent channel names
]]>
+
The two router implementations shown above share some common properties, such as "defaultOutputChannel" and "resolutionRequired".
If "resolutionRequired" is set to "true", and the router is unable to determine a target channel (e.g. there is
@@ -99,6 +89,9 @@
will be thrown.
+
+
+