diff --git a/spring-integration-reference/src/configuration.xml b/spring-integration-reference/src/configuration.xml
index ac195e30e8..69f33943a0 100644
--- a/spring-integration-reference/src/configuration.xml
+++ b/spring-integration-reference/src/configuration.xml
@@ -94,18 +94,26 @@
Configuring the Message Bus
- The Message Bus plays a central role, but its configuration is quite simple since it is primarily concerned
- with managing internal details based on the configuration of channels and endpoints. The bus is aware of its
- host application context, and therefore is also capable of auto-detecting the channels and endpoints.
- The Message Bus can be configured with a single empty element:
- <message-bus/>
+ In Spring Integration, the ApplicationContext plays the central role of a Message Bus, and there are only a
+ couple configuration options to be aware of. First, you may want to control the central TaskScheduler instance.
+ You can do so by providing a single bean with the name "taskScheduler". This is also defined as a constant:
+
+ By default Spring Integration uses the SimpleTaskScheduler implementation. That in turn
+ just delegates to any instance of Spring's TaskExecutor abstraction. Therefore,
+ it's rather trivial to supply your own configuration. The "taskScheduler" bean is then responsible for managing
+ all pollers. The TaskScheduler will startup automatically by default. If you provide your own instance of
+ SimpleTaskScheduler however, you can set the 'autoStartup' property to false instead.
- The Message Bus provides default error handling for its components in the form of a configurable error channel,
- and it will first check for a channel bean named 'errorChannel' within the context:
-
-
-]]>
+ When the endpoints are concurrency-enabled with their own 'taskExecutor' reference, the invocation of the
+ handling methods will happen within that executor's thread pool and not the main scheduler pool. However,
+ when no task-executor is provided for an endpoint's poller, it will be invoked in the dispatcher's thread
+ (with the exception of subscribable channels where the subscribers will be invoked directly).
+
+
+ The Message Bus supports error handling for its components in the form of a configurable error channel,
+ and it will first check for a channel bean named "errorChannel" within the context:
+ ]]>
When exceptions occur in a scheduled poller task's execution, those exceptions will be wrapped in
ErrorMessages and sent to the 'errorChannel' by default. To enable global error
handling, simply register a handler on that channel. For example, you can configure Spring Integration's
@@ -115,22 +123,6 @@
MessageDeliveryException or MessageHandlingException,
the ErrorMessageExceptionTypeRouter is typically a better option.
-
- The 'message-bus' element accepts several more optional attributes. First, you can control whether the
- MessageBus will be started automatically (the default) or will require explicit startup
- by invoking its start() method (MessageBus implements
- Spring's Lifecycle interface):
- ]]>
-
-
- Another configurable property is the reference to a TaskScheduler implementation.
- If not provided, a default will be created. The scheduler is responsible for managing the pollers.
- ]]>
- When the endpoints are concurrency-enabled with their own 'taskExecutor' reference, the invocation of the handling
- methods will happen within that executor's thread pool and not the main scheduler pool. However, when no
- task-executor is provided for an endpoint's poller, then it will be invoked in the dispatcher's thread
- (with the exception of subscribable channels where the subscribers may be invoked directly).
-
@@ -204,6 +196,22 @@ public class FooService {
the such an endpoint's output channel will be used if available, and the message header's REPLY_CHANNEL value
will be the fallback.
+
+ In addition to the examples shown here, these annotations also support inputChannel and outputChannel properties.
+ public class FooService {
+
+ @ServiceActivator(inputChannel="input", outputChannel="output")
+ public void bar(String payload, @Headers Map<String, Object> headerMap) {
+ ...
+ }
+
+}
+ That provides a pure annotation-driven alternative to the XML configuration. However, it is generally recommended
+ to use XML for the endpoints, since it is easier to keep track of the overall configuration in a single, external
+ location (and besides the XML configuration is not very verbose). If you do prefer to provide channels with the
+ annotations however, you just need to enable a BeanPostProcessor. The following element should be added:
+ ]]>
+
\ No newline at end of file