diff --git a/.gitignore b/.gitignore
index 89aaddae50..94eb6643c5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -20,3 +20,4 @@ spring-integration-jms/activemq-data/
spring-integration-samples/loanshark/application.log*
target
build.log
+.DS_Store
diff --git a/docs/src/reference/docbook/bridge.xml b/docs/src/reference/docbook/bridge.xml
index aac5dd0868..f3ea04ba89 100644
--- a/docs/src/reference/docbook/bridge.xml
+++ b/docs/src/reference/docbook/bridge.xml
@@ -31,22 +31,22 @@
The <bridge> element is used to create a Messaging Bridge between two Message Channels or Channel Adapters.
Simply provide the "input-channel" and "output-channel" attributes:
- ]]>
+ ]]>
As mentioned above, a common use case for the Messaging Bridge is to connect a
PollableChannel to a SubscribableChannel, and when
performing this role, the Messaging Bridge may also serve as a throttler:
-
-
- ]]>
+
+
+ ]]>
Connecting Channel Adapters is just as easy. Here is a simple echo example between the "stdin" and "stdout"
adapters from Spring Integration's "stream" namespace.
-
+
-
+
- ]]>
+ ]]>
Of course, the configuration would be similar for other (potentially more useful) Channel Adapter bridges, such
as File to JMS, or Mail to File. The various Channel Adapters will be discussed in upcoming chapters.
diff --git a/docs/src/reference/docbook/chain.xml b/docs/src/reference/docbook/chain.xml
index 20056e958d..6e7dd385aa 100644
--- a/docs/src/reference/docbook/chain.xml
+++ b/docs/src/reference/docbook/chain.xml
@@ -58,13 +58,13 @@
The <chain> element provides an input-channel attribute, and if the last element in the chain is capable
of producing reply messages (optional), it also supports an output-channel attribute. The sub-elements are then
filters, transformers, splitters, and service-activators. The last element may also be a router.
-
-
-
-
-
-
- ]]>
+
+
+
+
+
+
+ ]]>
The <header-enricher> element used in the above example will set a message header named "foo" with a value
@@ -78,34 +78,34 @@
back and continue execution within the original chain.
To accomplish this you can utilize a Messaging Gateway by including a <gateway> element.
For example:
-
-
-
-
-
+
+
+
+
+
-
-
-
+
+
+
-
-
-
-
-
-
+
+
+
+
+
+
-
-
+
+
-
-
-
-
-
+
+
+
+
+
-
- ]]>
+
+ ]]>
In the above example the nested-chain-a will be called at the end of
main-chain processing by the 'gateway' element configured there. While in
diff --git a/docs/src/reference/docbook/channel-adapter.xml b/docs/src/reference/docbook/channel-adapter.xml
index 045a49e899..efec45d05b 100644
--- a/docs/src/reference/docbook/channel-adapter.xml
+++ b/docs/src/reference/docbook/channel-adapter.xml
@@ -21,13 +21,13 @@
poller will be scheduled with the TaskScheduler according to the provided
configuration. To configure the polling interval or cron expression for an individual channel-adapter,
provide a 'poller' element with one of the scheduling attributes, such as 'fixed-rate' or 'cron'.
-
-
-
+
+
+
-
-
-]]>
+
+
+]]>
@@ -45,16 +45,16 @@
For example:
-
+
-]]>
+]]>
In the the first configuration the polling task will be invoked once per poll and during such task (poll)
the method (which results in the production of the Message) will be invoked once based on the
max-messages-per-poll attribute value. In the second configuration the polling task will be invoked
10 times per poll or until it returns 'null' thus possibly producing 10 Messages per poll while each poll happens
at 1 second intervals.
However what if the configuration looks like this:
- ]]>
+ ]]>
Note there is no max-messages-per-poll specified. As you'll learn later the identical poller configuration
in the PollingConsumer (e.g., service-activator, filter, router etc.) would have a default
value of -1 for max-messages-per-poll which means "execute poling task non-stop unless polling method
@@ -71,7 +71,7 @@
However if you are sure that your method can return null and you need the behavior where you want to poll
for as many sources as available per each poll, then you should explicitly set max-messages-per-poll
to negative value.
- ]]>
+ ]]>
@@ -83,16 +83,16 @@
An "outbound-channel-adapter" element can also connect a MessageChannel to any POJO consumer
method that should be invoked with the payload of Messages sent to that channel.
-
+
]]>
If the channel being adapted is a PollableChannel, provide a poller sub-element:
-
- ]]>
+
+ ]]>
]]>
+
]]>
@@ -102,10 +102,10 @@
in other <outbound-channel-adapter> definitions. However if the consumer implementation
is only referenced by a single definition of the <outbound-channel-adapter>, you
can define it as inner bean:
-
+
]]>
+
]]>
diff --git a/docs/src/reference/docbook/claim-check.xml b/docs/src/reference/docbook/claim-check.xml
index e9b96f5957..7379d113a1 100644
--- a/docs/src/reference/docbook/claim-check.xml
+++ b/docs/src/reference/docbook/claim-check.xml
@@ -59,7 +59,7 @@
An Outgoing Claim Check Transformer allows you to transform a Message with a Claim Check payload
into a Message with the original content as its payload.
- ]]>
@@ -80,7 +80,7 @@
especially in the case of the in-memory Map-based SimpleMessageStore where failing to remove the Messages
could ultimately lead to an OutOfMemoryException. If you don't expect multiple claims to be made, it's
recommended that you set the remove-message attribute's value to false.
- xmlns:integration="http://www.springframework.org/schema/integration"xmlns:int="http://www.springframework.org/schema/integration"http://www.springframework.org/schema/integration
http://www.springframework.org/schema/integration/spring-integration-2.0.xsd">
- You can choose any name after "xmlns:"; integration is used here for clarity, but you might
+ You can choose any name after "xmlns:"; int is used here for clarity, but you might
prefer a shorter abbreviation. Of course if you are using an XML-editor or IDE support, then the availability of
auto-completion may convince you to keep the longer name for clarity. Alternatively, you can create configuration
files that use the Spring Integration schema as the primary namespace:
@@ -64,12 +64,12 @@
-
- ]]>
+
+
+ ]]>
The default "errorChannel" is a PublishSubscribeChannel.
@@ -438,9 +438,9 @@ Below are some of the examples of ambiguous conditions which result in an Except
could be mapped to 'str' and Message Headers could be mapped to 'm'. The second method could easily also be a candidate where
only Message Headers are mapped to 'm'. To make meters worse both methods have the same name which at first might look very
ambiguous considering the following configuration:
-
+
-]]>
+]]>
At this point it would be important to understand Spring Integration mapping Conventions where at the very core,
mappings are based on Payload first and everything else next. In other words the method whose argument could be mapped
to a Payload will take precedence over all other methods.
@@ -460,9 +460,9 @@ However if the method names were different you could influence the mapping with
public String bar(String str);
}
-
+
-]]>
+]]>
Now there is no ambiguity since the configuration explicitly maps to the 'bar' method which has no name conflicts.
diff --git a/docs/src/reference/docbook/control-bus.xml b/docs/src/reference/docbook/control-bus.xml
index 06f9f02472..5d2b5c0098 100644
--- a/docs/src/reference/docbook/control-bus.xml
+++ b/docs/src/reference/docbook/control-bus.xml
@@ -14,7 +14,7 @@
Integration we build upon the adapters described above so that it's possible
to send Messages as a means of invoking exposed operations.
- <control-bus input-channel="operationChannel"/>
+ <int:control-bus input-channel="operationChannel"/>
The Control Bus has an input channel that can be accessed for invoking
operations on the beans in the application context. It also has all the
diff --git a/docs/src/reference/docbook/delayer.xml b/docs/src/reference/docbook/delayer.xml
index 60807244d6..9b6ea0b224 100644
--- a/docs/src/reference/docbook/delayer.xml
+++ b/docs/src/reference/docbook/delayer.xml
@@ -23,10 +23,10 @@
As with the other endpoints, you can provide the "input-channel" and "output-channel" attributes,
but the delayer also requires at least the 'default-delay' attribute with the number of milliseconds
that each Message should be delayed.
- ]]>
+ ]]>
If you need per-Message determination of the delay, then you can also provide the name of a header
within the 'delay-header-name' attribute:
- ]]>
In the example above the 3 second delay would only apply in the case that the header value is
not present for a given inbound Message. If you only want to apply a delay to Messages that have
@@ -50,7 +50,7 @@
The default scheduler used by the delayer is a ThreadPoolTaskScheduler instance with a pool size of 1.
If you want to delegate to a different scheduler, you can provide a reference through the delayer element's
'scheduler' attribute:
-
diff --git a/docs/src/reference/docbook/endpoint.xml b/docs/src/reference/docbook/endpoint.xml
index 5cb84d361a..80b6952654 100644
--- a/docs/src/reference/docbook/endpoint.xml
+++ b/docs/src/reference/docbook/endpoint.xml
@@ -166,20 +166,20 @@ consumer.setTransactionManager(txManager);
referenced: PollableChannel or SubscribableChannel
respectively. When the channel is pollable, then the polling behavior is determined based on the endpoint
element's "poller" sub-element and its attributes. For example, a simple interval-based poller with a 1-second interval would be
- configured like this:
-
-]]>
+
+]]>
As an alternative to 'fixed-rate' you can also use the 'fixed-delay' attribute.
For a poller based on a Cron expression, use the "cron" attribute instead:
-
-
- ]]>
+
+ ]]>
If the input channel is a PollableChannel, then the poller configuration is
@@ -190,13 +190,13 @@ consumer.setTransactionManager(txManager);
It is also possible to create top-level pollers in which case only a "ref" is required:
-
+
-
-
- ]]>
+
+ ]]>
The "ref" attribute is only allowed on the inner-poller definitions. Defining this attribute on a top-level
poller will result in a configuration exception thrown during initialization of the Application Context.
@@ -205,25 +205,25 @@ consumer.setTransactionManager(txManager);
an ApplicationContext may have the default attribute with a value of "true". In that case, any
endpoint with a PollableChannel for its input-channel that is defined within the same ApplicationContext and has
no explicitly configured 'poller' sub-element will use that default.
-
+
- ]]>
+ ]]>
Spring Integration also provides transaction support for the pollers so that each receive-and-forward
operation can be performed as an atomic unit-of-work. To configure transactions for a poller, simply add the
<transactional/> sub-element. The attributes for this element should be familiar to anyone who has
experience with Spring's Transaction management:
-
-
-]]>
+
+
+]]>
@@ -234,16 +234,16 @@ consumer.setTransactionManager(txManager);
behavior of the message flow initiated by the poler, some times there is a need to provide extra Advice(s) to handle other
cross cutting behavior associated with the poller. For that poller defines an 'advice-chain' element allowing you to add
more advices - class that implements MethodInterceptor interface..
-
-
-
-
+
+
+
-
-
-]]>
+
+
+]]>
For more information on how to implement MethodInterceptor please refer to AOP sections of Spring
reference manual (section 7 and 8). Advice chain can also be applied on the poller that does not have
any transaction configuration essentially allowing you to enhance the behavior of the message flow initiated by the poller.
@@ -258,7 +258,7 @@ any transaction configuration essentially allowing you to enhance the behavior o
(the other major factor being the expected volume on the channel to which the endpoint subscribes). To enable
concurrency for a polling endpoint that is configured with the XML namespace support, provide the 'task-executor'
reference on its <poller/> element and then provide one or more of the properties shown below:
-
+
-
+
- ]]>
+ ]]>
Using this approach does not carry much overhead since internally it is nothing more then a timed-wait thread
which does not require nearly as much CPU resource usage as a thrashing, infinite while loop for example.
@@ -333,7 +333,7 @@ any transaction configuration essentially allowing you to enhance the behavior o
-
+
]]>
diff --git a/docs/src/reference/docbook/filter.xml b/docs/src/reference/docbook/filter.xml
index b8bcf12656..ee8824b98c 100644
--- a/docs/src/reference/docbook/filter.xml
+++ b/docs/src/reference/docbook/filter.xml
@@ -36,7 +36,7 @@
The <filter> element is used to create a Message-selecting endpoint. In addition to "input-channel
and output-channel attributes, it requires a ref. The ref may point to a
MessageSelector implementation:
-
+
]]>
@@ -45,7 +45,7 @@
The referenced method may expect either the Message type or the payload type of
inbound Messages. The method must return a boolean value. If the method returns 'true',
the Message will be sent to the output-channel.
-
]]>
@@ -55,10 +55,10 @@
handling of the rejected Message. By default (if configured like the example above), rejected Messages will
be silently dropped. If rejection should instead result in an error condition, then set the
throw-exception-on-rejection attribute to true:
- ]]>
If you want rejected messages to be routed to a specific channel, provide that reference as the discard-channel:
- ]]>
@@ -72,7 +72,7 @@
Using a ref attribute is generally recommended if the custom filter implementation is referenced in other
<filter> definitions. However if the custom filter implementation is scoped to a
single <filter> element, provide an inner bean definition:
-
+
]]>
@@ -86,7 +86,7 @@
With the introduction of SpEL support, Spring Integration added the expression attribute to the filter
element. It can be used to avoid Java entirely for simple filters.
- ]]>
+ ]]>
The string passed as the expression attribute will be evaluated as a SpEL expression with the Message available in
the evaluation context.
@@ -96,7 +96,7 @@
SpEL reference documentation
.
- ]]>
+ ]]>
If the Expression itself needs to be dynamic, then an 'expression' sub-element may be used. That provides a level of
indirection for resolving the Expression by its key from an ExpressionSource. That is a strategy interface that you
@@ -107,9 +107,9 @@
source attribute on the <expression> element, but in this case it's shown for completeness.
-
-
+
+
+
diff --git a/docs/src/reference/docbook/ftp.xml b/docs/src/reference/docbook/ftp.xml
index f272a47e42..003f61939b 100644
--- a/docs/src/reference/docbook/ftp.xml
+++ b/docs/src/reference/docbook/ftp.xml
@@ -24,7 +24,7 @@
To use the FTP namespace, add the following to the header of your XML file:
-
diff --git a/docs/src/reference/docbook/gateway.xml b/docs/src/reference/docbook/gateway.xml
index 9ae34a21b8..c8e2ec0b00 100644
--- a/docs/src/reference/docbook/gateway.xml
+++ b/docs/src/reference/docbook/gateway.xml
@@ -22,7 +22,7 @@ public interface Cafe {
Namespace support is also
provided which allows you to configure such an interface as a service as demonstrated by the following example.
- ]]>
@@ -82,12 +82,12 @@ public interface Cafe {
If you prefer the XML approach of configuring Gateway methods, you can provide method sub-elements
to the gateway configuration.
-
-
-
-
-]]>
+
+
+
+]]>
You can also provide individual headers per method invocation via XML.
@@ -123,12 +123,12 @@ public interface Cafe {
that a 'transformer' is used to create a reply Message from the Exception.
-
-
]]>
diff --git a/docs/src/reference/docbook/groovy.xml b/docs/src/reference/docbook/groovy.xml
index 50155b9c6d..fd4e8df7e9 100644
--- a/docs/src/reference/docbook/groovy.xml
+++ b/docs/src/reference/docbook/groovy.xml
@@ -29,15 +29,15 @@
write a script that uses those
variables. Below are a couple of sample configurations:
- Filter <filter input-channel="referencedScriptInput">
- <groovy:script location="some/path/to/groovy/file/GroovyFilterTests.groovy"/>
-</filter>
+ Filter <int:filter input-channel="referencedScriptInput">
+ <int-groovy:script location="some/path/to/groovy/file/GroovyFilterTests.groovy"/>
+</int:filter>
-<filter input-channel="inlineScriptInput">
- <groovy:script><![CDATA[
+<int:filter input-channel="inlineScriptInput">
+ <int-groovy:script><![CDATA[
return payload == 'good'
- ]]></groovy:script>
-</filter>
+ ]]></int-groovy:script>
+</int:filter>
Here, you see that the script can be included inline
or via the location attribute using the groovy namespace
@@ -53,7 +53,7 @@
the refresh-check-delay attribute on the script
element.
- <groovy:script location="..." refresh-check-delay="5000"/>
+ <int-groovy:script location="..." refresh-check-delay="5000"/>
In the above example any invocations that occur within the 5 seconds immediately following the
updating of the script would still be using the old script. However, any invocation that occurs
@@ -61,13 +61,13 @@
result in execution of the new script. This is a good example where 'near real
time' is acceptable.
- <groovy:script location="..." refresh-check-delay="0"/>
+ <int-groovy:script location="..." refresh-check-delay="0"/>
In the above example the context will be updated with any script modifications
as soon as such modification occurs. Basically this is an example of
'real-time' configuration and might not be the most efficient option (but could be useful during development).
- <groovy:script location="..." refresh-check-delay="-1"/>
+ <int-groovy:script location="..." refresh-check-delay="-1"/>
Any negative number value means the script will never be refreshed after
initial initialization of the application context. This is the default behavior.
@@ -106,7 +106,7 @@
If you need more control over how a particular variable is generated, then all you need to do is
provide your own implementation of ScriptVariableGenerator and reference it with the script-variable-generator
attribute:
-
]]>
@@ -122,9 +122,9 @@
customizer attribute. For example, this might be useful if you want to configure a domain-specific
language (DSL) by modifying the MetaClass and registering functions to be available within the script.
-
-
-
+
+
+
]]>
@@ -143,7 +143,7 @@
"application-level" messaging. In Spring Integration we build upon the
adapters described above so that it's possible to send Messages as a means
of invoking exposed operations. One option for those operations is Groovy scripts.
- <groovy:control-bus input-channel="operationChannel"/>
+ <int-groovy:control-bus input-channel="operationChannel"/>
The Control Bus has an input channel that can be accessed for
invoking operations on the beans in the application context.
@@ -161,7 +161,7 @@
that implements org.springframework.scripting.groovy.GroovyObjectCustomizer via
the customizer attribute.
-
diff --git a/docs/src/reference/docbook/http.xml b/docs/src/reference/docbook/http.xml
index f0bd65e5fc..580a2b1e71 100644
--- a/docs/src/reference/docbook/http.xml
+++ b/docs/src/reference/docbook/http.xml
@@ -113,12 +113,12 @@ In the case of the Outbound Gateway, the reply message produced by the gateway w
To configure an inbound http channel adapter which is an instance of HttpInboundEndpoint configured
not to expect a response.
- ]]>
To configure an inbound http gateway which expects a response.
- ]]>
@@ -127,7 +127,7 @@ In the case of the Outbound Gateway, the reply message produced by the gateway w
default http-method is POST, and the default response type is null. With a null response type, the payload of the reply Message would only
contain the status code (e.g. 200) as long as it's a successful status (non-successful status codes will throw Exceptions). If you are expecting a different
type, such as a String, then provide that fully-qualified class name as shown below.
- If your outbound adapter is to be used in a unidirectional way, then you can use an outbound-channel-adapter instead. This means that
a successful response will simply execute without sending any Messages to a reply channel. In the case of any non-successful response
status code, it will throw an exception. The configuration looks very similar to the gateway:
- uri-variable sub element in
Http Outbound Gateway configuration.
-
-
-]]>
+
+]]>
The uri-variable defines two attributes expression and value. You generally use
the value attribute for literal values, but if the value you are trying to inject is dynamic and requires
diff --git a/docs/src/reference/docbook/httpinvoker.xml b/docs/src/reference/docbook/httpinvoker.xml
index ef681b891b..3b46f53684 100644
--- a/docs/src/reference/docbook/httpinvoker.xml
+++ b/docs/src/reference/docbook/httpinvoker.xml
@@ -82,7 +82,7 @@
To configure the inbound gateway you can choose to use the namespace support for it. The following code snippet shows the different configuration options that are supported.
-
To configure the outbound gateway you can use the namespace support as well. The following code snippet shows the different configuration for an outbound HttpInvoker gateway. Only the 'url' and 'request-channel' are required.
-
UDP Adapters
-
-
-
-
-
]]>
@@ -185,7 +185,7 @@
-
DataSource reference.
- ]]>
@@ -55,12 +55,12 @@
controlled. A very important feature of the poller for JDBC usage is the
option to wrap the poll operation in a transaction, for example:
-
-
-
-
-]]>
+
+
+
+]]>
If a poller is not explicitly specified, a default value will be used (and as per normal with Spring Integration can be defined as a top level bean).
@@ -84,7 +84,7 @@
payload and headers are available by default as input parameters to the
query, for instance:
- ]]>
@@ -116,7 +116,7 @@
SQL query and then respond with the result sending it to a reply channel.
The message payload and headers are available by default as input
parameters to the query, for instance:
- ]]>
@@ -130,7 +130,7 @@
the default because it is not supported by some database platforms). For
example:
- ]]>
@@ -139,7 +139,7 @@
provide a select query to execute and generate a reply message from the result
(like the inbound adapter), e.g:
- ]]>
@@ -168,7 +168,7 @@
implemented by the JdbcMessageStore, and there is also support for
configuring store instances in XML. For example:
-
+
]]>
A JdbcTemplate can be specified instead of a
@@ -176,7 +176,7 @@
Other optional attributes are show in the next example:
- ]]>
Here we have specified a LobHandler for dealing with
diff --git a/docs/src/reference/docbook/jms.xml b/docs/src/reference/docbook/jms.xml
index 436f63efea..a5d68ad173 100644
--- a/docs/src/reference/docbook/jms.xml
+++ b/docs/src/reference/docbook/jms.xml
@@ -32,9 +32,9 @@
instance or both ConnectionFactory and Destination
(a 'destinationName' can be provided in place of the 'destination' reference). The following example defines an
inbound Channel Adapter with a Destination reference.
-
-
- ]]>
+
+
+ ]]>
Notice from the configuration that the inbound-channel-adapter is a Polling Consumer. That means that
it invokes receive() when triggered. This should only be used in situations where polling is done relatively
@@ -55,12 +55,12 @@
String-based payload, a JMS BytesMessage will produce a byte array payload, and a JMS ObjectMessage's
Serializable instance will become the Spring Integration Message's payload. If instead you prefer to have
the raw JMS Message as the Spring Integration Message's payload, then set 'extract-payload' to false.
-
-
- ]]>
+
+ ]]>
@@ -72,7 +72,7 @@
ConnectionFactory and Destination
(a 'destinationName' can be provided in place of the 'destination' reference). The following example defines a
message-driven Channel Adapter with a Destination reference.
- ]]>
+ ]]>
The Message-Driven adapter also accepts several properties that pertain to the MessageListener container.
These values are only considered if you do not provide an actual 'container' reference. In that case,
@@ -91,7 +91,7 @@
Finally, the <message-driven-channel-adapter> also accepts the 'error-channel' attribute. This
provides the same basic functionality as described in .
-
]]>
@@ -113,7 +113,7 @@
inbound Channel Adapter, the easiest way to configure this adapter is with the namespace support. The following
configuration will produce an adapter that receives Spring Integration Messages from the "exampleChannel" and then
converts those into JMS Messages and sends them to the JMS Destination reference whose bean name is "outQueue".
- ]]>
+ ]]>
As with the inbound Channel Adapters, there is an 'extract-payload' property. However, the meaning is reversed
@@ -141,7 +141,7 @@
ConnectionFactory, and a request Destination (or
'requestDestinationName'). The following example defines a JMS "inbound-gateway" that receives from the JMS
queue referenced by the bean id "inQueue" and sends to the Spring Integration channel named "exampleChannel".
- ]]>
@@ -174,7 +174,7 @@
request-channel="jmsinputchannel"
error-channel="errorTransformationChannel"/>
-
]]>
You might notice that this example looks very similar to that included
@@ -193,7 +193,7 @@
'request-destination'. It will then handle the JMS reply Message either by using a selector to
receive from the 'reply-destination' that you configure, or if no 'reply-destination' is provided,
it will create JMS TemporaryQueues. Notice that the "reply-channel" is also provided.
- ]]>
@@ -280,7 +280,7 @@
required even though conceptually the goal is to have a single Message Channel. A better option is
supported as of Spring Integration version 2.0. Now it is possible to define a single "channel" when
using the JMS namespace.
- ]]>
+ ]]>
The channel in the above example will behave much like a normal <channel/> element from the main
@@ -304,11 +304,11 @@
Since the example above is referencing a JMS Queue instance, it will act as a point-to-point channel. If
on the other hand, publish/subscribe behavior is needed, then a separate element can be used, and a JMS
Topic can be referenced instead.
- ]]>
+ ]]>
For either type of JMS-backed channel, the name of the destination may be provided instead of a reference.
-
+
]]>
@@ -319,7 +319,7 @@
ConnectionFactory is a required property of the channel, but by default
the expected bean name would be "connectionFactory". The example below provides both a custom instance
for resolution of the JMS Destination names and a different name for the ConnectionFactory.
- ]]>
diff --git a/docs/src/reference/docbook/jmx.xml b/docs/src/reference/docbook/jmx.xml
index 3d9c614de7..06a3cd6ada 100644
--- a/docs/src/reference/docbook/jmx.xml
+++ b/docs/src/reference/docbook/jmx.xml
@@ -18,7 +18,7 @@
The Notification-listening Channel Adapter requires a JMX ObjectName
for the MBean that publishes Notifications to which this listener should
be registered. A very simple configuration might look like this:
- <jmx:notification-listening-channel-adapter id="adapter"
+ <int-jmx:notification-listening-channel-adapter id="adapter"
channel="channel"
object-name="example.domain:name=publisher"/>
The notification-listening-channel-adapter
@@ -30,7 +30,7 @@
"handback" Object to provide some context that is passed back with each
Notification. Both of those attributes are optional. Extending the above
example to include those attributes as well as an explicit MBeanServer
- bean name would produce the following: <jmx:notification-listening-channel-adapter id="adapter"
+ bean name would produce the following: <int-jmx:notification-listening-channel-adapter id="adapter"
channel="channel"
mbean-server="someServer"
object-name="example.domain:name=somePublisher"
@@ -48,7 +48,7 @@
only requires a JMX ObjectName in its configuration as shown below.
<context:mbean:export/>
- <jmx:notification-publishing-channel-adapter id="adapter"
+ <int-jmx:notification-publishing-channel-adapter id="adapter"
channel="channel"
object-name="example.domain:name=publisher"/>
It does also require that an MBeanExporter be present in the context. That
@@ -68,7 +68,7 @@
fallback "default-notification-type" attribute provided in the
configuration. <context:mbean:export/>
- <jmx:notification-publishing-channel-adapter id="adapter"
+ <int-jmx:notification-publishing-channel-adapter id="adapter"
channel="channel"
object-name="example.domain:name=publisher"
default-notification-type="some.default.type"/>
@@ -85,12 +85,12 @@
An MBeanServer reference is also required, but it will automatically check
for a bean named "mbeanServer" by default just like the
notification-listening-channel-adapter described above. <jmx:attribute-polling-channel-adapter id="adapter"
+ language="xml"> <int-jmx:attribute-polling-channel-adapter id="adapter"
channel="channel"
object-name="example.domain:name=someService"
attribute-name="InvocationCount">
- <si:poller max-messages-per-poll="1" fixed-rate="5000"/>
- </jmx:attribute-polling-channel-adapter>
+ <int:poller max-messages-per-poll="1" fixed-rate="5000"/>
+ </int-jmx:attribute-polling-channel-adapter>
@@ -100,7 +100,7 @@
Message-driven invocation of any managed operation exposed by an MBean.
Each invocation requires the operation name to be invoked and the
ObjectName of the target MBean. Both of these must be explicitly provided
- via adapter configuration: <jmx:operation-invoking-channel-adapter id="adapter"
+ via adapter configuration: <int-jmx:operation-invoking-channel-adapter id="adapter"
object-name="example.domain:name=TestBean"
operation-name="ping"/> Then the adapter
only needs to be able to discover the "mbeanServer" bean. If a different
@@ -128,7 +128,7 @@
operation-invoking-outbound-gateway which could be
used when dealing with non-void operations and return value is required.
Such return value will be sent as message payload to the 'reply-channel'
- specified by this Gateway. <jmx:operation-invoking-outbound-gateway request-channel="requestChannel"
+ specified by this Gateway. <int-jmx:operation-invoking-outbound-gateway request-channel="requestChannel"
reply-channel="replyChannel"
object-name="org.springframework.integration.jmx.config:type=TestBean,name=testBeanGateway"
operation-name="testWithReturn"/> Another way of
@@ -145,7 +145,7 @@
create an instance of the IntegrationMBeanExporter,
define a bean and provide a reference to an MBeanServer and a domain name
(if desired). The domain can be left out in which case the default domain
- is "org.springframework.integration". <jmx:mbean-exporter default-domain="my.company.domain" server="mbeanServer"/>
+ is "org.springframework.integration". <int-jmx:mbean-exporter default-domain="my.company.domain" server="mbeanServer"/>
<bean id="mbeanServer" class="org.springframework.jmx.support.MBeanServerFactoryBean">
<property name="locateExistingServerIfPossible" value="true"/>
diff --git a/docs/src/reference/docbook/mail.xml b/docs/src/reference/docbook/mail.xml
index 14af8737e8..f2b20d5a47 100644
--- a/docs/src/reference/docbook/mail.xml
+++ b/docs/src/reference/docbook/mail.xml
@@ -70,7 +70,7 @@
locations.
]]>
Alternatively, provide the host, username, and password:
- ]]>
Keep in mind, as with any outbound Channel Adapter, if the referenced channel is a PollableChannel, a
@@ -183,7 +183,7 @@
When using the namespace support, a header-enricher Message Transformer is also available.
This simplifies the application of the headers mentioned above to any Message prior to sending to the
Mail-sending Channel Adapter.
- <bean class="org.springframework.integration.aop.PublisherAnnotationBeanPostProcessor"/>
You can instead use namespace support for a more concise configuration:
-<si:annotation-config default-publisher-channel="defaultChannel"/>
+<int:annotation-config default-publisher-channel="defaultChannel"/>
@@ -327,39 +327,39 @@ static class BankingOperationsImpl implements BankingOperations {
-
-
-]]>
+
+]]>
In the above example an inbound Channel Adapter will be created which will construct a Message with its payload being the result of the expression
defined in the expression attribute. Such messages will be created and sent every time the delay specified by the fixed-delay attribute occurs.
-
-
-]]>
+
+]]>
This example is very similar to the previous one, except that we are using the fixed-rate attribute which will allow us to send messages at a fixed rate (measuring from the start time of each task).
-
-
-]]>
+
+]]>
This example demonstrates how you can apply a Cron trigger with a value specified in the cron attribute.
-
-
-
-
-]]>
+
+
+
+]]>
Here you can see that in a way very similar to the Message publishing feature we are enriching a newly constructed Message with
extra Message headers which can take scalar values or the results of evaluating Spring expressions.
@@ -369,10 +369,10 @@ static class BankingOperationsImpl implements BankingOperations {
If you need to implement your own custom trigger you can use the trigger attribute to provide a reference to any spring configured
bean which implements the org.springframework.scheduling.Trigger interface.
-
-
-
+
+
diff --git a/docs/src/reference/docbook/resequencer.xml b/docs/src/reference/docbook/resequencer.xml
index f5b0502da7..63f7556e2c 100644
--- a/docs/src/reference/docbook/resequencer.xml
+++ b/docs/src/reference/docbook/resequencer.xml
@@ -32,11 +32,11 @@
A sample resequencer configuration is shown below.
-
+
-
+
-RMI namespace support
To configure the inbound gateway you can choose to use the namespace support for it. The following code snippet shows the different configuration options that are supported.
-
+
-
-
-
- ]]>
To configure the outbound gateway you can use the namespace support as well. The following code snippet shows the different configuration for an outbound rmi gateway.
- ]]>
diff --git a/docs/src/reference/docbook/router.xml b/docs/src/reference/docbook/router.xml
index 3e5e50a8f4..7dc1c4808f 100644
--- a/docs/src/reference/docbook/router.xml
+++ b/docs/src/reference/docbook/router.xml
@@ -33,10 +33,10 @@
The example below demonstrates a PayloadTypeRouter configuration which is equivalent to the one above using the namespace support:
-
-
-
-]]>
+
+
+
+]]>
The 'apply-sequence' flag here has the same effect as it does for a publish-subscribe-channel,
@@ -176,24 +176,24 @@
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:
-
+
-]]>
+]]>
@@ -343,10 +343,10 @@ public List<String> route(@Header("orderStatus") OrderStatus status)Payload Type Router
-
-
-
-]]>
+
+
+
+]]>
Within the context of the Payload Type Router the 3 steps mentioned above would be realized as:
@@ -373,10 +373,10 @@ public List<String> route(@Header("orderStatus") OrderStatus status)Header Value Router
-
-
-
-]]>
+
+
+
+]]>
Similar to the PayloadTypeRouter:
@@ -402,7 +402,7 @@ public List<String> route(@Header("orderStatus") OrderStatus status)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?
diff --git a/docs/src/reference/docbook/samples.xml b/docs/src/reference/docbook/samples.xml
index eb82d099b9..e55dbd1ea8 100644
--- a/docs/src/reference/docbook/samples.xml
+++ b/docs/src/reference/docbook/samples.xml
@@ -249,13 +249,13 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
XML <gateway> element or via annotation and use it as any other Spring bean. SI will take care of
delegating and mapping method invocations to the Messaging infrastructure by generating a Message (payload is mapped to an
input parameter of the method) and sending it to the designated channel.
-
-
-
-
-]]>
+
+
+
+]]>
Our current Gateway provides two methods that could be invoked. One that will return the best single quote and another one that
@@ -334,11 +334,11 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
An Aggregator pattern describes an endpoint which groups related Messages into a single
Message. Criteria and rules can be provided to determine an aggregation and correlation strategy.
SI provides several implementations of the Aggregator pattern as well as a convenient name-space based configuration.
-
-]]>
+]]>
@@ -412,10 +412,10 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
Here is the XML configuration:
-
-
+
-
-
+
+
-
-
+
+
-
-
-
-
+
+
+
-
-
-
-
+
+
+
-
-
+
-
+
@@ -459,7 +459,7 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
-
+
]]>
As you can see, each Message Endpoint is connected to input and/or output channels. Each endpoint will manage
@@ -576,18 +576,18 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
This is to be expected based on their respective delays of 1000 and 5000 milliseconds. However, by configuring a
poller with a concurrent task executor, you can dramatically change the results. For example, you could use a
thread pool executor with 5 workers for the hot drink barista while keeping the cold drink barista as it is:
-
-
- ]]>
+ ]]>
]]>
+
]]>]]>
@@ -613,10 +613,11 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
First the order is split into a number of messages, each one representing a single order item using
the XPath splitter component.
-
-
-
+
+
]]>
@@ -624,9 +625,10 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
from the stock checker about order item stock level. This enriched order item message is then used to route the message. In the
case where the order item is in stock the message is routed to the warehouse. The XPath router makes use of the default
ChannelResolver strategy which maps the XPath evaluation result to a channel reference in the ApplicationContext.
-
-
+
]]>
@@ -634,8 +636,9 @@ That includes Samples; so, if you can't find what you are looking for, let us kn
Where the order item is not in stock the message is transformed using
xslt into a format suitable for sending to the supplier.
-
+
]]>
diff --git a/docs/src/reference/docbook/security.xml b/docs/src/reference/docbook/security.xml
index a1b44e8786..0682144cb1 100644
--- a/docs/src/reference/docbook/security.xml
+++ b/docs/src/reference/docbook/security.xml
@@ -26,8 +26,8 @@
definition of one or more channel name patterns in conjunction with a definition of the security configuration for send and receive. The pattern
is a java.util.regexp.Pattern.
-
-
-
-
-]]>
+
+
+
+]]>
By default the secured-channels namespace element expects a bean named authenticationManager which implements
AuthenticationManager and a bean named accessDecisionManager which implements
AccessDecisionManager. Where this is not the case references to the appropriate beans can be configured
as attributes of the secured-channels element as below.
-
-
-
-]]>
+
+
+]]>
diff --git a/docs/src/reference/docbook/service-activator.xml b/docs/src/reference/docbook/service-activator.xml
index 37bc0898f3..4f74ef6d99 100644
--- a/docs/src/reference/docbook/service-activator.xml
+++ b/docs/src/reference/docbook/service-activator.xml
@@ -19,19 +19,19 @@
Configuring Service Activator
To create a Service Activator, use the 'service-activator' element with the 'input-channel' and 'ref' attributes:
- <service-activator input-channel="exampleChannel" ref="exampleHandler"/>
+ <int:service-activator input-channel="exampleChannel" ref="exampleHandler"/>
The configuration above assumes that "exampleHandler" either contains a single method annotated with the
@ServiceActivator annotation or that it contains only one public method at all. To delegate to an explicitly
defined method of any object, simply add the "method" attribute.
- <service-activator input-channel="exampleChannel" ref="somePojo" method="someMethod"/>
+ <int:service-activator input-channel="exampleChannel" ref="somePojo" method="someMethod"/>
In either case, when the service method returns a non-null value, the endpoint will attempt to send the reply
message to an appropriate reply channel. To determine the reply channel, it will first check if an
"output-channel" was provided in the endpoint configuration:
- <service-activator input-channel="exampleChannel" output-channel="replyChannel"
+ <int:service-activator input-channel="exampleChannel" output-channel="replyChannel"
ref="somePojo" method="someMethod"/>
If no "output-channel" is available, it will then check the Message's replyChannel header
value. If that value is available, it will then check its type. If it is a
@@ -57,10 +57,10 @@
Using a "ref" attribute is generally recommended if the custom Service Activator handler implementation can be reused
in other <service-activator> definitions. However if the custom Service Activator handler implementation
is only used within a single definition of the <service-activator>, you can provide an inner bean definition:
-
-]]>
+]]>
diff --git a/docs/src/reference/docbook/sftp.xml b/docs/src/reference/docbook/sftp.xml
index ce9b4675eb..f3c8ef5837 100644
--- a/docs/src/reference/docbook/sftp.xml
+++ b/docs/src/reference/docbook/sftp.xml
@@ -21,7 +21,7 @@
Inbound Channel Adapters and Outbound Channel Adapters as well as convenient
namespace configuration to define these clients.
-
@@ -71,7 +71,7 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/sftp
The SFTP Inbound Channel Adapter is a special listener that will connect to the server and listen for
the remote directory events (e.g., new file created) at which point it will initiate a file transfer.
-
-
-]]>
+
+]]>
As you can see from the configuration above you can configure the SFTP Inbound Channel Adapter via the
inbound-channel-adapter element while also providing values for various attributes such as local-directory
diff --git a/docs/src/reference/docbook/splitter.xml b/docs/src/reference/docbook/splitter.xml
index 3a2851430d..d9085945f7 100644
--- a/docs/src/reference/docbook/splitter.xml
+++ b/docs/src/reference/docbook/splitter.xml
@@ -84,15 +84,15 @@
Configuring a Splitter using XML
- A splitter can be configured through XML as follows:<channel id="inputChannel"/>
+ A splitter can be configured through XML as follows:<int:channel id="inputChannel"/>
-<splitter id="splitter"
+<int:splitter id="splitter"
ref="splitterBean"
method="split"
input-channel="inputChannel"
output-channel="outputChannel" />
-<channel id="outputChannel"/>
+<int:channel id="outputChannel"/>
<beans:bean id="splitterBean" class="sample.PojoSplitter"/>
@@ -133,14 +133,14 @@
Using a ref attribute is generally recommended if the custom splitter implementation may be referenced in other
<splitter> definitions. However if the custom splitter handler implementation should be scoped to a
single definition of the <splitter>, configure an inner bean definition:
-
-]]>
+]]>
- Using both a ref attribute and an inner handler definition in the same <splitter>
+ Using both a ref attribute and an inner handler definition in the same <int:splitter>
configuration is not allowed, as it creates an ambiguous condition and will result in an Exception being thrown.
diff --git a/docs/src/reference/docbook/stream.xml b/docs/src/reference/docbook/stream.xml
index f4b1c35d8e..da62d31193 100644
--- a/docs/src/reference/docbook/stream.xml
+++ b/docs/src/reference/docbook/stream.xml
@@ -62,7 +62,7 @@
To reduce the configuration needed for stream related channel adapters there is a namespace defined. The following schema locations are needed to use it.
-
+
-]]>
+]]>
To configure the outbound channel adapter you can use the namespace support as well. The following code snippet shows the different configuration for an outbound channel adapters.
-
+
-
+
-
+
-
+
]]>
diff --git a/docs/src/reference/docbook/transactions.xml b/docs/src/reference/docbook/transactions.xml
index d3e59e8715..382d26fa49 100644
--- a/docs/src/reference/docbook/transactions.xml
+++ b/docs/src/reference/docbook/transactions.xml
@@ -106,7 +106,7 @@
Poller Transaction Support
Any time you configure a Poller you can provide transactional configuration via the transactional sub-element and its attributes:
-
+
<advice-chain> with the same convenience as before but with much more control
since you now have an option to position any advice in the desired order.
-
+
diff --git a/docs/src/reference/docbook/transformer.xml b/docs/src/reference/docbook/transformer.xml
index 4ce000e62d..83d31ea3e5 100644
--- a/docs/src/reference/docbook/transformer.xml
+++ b/docs/src/reference/docbook/transformer.xml
@@ -38,7 +38,7 @@
and "output-channel" attributes, it requires a "ref". The "ref" may either point to an Object that contains the
@Transformer annotation on a single method (see below) or it may be combined with an explicit method name value
provided via the "method" attribute.
-
]]>
@@ -46,7 +46,7 @@
Using a "ref" attribute is generally recommended if the custom transformer handler implementation can be reused in
other <transformer> definitions. However if the custom transformer handler implementation should
be scoped to a single definition of the <transformer>, you can define an inner bean definition:
-
]]>
@@ -101,7 +101,7 @@
ObjectToStringTransformer whose output is a Message with a String payload. That String
is the result of invoking the toString() operation on the inbound Message's payload.
- ]]>
+ ]]>
A potential example for this would be sending some arbitrary object to the 'outbound-channel-adapter' in the
file namespace. Whereas that Channel Adapter only supports String, byte-array, or
@@ -120,9 +120,9 @@
by default, but you can provide an implementation of Spring 3.0's Serializer or Deserializer strategies via the
'serializer' and 'deserializer' attributes, respectively.
-
+
- ]]>
+ ]]>
Object-to-Map Transformer
@@ -171,7 +171,7 @@ public class Kid {
To configure these transformers, Spring Integration provides namespace support
Object-to-Map:
-]]>
+]]>
Map-to-Object
Spring Integration provides a convenient namespace configuration to define Twitter artifacts. You can enable it by adding
the following within your XML header.
-
@@ -160,11 +160,11 @@ received.
Inbound Message Channel Adapter
This adapter allows you to receive updates from everyone you follow. It's essentially the "Timeline Update" adapter.
-
-
-]]>
+
+]]>
@@ -172,11 +172,11 @@ received.
Direct Inbound Message Channel Adapter
This adapter allows you to receive Direct Messages that were sent to you from other Twitter users.
-
-
-]]>
+
+]]>
@@ -184,11 +184,11 @@ received.
Mentions Inbound Message Channel Adapter
This adapter allows you to receive Twitter Messages that Mention you via @user syntax.
-
-
-]]>
+
+]]>
@@ -197,11 +197,11 @@ received.
This adapter allows you to perform searches. As you can see it is not necessary to define twitter-template
since a search can be performed anonymously, however you must define a search query.
-
-
-]]>
+
+]]>
@@ -240,7 +240,7 @@ received.
This adapter allows you to send regular status updates by simply sending a Message to the channel
identified by the channel attribute.
- ]]>
The only extra configuration that is required for this adapter is the twitter-template reference.
@@ -252,7 +252,7 @@ received.
This adapter allows you to send Direct Twitter Messages (i.e., @user) by simply sending a Message to the channel
identified by the channel attribute.
- ]]>
The only extra configuration that is required for this adapter is the twitter-template reference.
@@ -269,16 +269,16 @@ received.
The above approach works well if you are creating the Message programmatically. However it's more common to
provide the header value within a messaging flow. The value can be provided by an upstream <header-enricher>.
-
-
-]]>
+
+
+]]>
It's quite common that the value must be determined dynamically. For those cases you can take advantage
of SpEL support within the <header-enricher>.
-
-
-]]>
+
+
+]]>
diff --git a/docs/src/reference/docbook/ws.xml b/docs/src/reference/docbook/ws.xml
index 254bae2b17..647ea29fa8 100644
--- a/docs/src/reference/docbook/ws.xml
+++ b/docs/src/reference/docbook/ws.xml
@@ -68,7 +68,7 @@ as per standard Spring Web Services configuration.
Web Service Namespace Support
To configure an outbound Web Service Gateway, use the "outbound-gateway" element from the "ws" namespace:
- ]]>
@@ -91,17 +91,17 @@ as per standard Spring Web Services configuration.
To set up an inbound Web Service Gateway, use the "inbound-gateway":
- ]]>
To use Spring OXM Marshallers and/or Unmarshallers, provide bean references. For outbound:
- ]]>
And for inbound:
- ]]>
diff --git a/docs/src/reference/docbook/xml.xml b/docs/src/reference/docbook/xml.xml
index ae11a87ebb..8b2c276cf7 100644
--- a/docs/src/reference/docbook/xml.xml
+++ b/docs/src/reference/docbook/xml.xml
@@ -119,8 +119,8 @@
-
-
-
+
+
]]>
@@ -152,13 +152,13 @@
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.
-
-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.
-
-
+
-
+
]]>
@@ -261,20 +261,20 @@
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:
-
-
+
+
-
+
]]>
@@ -345,7 +345,7 @@
Let's look at the following transformer configuration:
- ]]>
. . . and Message
@@ -366,10 +366,10 @@
You can configure the desired type by simply using evaluation-type
attribute of the <xpath-transformer/> element.
-
-
]]>
@@ -381,7 +381,7 @@
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:
-
]]>
. . . and Sample NodeMapper implementation:
@@ -397,7 +397,7 @@
You can also use implementation of the org.springframework.integration.xml.XmlPayloadConverter to
provide more granular transformation:
-
]]>
. . . and Sample XmlPayloadConverter implementation:
@@ -427,7 +427,7 @@
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.
@@ -441,32 +441,32 @@
<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
-
-
-
-
+
+
+
-
-
+
-
+
-
-
+
+
-
-
+
+
-
-
+
-
+
@@ -476,20 +476,20 @@
XPath splitter namespace support allows the creation of a Message Endpoint with an input channel and output channel.
-
-
-
+
+
-
-
-
-]]>
+
+
+]]>
diff --git a/docs/src/reference/docbook/xmpp.xml b/docs/src/reference/docbook/xmpp.xml
index 9651845bce..1ad3600113 100644
--- a/docs/src/reference/docbook/xmpp.xml
+++ b/docs/src/reference/docbook/xmpp.xml
@@ -32,7 +32,7 @@
convenient namespace-based configuration.
To configure the XMPP namespace, include the following elements in the headers of your XML configuration file:
-
@@ -48,7 +48,7 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/xmpp
To create a basic XMPP connection, you can utilize the convenience of the namespace.
- Inbound Message Channel Adapter is provided via the inbound-channel-adapter element.
-