Previously, you could specify a reply-channel on an outbound gateway within a chain. It was completely ignored. The gateway’s reply goes to the next chain element or, if the gateway is the last element, to the chain’s output channel. This condition is now detected and disallowed. If you have such a configuration, remove the reply-channel.

We added an option to make the service activator be synchronous. See Section 10.5.2, “Asynchronous Service Activator” for more information.

The messaging annotation support does not require a @MessageEndpoint (or any other @Component) annotation declaration on the class level. To restore the previous behavior, set the spring.integration.messagingAnnotations.require.componentAnnotation of spring.integration.properties to true. See Section E.4, “Global Properties” and Section E.5, “Annotation Support” for more information.

The customizable userFlag (added in 4.2.2 to provide customization of the flag used to denote that the mail has been seen) is now available in the XML namespace. See Section 24.5, “Marking IMAP Messages When \Recent Is Not Supported” for more information.

You can now map inbound mail messages with the MessageHeaders containing the mail headers and the payload containing the email content. Previously, the payload was always the raw MimeMessage. See Section 24.3, “Inbound Mail Message Mapping” for more information.

The DefaultJmsHeaderMapper now maps the standard correlationId header as a message property by invoking its toString() method. See Section 23.6, “Mapping Message Headers to and from JMS Message” for more information.

The JMS outbound gateway now has an async property. See Section 23.5.4, “Async Gateway” for more information.

A new TcpConnectionServerListeningEvent is emitted when a server connection factory is started. See Section 34.5, “TCP Connection Events” for more information.

You can now use the destination-expression and socket-expression attributes on <int-ip:udp-outbound-channel-adapter>. See Section 34.2, “UDP Adapters” for more information.

The various deserializers that cannot allocate the final buffer until the whole message has been assembled now support pooling the raw buffer into which the data is received rather than creating and discarding a buffer for each message. See Section 34.3, “TCP Connection Factories” for more information.

The message mapper now, optionally, sets a configured content type header. See Section 34.13, “IP Message Headers” for more information.

The generated file name for the FileWritingMessageHandler can represent a sub-path to save the desired directory structure for a file in the target directory. See Section 17.2.1, “Generating File Names” for more information.

The FileReadingMessageSource now hides the WatchService directory scanning logic in the inner class. We added the use-watch-service and watch-events options to enable this behavior. We deprecated the top-level WatchServiceDirectoryScanner because of inconsistency around the API. See Section 17.1.4, “WatchServiceDirectoryScanner” for more information.

When writing files, you can now specify the buffer size.

You can now avoid flushing files when appending and use a number of strategies to flush the data during idle periods. See Section 17.2.4, “Flushing Files When Using APPEND_NO_FLUSH” for more information.

You can now configure the outbound channel adapter to set the destination file’s lastmodified timestamp. See Section 17.2.5, “File Timestamps” for more information.

The FileSplitter now automatically closes an FTP or SFTP session when the file is completely read. This applies when the outbound gateway returns an InputStream or when you use the new FTP or SFTP streaming channel adapters. We also introduced a new markers-json option to convert FileSplitter.FileMarker to JSON String for relaxed downstream network interaction. See Section 17.4, “File Splitter” for more information.

We added ChainFileListFilter as an alternative to CompositeFileListFilter. See Section 17.1, “Reading Files” for more information.

The outbound endpoints now support a RabbitTemplate configured with a ContentTypeDelegatingMessageConverter such that you can choose the converter based on the message content type. See Section 14.8, “Outbound Message Conversion” for more information.

Spring AMQP 1.6 adds support for delayed message exchanges. Header mapping now supports the headers (amqp_delay and amqp_receivedDelay) used by this feature.

AMQP-backed channels now support message mapping. See Section 14.11, “AMQP-backed Message Channels” for more information.

Previously, the queue channel adapters always used the Redis list in a fixed direction, pushing to the left end and reading from the right end. You can now configure the reading and writing direction with the rightPop and leftPush options for the RedisQueueMessageDrivenEndpoint and RedisQueueOutboundChannelAdapter, respectively. See Section 27.2.4, “Redis Queue Inbound Channel Adapter” and Section 27.2.5, “Redis Queue Outbound Channel Adapter” for more information.

The default serializer in the inbound gateway has been changed to a JdkSerializationRedisSerializer for compatibility with the outbound gateway. See Section 27.9, “Redis Queue Inbound Gateway” for more information.

We added a new factory bean to simplify the configuration of Jsch proxies for SFTP. See Section 30.2, “Proxy Factory Bean” for more information.

The SFTP outbound gateway (for put and mput commands) and the SFTP outbound channel adapter now support the chmod attribute to change the remote file permissions after uploading. See <<sftp-outbound>> and <<sftp-outbound-gateway>> for more information.

The FtpSession now supports null for the list() and listNames() methods, since underlying FTP Client can use it. With that, you can now configure the FtpOutboundGateway without the remoteDirectory expression. You can also configure the <int-ftp:inbound-channel-adapter> without remote-directory or remote-directory-expression. See Chapter 18, FTP/FTPS Adapters for more information.

AMQP, WS, and XMPP header mappings (such as request-header-mapping and reply-header-mapping) now support negated patterns. See Section 14.12, “AMQP Message Headers”, Section 37.5, “WS Message Headers”, and Section 39.5, “XMPP Message Headers” for more information.

Previously, only standard AMQP headers were mapped by default. You had to explicitly enable mapping of user-defined headers. With this release, all headers are mapped by default. In addition, the inbound amqp_deliveryMode header is no longer mapped by default. See Section 14.12, “AMQP Message Headers” for more information.

The <int-file:outbound-channel-adapter> and <int-file:outbound-gateway> now support an append-new-line attribute. If set to true, a new line is appended to the file after a message is written. The default attribute value is false.

We added the ignore-hidden attribute for the <int-file:inbound-channel-adapter> to let you set whether to pick up hidden files from the source directory. It defaults to true.

The FileWritingMessageHandler now also accepts InputStream as a valid message payload type.

You can now use the HeadDirectoryScanner with other FileListFilter implementations.

We added the LastModifiedFileListFilter.

We added the WatchServiceDirectoryScanner.

The AbstractPersistentFileListFilter has a new property (flushOnUpdate) which, when set to true, calls flush() on the metadata store if it implements Flushable (for example, PropertiesPersistingMetadataStore).

The TCP Serializers no longer flush() the OutputStream. This is now done by the TcpNxxConnection classes. If you use the serializers directly within your code, you may have to flush() the OutputStream.

TcpConnectionServerExceptionEvent instances are now published whenever an unexpected exception occurs on a TCP server socket (also added to 4.1.3 and 4.0.7). See Section 34.5, “TCP Connection Events” for more information.

If you configure a TCP server socket factory to listen on a random port, you can now obtain the actual port chosen by the OS by using getPort(). getServerSocketAddress() is also available.

See "Section 34.3, “TCP Connection Factories”" for more information.

The TcpOutboundGateway now supports remote-timeout-expression as an alternative to the existing remote-timeout attribute. This allows setting the timeout based on each message.

Also, the remote-timeout no longer defaults to the same value as reply-timeout, which has a completely different meaning.

See Table 34.7, “TCP Outbound Gateway Attributes” for more information.

TcpConnection implementations now support getSslSession() to let you extract information from the session to add to message headers. See Section 34.13, “IP Message Headers” for more information.

New events are now published whenever a correlation exception occurs — such as sending a message to a non-existent socket.

The TcpConnectionEventListeningMessageProducer is deprecated. Use the generic event adapter instead.

See Section 34.5, “TCP Connection Events” for more information.

You can now configure the reply listener in JMS outbound gateways to be initialized on-demand and stopped after an idle period, instead of being controlled by the gateway’s lifecycle. See Section 23.5, “Outbound Gateway” for more information.

The error-channel is now used for the conversion errors. In previous versions, they caused transaction rollback and message redelivery.

See Section 23.2, “Message-driven Channel Adapter” and Section 23.4, “Inbound Gateway” for more information.

When using an implicitly defined DefaultMessageListenerContainer, the default acknowledge is now transacted. We recommend using transacted when using this container, to avoid message loss. This default now applies to the message-driven inbound adapter and the inbound gateway. It was already the default for JMS-backed channels.

See Section 23.2, “Message-driven Channel Adapter” and Section 23.4, “Inbound Gateway” for more information.

We added Namespace support for shared subscriptions (JMS 2.0) to message-driven endpoints and the <int-jms:publish-subscribe-channel>. Previously, you had to wire up listener containers as <bean/> declarations to use shared connections.

See Chapter 23, JMS Support for more information.

The <int-amqp:outbound-gateway> now supports confirm-correlation-expression, confirm-ack-channel, and confirm-nack-channel attributes (which have a purpose similar to that of <int-amqp:outbound-channel-adapter>).

For both the outbound channel adapter and the inbound gateway, if the correlation data is a Message<?>, it becomes the basis of the message on the ack or nack channel, with the additional header(s) added. Previously, any correlation data (including Message<?>) was returned as the payload of the ack or nack message.

The <int-amqp:inbound-gateway> now exposes the amqp-template attribute to allow more control over an external bean for the reply RabbitTemplate. You can also provide your own AmqpTemplate implementation. In addition, you can use default-reply-to if the request message does not have a replyTo property.

See Chapter 14, AMQP Support for more information.

The HTTP inbound endpoints (<int-http:inbound-channel-adapter> and <int-http:inbound-gateway>) now allow the configuration of Cross-origin Resource Sharing (CORS).

See Section 20.3.3, “Cross-origin Resource Sharing (CORS) Support” for more information.

You can configure the HTTP inbound gate way to return a status code that you specify when a request times out. The default is now 500 Internal Server Error instead of 200 OK.

See Section 20.3.4, “Response Status Code” for more information.

We added documentation for proxying multipart/form-data requests. See Chapter 20, HTTP Support for more information.

When using Java 8, gateway methods can now return CompletableFuture<?>. See the section called “CompletableFuture” for more information.

The request and reply timeout properties are now String instead of Long to allow configuration with property placeholders or SpEL. See Section 10.4.6, “@MessagingGateway Annotation”.

This release includes some performance improvements for aggregating components (aggregator, resequencer, and others), by more efficiently removing messages from groups when they are released. New methods (removeMessagesFromGroup) have been added to the message store. Set the removeBatchSize property (default: 100) to adjust the number of messages deleted in each operation. Currently, the JDBC, Redis, and MongoDB message stores support this property.

When using a ref or inner bean for the aggregator, you can now directly bind a MessageGroupProcessor. In addition, we added a SimpleMessageGroupProcessor that returns the collection of messages in the group. When an output processor produces a collection of Message<?>, the aggregator releases those messages individually. Configuring the SimpleMessageGroupProcessor makes the aggregator a message barrier, where messages are held up until they all arrive and are then released individually. See Section 8.4, “Aggregator” for more information.

You can now specify a remote-directory-expression on the inbound channel adapters, to determine the directory at runtime. See Chapter 18, FTP/FTPS Adapters and Chapter 30, SFTP Adapters for more information.

When you use FTP or SFTP outbound gateways to operate on multiple files (with mget and mput), an exception can occur after part of the request is completed. If such a condition occurs, a PartialSuccessException that contains the partial results is thrown. See Section 18.9, “FTP Outbound Gateway” and Section 30.11, “SFTP Outbound Gateway” for more information.

We added a delegating session factory, enabling the selection of a particular session factory based on some thread context value.

See Section 18.3, “Delegating Session Factory” and Section 30.3, “Delegating Session Factory” for more information.

Previously, the DefaultSftpSessionFactory unconditionally allowed connections to unknown hosts. This is now configurable (default: false).

The factory now requires a configured knownHosts, file unless the allowUnknownKeys property is true (default: false).

See Section 30.1.1, “Configuration Properties” for more information.

We introduced the MessageSessionCallback<F, T> to perform any custom Session operations with the requestMessage context in the <int-(s)ftp:outbound-gateway/>.

See Section 18.12, “Using MessageSessionCallback” and Section 30.13, “MessageSessionCallback” for more information.

The messaging gateway methods now support a Reactor Promise return type. See Section 10.4.10, “Asynchronous Gateway”.

The WebSocket module is now available. It is fully based on the Spring WebSocket and Spring Messaging modules and provides an <inbound-channel-adapter> and an <outbound-channel-adapter>. See Chapter 36, WebSockets Support for more information.

We implemented the scatter-gather enterprise integration pattern. See Section 8.7, “Scatter-Gather” for more information.

We added the routing slip EIP pattern implementation. See the section called “Routing Slip” for more information.

We added the idempotent receiver enterprise integration pattern implementation by adding the <idempotent-receiver> component in XML or the IdempotentReceiverInterceptor and IdempotentReceiver annotations for Java configuration. See Section 10.9.10, “Idempotent Receiver Enterprise Integration Pattern” and the Javadoc for more information.

We added the Boon JsonObjectMapper for the JSON transformers. See Section 9.1, “Transformer” for more information.

We added the <redis-queue-inbound-gateway> and <redis-queue-outbound-gateway> components. See Section 27.9, “Redis Queue Inbound Gateway” and Section 27.8, “Redis Queue Outbound Gateway”.

We added the PollSkipAdvice, which you can use within the <advice-chain> of the <poller> to determine if the current poll should be suppressed (skipped) by some condition that you implement with PollSkipStrategy. See Section 6.2, “Poller” for more information.

Elements that use a message listener container (inbound endpoints and channel) now support the missing-queues-fatal attribute. See Chapter 14, AMQP Support for more information.

The AMQP outbound endpoints support a new property called lazy-connect (default: true). When true, the connection to the broker is not established until the first message arrives (assuming there are no inbound endpoints, which always try to establish the connection during startup). When set to false, an attempt to establish the connection is made during application startup. See Chapter 14, AMQP Support for more information.

The SimpleMessageStore no longer makes a copy of the group when calling getMessageGroup(). See Caution about SimpleMessageStore for more information.

The <ws:outbound-gateway/> now provides an encode-uri attribute to allow disabling the encoding of the URI object before sending the request.

The <http:inbound-channel-adapter> can now be configured with a status-code-expression to override the default 200 OK status. See Section 20.3, “HTTP Namespace Support” for more information.

You can now configure the MQTT channel adapters to connect to multiple servers — for example, to support High Availability (HA). See Chapter 26, MQTT Support for more information.

The MQTT message-driven channel adapter now supports specifying the QoS setting for each subscription. See Section 26.1, “Inbound (Message-driven) Channel Adapter” for more information.

The MQTT outbound channel adapter now supports asynchronous sends, avoiding blocking until delivery is confirmed. See Section 26.2, “Outbound Channel Adapter” for more information.

It is now possible to programmatically subscribe to and unsubscribe from topics at runtime. See Section 26.1, “Inbound (Message-driven) Channel Adapter” for more information.

The FTP and SFTP outbound channel adapters now support appending to remote files and taking specific actions when a remote file already exists. The remote file templates now also supports this, as well as rmdir() and exists(). In addition, the remote file templates provide access to the underlying client object, enabling access to low-level APIs.

See Chapter 18, FTP/FTPS Adapters and Chapter 30, SFTP Adapters for more information.

Splitter components now support an Iterator as the result object for producing output messages. See Section 8.3, “Splitter” for more information.

Aggregator instancess now support a new attribute expire-groups-upon-timeout. See Section 8.4, “Aggregator” for more information.

We added a null-result-expression attribute, which is evaluated and returned if <enricher> returns null. You can add it in <header> and <property>. See Section 9.2, “Content Enricher” for more information.

We added an error-channel attribute, which is used to handle an error flow if an Exception occurs downstream of the request-channel. This lets you return an alternative object to use for enrichment. See Section 9.2, “Content Enricher” for more information.

The <header-enricher/> element’s <header-channels-to-string/> child element can now override the header channel registry’s default time for retaining channel mappings. See the section called “Header Channel Registry” for more information.

We made improvements to the orderly shutdown algorithm. See Section 12.7, “Orderly Shutdown” for more information.

The RecipientListRouter now provides several management operations to configure recipients at runtime. With that, you can now configure the <recipient-list-router> without any <recipient> from the start. See the section called “RecipientListRouterManagement” for more information.

The AbstractHeaderMapper implementation now provides the additional NON_STANDARD_HEADERS token to map any user-defined headers, which are not mapped by default. See Section 14.12, “AMQP Message Headers” for more information.

We introduced the template-channel-transacted attribute for AMQP MessageChannel instances. See Section 14.11, “AMQP-backed Message Channels” for more information.

The default syslog message converter now has an option to retain the original message in the payload while still setting the headers. See Section 33.1, “Syslog Inbound Channel Adapter” for more information.

In addition to the Promise return type mentioned earlier, gateway methods may now return a ListenableFuture, introduced in Spring Framework 4.0. You can also disable asynchronous processing in the gateway, letting a downstream flow directly return a Future. See Section 10.4.10, “Asynchronous Gateway”.

Aggregator and Resequencer now support <expire-advice-chain/> and <expire-transactional/> child elements to advise the forceComplete operation. See ??? for more information.

The <int:outbound-channel-adapter/> now supports the <script/> child element. The underlying script must have a void return type or return null. See Section 10.8, “Groovy support” and Section 10.7, “Scripting Support”.

When a message group in a resequencer times out (using group-timeout or a MessageGroupStoreReaper), late arriving messages are now, by default, discarded immediately. See Section 8.5, “Resequencer”.

Spring Integration now consistently handles the Java 8’s Optional type. See Section 10.5.1, “Configuring Service Activator”.

The QueueChannel backed Queue type has been changed from BlockingQueue to the more generic Queue. This change allows the use of any external Queue implementation (for example, Reactor’s PersistentQueue). See the section called “QueueChannel Configuration”.

The ChannelInterceptor now supports additional afterSendCompletion() and afterReceiveCompletion() methods. See Section 6.1.3, “Channel Interceptors”.

Since version 4.1.1 there is a change of behavior if you explicitly set the mail.[protocol].peek JavaMail property to false (where [protocol] is imap or imaps). See Important: IMAP PEEK.

The MQTT channel adapters (previously available in the Spring Integration Extensions repository) are now available as part of the normal Spring Integration distribution. See Chapter 26, MQTT Support.

We added the @EnableIntegration annotation to permit declaration of standard Spring Integration beans when using @Configuration classes. See Section E.5, “Annotation Support” for more information.

We added the @IntegrationComponentScan annotation to permit classpath scanning for Spring Integration-specific components. See Section E.5, “Annotation Support” for more information.

You can now enable message history with the @EnableMessageHistory annotation in a @Configuration class. In addition, a JMX MBean can modify the message history settings. Also, MessageHistory can track auto-created MessageHandler instances for annotated endpoints (such as @ServiceActivator, @Splitter, and others). For more information, see Section 12.3, “Message History”.

You can now configure messaging gateway interfaces with the @MessagingGateway annotation. It is an analogue of the <int:gateway/> XML element. For more information, see Section 10.4.6, “@MessagingGateway Annotation”.

As well as the @EnableIntegration annotation mentioned earlier, we introduced a hook to allow the Spring Integration infrastructure beans to be configured with Spring Boot’s @EnableAutoConfiguration annotation. For more information, see "Auto-configuration" in the Spring Boot Reference Guide.

As well as the @EnableIntegration annotation mentioned above, we introduced the @GlobalChannelInterceptor annotation. For more information, see Section E.5, “Annotation Support”.

We introduced the @IntegrationConverter annotation as an analogue of the <int:converter/> component. For more information, see Section E.5, “Annotation Support”.

We added the @EnablePublisher annotation to allow the specification of a default-publisher-channel for @Publisher annotations. See Section E.5, “Annotation Support” for more information.

We added a Redis MessageGroupStore that is optimized for use when backing a QueueChannel for persistence. For more information, see Section 27.3.1, “Redis Channel Message Stores”.

We added a Redis ChannelPriorityMessageStore. You can use it to retrieve messages by priority. For more information, see Section 27.3.1, “Redis Channel Message Stores”.

The MongoDB support now provides the MongoDbChannelMessageStore, which is a channel-specific MessageStore implementation. With priorityEnabled = true, you can use it in <int:priority-queue> elements to achieve priority order polling of persisted messages. For more information see Section 25.2.1, “MongoDB Channel Message Store”.

You can now enable the IntegrationMBeanExporter with the @EnableIntegrationMBeanExport annotation in a @Configuration class. For more information, see Section 12.2.7, “MBean Exporter”.

ChannelSecurityInterceptorFactoryBean now supports configuration of Spring Security for message channels that use @Configuration classes. For more information, see Appendix D, Security in Spring Integration.

The Redis support now provides the <outbound-gateway> component to perform generic Redis commands by using the RedisConnection#execute method. For more information, see Section 27.7, “Redis Outbound Command Gateway”.

The RedisLockRegistry and GemfireLockRegistry are now available to support global locks visible to multiple application instances and servers. These can be used with aggregating message handlers across multiple application instances such that group release occurs on only one instance. For more information, see Section 27.10, “Redis Lock Registry”, Section 19.5, “Gemfire Lock Registry”, and Section 8.4, “Aggregator”.

Annotation-based messaging configuration can now have a poller attribute. This means that methods annotated with @ServiceActivator, @Aggregator, and similar annotations can now use an inputChannel that is a reference to a PollableChannel. For more information, see Section E.5, “Annotation Support”.

We added the @InboundChannelAdapter method annotation. It is an analogue of the <int:inbound-channel-adapter> XML component. In addition, all messaging annotations now provide SmartLifecycle options. For more information, see Section E.5, “Annotation Support”.

We added a new twitter endpoint: <int-twitter-search-outbound-gateway/>. Unlike the search inbound adapter, which polls by using the same search query each time, the outbound gateway allows on-demand customized queries. For more information, see Spring Integration Social Twitter.

We added the GemfireMetadataStore, letting it be used, for example, in an AbstractPersistentAcceptOnceFileListFilter implementation in a multiple application instance or server environment. For more information, see Section 12.5, “Metadata Store”, Section 17.1, “Reading Files”, Section 18.4, “FTP Inbound Channel Adapter”, and Section 30.6, “SFTP Inbound Channel Adapter”.

We introduced @BridgeFrom and @BridgeTo @Bean method annotations to mark MessageChannel beans in @Configuration classes. For more information, see Section E.5, “Annotation Support”.

Messaging annotations (@ServiceActivator, @Router, @MessagingGateway, and others) can now be configured as meta-annotations for user-defined messaging annotations. In addition, the user-defined annotations can have the same attributes (inputChannel, @Poller, autoStartup, and others). For more information, see Section E.5, “Annotation Support”.

We moved the core messaging abstractions (Message, MessageChannel, and others) to the Spring Framework spring-messaging module. Developers who reference these classes directly in their code need to make changes, as described in the first section of the 3.0 to 4.0 Migration Guide.

We introduced the header-type attribute for the header child element of the <int-xml:xpath-header-enricher>. This attribute provides the target type for the header value (to which the result of the XPath expression evaluation is converted). For more information see Section 38.6, “XPath Header Enricher”.

We introduced the result-type attribute for the <int:object-to-json-transformer>. This attribute provides the target type for the result of mapping an object to JSON. It supports STRING (the default) and NODE. For more information see the section called “JSON Transformers”.

The DefaultJmsHeaderMapper now maps an incoming JMSPriority header to the Spring Integration priority header. Previously, priority was only considered for outbound messages. For more information, see Section 23.6, “Mapping Message Headers to and from JMS Message”.

The JMS outbound channel adapter now supports the session-transacted attribute (default: false). Previously, you had to inject a customized JmsTemplate to use transactions. See Section 23.3, “Outbound Channel Adapter”.

The JMS inbound channel adapter now supports the session-transacted attribute (default: false). Previously, you had to inject a customized JmsTemplate to use transactions. The adapter allowed transacted in the acknowledgeMode, which was incorrect and didn’t work. This value is no longer allowed. See Section 23.1, “Inbound Channel Adapter”.

You can now specify a MessageConverter to be used when converting (if necessary) payloads to one of the accepted datatype instances in a Datatype channel. For more information, see the section called “Datatype Channel Configuration”.

We added simplified namespace support to configure a RequestHandlerRetryAdvice. For more information, see the section called “Configuring the Retry Advice”.

We added the mutually exclusive group-timeout and group-timeout-expression attributes to <int:aggregator> and <int:resequencer>. These attributes allow forced completion of a partial MessageGroup, provided the ReleaseStrategy does not release a group and no further messages arrive within the time specified. For more information, see ???.

The RedisMetadataStore now implements ConcurrentMetadataStore, letting it be used, for example, in an AbstractPersistentAcceptOnceFileListFilter implementation in a multiple application instance or server environment. For more information, see Section 27.4, “Redis Metadata Store”, Section 17.1, “Reading Files”, Section 18.4, “FTP Inbound Channel Adapter”, and Section 30.6, “SFTP Inbound Channel Adapter”.

T`JdbcChannelMessageStore` now implements PriorityCapableChannelMessageStore, letting it be used as a message-store reference for priority-queue instances. For more information, see Section 21.4.3, “Backing Message Channels”.

Spring AMQP, by default, creates persistent messages on the broker. You can override this behavior by setting the amqp_deliveryMode header or customizing the mappers. We added a convenient default-delivery-mode attribute to the adapters to provide easier configuration of this important setting. For more information, see Section 14.5, “Outbound Channel Adapter” and Section 14.6, “Outbound Gateway”.

The DefaultFtpSessionFactory now exposes the connectTimeout, defaultTimeout, and dataTimeout properties, avoiding the need to subclass the factory to set these common properties. The postProcess* methods are still available for more advanced configuration. See Section 18.1, “FTP Session Factory” for more information.

The StatusUpdatingMessageHandler (<int-twitter:outbound-channel-adapter>) now supports the tweet-data-expression attribute to build a org.springframework.social.twitter.api.TweetData object for updating the timeline status. This feature allows, for example, attaching an image. See Spring Integration Social Twitter for more information.

We introduced the id-expression attribute for <int-jpa:retrieving-outbound-gateway> to perform EntityManager.find(Class entityClass, Object primaryKey). See Section 22.7.5, “Retrieving Outbound Gateway” for more information.

When one of the standard deserializers encounters a problem decoding the input stream to a message, it now emits a TcpDeserializationExceptionEvent, letting applications examine the data at the point at which the exception occurred. See Section 34.5, “TCP Connection Events” for more information.

You can now configure messaging annotations (@ServiceActivator, @Router, @InboundChannelAdapter, and others) on @Bean definitions in @Configuration classes. For more information, see Section E.5, “Annotation Support”.

The HTTP module now provides powerful request mapping support for inbound endpoints. We replaced the UriPathHandlerMapping class with IntegrationRequestMappingHandlerMapping, which is registered under the bean name of integrationRequestMappingHandlerMapping in the application context. Upon parsing of the HTTP inbound endpoint, either a new IntegrationRequestMappingHandlerMapping bean is registered or an existing bean is reused. To achieve flexible request mapping configuration, Spring Integration provides the <request-mapping/> child element for <http:inbound-channel-adapter/> and the <http:inbound-gateway/>. Both HTTP inbound endpoints are now fully based on the request mapping infrastructure that was introduced with Spring MVC 3.1. For example, multiple paths are supported on a single inbound endpoint. For more information see Section 20.3, “HTTP Namespace Support”.

We added a new IntegrationEvaluationContextFactoryBean to allow configuration of custom PropertyAccessor implementations and functions for use in SpEL expressions throughout the framework. For more information, see Appendix A, Spring Expression Language (SpEL).

To customize the SpEL EvaluationContext with static Method functions, we introduced the <spel-function/> component. We also added two built-in functions: #jsonPath and #xpath. For more information, see Section A.2, “SpEL Functions”.

To customize the SpEL EvaluationContext with PropertyAccessor implementations, we added the <spel-property-accessors/> component. For more information, see Section A.3, “Property Accessors”.

We added a new Redis-based MetadataStore implementation. You can use the RedisMetadataStore to maintain the state of a MetadataStore across application restarts. This new MetadataStore implementation can be used with adapters, such as:

We added new queue-based components. We added the <int-redis:queue-inbound-channel-adapter/> and <int-redis:queue-outbound-channel-adapter/> components to perform right pop and left push operations, respectively, on a Redis List.

For more information, "see <<redis>>".

You can now instruct the framework to store reply channels and error channels in a registry for later resolution. This is useful for cases where the replyChannel or errorChannel might be lost (for example, when serializing a message). See Section 9.2.1, “Header Enricher” for more information.

In addition to the existing eMongoDbMessageStore, we introduced a new ConfigurableMongoDbMessageStore. This provides a more robust and flexible implementation of MessageStore for MongoDB. It does not have backward compatibility with the existing store, but we recommend using it for new applications. Existing applications can use it, but messages in the old store are not available. See Chapter 25, MongoDb Support for more information.

Building on the 2.2 SyslogToMapTransformer, Spring Integration 3.0 introduces UDP and TCP inbound channel adapters especially tailored for receiving SYSLOG messages. For more information, see Chapter 33, Syslog Support.

We added file inbound channel adapters that use the tail command to generate messages when lines are added to the end of text files. See Section 17.1.8, “'tail’ing Files”.

We added <int-jmx:tree-polling-channel-adapter/>. This adapter queries the JMX MBean tree and sends a message with a payload that is the graph of objects that match the query. By default, the MBeans are mapped to primitives and simple Objects (such as Map, List, and arrays). It permits simple transformation to, for example, JSON.

The IntegrationMBeanExporter now allows the configuration of a custom ObjectNamingStrategy by using the naming-strategy attribute.

For more information, see Section 12.2, “JMX Support”.

TcpConnection instances now emit ApplicationEvent instances (specifically TcpConnectionEvent instances) when connections are opened or closed or when an exception occurs. This change lets applications be informed of changes to TCP connections by using the normal Spring ApplicationListener mechanism.

We renamed AbstractTcpConnection to TcpConnectionSupport. Custom connections that are subclasses of this class can use its methods to publish events. Similarly, we renamed AbstractTcpConnectionInterceptor to TcpConnectionInterceptorSupport.

In addition, we added <int-ip:tcp-connection-event-inbound-channel-adapter/>. By default, this adapter sends all TcpConnectionEvent instances to a Channel.

Further, the TCP connection factories now provide a new method called getOpenConnectionIds(), which returns a list of identifiers for all open connections. It lets applications broadcast to all open connections, among other uses.

Finally, the connection factories also provide a new method called closeConnection(String connectionId), which lets applications explicitly close a connection by using its ID.

For more information see Section 34.5, “TCP Connection Events”.

The <int:inbound-channel-adapter/> now supports using <expression/> and <script/> child elements to create a MessageSource. See Section 6.3.3, “Channel Adapter Expressions and Scripts”.

The content enricher now provides configuration for <header/> child elements, to enrich the outbound message with headers based on the reply message from the underlying message flow. For more information see Section 9.2.2, “Payload Enricher”.

Previously, message IDs were generated by using the JDK UUID.randomUUID() method. With this release, the default mechanism has been changed to use a more efficient and significantly faster algorithm. In addition, we added the ability to change the strategy used to generate message IDs. For more information see Section 7.2.2, “Message ID Generation”.

You can now set common headers across all gateway methods, and we added more options for adding information to the message about which method was invoked.

You can now entirely customize the way that gateway method calls are mapped to messages.

The GatewayMethodMetadata is now a public class. It lets you programmatically configure the GatewayProxyFactoryBean from Java.

For more information, see Section 10.4, “Messaging Gateways”.

For more information, see Chapter 20, HTTP Support.

For more information, see "JSON Transformers" in Section 9.1, “Transformer”.

Previously, the id attribute for elements within a <chain> was ignored and, in some cases, disallowed. Now, the id attribute is allowed for all elements within a <chain>. The bean names of chain elements is a combination of the surrounding chain’s id and the id of the element itself. For example: myChain$child.myTransformer.handler. For more information see, Section 8.6, “Message Handler Chain”.

The AbstractCorrelatingMessageHandler provides a new property called empty-group-min-timeout to allow empty group expiry to run on a longer schedule than expiring partial groups. Empty groups are not removed from the MessageStore until they have not been modified for at least this number of milliseconds. For more information, see ???.

New FileListFilter implementations that use a persistent MetadataStore are now available. You can use these to prevent duplicate files after a system restart. See Section 17.1, “Reading Files”, Section 18.4, “FTP Inbound Channel Adapter”, and Section 30.6, “SFTP Inbound Channel Adapter” for more information.

We introduced a new variables attribute for scripting components. In addition, variable bindings are now allowed for inline scripts. See Section 10.8, “Groovy support” and Section 10.7, “Scripting Support” for more information.

Previously, when configuring LoadBalancingStrategy on the channel’s dispatcher child element, the only available option was to use a pre-defined enumeration of values which did not let developers set a custom implementation of the LoadBalancingStrategy. You can now use load-balancer-ref to provide a reference to a custom implementation of the LoadBalancingStrategy. For more information, see the section called “DirectChannel”.

Previously, sending to a <publish-subscribe-channel/> that had no subscribers would return a false result. If used in conjunction with a MessagingTemplate, this would result in an exception being thrown. Now, the PublishSubscribeChannel has a property called minSubscribers (default: 0). If the message is sent to at least the minimum number of subscribers, the send operation is deemed to be successful (even if the number is zero). If an application expects to get an exception under these conditions, set the minimum subscribers to at least 1.

The FTP, SFTP and FTPS endpoints no longer cache sessions by default.

We removed the deprecated cached-sessions attribute from all endpoints. Previously, the embedded caching mechanism controlled by this attribute’s value did not provide a way to limit the size of the cache, which could grow indefinitely. Release 2.1 introduced CachingConnectionFactory, and it became the preferred (and is now the only) way to cache sessions.

CachingConnectionFactory now provides a new method: resetCache(). This method immediately closes idle sessions and causes in-use sessions to be closed as and when they are returned to the cache.

The DefaultSftpSessionFactory (in conjunction with a CachingSessionFactory) now supports multiplexing channels over a single SSH connection (SFTP Only).

All outbound gateways (such as <jdbc:outbound-gateway/> or <jms:outbound-gateway/>) are designed for request-reply scenarios. A response is expected from the external service and is published to the reply-channel or the replyChannel message header. However, there are some cases where the external system might not always return a result (for example, a <jdbc:outbound-gateway/> when a SELECT ends with an empty ResultSet or perhaps a one-way web service). Consequently, developers needed an option to configure whether or not a reply is required. For this purpose, we introduced the requires-reply attribute for outbound gateway components. In most cases, the default value for requires-reply is true. If there is no result, a ReplyRequiredException is thrown. Changing the value to false means that, if an external service does not return anything, the message flow ends at that point, similar to an outbound channel adapter.

Note

The WebService outbound gateway has an additional attribute called ignore-empty-responses. It is used to treat an empty String response as if no response were received. By default, it is true, but you can set it to false to allow the application to receive an empty String in the reply message payload. When the attribute is true, an empty string is treated as no response for the purposes of the requires-reply attribute. By default, requires-reply is false for the WebService outbound gateway.

Note that the requiresReply property was previously present but set to false in the AbstractReplyProducingMessageHandler, and there was no way to configure it on outbound gateways by using the XML namespace.

	Important
	Previously, a gateway receiving no reply would silently end the flow (with a DEBUG log message). By default, with this change, an exception is now thrown by most gateways. To revert to the previous behavior, set requires-reply to false.

Previously, the <int-amqp:outbound-gateway/> mapped headers before invoking the message converter, and the converter could overwrite headers such as content-type. The outbound adapter maps the headers after the conversion, which means headers like content-type from the outbound Message (if present) are used.

Starting with this release, the gateway now maps the headers after the message conversion, consistent with the adapter. If your application relies on the previous behavior (where the converter’s headers overrode the mapped headers), you either need to filter those headers (before the message reaches the gateway) or set them appropriately. The headers affected by the SimpleMessageConverter are content-type and content-encoding. Custom message converters may set other headers.

For more complex database-specific types not supported by the standard CallableStatement.getObject method, we introduced two new additional attributes to the <sql-parameter-definition/> element with OUT-direction:

The row-mapper attribute of the stored procedure inbound channel adapter <returning-resultset/> child element now supports a reference to a RowMapper bean definition. Previously, it contained only a class name (which is still supported).

For more information, see Section 21.5, “Stored Procedures”.

The web service outbound gateway uri attribute now supports <uri-variable/> substitution for all URI schemes supported by Spring Web Services. For more information, see Section 37.4, “Outbound URI Configuration”.

The Redis inbound channel adapter can now use a null value for the serializer property, with the raw data being the message payload.

The Redis outbound channel adapter now has the topic-expression property to determine the Redis topic for the Message at runtime.

The Redis inbound channel adapter, in addition to the existing topics attribute, now has the topic-patterns attribute.

For more information, see Chapter 27, Redis Support.

Previously, when a <filter/> had a <request-handler-advice-chain/>, the discard action was all performed within the scope of the advice chain (including any downstream flow on the discard-channel). The filter element now has an attribute called discard-within-advice (default: true) to allow the discard action to be performed after the advice chain completes. See Section 10.9.6, “Advising Filters”.

Request handler advice chains can now be configured using annotations. See Section 10.9.7, “Advising Endpoints Using Annotations”.

This transformer now correctly transforms byte[] and char[] payloads to String. For more information, see Section 9.1, “Transformer”.

Payloads to persist or merge can now be of type http://docs.oracle.com/javase/7/docs/api/java/lang/Iterable.html[java.lang.Iterable].

In that case, each object returned by the Iterable is treated as an entity and persisted or merged by using the underlying EntityManager. Null values returned by the iterator are ignored.

The JPA adapters now have additional attributes to optionally flush and clear entities from the associated persistence context after performing persistence operations.

Retrieving gateways had no mechanism to specify the first record to be retrieved, which is a common use case. The retrieving gateways now support specifying this parameter by adding the first-result and first-result-expression attributes to the gateway definition. For more information, see Section 22.7.5, “Retrieving Outbound Gateway”.

The JPA retrieving gateway and inbound adapter now have an attribute to specify the maximum number of results in a result set as an expression. In addition, we introduced the max-results attribute to replace max-number-of-results, which has been deprecated. max-results and max-results-expression are used to provide the maximum number of results or an expression to compute the maximum number of results, respectively, in the result set.

For more information, see Chapter 22, JPA Support.

Previously, the <delayer> provided a delay-header-name attribute to determine the delay value at runtime. In complex cases, the <delayer> had to be preceded with a <header-enricher>. Spring Integration 3.0 introduced the expression attribute and expression child element for dynamic delay determination. The delay-header-name attribute is now deprecated, because you can specify the header evaluation in the expression. In addition, we introduced the ignore-expression-failures to control the behavior when an expression evaluation fails. For more information, see Section 10.6, “Delayer”.

Spring Integration 3.0 adds a new set of DDL scripts for MySQL version 5.6.4 and higher. Now MySQL supports fractional seconds and is thus improving the FIFO ordering when polling from a MySQL-based message store. For more information, see Section 21.4.2, “The Generic JDBC Message Store”.

Previously, if an IMAP idle connection failed, it was logged, but there was no mechanism to inform an application. Such exceptions now generate ApplicationEvent instances. Applications can obtain these events by using an <int-event:inbound-channel-adapter> or any ApplicationListener configured to receive an ImapIdleExceptionEvent (or one of its super classes).

The TCP connection factories now enable the configuration of a flexible mechanism to transfer selected headers (as well as the payload) over TCP. A new TcpMessageMapper enables the selection of the headers, and you need to configure an appropriate serializer or deserializer to write the resulting Map to the TCP stream. We added a MapJsonSerializer as a convenient mechanism to transfer headers and payload over TCP. For more information, see Section 34.8.3, “Transferring Headers”.

Previously, when configuring a <message-driven-channel-adapter/>, if you wished to use a specific TaskExecutor, you had to declare a container bean and provide it to the adapter by setting the container attribute. We added the task-executor, letting it be set directly on the adapter. This is in addition to several other container attributes that were already available.

The RMI Inbound Gateway now supports an error-channel attribute. See Section 29.2, “Inbound RMI”.

You can now specify the transformer factory class name by setting the transformer-factory-class attribute. See <<xml-xslt-payload-transformers>>.

Spring Integration now has RedisStore Inbound and Outbound Channel Adapters, letting you write and read Message payloads to and from Redis collections. For more information, see Section 27.6, “RedisStore Outbound Channel Adapter” and Section 27.5, “Redis Store Inbound Channel Adapter”.

Spring Integration now has MongoDB inbound and outbound channel adapters, letting you write and read Message payloads to and from a MongoDB document store. For more information, see Section 25.4, “MongoDB Outbound Channel Adapter” and Section 25.3, “MongoDB Inbound Channel Adapter”.

Spring Integration now includes components for the Java Persistence API (JPA) for retrieving and persisting JPA entity objects. The JPA Adapter includes the following components:

For more information, see Chapter 22, JPA Support.

Spring Integration now uses Spring 3.1.

The ability to add an <advice-chain/> to a poller has been available for some time. However, the behavior added by this affects the entire integration flow. It did not address the ability to add (for example) retry to an individual endpoint. The 2.2. release introduced the <request-handler-advice-chain/> to many endpoints.

In addition, we added three standard advice classes for this purpose:

For more information, see Section 10.9, “Adding Behavior to Endpoints”.

Pollers can now participate in Spring’s Transaction Synchronization feature. This allows for synchronizing such operations as renaming files by an inbound channel adapter, depending on whether the transaction commits or rolls back.

In addition, you can enable these features when no "real" transaction is present, by means of a PseudoTransactionManager.

For more information, see Section C.3, “Transaction Synchronization”.

When using the file outbound channel adapter or the file outbound gateway, you can use a new mode property. Prior to Spring Integration 2.2, target files were replaced when they existed. Now you can specify the following options:

For more information, see Section 17.2.3, “Dealing with Existing Destination Files”.

The XML Namespace support adds the reply-timeout attribute to the following outbound gateways:

Spring Integration now uses Spring AMQP 1.1. This enables several features to be used within a Spring Integration application, including the following:

When you use the JDBC outbound gateway, the update query is no longer mandatory. You can now provide only a select query by using the request message as a source of parameters.

We added a new message channel-specific message store implementation, providing a more scalable solution using database-specific SQL queries. For more information, see Section 21.4.3, “Backing Message Channels”.

We added a method called stopActiveComponents() to the IntegrationMBeanExporter. It allows a Spring Integration application to be shut down in an orderly manner, disallowing new inbound messages to certain adapters and waiting for some time to allow in-flight messages to complete.

You can now configure the JMS outbound gateway to use a MessageListener container to receive replies. Doing so can improve performance of the gateway.

By default, the ObjectToJsonTransformer now sets the content-type header to application/json. For more information, see Section 9.1, “Transformer”.

Java serialization over HTTP is no longer enabled by default. Previously, when setting an expected-response-type on a Serializable object, the Accept header was not properly set up. We updated the SerializingHttpMessageConverter to set the Accept header to application/x-java-serialized-object. However, because this could cause incompatibility with existing applications, we decided to no longer automatically add this converter to the HTTP endpoints.

If you wish to use Java serialization, you need to add the SerializingHttpMessageConverter to the appropriate endpoints by using the message-converters attribute (when you use XML configuration) or by using the setMessageConverters() method (in Java).

Alternatively, you may wish to consider using JSON instead. It is enabled by having Jackson on the classpath.

In Spring Integration 2.0, we added support for Groovy. With Spring Integration 2.1, we expanded support for additional languages substantially by implementing support for JSR-223 ("Scripting for the Java™ Platform"). Now you have the ability to use any scripting language that supports JSR-223 including:

For further details, see Section 10.7, “Scripting Support”.

Spring Integration provides support for GemFire by providing inbound adapters for entry and continuous query events, an outbound adapter to write entries to the cache, and MessageStore and MessageGroupStore implementations. Spring integration leverages the Spring Gemfire project, providing a thin wrapper over its components.

For further details, see Chapter 19, Pivotal GemFire and Apache Geode Support.

Spring Integration 2.1 added several channel adapters for receiving and sending messages by using the Advanced Message Queuing Protocol (AMQP). Furthermore, Spring Integration also provides a point-to-point message channel and a publish-subscribe message channel, both of which are backed by AMQP Exchanges and Queues.

For further details, see Chapter 14, AMQP Support.

As of version 2.1, Spring Integration provides support for MongoDB by providing a MongoDB-based MessageStore.

For further details, see Chapter 25, MongoDb Support.

As of version 2.1, Spring Integration supports Redis, an advanced key-value store, by providing a Redis-based MessageStore as well as publish-subscribe messaging adapters.

For further details, see Chapter 27, Redis Support.

In version 2.1, we introduced a new resource inbound channel adapter that builds upon Spring’s resource abstraction to support greater flexibility across a variety of actual types of underlying resources, such as a file, a URL, or a classpath resource. Therefore, it is similar to but more generic than the file inbound channel adapter.

For further details, see Section 28.1, “Resource Inbound Channel Adapter”.

With Spring Integration 2.1, the JDBC Module also provides stored procedure support by adding several new components, including inbound and outbound channel adapters and an outbound gateway. The stored procedure support leverages Spring’s SimpleJdbcCall class and consequently supports stored procedures for:

The stored procedure components also support SQL functions for the following databases:

For further details, see Section 21.5, “Stored Procedures”.

Spring Integration 2.1 provides a new XPath-based message filter. It is part of the XML module. The XPath filter lets you filter messages by using XPath Expressions. We also added documentation for the XML validating filter.

For more details, see Section 38.7, “Using the XPath Filter” and Section 38.9, “XML Validating Filter”.

Since Spring Integration 2.1, we added the payload enricher. A payload enricher defines an endpoint that typically passes a Message to the exposed request channel and then expects a reply message. The reply message then becomes the root object for evaluation of expressions to enrich the target payload.

For further details, see Section 9.2.2, “Payload Enricher”.

Spring Integration 2.1 provides two new outbound gateways to interact with remote File Transfer Protocol (FTP) or Secure File Transfer Protocol (SFT) servers. These two gateways let you directly execute a limited set of remote commands.

For instance, you can use these outbound gateways to list, retrieve, and delete remote files and have the Spring Integration message flow continue with the remote server’s response.

For further details, see Section 18.9, “FTP Outbound Gateway” and Section 30.11, “SFTP Outbound Gateway”.

As of version 2.1, we have exposed more flexibility with regards to session management for remote file adapters (for example, FTP, SFTP, and others).

Specifically, we deprecated the cache-sessions attribute (which is available via the XML namespace support). As an alternative, we added the sessionCacheSize and sessionWaitTimeout attributes on the CachingSessionFactory.

For further details, see Section 18.10, “FTP Session Caching” and Section 30.4, “SFTP Session Caching”.

We standardized router parameters across all router implementations with Spring Integration 2.1 to provide a more consistent user experience.

In Spring Integration 2.1, we removed the ignore-channel-name-resolution-failures attribute in favor of consolidating its behavior with the resolution-required attribute. Also, the resolution-required attribute now defaults to true.

Starting with Spring Integration 2.1, routers no longer silently drop any messages if no default output channel was defined. This means that, by default, routers now require at least one resolved channel (if no default-output-channel was set) and, by default, throw a MessageDeliveryException if no channel was determined (or an attempt to send was not successful).

If, however, you do want to drop messages silently, you can set default-output-channel="nullChannel".

	Important
	With the standardization of router parameters and the consolidation of the parameters described earlier, older Spring Integration based applications may break.

For further details, see <<router>>.

Spring Integration 2.1 ships with an updated XML Schema (version 2.1). It provides many improvements, such as the Router standardizations discussed earlier.

From now on, developers must always declare the latest XML schema (currently version 2.1). Alternatively, they can use the version-less schema. Generally, the best option is to use version-less namespaces, as these automatically use the latest available version of Spring Integration.

The following example declares a version-less Spring Integration namespace:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:int="http://www.springframework.org/schema/integration"
   xsi:schemaLocation="http://www.springframework.org/schema/integration
           http://www.springframework.org/schema/integration/spring-integration.xsd
           http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans.xsd">
...
</beans>

The following example declares a Spring Integration namespace with an explicit version:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:int="http://www.springframework.org/schema/integration"
   xsi:schemaLocation="http://www.springframework.org/schema/integration
           http://www.springframework.org/schema/integration/spring-integration-2.2.xsd
           http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans.xsd">
...
</beans>

The old 1.0 and 2.0 schemas are still there. However, if an application context still references one of those deprecated schemas, the validator fails on initialization.

Since version 2.0, the Spring Integration project uses Git for version control. To increase community visibility even further, the project was moved from SpringSource hosted Git repositories to Github. The Spring Integration Git repository is located at: spring-integration.

For the project, we also improved the process of providing code contributions. Further, we ensure that every commit is peer-reviewed. In fact, core committers now follow the same process as contributors. For more details, see Contributing.

In an effort to provide better source code visibility and consequently to monitor the quality of Spring Integration’s source code, we set up an instance of Sonar. We gather metrics nightly and make them available at sonar.spring.io.

You can now use SpEL expressions within the transformer, router, filter, splitter, aggregator, service-activator, header-enricher, and many more elements of the Spring Integration core namespace as well as within various adapters. This guide includes many samples.

You can now benefit from the conversion service support provided with Spring while configuring many Spring Integration components, such as a Datatype channel. See Section 6.1.2, “Message Channel Implementations” and ???. Also, the SpEL support mentioned in the previous point also relies upon the conversion service. Therefore, you can register converters once and take advantage of them anywhere you use SpEL expressions.

Spring 3.0 defines two new strategies related to scheduling: TaskScheduler and Trigger. Spring Integration (which uses a lot of scheduling) now builds upon these. In fact, Spring Integration 1.0 had originally defined some of the components (such as CronTrigger) that have now been migrated into Spring 3.0’s core API. Now you can benefit from reusing the same components within the entire application context (not just Spring Integration configuration). We also greatly simplified configuration of Spring Integration pollers by providing attributes for directly configuring rates, delays, cron expressions, and trigger references. See Section 6.3, “Channel Adapter” for sample configurations.

Our outbound HTTP adapters now delegate to Spring’s RestTemplate for executing the HTTP request and handling its response. This also means that you can reuse any custom HttpMessageConverter implementations. See Section 20.2, “HTTP Outbound Components” for more details.

We now provide support for the message history pattern, letting you keep track of all traversed components, including the name of each channel and endpoint as well as the timestamp of that traversal. See Section 12.3, “Message History” for more details.

We now provide support for the message store pattern. The message store provides a strategy for persisting messages on behalf of any process whose scope extends beyond a single transaction, such as the aggregator and the resequencer. Many sections of this guide include samples of how to use a message store, as it affects several areas of Spring Integration. See Section 12.4, “Message Store”, Section 9.3, “Claim Check”, Section 6.1, “Message Channels”, Section 8.4, “Aggregator”, Chapter 21, JDBC Support`", and Section 8.5, “Resequencer” for more details.

We have added an implementation of the claim check pattern. The idea behind the claim check pattern is that you can exchange a message payload for a "claim ticket". This lets you reduce bandwidth and avoid potential security issues when sending messages across channels. See Section 9.3, “Claim Check” for more details.

We have provided implementations of the control bus pattern, which lets you use messaging to manage and monitor endpoints and channels. The implementations include both a SpEL-based approach and one that runs Groovy scripts. See Section 12.6, “Control Bus” and Section 10.8.4, “Control Bus” for more details.

We have added channel adapters for receiving and sending messages over the TCP and UDP internet protocols. See Chapter 34, TCP and UDP Support for more details. See also the following blog: "Using UDP and TCP Adapters in Spring Integration 2.0 M3".

Twitter adapters provides support for sending and receiving Twitter status updates as well as direct messages. You can also perform Twitter Searches with an inbound channel adapter. See Spring Integration Social Twitter for more details.

The new XMPP adapters support both chat messages and presence events. See Chapter 39, XMPP Support for more details.

Inbound and outbound file transfer support over FTP and FTPS is now available. See Chapter 18, FTP/FTPS Adapters for more details.

Inbound and outbound file transfer support over SFTP is now available. See Chapter 30, SFTP Adapters for more details.

We have also added channel adapters for receiving news feeds (ATOM and RSS). See Chapter 16, Feed Adapter for more details.

Spring Integration 2.0 added Groovy support, letting you use the Groovy scripting language to provide integration and business logic. See Section 10.8, “Groovy support” for more details.

These symmetrical transformers convert payload objects to and from Map objects. See Section 9.1, “Transformer” for more details.

These symmetrical transformers convert payload objects to and from JSON. See Section 9.1, “Transformer” for more details.

These symmetrical transformers convert payload objects to and from byte arrays. They also support the serializer and deserializer strategy interfaces that Spring 3.0.5 added. See Section 9.1, “Transformer” for more details.