Appendix D. Change History

D.1 Changes between 1.0 and 2.0

For a detailed migration guide in regards to upgrading an existing application that uses Spring Integration older than version 2.0, please see:

D.1.1 Spring 3 support

Spring Integration 2.0 is built on top of Spring 3.0.5 and makes many of its features available to our users.

Support for the Spring Expression Language (SpEL)

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 various adapters. There are many samples provided throughout this manual.

ConversionService and Converter

You can now benefit from Conversion Service support provided with Spring while configuring many Spring Integration components such as Datatype Channel. See Section 3.1.2, “Message Channel Implementations” as well Section 7.3.1, “Introduction”. Also, the SpEL support mentioned in the previous point also relies upon the ConversionService. Therefore, you can register Converters once, and take advantage of them anywhere you are using SpEL expressions.

TaskScheduler and Trigger

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 (e.g. 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). Configuration of Spring Integration Pollers has been greatly simplified as well by providing attributes for directly configuring rates, delays, cron expressions, and trigger references. See Section 3.3, “Channel Adapter” for sample configurations.

RestTemplate and HttpMessageConverter

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 15.3, “Http Outbound Gateway” for more details.

D.1.2 Enterprise Integration Pattern Additions

Also in 2.0 we have added support for even more of the patterns described in Hohpe and Woolf's Enterprise Integration Patterns book.

Message History

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

Message Store

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 Resequencer. Many sections of this document provide samples on how to use a Message Store as it affects several areas of Spring Integration. See Section 8.3, “Message Store”, Section 6.3, “Claim Check”, Section 3.1, “Message Channels”, Section 5.4, “Aggregator”, Chapter 17, JDBC Support, and Section 5.5, “Resequencer” for more details

Claim Check

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" and vice-versa. This allows you to reduce bandwidth and/or avoid potential security issues when sending Messages across channels. See Section 6.3, “Claim Check” for more details.

Control Bus

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

D.1.3 New Channel Adapters and Gateways

We have added several new Channel Adapters and Messaging Gateways in Spring Integration 2.0.

TCP/UDP Adapters

We have added Channel Adapters for receiving and sending messages over the TCP and UDP internet protocols. See Chapter 16, TCP and UDP Support for more details. Also, you can checkout the following blog: TCP/UDP support

Twitter Adapters

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 Chapter 27, Twitter Adapter for more details.

XMPP Adapters

The new XMPP adapters support both Chat Messages and Presence events. See Chapter 30, XMPP Support for more details.

FTP/FTPS Adapters

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

SFTP Adapters

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

Feed Adapters

We have also added Channel Adapters for receiving news feeds (ATOM/RSS). See Chapter 11, Feed Adapter for more details.

D.1.4 Other Additions

Groovy Support

With Spring Integration 2.0 we've added Groovy support allowing you to use Groovy scripting language to provide integration and/or business logic. See Section 7.6, “Groovy support” for more details.

Map Transformers

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

JSON Transformers

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

Serialization Transformers

These symmetrical transformers convert payload objects to and from byte arrays. They also support the Serializer and Deserializer strategy interfaces that have been added as of Spring 3.0.5. See Section 6.1, “Transformer” for more details.

D.1.5 Framework Refactoring

The core API went through some significant refactoring to make it simpler and more usable. Although we anticipate that the impact to the end user should be minimal, please read through this document to find what was changed. Especially, visit Section 5.1.5, “Dynamic Routers” , Section 7.2, “Messaging Gateways”, Section 15.3, “Http Outbound Gateway”, Section 4.1, “Message”, and Section 5.4, “Aggregator” for more details. If you are depending directly on some of the core components (Message, MessageHeaders, MessageChannel, MessageBuilder, etc.), you will notice that you need to update any import statements. We restructured some packaging to provide the flexibility we needed for extending the domain model while avoiding any cyclical dependencies (it is a policy of the framework to avoid such "tangles").

D.1.6 New Source Control Management and Build Infrastructure

With Spring Integration 2.0 we have switched our build environment to use Git for source control. To access our repository simply follow this URL: We have also switched our build system to Gradle.

D.1.7 New Spring Integration Samples

With Spring Integration 2.0 we have decoupled the samples from our main release distribution. Please read this blog to get more info New Spring Integration Samples We have also created many new samples, including samples for every new Adapter.

D.1.8 SpringSource Tool Suite Visual Editor for Spring Integration

There is an amazing new visual editor for Spring Integration included within the latest version of SpringSource Tool Suite. If you are not already using STS, please download it here:

D.2 Changes between 2.0 and 2.1

D.2.1 New Components

JSR-223 Scripting Support

In Spring Integration 2.0, support for Groovy was added. 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:

  • Javascript
  • Ruby/JRuby
  • Python/Jython
  • Groovy

For further details please see Section 7.5, “Scripting support”.

GemFire 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 please see Chapter 14, GemFire Support.

AMQP Support

Spring Integration 2.1 adds several Channel Adapters for receiving and sending messages using the Advanced Message Queuing Protocol (AMQP). Furthermore, Spring Integration also provides a point-to-point Message Channel, as well as a publish/subscribe Message Channel that are backed by AMQP Exchanges and Queues.

For further details please see Chapter 9, AMQP Support.

MongoDB Support

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

For further details please see Chapter 21, MongoDb Support.

Redis 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 please see Chapter 22, Redis Support.

Support for Spring's Resource abstraction

As of version 2.1, we've 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 class path resource. Therefore, it's similar to but more generic than the File Inbound Channel Adapter.

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

Stored Procedure Components

With Spring Integration 2.1, the JDBC Module also provides Stored Procedure support by adding several new components, including inbound/outbound channel adapters and an Outbound Gateway. The Stored Procedure support leverages Spring's SimpleJdbcCall class and consequently supports stored procedures for:

  • Apache Derby
  • DB2
  • MySQL
  • Microsoft SQL Server
  • Oracle
  • PostgreSQL
  • Sybase

The Stored Procedure components also support Sql Functions for the following databases:

  • MySQL
  • Microsoft SQL Server
  • Oracle
  • PostgreSQL

For further details please see Section 17.5, “Stored Procedures”.

XPath and XML Validating Filter

Spring Integration 2.1 provides a new XPath-based Message Filter, that is part of the XML module. The XPath Filter allows you to filter messages using provided XPath Expressions. Furthermore, documentation was added for the XML Validating Filter.

For more details please see Section 29.8, “Using the XPath Filter” and Section 29.9, “XML Validating Filter”.

Payload Enricher

Since Spring Integration 2.1, the Payload Enricher is provided. 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 please see Section 6.2.3, “Payload Enricher”.

FTP and SFTP Outbound Gateways

Spring Integration 2.1 provides two new Outbound Gateways in order to interact with remote File Transfer Protocol (FTP) or Secure File Transfer Protocol (SFT) servers. These two gateways allow you to 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 please see Section 13.5, “FTP Outbound Gateway” and Section 25.6, “SFTP Outbound Gateway”.

FTP Session Caching

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

Specifically, the cache-sessions attribute, which is available via the XML namespace support, is now deprecated. Alternatively, we added the sessionCacheSize and sessionWaitTimeout attributes on the CachingSessionFactory.

For further details please see Section 13.6, “FTP Session Caching” and Section 25.3, “SFTP Session Caching”.

D.2.2 Framework Refactoring

Standardizing Router Configuration

Router parameters have been standardized across all router implementations with Spring Integration 2.1 providing a more consistent user experience.

With Spring Integration 2.1 the ignore-channel-name-resolution-failures attribute has been removed 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 will 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 will throw a MessageDeliveryException if no channel was determined (or an attempt to send was not successful).

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

With the standardization of Router parameters and the consolidation of the parameters described above, there is the possibility of breaking older Spring Integration based applications.

For further details please see Section 5.1, “Routers”

XML Schemas updated to 2.1

Spring Integration 2.1 ships with an updated XML Schema (version 2.1), providing many improvements, e.g. the Router standardizations discussed above.

From now on, users 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 will automatically use the latest available version of Spring Integration.

Declaring a version-less Spring Integration namespace:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""

Declaring a Spring Integration namespace using an explicit version:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""

The old 1.0 and 2.0 schemas are still there, but if an Application Context still references one of those deprecated schemas, the validator will fail on initialization.

D.2.3 Source Control Management and Build Infrastructure

Source Code now hosted on Github

Since version 2.0, the Spring Integration project uses Git for version control. In order 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:

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

Improved Source Code Visibility with Sonar

In an effort to provide better source code visibility and consequently to monitor the quality of Spring Integration's source code, an instance of Sonar was setup and metrics are gathered nightly and made avaiblable at:

D.2.4 New Samples

For the 2.1 release of Spring Integration we also expanded the Spring Integration Samples project and added many new samples, e.g. samples covering AMQP support, the new payload enricher, a sample illustrating techniques for testing Spring Integration flow fragments, as well as an example for executing Stored Procedures against Oracle. For details please visit:

D.3 Changes between 2.1 and 2.2

For an overview of the changes in Spring Integration 2.2 since version 2.1, please see Chapter 1, What's new in Spring Integration 2.2?.