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 .

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 .

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 .

As of version 2.1 Spring Integration provides support for MongoDB by providing a MongoDB-based MessageStore. For further details please see .

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 .

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 .

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 .

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 and .

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 .

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 and .

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 and .

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

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: ... ]]> Declaring a Spring Integration namespace using an explicit version: ... ]]> 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.

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:

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:

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: