Routers Outside a Chain
-
-
-
-
-
-
-
-
-
-
- Attribute
- router
- header value router
- xpath router
- payload type router
- recipient list router
- exception type router
-
-
-
-
- apply-sequence
- xxxxxxx
-
-
- default-output-channel
- xxxxxx
-
-
- resolution-required
- xxxxxx
-
-
- ignore-send-failures
- xxxxxx
-
-
- timeout
- xxxxxx
-
-
- id
- xxxxxx
-
-
- auto-startup
- xxxxxx
-
-
- input-channel
- xxxxxx
-
-
- order
- xxxxxx
-
-
- channel-resolver
- x
-
-
- method
- x
-
-
- ref
- x
-
-
- expression
- x
-
-
- header-name
- x
-
-
- evaluate-as-string
- x
-
-
- xpath-expression-ref
- x
-
-
-
-
-
Routers Inside a Chain
-
-
-
-
-
-
-
-
+
+ Spring Integration provides the following routers out-of-the-box:
+
+
+
+ Payload Type Router
+
+
+ Header Value Router
+
+
+ Recipient List Router
+
+
+ XPath Router (Part of the XML Module)
+
+
+ Error Message Exception Type Router
+
+
+ (Generic) Router
+
+
+
+ Router implementations share many configuration parameters. Yet, certain differences
+ exist between routers. Furthermore, the availability of configuration parameters
+ depends on whether Routers are used inside or outside of a chain. In order to
+ provide a quick overview, all available attributes are listed in the 2 tables
+ below.
+
+
-
- Router parameters have been more standardized across all router implementations
- in Spring Integration 2.1. Consequently, there are a few minor changes that
- leave the possibility of breaking older Spring Integration based applications.
-
-
- Since Spring Integration 2.1 the "ignore-channel-name-resolution-failures"
- attribute was removed in favor of consolidating its behavior with the
- "resolution-required" attribute. Also, the "resolution-required" attribute
- now defaults to "true".
-
- Prior to these changes, the "resolution-required" attribute defaulted to false
- causing messages to be dropped silently when no channel was resolved and
- no "default-output-channel" was set.
-
- The new behavior will require at least one resolved channel and by default
- will throw an Exception if no channel was determined (or an attempt to send
- was not successful).
-
- If you do desire to drop messages silently simply set "default-output-channel='nullChannel'".
-
-
-
- Router Implementations
-
- Since content-based routing often requires some domain-specific logic, most use-cases will require
- Spring Integration's options for delegating to POJOs using the XML namespace support and/or Annotations.
- Both of these are discussed below, but first we present a couple implementations that are available
- out-of-the-box since they fulfill common requirements.
-
-
- PayloadTypeRouter
+
+
+
+ Router parameters have been more standardized across all router implementations
+ with Spring Integration 2.1. Consequently, there are a few minor changes that
+ leave the possibility of breaking older Spring Integration based applications.
+
+
+ Since Spring Integration 2.1 the ignore-channel-name-resolution-failures
+ attribute is removed in favor of consolidating its behavior with the
+ resolution-required attribute. Also, the resolution-required attribute
+ now defaults to true.
+
+
+ Prior to these changes, the resolution-required attribute defaulted
+ to false causing messages to be silently dropped when no channel was
+ resolved and no default-output-channel was set.
+
+ The new behavior will require at least one resolved channel and by default
+ will throw an MessageDeliveryException if no channel was
+ determined (or an attempt to send was not successful).
+
+
+ If you do desire to drop messages silently simply set default-output-channel="nullChannel".
+
+
+
+
+ Common Router Parameters
+
+ Inside and Outside of a Chain
+ The following parameters are valid for all routers inside and outside of
+ chains.
+
+
+ apply-sequence
+
+
+ This attribute specifies whether sequence number and
+ size headers should be added to each Message. This
+ optional attribute defaults
+ to false.
+
+
+
+ default-output-channel
+
+
+ If set, this attribute provides a reference to the
+ channel, where Messages should be sent, if channel
+ resolution fails to return any channels. If no default
+ output channel is provided, the router will throw an Exception.
+ If you would like to silently drop those messages instead,
+ add the nullChannel as the default output
+ channel attribute value.
+
+
+
+ resolution-required
+
+
+ If true this attribute specifies
+ that channel names must always be successfully resolved
+ to channel instances that exist. If set to
+ true, a MessagingException
+ will be raised, in case the channel cannot be resolved.
+ Setting this attribute to false,
+ will cause any unresovable channels to be ignored. This
+ optional attribute will, if not
+ explicitly set, default to true.
+
+
+
+ ignore-send-failures
+
+
+ If set to true, any failures that
+ occur while trying to send to a single channel will be
+ ignored. Otherwise, a MessageDeliveryExceptions
+ will be thrown. This attribute defaults to
+ false.
+
+
+
+ timeout
+
+
+ The timeout attribute specifies the maximum
+ amount of time in milliseconds to wait, when
+ sending Messages to the target Message Channels. By default
+ the send operation will block indefinitely.
+
+
+
+
+
+
+ Top-Level (Outside of a Chain)
+
+ The following parameters are valid only across all top-level routers that are
+ ourside of chains.
+
+
+
+ id
+
+
+ Identifies the underlying Spring bean definition which
+ in case of Routers is an instance of EventDrivenConsumer or
+ PollingConsumer depending on whether the Router's
+ input-channel is a
+ SubscribableChannel or
+ PollableChannel, respectively.
+ This is an optional attribute.
+
+
+
+ auto-startup
+
+
+ This Lifecycle attribute signaled if this
+ component should be started during startup of the Application
+ Context. This optional
+ attribute defaults to true.
+
+
+
+ input-channel
+
+
+ The receiving Message channel of this endpoint.
+
+
+
+ order
+
+
+ This attribute defines the order for invocation when
+ this endpoint is connected as a subscriber to a channel.
+ This is particularly relevant when that channel is using a
+ failover dispatching strategy. It
+ has no effect when this endpoint itself is a Polling
+ Consumer for a channel with a queue.
+
+
+
+
+
+
+
+
+ Router Implementations
- A PayloadTypeRouter will send Messages to the channel as defined by payload-type
- mappings.
-
+ Since content-based routing often requires some domain-specific logic, most use-cases will require
+ Spring Integration's options for delegating to POJOs using the XML namespace support and/or Annotations.
+ Both of these are discussed below, but first we present a couple implementations that are available
+ out-of-the-box since they fulfill common requirements.
+
+
+ PayloadTypeRouter
+
+ A PayloadTypeRouter will send Messages to the channel as defined by payload-type
+ mappings.
+
]]>
-
-
- Configuration of the PayloadTypeRouter is also supported via the namespace provided by Spring Integration (see ),
- which essentially simplifies configuration by combining the <router/> configuration and its corresponding implementation
- defined using a <bean/> element
- into a single and more concise configuration element.
- The example below demonstrates a PayloadTypeRouter configuration which is equivalent to the one above using the namespace support:
-
-
-
-
-
+
+
+ Configuration of the PayloadTypeRouter is also supported via the namespace provided by Spring Integration (see ),
+ which essentially simplifies configuration by combining the <router/> configuration and its corresponding implementation
+ defined using a <bean/> element
+ into a single and more concise configuration element.
+ The example below demonstrates a PayloadTypeRouter configuration which is equivalent to the one above using the namespace support:
+
+
+
+
]]>
-
-
-
- HeaderValueRouter
-
- A HeaderValueRouter will send Messages to the channel based on the individual header value mappings.
- When a 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
-
-
- 2. Channel name
-
-
- If arbitrary then additional mappings for these header values to channel names is required, otherwise no additional configuration is needed.
-
-
- Spring Integration provides a simple namespace-based XML configuration to configure a HeaderValueRouter.
- The example below demonstrates two types of namespace-based configuration for the HeaderValueRouter.
-
- 1. Configuration where mapping of header values to channels is required
-
-
-
-
+
+
+ HeaderValueRouter
+
+ A HeaderValueRouter will send Messages to the channel based on the individual header value mappings.
+ When a 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
+
+
+ 2. Channel name
+
+
+ If arbitrary then additional mappings for these header values to channel names is required, otherwise no additional configuration is needed.
+
+
+ Spring Integration provides a simple namespace-based XML configuration to configure a HeaderValueRouter.
+ The example below demonstrates two types of namespace-based configuration for the HeaderValueRouter.
+
+ 1. Configuration where mapping of header values to channels is required
+
+
+
]]>
-
-
- During the resolution process this router may encounter channel resolution failures, causing an
- exception. If you want to suppress such exceptions and send unresolved messages to the default output channel
- (identified with the default-output-channel attribute) set ignore-channel-name-resolution-failures to true.
- Normally, messages for which the header value is not explicitly mapped to a channel will be sent to the default-output-channel.
- However, in cases where the header value is mapped to a channel name but the channel cannot be resolved, setting
- the ignore-channel-name-resolution-failures
- attribute to true will result in routing such 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 attributes, such as default-output-channel and resolution-required.
- If resolution-required is set to true, and the router is unable to determine a target channel (e.g. there is
- no matching payload for a PayloadTypeRouter and no default-output-channel has been specified), then an Exception
- will be thrown.
-
-
-
-
-
-
- RecipientListRouter
-
- A RecipientListRouter will send each received Message to a statically defined
- list of Message Channels:
-
+
+ During the resolution process this router may encounter channel
+ resolution failures, causing an exception. If you want to suppress
+ such exceptions and send unresolved messages to the default output
+ channel (identified with the default-output-channel
+ attribute) set resolution-required to false.
+
+
+ Normally, messages for which the header value is not explicitly
+ mapped to a channel will be sent to the default-output-channel.
+ However, in cases where the header value is mapped to a channel
+ name but the channel cannot be resolved, setting the resolution-required
+ attribute to false will result in routing such messages
+ to the default-output-channel.
+
+
+
+ With Spring Integration 2.1 the attribute was changed from
+ ignore-channel-name-resolution-failures to
+ resolution-required. Attribute resolution-required
+ will default to true.
+
+
+ 2. Configuration where mapping of header values to channel names
+ is not required since header values themselves represent channel names
+
+ ]]>
+
+
+ Since Spring Integration 2.1 the behavior of resolving channels is
+ more explicit. For example, if you ommit the default-output-channel attribute
+ and the Router was unable to resolve at least one valid channel, and any channel name resolution
+ failures were ignored by setting resolution-required to false, then a
+ MessageDeliveryException is thrown.
+
+
+ Basically, by default the Router must be able to route messages
+ successfully to at least one channel. If you really want to
+ drop messages, you must also have default-output-channel
+ set to nullChannel.
+
+
+
+
+ RecipientListRouter
+
+ A RecipientListRouter will send each received Message to a statically defined
+ list of Message Channels:
+
@@ -339,378 +489,442 @@
]]>
-
-
-
- Spring Integration also provides namespace support for the RecipientListRouter configuration (see )
- as the example below demonstrates.
-
-
-
+
+
+ Spring Integration also provides namespace support for the RecipientListRouter configuration (see )
+ as the example below demonstrates.
+
+
+
]]>
-
-
- The 'apply-sequence' flag here has the same effect as it does for a publish-subscribe-channel,
- and like a publish-subscribe-channel, it is disabled by default on the recipient-list-router. Refer to
- for more information.
-
-
-
- Another convenient option when configuring a RecipientListRouter is to use Spring Expression Language (SpEL) support
- as selectors for individual recipient channels. This is similar to using a Filter at the beginning of 'chain' to act as a "Selective Consumer".
- However, in this case, it's all combined rather concisely into the router's configuration.
-
-
-
-
+
+
+ The 'apply-sequence' flag here has the same effect as it does for a publish-subscribe-channel,
+ and like a publish-subscribe-channel, it is disabled by default on the recipient-list-router. Refer to
+ for more information.
+
+
+ Another convenient option when configuring a RecipientListRouter is to use Spring Expression Language (SpEL) support
+ as selectors for individual recipient channels. This is similar to using a Filter at the beginning of 'chain' to act as a "Selective Consumer".
+ However, in this case, it's all combined rather concisely into the router's configuration.
+
+
+
+
]]>
- In the above configuration a SpEL expression identified by the selector-expression attribute will be evaluated to determine if this recipient
- should be included in the recipient list for a given input Message. The evaluation result of the expression must be a boolean. If this
- attribute is not defined, the channel will always be among the list of recipients.
-
-
-
-
-
- Routing and Error handling
-
-
- Spring Integration also provides a special type-based router called ErrorMessageExceptionTypeRouter for routing
- Error Messages (Messages whose payload is a Throwable instance).
- ErrorMessageExceptionTypeRouter is very similar to the PayloadTypeRouter.
- In fact they are almost identical. The only difference is that while PayloadTypeRouter navigates
- the instance hierarchy of a payload instance (e.g., payload.getClass().getSuperclass()) to find the most
- specific type/channel mappings, the ErrorMessageExceptionTypeRouter navigates the hierarchy of
- 'exception causes' (e.g., payload.getCause()) to find the most specific Throwable type/channel mappings.
-
-
- Below is a sample configuration for ErrorMessageExceptionTypeRouter.
-
-
-
-
+
+ In the above configuration a SpEL expression identified by the selector-expression attribute will be evaluated to determine if this recipient
+ should be included in the recipient list for a given input Message. The evaluation result of the expression must be a boolean. If this
+ attribute is not defined, the channel will always be among the list of recipients.
+
+
+
+
+ XPath Router
+ The XPath Router is part of the XML Module. As such, please read chapter
+
+
+
+
+
+ Routing and Error handling
+
+
+ Spring Integration also provides a special type-based router called ErrorMessageExceptionTypeRouter for routing
+ Error Messages (Messages whose payload is a Throwable instance).
+ ErrorMessageExceptionTypeRouter is very similar to the PayloadTypeRouter.
+ In fact they are almost identical. The only difference is that while PayloadTypeRouter navigates
+ the instance hierarchy of a payload instance (e.g., payload.getClass().getSuperclass()) to find the most
+ specific type/channel mappings, the ErrorMessageExceptionTypeRouter navigates the hierarchy of
+ 'exception causes' (e.g., payload.getCause()) to find the most specific Throwable type/channel mappings.
+
+
+ Below is a sample configuration for ErrorMessageExceptionTypeRouter.
+
+
+
+ ]]>
-
-
+
+
+
+ Configuring (Generic) Router
+
+ Configuring a Content Based Router with XML
+
+ The "router" element provides a simple way to connect a router to an input channel and also accepts the
+ optional default-output-channel attribute. The ref attribute references the bean name of a custom Router implementation
+ (extending AbstractMessageRouter):
+
-
- Configuring Router
-
- Configuring a Content Based Router with XML
-
- The "router" element provides a simple way to connect a router to an input channel and also accepts the
- optional default-output-channel attribute. The ref attribute references the bean name of a custom Router implementation
- (extending AbstractMessageRouter):
-
+
-
+
-
+]]>
- Alternatively, ref may point to a simple POJO that contains the @Router annotation (see below), or the
- ref may be combined with an explicit method name. Specifying a method applies the same behavior
- described in the @Router annotation section below.
- ]]>
- Using a ref attribute is generally recommended if the custom router implementation is referenced in other
- <router> definitions. However if the custom router implementation should be scoped to a
- single definition of the <router>, you may provide an inner bean definition:
-
-
+
+ Alternatively, ref may point to a simple POJO that contains the @Router annotation (see below), or the
+ ref may be combined with an explicit method name. Specifying a method applies the same behavior
+ described in the @Router annotation section below.
+
+
+ ]]>
+
+
+ Using a ref attribute is generally recommended if the custom router implementation is referenced in other
+ <router> definitions. However if the custom router implementation should be scoped to a
+ single definition of the <router>, you may provide an inner bean definition:
+
+
+
+
]]>
-
-
-
- Using both the ref attribute and an inner handler definition in the same <router> configuration
- is not allowed, as it creates an ambiguous condition, and an Exception will be thrown.
-
-
-
- Routers and the Spring Expression Language (SpEL)
-
-
- Sometimes the routing logic may be simple and writing a separate class for it and configuring it as a bean may seem
- like overkill. As of Spring Integration 2.0 we offer an alternative where you can now use
- SpEL
- to implement simple computations that previously required a custom POJO router. Generally a SpEL expression is evaluated and the
- result is mapped to a channel:
-
-
-
-
-
-]]>
-
- To simplify things even more, the SpEL expression may evaluate to a channel name:
-
- ]]>
- In the above configuration the result channel will be computed by the SpEL expression which simply concatenates the value
- of the payload with the literal String 'Channel'.
-
-
-
- Another value of SpEL for configuring routers is that an expression can actually return a Collection,
- effectively making every <router> a Recipient List Router. Whenever the expression returns
- multiple channel values the Message will be forwarded to each channel.
-
- ]]>
-
- In the above configuration, if the Message includes a header with the name 'channels' the value of which is a
- List of channel names then the Message will be sent to each channel in the list.
-
- You may also find Collection Projection and Collection Selection
- expressions useful to select multiple channels.
- See "http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/expressions.html#d0e12084"
-
-
+
+
+ Using both the ref attribute and an inner handler definition in the same <router> configuration
+ is not allowed, as it creates an ambiguous condition, and an Exception will be thrown.
+
+
+
+ Routers and the Spring Expression Language (SpEL)
+
+
+ Sometimes the routing logic may be simple and writing a separate class for
+ it and configuring it as a bean may seem like overkill. As of Spring Integration 2.0
+ we offer an alternative where you can now use SpEL to implement simple
+ computations that previously required a custom POJO router.
+
+
+
+ For more information about the Spring Expression Language, please
+ refer to the respective chapter in the Spring Framework Reference
+ Documentation at:
+
+
+
+
+
+
+ Generally a SpEL expression is evaluated and the result is mapped to
+ a channel:
+
-
- Configuring a Router with Annotations
-
- When using @Router to annotate a method, the method may return either a
- MessageChannel or String type. In the latter case,
- the endpoint will resolve the channel name as it does for the default output channel. Additionally, the method may return
- either a single value or a collection. If a collection is returned, the reply message will be sent to multiple
- channels. To summarize, the following method signatures are all valid.
- @Router
+
+
+
+
+]]>
+
+
+ To simplify things even more, the SpEL expression may evaluate to a channel name:
+
+
+ ]]>
+
+
+ In the above configuration the result channel will be computed by the SpEL
+ expression which simply concatenates the value of the payload
+ with the literal String 'Channel'.
+
+
+ Another value of SpEL for configuring routers is that an expression can actually return a Collection,
+ effectively making every <router> a Recipient List Router. Whenever the expression returns
+ multiple channel values the Message will be forwarded to each channel.
+
+
+ ]]>
+
+
+ In the above configuration, if the Message includes a header with the name 'channels' the value of which is a
+ List of channel names then the Message will be sent to each channel in the list.
+
+ You may also find Collection Projection and Collection Selection
+ expressions useful to select multiple channels. For further information,
+ please see:
+
+
+
+
+
+
+
+
+
+
+
+ Configuring a Router with Annotations
+
+ When using @Router to annotate a method, the method may return either a
+ MessageChannel or String type. In the latter case,
+ the endpoint will resolve the channel name as it does for the default output channel. Additionally, the method may return
+ either a single value or a collection. If a collection is returned, the reply message will be sent to multiple
+ channels. To summarize, the following method signatures are all valid.
+
+
+ route(Message message) {...}
@Router
public String route(Foo payload) {...}
@Router
-public List<String> route(Foo payload) {...}
-
-
- In addition to payload-based routing, a Message may be routed based on metadata available within the
- message header as either a property or attribute. In this case, a method annotated with @Router
- may include a parameter annotated with @Header which is mapped to a header value as illustrated
- below and documented in .
-
- @Router
-public List<String> route(@Header("orderStatus") OrderStatus status)
-
-
-
-
-
-
-
+public List route(Foo payload) {...}]]>
+
+
+ In addition to payload-based routing, a Message may be routed based on metadata available within the
+ message header as either a property or attribute. In this case, a method annotated with @Router
+ may include a parameter annotated with @Header which is mapped to a header value as illustrated
+ below and documented in .
+
+
+ route(@Header("orderStatus") OrderStatus status)]]>
+
+
+
+
For routing of XML-based Messages, including XPath support, see .
-
+
-
- Dynamic Routers
-
- So as you can see, Spring Integration provides quite a few different router configurations for common
- content-based routing use cases as well as the option of implementing custom routers as POJOs.
- For example PayloadTypeRouter provides a simple way to configure a router which computes channels
- based on the payload type of the incoming Message while HeaderValueRouter provides the
- same convenience in configuring a router which computes channels by evaluating the value
- of a particular Message Header. There are also expression-based (SpEL) routers where the channel
- is determined based on evaluating an expression. Thus, these type of routers exhibit some dynamic characteristics.
-
-
- However these routers all require static configuration. Even in the case of
- expression-based routers, the expression itself is defined as part of the router configuration which means that
- the same expression operating on the same value will always result in the computation of the same channel.
- This is acceptable in most cases since such routes are well defined and therefore predictable. But there are times when we
- need to change router configurations dynamically so message flows may be routed to a different channel.
-
- Example:
-
- You might want to bring down some part of your system for maintenance and temporarily re-reroute
- messages to a different message flow. Or you may want to introduce more granularity to your message flow by adding another
- route to handle a more concrete type of java.lang.Number (in the case of PayloadTypeRouter).
-
-
- Unfortunately with static router configuration to accomplish this you would have to bring down your entire application,
- change the configuration of the router (change routes) and bring it back up. This is obviously not the solution.
-
-
- The Dynamic Router
- pattern describes the mechanisms by which one can change/configure routers dynamically without
- bringing down the system or individual routers.
-
-
- Before we get into the specifics of how this is accomplished in Spring Integration let's quickly summarize the
- typical flow of the router, which consists of 3 simple steps:
-
-
- Step 1 - Compute channel identifier which is a value calculated by the
- router once it receives the Message. Typically it is a String or and instance of the actual
- MessageChannel.
-
-
- Step 2 - Resolve channel identifier to channel name. We'll describe
- specifics of this process in a moment.
-
-
- Step 3 - Resolve channel name to the actual MessageChannel
-
-
-
+
+ Dynamic Routers
+
+ So as you can see, Spring Integration provides quite a few different router configurations for common
+ content-based routing use cases as well as the option of implementing custom routers as POJOs.
+ For example PayloadTypeRouter provides a simple way to configure a router which computes channels
+ based on the payload type of the incoming Message while HeaderValueRouter provides the
+ same convenience in configuring a router which computes channels by evaluating the value
+ of a particular Message Header. There are also expression-based (SpEL) routers where the channel
+ is determined based on evaluating an expression. Thus, these type of routers exhibit some dynamic characteristics.
+
+
+ However these routers all require static configuration. Even in the case of
+ expression-based routers, the expression itself is defined as part of the router configuration which means that
+ the same expression operating on the same value will always result in the computation of the same channel.
+ This is acceptable in most cases since such routes are well defined and therefore predictable. But there are times when we
+ need to change router configurations dynamically so message flows may be routed to a different channel.
+
+ Example:
+
+ You might want to bring down some part of your system for maintenance and temporarily re-reroute
+ messages to a different message flow. Or you may want to introduce more granularity to your message flow by adding another
+ route to handle a more concrete type of java.lang.Number (in the case of PayloadTypeRouter).
+
+
+ Unfortunately with static router configuration to accomplish this, you would have to bring down your entire application,
+ change the configuration of the router (change routes) and bring it back up. This is obviously not the solution.
+
+
+ The Dynamic Router
+ pattern describes the mechanisms by which one can change/configure routers dynamically without
+ bringing down the system or individual routers.
+
+
+ Before we get into the specifics of how this is accomplished in Spring Integration, let's quickly summarize the
+ typical flow of the router, which consists of 3 simple steps:
+
+
+
+ Step 1 - Compute channel identifier which is a value calculated by the
+ router once it receives the Message. Typically it is a String or and instance of the actual
+ MessageChannel.
+
+
+ Step 2 - Resolve channel identifier to channel name. We'll describe
+ specifics of this process in a moment.
+
+
+ Step 3 - Resolve channel name to the actual MessageChannel
+
+
+
+
+ There is not much that can be done with regard to dynamic routing if Step 1 results in the actual instance of the
+ MessageChannel, simply because the MessageChannel is the final product of any
+ router's job. However, if Step 1 results in a channel identifier that is not an instance of MessageChannel,
+ then there are quite a few possibilities to influence the process of deriving the Message Channel.
+ Lets look at couple of the examples in the context of the 3 steps mentioned above:
+
+
+ Payload Type Router
+
-
- There is not much that can be done with regard to dynamic routing if Step 1 results in the actual instance of the
- MessageChannel simply because the MessageChannel is the final product of any
- router's job. However, if Step 1 results in a channel identifier that is not an instance of MessageChannel,
- then there are quite a few possibilities to influence the process of deriving the Message Channel.
- Lets look at couple of the examples in the context of the 3 steps mentioned above:
-
-
- Payload Type Router
-
-
-
-
+
+
]]>
-
-
- Within the context of the Payload Type Router the 3 steps mentioned above would be realized as:
-
-
- Step 1 - Compute channel identifier which is the fully qualified name of the payload type
- (e.g., java.lang.String).
-
-
- Step 2 - Resolve channel identifier to channel name where
- the result of the previous step is used to select the appropriate value from the payload type mapping
- defined via mapping element.
-
-
- Step 3 - Resolve channel name to the actual instance of the
- MessageChannel where using ChannelResolver, the router will obtain a
- reference to a bean (which is hopefully a MessageChannel) identified by the result of the
- previous step.
-
-
- In other words each step feeds the next step until the process completes.
-
-
- Header Value Router
-
-
-
-
-
+
+
+ Within the context of the Payload Type Router the 3 steps mentioned above would be realized as:
+
+
+
+ Step 1 - Compute channel identifier which is the fully qualified name of the payload type
+ (e.g., java.lang.String).
+
+
+ Step 2 - Resolve channel identifier to channel name where
+ the result of the previous step is used to select the appropriate value from the payload type mapping
+ defined via mapping element.
+
+
+ Step 3 - Resolve channel name to the actual instance of the
+ MessageChannel where using ChannelResolver, the router will obtain a
+ reference to a bean (which is hopefully a MessageChannel) identified by the result of the
+ previous step.
+
+
+
+ In other words, each step feeds the next step until the process completes.
+
+
+ Header Value Router
+
+
+
+
+
]]>
-
-
- Similar to the PayloadTypeRouter:
-
-
- Step 1 - Compute channel identifier which is the value of the header identified by the
- header-name attribute.
-
-
- Step 2 - Resolve channel identifier to channel name where
- the result of the previous step is used to select the appropriate value from the general mapping
- defined via mapping element.
-
-
- Step 3 - Resolve channel name to the actual instance of the
- MessageChannel where using ChannelResolver, the router will obtain a
- reference to a bean (which is hopefully a MessageChannel) identified by the result of the
- previous step.
-
-
-
-
- The above two configurations of two different router types look almost identical.
- However if we look at the alternate configuration of the HeaderValueRouter we clearly see that
- there is no mapping sub element:
- ]]>
- But the configuration is still perfectly valid. So the natural question is what about the mapping in the Step 2?
-
-
- What this means is that Step 2 is now an optional step. If mapping is not defined then the channel identifier
- value computed in Step 1 will automatically be treated as the channel name which will now be resolved to the
- actual MessageChannel in the Step 3. What it also means is that Step 2 is one of the key steps to
- provide dynamic characteristics to the routers, since it introduces a process which
- allows you to change the way 'channel identifier' resolves to 'channel name',
- thus influencing the process of determining the final instance of the MessageChannel from the initial
- channel identifier.
-
- For Example:
-
- In the above configuration let's assume that the testHeader value is 'kermit' which is now a channel identifier
- (Step 1). Since there is no mapping in this router, resolving this channel identifier to a channel name
- (Step 2) is impossible and this channel identifier is now treated as channel name. However what if
- there was a mapping but for a different value? The end result would still be the same and that is:
- if new value cannot be determined through the process of resolving the 'channel identifier' to a 'channel name',
- such 'channel identifier' becomes 'channel name'.
-
-
- So all that is left is for Step 3 to resolve the channel name ('kermit') to an actual instance of the
- MessageChannel identified by this name. That will be done via the default
- ChannelResolver implementation which is a BeanFactoryChannelResolver. It
- basically does a bean lookup for the name provided. So now all messages which contain the header/value pair as testHeader=kermit
- are going to be routed to a MessageChannel whose bean name (id) is 'kermit'.
-
-
- But what if you want to route these messages to the 'simpson' channel? Obviously changing a static configuration will work,
- but will also require bringing your system down. However if you had access to the channel identifier map, then you
- could just introduce a new mapping where the header/value pair is now kermit=simpson, thus allowing Step 2 to treat
- 'kermit' as a channel identifier while resolving it to 'simpson' as the channel name .
-
-
- The same obviously applies for PayloadTypeRouter where you can now remap or remove a particular payload type
- mapping. In fact, it applies to every other router including expression-based routers since their computed values
- will now have a chance to go through Step 2 to be additionally resolved to the actual channel name.
-
-
- In Spring Integration 2.0 the routers hierarchy underwent significant refactoring so that now any router that is a subclass of the
- AbstractMessageRouter (which includes all framework defined routers) is a Dynamic Router simply because the
- channelIdentiferMap is defined at the AbstractMessageRouter level. That map's setter method is
- exposed as a public method along with 'setChannelMapping' and 'removeChannelMapping' methods. These allow you to change/add/remove
- router mappings at runtime as long as you have a reference to the router itself. It also means that you could expose these same
- configuration options via JMX (see ) or the Spring Integration ControlBus (see ) functionality.
-
-
- Control Bus
-
-
- One way to manage the router mappings is through the Control Bus
- pattern which exposes a Control Channel where you can send
- control messages to manage and monitor Spring Integration components, including routers.
- For more information about the Control Bus see . Typically you would send a control message asking to invoke a
- particular operation on a particular managed component (e.g., router). The two managed operations (methods) that are
- specific to changing the router resolution process are:
-
-
- public void setChannelMapping(String channelIdentifier, String channelName) -
- will allow you to add a new or modify an existing mapping between channel identifier and channel name
-
-
- public void removeChannelMapping(String channelIdentifier) -
- will allow you to remove a particular channel mapping, thus disconnecting the relationship between
- channel identifier and channel name
-
-
-
-
- You can also expose a router instance with Spring's JMS support and then use your favorite JMX client (e.g., JConsole) to
- manage those operations (methods) for changing the router's configuration. For more information on Spring Integration
- management and monitoring please visit .
-
-
+
+ Similar to the PayloadTypeRouter:
+
+
+
+ Step 1 - Compute channel identifier which is the value of the header identified by the
+ header-name attribute.
+
+
+ Step 2 - Resolve channel identifier to channel name where
+ the result of the previous step is used to select the appropriate value from the general mapping
+ defined via mapping element.
+
+
+ Step 3 - Resolve channel name to the actual instance of the
+ MessageChannel where using ChannelResolver, the router will obtain a
+ reference to a bean (which is hopefully a MessageChannel) identified by the result of the
+ previous step.
+
+
+
+ The above two configurations of two different router types look almost identical.
+ However if we look at the alternate configuration of the HeaderValueRouter we clearly see that
+ there is no mapping sub element:
+
+ ]]>
+
+ But the configuration is still perfectly valid. So the natural question is what about the mapping in the Step 2?
+
+
+ What this means is that Step 2 is now an optional step. If mapping is not defined then the channel identifier
+ value computed in Step 1 will automatically be treated as the channel name, which will now be resolved to the
+ actual MessageChannel as in Step 3. What it also means is that Step 2 is one of the key steps to
+ provide dynamic characteristics to the routers, since it introduces a process which
+ allows you to change the way 'channel identifier' resolves to 'channel name',
+ thus influencing the process of determining the final instance of the MessageChannel from the initial
+ channel identifier.
+
+ For Example:
+
+ In the above configuration let's assume that the testHeader value is 'kermit' which is now a channel identifier
+ (Step 1). Since there is no mapping in this router, resolving this channel identifier to a channel name
+ (Step 2) is impossible and this channel identifier is now treated as channel name. However what if
+ there was a mapping but for a different value? The end result would still be the same and that is:
+ if a new value cannot be determined through the process of resolving the 'channel identifier' to a 'channel name',
+ such 'channel identifier' becomes 'channel name'.
+
+
+ So all that is left is for Step 3 to resolve the channel name ('kermit') to an actual instance of the
+ MessageChannel identified by this name. That will be done via the default
+ ChannelResolver implementation which is a BeanFactoryChannelResolver. It
+ basically does a bean lookup for the name provided. So now all messages which contain the header/value pair as testHeader=kermit
+ are going to be routed to a MessageChannel whose bean name (id) is 'kermit'.
+
+
+ But what if you want to route these messages to the 'simpson' channel? Obviously changing a static configuration will work,
+ but will also require bringing your system down. However if you had access to the channel identifier map, then you
+ could just introduce a new mapping where the header/value pair is now kermit=simpson, thus allowing Step 2 to treat
+ 'kermit' as a channel identifier while resolving it to 'simpson' as the channel name .
+
+
+ The same obviously applies for PayloadTypeRouter, where you can now remap or remove a particular payload type
+ mapping. In fact, it applies to every other router, including expression-based routers, since their computed values
+ will now have a chance to go through Step 2 to be additionally resolved to the actual channel name.
+
+
+ In Spring Integration 2.0 the router hierarchy underwent significant refactoring, so that now any router that is a subclass of the
+ AbstractMessageRouter (which includes all framework defined routers) is a Dynamic Router simply because the
+ channelIdentiferMap is defined at the AbstractMessageRouter level. That map's setter method is
+ exposed as a public method along with 'setChannelMapping' and 'removeChannelMapping' methods. These allow you to change/add/remove
+ router mappings at runtime as long as you have a reference to the router itself. It also means that you could expose these same
+ configuration options via JMX (see ) or the Spring Integration ControlBus (see ) functionality.
+
+
+
+ Manage Router Mappings using the Control Bus
+
+ One way to manage the router mappings is through the Control Bus
+ pattern which exposes a Control Channel where you can send
+ control messages to manage and monitor Spring Integration components, including routers.
+
+
+
+ For more information about the Control Bus, please see chapter .
+
+
+
+ Typically you would send a control message asking to invoke a
+ particular operation on a particular managed component (e.g. router). The two managed operations (methods) that are
+ specific to changing the router resolution process are:
+
+
+
+ public void setChannelMapping(String channelIdentifier, String channelName) -
+ will allow you to add a new or modify an existing mapping between channel identifier and channel name
+
+
+ public void removeChannelMapping(String channelIdentifier) -
+ will allow you to remove a particular channel mapping, thus disconnecting the relationship between
+ channel identifier and channel name
+
+
+
+
+ Manage Router Mappings using JMX
+
+ You can also expose a router instance with Spring's JMX support, and then use your favorite JMX client (e.g., JConsole) to
+ manage those operations (methods) for changing the router's configuration.
+
+
+
+ For more information about Spring Integration's JMX suppor, please see chapter .
+
+
+
+
diff --git a/docs/src/reference/docbook/xml.xml b/docs/src/reference/docbook/xml.xml
index 5e467b93e7..572a2ecbf2 100644
--- a/docs/src/reference/docbook/xml.xml
+++ b/docs/src/reference/docbook/xml.xml
@@ -49,6 +49,8 @@
and org.w3c.dom.Document payloads are supported. Custom conversion to a
Source is also supported by injecting an implementation of
SourceFactory.
+
+
@@ -67,18 +69,21 @@
the payload into an alternative xml format. To achieve this configure a
ResultTransformer. Two implementations are provided, one which converts to
String and another which converts to Document.
+
+
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
]]>
-
+
By default, the MarshallingTransformer will pass the payload Object
to the Marshaller, but if its boolean extractPayload property
@@ -97,14 +102,18 @@
by default XsltPayloadTransformer will create a message with a
Result payload. This can be customised by providing a
ResultFactory and/or a ResultTransformer.
-
-
-
-
-
-]]>
+
+
+
+
+
+
+]]>
+
@@ -116,21 +125,24 @@
according to the type of the provided input channel. The namespace support is designed
to reduce the amount of xml configuration by allowing the creation of an endpoint and transformer
using one element.
-
+
+
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xmlns:int="http://www.springframework.org/schema/integration"
+ xmlns:int-xml="http://www.springframework.org/schema/integration/xml"
+ xsi:schemaLocation="http://www.springframework.org/schema/beans
+ http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
+ http://www.springframework.org/schema/integration
+ http://www.springframework.org/schema/integration/spring-integration-2.0.xsd
+ http://www.springframework.org/schema/integration/xml
+ http://www.springframework.org/schema/integration/xml/spring-integration-xml-2.0.xsd">
]]>
+
The namespace support for UnmarshallingTransformer is shown below.
Since the namespace is now creating an endpoint instance rather than a transformer,
a poller can also be nested within the element to control the polling of the input channel.
+
-
- ]]>
-
+]]>
The namespace support for the marshalling transformer requires an input channel, output channel and a
@@ -152,6 +162,8 @@
reference to a custom implementation of ResultFactory can be provided as an alternative
to setting the result-type attribute using the result-factory attribute. An optional result-transformer can also be
specified in order to convert the created Result after marshalling.
+
+
]]>
-
Namespace support for the XsltPayloadTransformer allows either a resource to be passed in in order to create the
@@ -175,6 +186,7 @@
be controlled by specifying either the result-factory or result-type attribute. A result-transfomer attribute can also
be used to reference an implementation of ResultTransfomer where conversion of the result
is required before sending.
+ ]]>
-
+
Very often to assist with transformation you may need to have access to Message data (e.g., Message Headers). For example; you may need to get access to certain Message Headers
and pass them on as parameters to a transformer (e.g., transformer.setParameter(..)).
@@ -222,6 +234,7 @@
messages. The XPath splitter implements MessageHandler and should
therefore be configured in conjunction with an appropriate endpoint (see the namespace support below
for a simpler configuration alternative).
+
@@ -234,76 +247,135 @@
]]>
-
- Routing xml messages using XPath
-
+ Routing XML Messages using XPath
- Similar to SpEL-based routers, Spring Integration provides support for routing messages based on the XPath expressions
- allowing you to create a Message Endpoint with an input channel but no output channel
- since the output channel(s) is determined dynamically.
-
-
-
-]]>
+ Similar to SpEL-based routers, Spring Integration provides support for routing messages based on XPath expressions,
+ allowing you to create a Message Endpoint with an input channel but no output channel. Instead, one or more output
+ channels are determined dynamically.
-
-
- Internally XPath expression will be evaluated as NODESET type and converted to a
- List<String> representing channel names. Typically such list will contain a single channel name.
- However, based on the result of an XPath Expression XPath router can also take on the characteristics of the Recipient List Router
- if XPath Expression returns more then one value, thus resulting in the List<String> containing more
- then one channel name. In that case Message will be sent to all channels in the list.
- So assuming that the xml file passed to the router configured below contains many responder sub-elements representing channel names,
- the message will be sent to all of those channels.
-
-
-
-
-
-]]>
+
+
+]]>
- If the returned values do not represent the channel names additional mapping could be specified. For example if
- the /request/responders expression results in two values responderA and responderB but
- you don't want to couple the responder names to channel names you may provide additional mapping as such:
+
+ For an overview of attributes that are common among Routers, please see chapter:
+
+
+
+ Internally XPath expressions will be evaluated as NODESET
+ type and converted to a List<String> representing
+ channel names. Typically such a list will contain a single channel name.
+ However, based on the results of an XPath Expression, the XPath router can
+ also take on the characteristics of a Recipient List Router
+ if the XPath Expression returns more then one value. In that case, the
+ List<String> will contain more then one
+ channel name and consequently Messages will be sent to all channels in the list.
+
+
+ Thus, assuming that the XML file passed to the router configured below
+ contains many responder sub-elements representing channel names,
+ the message will be sent to all of those channels.
+
-
-
-
+
]]>
-
-
-
- As we already said the default evaluation type for XPath expressions is NODESET which is converted
- to a List<String> of channel names, thus handling single channel scenarios as well as multiple.
- However certain XPath expressions may evaluate as String type from the very
- beginning (e.g., 'name(./node())' - which will return the name of the root node) thus resulting in
- the exception if default evaluation type (NODESET) is used.
- For these scenarious you may use evaluate-as-string attribute which will allow you to manage the
- evaluation type. It is FALSE by default, however if set to TRUE, the String evaluation type will be used.
- For example if we want to route based on the name of the root node we can have use the following configuration:
-
-
-
-
-]]>
-
- The XPath Router does support custom implementations of the XmlPayloadConverter strategy, and when configuring
- an 'xpath-router' element in XML, a reference to such an implementation may be provided via the 'converter' attribute.
- However, the DefaultXmlPayloadConverter is used if this reference is not provided, and it
- should be sufficient in most cases since it can convert from Node, Document, Source,
- File, and String typed payloads. If you need to extend beyond the capabilities of
- that default implementation, then an upstream Transformer is probably a better option
- than providing a reference to a custom implementation of this strategy here.
-
+
+ If the returned values do not represent the channel names directly, additional
+ mapping parameters can be specified, in order to map those returned values to actual
+ channel names. For example if the /request/responders expression
+ results in two values responderA and responderB but
+ you don't want to couple the responder names to channel names, you may provide
+ additional mapping configuration such as the following:
+
+
+
+
+
+
+
+]]>
+
+
+ As already mentioned, the default evaluation type for XPath expressions is
+ NODESET, which is converted to a
+ List<String> of channel names, therefore handling
+ single channel scenarios as well as multiple ones.
+
+
+ Nonetheless, certain XPath expressions may evaluate as String type from the
+ very beginning. Take for example the following XPath Expression:
+
+
+
+ This expression will return the name of the root node. It will resulting
+ in an exception, if the default evaluation type NODESET
+ is being used.
+
+
+ For these scenarious, you may use the evaluate-as-string attribute,
+ which will allow you to manage the evaluation type. It is FALSE
+ by default, however if set to TRUE, the String evaluation
+ type will be used.
+
+
+
+ To provide some background information: XPath 1.0 specifies 4 data types:
+
+
+ Node-sets
+ Strings
+ Number
+ Boolean
+
+
+ When the XPath Router evaluates expressions using the optional
+ evaluate-as-string attribute, the return value is
+ determined per the string() function as defined in the
+ XPath specification. This means that if the expression selects
+ multiple nodes, it will return the string value of the first node.
+
+
+ For further information, please see:
+
+
+ Specification: XML Path Language (XPath) Version 1.0: http://www.w3.org/TR/xpath/
+ XPath specification - string() function: http://www.w3.org/TR/xpath/#function-string
+
+
+
+ For example if we want to route based on the name of the root node, we
+ can use the following configuration:
+
+
+
+
+]]>
+
+ XML Payload Converter
+
+ For XPath Routers, you can also specify the Converter to use when converting
+ payloads prior to XPath evaluation. As such, the XPath Router supports
+ custom implementations of the XmlPayloadConverter strategy,
+ and when configuring an xpath-router element in XML, a reference
+ to such an implementation may be provided via the converter attribute.
+
+
+ If this reference is not explicitly provided, the DefaultXmlPayloadConverter
+ is used. It should be sufficient in most cases, since it can convert from
+ Node, Document, Source, File, and String typed payloads. If you need to
+ extend beyond the capabilities of that default implementation, then an
+ upstream Transformer is generally a better option in most cases, rather
+ than providing a reference to a custom implementation of this strategy here.
+
+
@@ -320,23 +392,25 @@
-
-
-
-
-
+ class="org.springframework.integration.channel.interceptor.MessageSelectingInterceptor">
+
+
+
+
+
-
-
-
-
-
-
+ class="org.springframework.integration.channel.interceptor.MessageSelectingInterceptor">
+
+
+
+
+
+ ]]>
@@ -351,12 +425,15 @@
Let's look at the following transformer configuration:
+ ]]>
-
+
. . . and Message
+ message =
MessageBuilder.withPayload("").build();]]>
+
After sending this message to the 'inputChannel' the XPath transformer configured above will transform
this XML Message to a simple Message with payload of 'John Doe' all based on
the simple XPath Expression specified in the xpath-expression attribute.
@@ -372,13 +449,15 @@
You can configure the desired type by simply using evaluation-type
attribute of the <xpath-transformer/> element.
-
-
-
-]]>
+
+
+
+]]>
+
Node Mappers
@@ -387,26 +466,33 @@
implementation of the org.springframework.xml.xpath.NodeMapper - an interface used by
XPathOperations implementations for mapping Node objects on a per-node basis. To provide a
reference to a NodeMapper simply use node-mapper attribute:
+
-]]>
+ node-mapper="testNodeMapper" output-channel="output"/>]]>
+
. . . and Sample NodeMapper implementation:
+
-
+
XML Payload Converter
You can also use an implementation of the org.springframework.integration.xml.XmlPayloadConverter to
provide more granular transformation:
-
+
+
]]>
+
+
. . . and Sample XmlPayloadConverter implementation:
+
-
- The DefaultXmlPayloadConverter is used if this reference is not provided, and it
- should be sufficient in most cases since it can convert from Node, Document, Source,
- File, and String typed payloads. If you need to extend beyond the capabilities of
- that default implementation, then an upstream Transformer is probably a better option
- than providing a reference to a custom implementation of this strategy here.
+
+ The DefaultXmlPayloadConverter is used if this reference is not provided, and it
+ should be sufficient in most cases since it can convert from Node, Document, Source,
+ File, and String typed payloads. If you need to extend beyond the capabilities of
+ that default implementation, then an upstream Transformer is probably a better option
+ than providing a reference to a custom implementation of this strategy here.Combination of SpEL and XPath expressions
@@ -439,7 +525,9 @@
You can also combine Spring Expression Language (SpEL) expressions with XPath expression and configure
them using expression attribute:
- ]]>
+
+ ]]>
+
In the above case the overall result of the expression will be the result of the XPath expression multiplied by 2.
@@ -453,6 +541,7 @@
<xpath-expression/> element. So the following configurations of an xpath-selector are all valid and represent the general
form of XPath namespace support. All forms of XPath expression result in the creation of an
XPathExpression using the Spring XPathExpressionFactory
+
@@ -484,10 +573,11 @@
]]>
-
+
XPath splitter namespace support allows the creation of a Message Endpoint with an input channel and output channel.
-
+
+
@@ -502,7 +592,7 @@
]]>
-
+
diff --git a/docs/src/reference/resources/images/tickmark.png b/docs/src/reference/resources/images/tickmark.png
new file mode 100644
index 0000000000..6b12a29529
Binary files /dev/null and b/docs/src/reference/resources/images/tickmark.png differ
diff --git a/spring-integration-core/src/main/resources/org/springframework/integration/config/xml/spring-integration-2.1.xsd b/spring-integration-core/src/main/resources/org/springframework/integration/config/xml/spring-integration-2.1.xsd
index dd8c1ec35b..a917fdb26a 100644
--- a/spring-integration-core/src/main/resources/org/springframework/integration/config/xml/spring-integration-2.1.xsd
+++ b/spring-integration-core/src/main/resources/org/springframework/integration/config/xml/spring-integration-2.1.xsd
@@ -50,9 +50,9 @@
@@ -102,7 +102,7 @@
- Provides MessageDispatcher configuration
+ Provides MessageDispatcher configuration
(i.e., failover, load-balancing, task-executor)
@@ -199,7 +199,7 @@
@@ -281,9 +281,9 @@
@@ -326,9 +326,9 @@
@@ -342,10 +342,10 @@
-
-
+
@@ -388,10 +388,10 @@
-
-
+
@@ -430,8 +430,8 @@
-
-
+
@@ -440,10 +440,10 @@
-
-
+
@@ -451,7 +451,7 @@
-
+
@@ -465,8 +465,8 @@
-
-
+
@@ -474,7 +474,7 @@
-
+
@@ -483,9 +483,9 @@
-
-
+
@@ -493,10 +493,10 @@
-
-
+
@@ -505,10 +505,10 @@
-
-
+
@@ -520,9 +520,9 @@
-
-
+
@@ -534,8 +534,8 @@
-
-
+
@@ -548,9 +548,9 @@
-
-
+
@@ -573,10 +573,10 @@
-
-
+
@@ -585,10 +585,10 @@
-
-
+
@@ -599,9 +599,9 @@
-
@@ -613,14 +613,14 @@
-
-
@@ -636,8 +636,8 @@
-
-
+
@@ -650,10 +650,10 @@
-
-
+
@@ -681,14 +681,14 @@
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
@@ -757,7 +757,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
Provide a name for the logger. This is useful when there are multiple logging Channel Adapters configured,
and you would like to differentiate them within the actual log. By default the logger name will be the
- fully qualified class name of the LoggingHandler implementation.
+ fully qualified class name of the LoggingHandler implementation.
@@ -796,7 +796,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- A reference to a bean defined in the application context.
+ A reference to a bean defined in the application context.
@@ -834,8 +834,8 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- Identifies channel attached to this adapter. Depending on the type of the adapter
- this channel could be the receiving channel (e.g., outbound-channel-adapter) or channel where
+ Identifies channel attached to this adapter. Depending on the type of the adapter
+ this channel could be the receiving channel (e.g., outbound-channel-adapter) or channel where
messages will be sent to by this adapter (e.g., inbound-channel-adapter).
@@ -1183,8 +1183,8 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- Allows this poller to reference another instance of a top-level poller.
- [IMPORTANT] - This attribute is only allowed on inner poller definitions.
+ Allows this poller to reference another instance of a top-level poller.
+ [IMPORTANT] - This attribute is only allowed on inner poller definitions.
Defining this attribute on a top-level poller definition will result in a configuration exception.
@@ -1419,7 +1419,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
provided, then the specified header values will NOT overwrite any
existing ones with the same
header
- names.
+ names.
@@ -1609,10 +1609,10 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- Boolean flag that specifies whether values provided in 'header-names' should be treated as
- match patterns or literal values. For example header-names='foo*' would mean remove all
- headers that begin with 'foo' including the header named 'foo*'. However if you want to
- treat '*' as literal value setting this flag to FALSE will not perform pattern match and
+ Boolean flag that specifies whether values provided in 'header-names' should be treated as
+ match patterns or literal values. For example header-names='foo*' would mean remove all
+ headers that begin with 'foo' including the header named 'foo*'. However if you want to
+ treat '*' as literal value setting this flag to FALSE will not perform pattern match and
the only header that will be removed is the one that is an exact match.
@@ -1878,7 +1878,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- If set to 'true' the Message will be removed from the MessageStore by
+ If set to 'true' the Message will be removed from the MessageStore by
this transformer. Useful when Message can be 'claimed' only once. DEFAULT is 'false'.
@@ -1919,7 +1919,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- Defines a Message Filters that is used to decide whether a Message should be passed
+ Defines a Message Filters that is used to decide whether a Message should be passed
along or dropped based on some criteria
@@ -1952,8 +1952,8 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
@@ -1970,16 +1970,16 @@ endpoint itself is a Polling Consumer for a channel with a queue.
@@ -1993,7 +1993,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
]]>
-
+
-
+
-
-
+
- The "ref" attribute references the bean name of a custom
+ The "ref" attribute references the bean name of a custom
Router implementation. Typically that implementation will
be a simple POJO, but it may extend AbstractMessageRouter.
-
+
Provide the "method" attribute as well to clarify which
method should be invoked, Alternatively, the "ref" attribute
may point to an instance that contains the @Router annotation
on one of its methods.
-
+
Instead of using the "ref" attribute you may also provide
- the custom Router implementation as an inner bean
+ the custom Router implementation as an inner bean
definition.
-
- However, keep in mind that using both the "ref" attribute
- and an inner handler definition in the same Router
- configuration is not allowed, as it creates an
+
+ However, keep in mind that using both the "ref" attribute
+ and an inner handler definition in the same Router
+ configuration is not allowed, as it creates an
ambiguous condition, and an Exception will be thrown.
Additionally, instead of using "ref" and "method" at all,
@@ -2060,18 +2060,18 @@ endpoint itself is a Polling Consumer for a channel with a queue.
When implementing a custom Router using a plain POJO
- the "ref" attribute may be combined with an explicit
- method name using the "method" attribute.
-
- The referenced method may return either a MessageChannel
- or a String type. Additionally, the method may return
- either a single value or a collection. If a collection
- is returned, the reply message will be sent to
+ the "ref" attribute may be combined with an explicit
+ method name using the "method" attribute.
+
+ The referenced method may return either a MessageChannel
+ or a String type. Additionally, the method may return
+ either a single value or a collection. If a collection
+ is returned, the reply message will be sent to
multiple channels.
-
- Specifying a "method" attribute applies the same behavior
+
+ Specifying a "method" attribute applies the same behavior
as when using the @Router annotation on a single method
- within the object pointed to by the "ref".
+ within the object pointed to by the "ref".
@@ -2085,15 +2085,15 @@ endpoint itself is a Polling Consumer for a channel with a queue.
SpEL Expression to be evaluated at runtime. Allows you
to implement simple computations without implementing
- a custom POJO router. Generally, the SpEL expression is
- evaluated and the result is mapped to a channel using
- "mapping" sub-elements.
-
- However, if no "mapping" sub-element is present, the
+ a custom POJO router. Generally, the SpEL expression is
+ evaluated and the result is mapped to a channel using
+ "mapping" sub-elements.
+
+ However, if no "mapping" sub-element is present, the
SpEL Expression will evaluate to a channel name directly.
-
- A SpEL expression may also return a Collection. Whenever
- the expression returns multiple channel values the
+
+ A SpEL expression may also return a Collection. Whenever
+ the expression returns multiple channel values the
Message will be forwarded to each channel.
Note that SpEL supports bean-references within expressions
@@ -2106,10 +2106,10 @@ endpoint itself is a Polling Consumer for a channel with a queue.
@@ -2132,28 +2132,28 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
-
+
+
-
+
@@ -2161,7 +2161,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
+
@@ -2171,12 +2171,12 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
+
-
+
@@ -2189,7 +2189,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
@@ -2207,17 +2207,17 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
+
-
+
@@ -2226,12 +2226,12 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
+
-
+
@@ -2253,20 +2253,20 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- An expression to be evaluated to determine if this recipient
- should be included in the recipient list for a given input
+ An expression to be evaluated to determine if this recipient
+ should be included in the recipient list for a given input
Message. The evaluation result of the expression must be a boolean.
- If this attribute is not defined, the channel will always be
+ If this attribute is not defined, the channel will always be
among the list of recipients.
-
+
-
+
@@ -2274,21 +2274,21 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- An expression to be evaluated to determine if this recipient
- should be included in the recipient list for a given input
+ An expression to be evaluated to determine if this recipient
+ should be included in the recipient list for a given input
Message. The evaluation result of the expression must be a boolean.
- If this attribute is not defined, the channel will always be
+ If this attribute is not defined, the channel will always be
among the list of recipients.
-
+
-
+
@@ -2303,8 +2303,8 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- ).
]]>
@@ -2315,7 +2315,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
+
@@ -2325,18 +2325,18 @@ endpoint itself is a Polling Consumer for a channel with a queue.
)
]]>
-
-
-
+
+
+
-
+
@@ -2353,22 +2353,22 @@ endpoint itself is a Polling Consumer for a channel with a queue.
)
-
- The most specific matching exception type is determined
- by navigating the hierarchy of 'exception causes'
+
+ The most specific matching exception type is determined
+ by navigating the hierarchy of 'exception causes'
(e.g., payload.getCause()).
]]>
-
+
-
+
@@ -2377,39 +2377,39 @@ endpoint itself is a Polling Consumer for a channel with a queue.
)
-
- The most specific matching exception type is determined
- by navigating the hierarchy of 'exception causes'
+
+ The most specific matching exception type is determined
+ by navigating the hierarchy of 'exception causes'
(e.g., payload.getCause()).
]]>
-
+
-
+
-
-
-
-
+
-
-
+
@@ -2423,7 +2423,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- A value of the evaluation token that will be mapped to a channel reference
+ A value of the evaluation token that will be mapped to a channel reference
(e.g., mapping value='foo' channel='myChannel')
@@ -2446,14 +2446,14 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
-
+
-
@@ -2469,19 +2469,19 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- An expression to be evaluated to determine if this recipient
- should be included in the recipient list for a given input
+ An expression to be evaluated to determine if this recipient
+ should be included in the recipient list for a given input
Message. The evaluation result of the expression must be a boolean.
- If this attribute is not defined, the channel will always be
+ If this attribute is not defined, the channel will always be
among the list of recipients.
-
-
+
@@ -2490,31 +2490,34 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
-
-
-
+
+
-
- Lifecycle attribute signaling if this component should be
+ Lifecycle attribute signaling if this component should be
started during Application Context startup. Defaults to true.
-
-
+
+
@@ -2539,25 +2542,25 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
-
+
- Reference to the channel where Messages should be sent if
- channel resolution fails to return any channels. If no
- default output channel is provided, the router will throw an
+ Reference to the channel where Messages should be sent if
+ channel resolution fails to return any channels. If no
+ default output channel is provided, the router will throw an
Exception.
-
- If you would like to silently drop those messages instead,
- add the "nullChannel" as the default output channel attribute
+
+ If you would like to silently drop those messages instead,
+ add the "nullChannel" as the default output channel attribute
value.
-
+
@@ -2568,8 +2571,8 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- Specify the maximum amount of time in milliseconds to wait
- when sending Messages to the target MessageChannels. By
+ Specify the maximum amount of time in milliseconds to wait
+ when sending Messages to the target MessageChannels. By
default the send will block indefinitely.
@@ -2577,7 +2580,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- Specify whether a failure to send to a single channel should
+ Specify whether a failure to send to a single channel should
be ignored. Otherwise MessageDeliveryExceptions will be thrown.
Defaults to false.
@@ -2595,26 +2598,26 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
+
- Specify whether channel names must always be successfully resolved
- to existing channel instances.
-
+ Specify whether channel names must always be successfully resolved
+ to existing channel instances.
+
If set to 'true', a MessagingException will be raised in case
- the channel cannot be resolved. Setting this attribute to 'false',
- will cause any unresovable channels to be ignored.
-
- If not explicitly set, 'resolution-required' will
- default to 'true'.
+ the channel cannot be resolved. Setting this attribute to 'false',
+ will cause any unresovable channels to be ignored.
+
+ If not explicitly set, 'resolution-required' will
+ default to 'true'.
-
-
+
+
@@ -2695,8 +2698,8 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- Boolean flag specifying if MessageGroup should be removed once completed. Useful for
- handling late arrival use cases where messages arriving with the correlationKey that
+ Boolean flag specifying if MessageGroup should be removed once completed. Useful for
+ handling late arrival use cases where messages arriving with the correlationKey that
is the same as the completed MessageGroup will be discarded. Default is 'false'
@@ -2713,7 +2716,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
decision algorithm.
-
+ A SpEL expression to apply to the message group (e.g, payload.size() > 6)
@@ -2734,7 +2737,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- A reference to a bean that implements the release strategy.
+ A reference to a bean that implements the release strategy.
The bean can be an implementation of the
ReleaseStrategy interface or a POJO
@@ -2753,8 +2756,8 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- A reference to a bean that implements the decision algorithm as to whether a given
- message group is complete. The bean can be an implementation of the
+ A reference to a bean that implements the decision algorithm as to whether a given
+ message group is complete. The bean can be an implementation of the
CorrelationStrategy interface or a POJO.
@@ -2774,7 +2777,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- A SpEL expression which implements correlation decision
+ A SpEL expression which implements correlation decision
algorithm to apply to the Message (e.g., payload.getPerson().getId() - correlate
based on the 'id' of the 'person' attribute of the message payload object)
@@ -2811,9 +2814,9 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- Specifies whether messages that expired should be aggregated and sent to the 'output-channel' or 'replyChannel'.
- Messages are expired when their containing MessageGroup expires. One of the ways of expiring MessageGroups is by
- configuring a MessageGroupStoreReaper. However MessageGroups can alternatively be expired by simply calling
+ Specifies whether messages that expired should be aggregated and sent to the 'output-channel' or 'replyChannel'.
+ Messages are expired when their containing MessageGroup expires. One of the ways of expiring MessageGroups is by
+ configuring a MessageGroupStoreReaper. However MessageGroups can alternatively be expired by simply calling
MessageGroupStore.expireMessageGroup(groupId). That could be accomplished via a ControlBus operation
or by simply invoking that method if you have a reference to the MessageGroupStore instance.
@@ -2885,7 +2888,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
Reference to a bean in this Application Context that implements ChannelInterceptor
-
+
@@ -2904,7 +2907,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
- Alows you to configure a Wire Tap interceptor that will send a copy of the message to a
+ Alows you to configure a Wire Tap interceptor that will send a copy of the message to a
channel identified by 'channel' attribute.
@@ -3144,7 +3147,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
+
@@ -3153,7 +3156,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
-
+
@@ -3193,7 +3196,7 @@ endpoint itself is a Polling Consumer for a channel with a queue.
Allows you to register Converters (implementation of the Converter interface) that will
-be automatically registered with the ConversionService. ConversionService itself does not have to be
+be automatically registered with the ConversionService. ConversionService itself does not have to be
explicitly defined since the default ConversionService will be registered under the name 'integrationConversionService'
unless bean with this name is already registered.
@@ -3223,7 +3226,7 @@ unless bean with this name is already registered.
@@ -3263,7 +3266,7 @@ The list of component name patterns you want to track (e.g., tracked-components
that will be available include:
1) any that are annotated with @ManagedAttribute or @ManagedOperation
2) Lifecycle methods
- 3) get/set or shutdown methods on configurable TaskExecutors or TaskSchedulers
+ 3) get/set or shutdown methods on configurable TaskExecutors or TaskSchedulers
]]>
@@ -3287,7 +3290,7 @@ The list of component name patterns you want to track (e.g., tracked-components
Specify the maximum amount of time in milliseconds to wait when sending a reply
Message to the
- output channel. By default the send will block for one second.
+ output channel. By default the send will block for one second.