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:

 IntegrationContextUtils.TASK_SCHEDULER_BEAN_NAME 

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.

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:

 <channel id="errorChannel" capacity="500"/>

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 ErrorMessageExceptionTypeRouter as the handler of an endpoint that is subscribed to the 'errorChannel'. That router can then spread the error messages across multiple channels based on Exception type. However, since most of the errors will already have been wrapped in MessageDeliveryException or MessageHandlingException, the ErrorMessageExceptionTypeRouter is typically a better option.