For an overview of the changes in Spring Integration 4.0 since version 3.0, please see Chapter 1, What's new in Spring Integration 4.0?.
The HTTP module now provides powerful Request Mapping support for Inbound Endpoints. Class
was replaced by
IntegrationRequestMappingHandlerMapping, which is registered under the bean name
integrationRequestMappingHandlerMapping in the application context. Upon parsing of the HTTP Inbound Endpoint,
IntegrationRequestMappingHandlerMapping bean is either registered or an existing bean is being reused.
To achieve flexible Request Mapping configuration, Spring Integration provides the
sub-element for the
<http:inbound-channel-adapter/> and the
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 16.4, “HTTP Namespace Support”.
IntegrationEvaluationContextFactoryBean is provided to allow
configuration of custom
PropertyAccessors 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, the new
component is introduced. Two built-in functions are also provided (
#xpath). For more information see Section A.3, “SpEL Functions”.
To customize the SpEL
<spel-property-accessors/> component is introduced.
For more information see Section A.4, “PropertyAccessors”.
A new Redis-based
implementation has been added. The
be used to maintain state of a
across application restarts. This new
implementation can be used with adapters such as:
New queue-based components have been added. The
<int-redis:queue-outbound-channel-adapter/> components are provided
to perform 'right pop' and 'left push' operations on a Redis List, respectively.
For more information see Chapter 23, Redis Support.
It is now possible to instruct the framework to store reply and error channels
in a registry for later resolution. This is useful for cases where
errorChannel might be lost; for example
a message. See Section 6.2.2, “Header Enricher” for more information.
In addition to the existing
eMongoDbMessageStore, a new
ConfigurableMongoDbMessageStore has been introduced.
This provides a more robust and flexible implementation of
It does not have backward compatibility, with the existing store,
but it is recommended to use it for new applications. Existing applications can use it, but messages
in the old store will not be available.
See Chapter 21, MongoDb Support for more information.
Building on the 2.2
Integration 3.0 now introduces
TCP inbound channel adapters especially tailored
for receiving SYSLOG messages. For more information, see
Chapter 28, Syslog Support.
File 'tail'ing inbound channel adapters are now provided to generate messages when lines are added to the end of text files; see Section 13.2.1, “'Tail'ing Files”.
<int-jmx:tree-polling-channel-adapter/>is provided; this adapter queries the JMX MBean tree and sends a message with a payload that is the graph of objects that matches the query. By default the MBeans are mapped to primitives and simple Objects like Map, List and arrays - permitting simple transformation, for example, to JSON.
IntegrationMBeanExporternow allows the configuration of a custom
For more information, see Section 8.1, “JMX Support”.
TcpConnections now emit
TcpConnectionEvents) when connections are
opened, closed, or an exception occurs. This allows applications
to be informed of changes to TCP connections using the normal
AbstractTcpConnection has been renamed
TcpConnectionSupport; custom connections that
are subclasses of this class, can use its methods to publish events.
been renamed to
In addition, a new
is provided; by default, this adapter sends all
Further, the TCP Connection Factories, now provide a new method
getOpenConnectionIds(), which returns a list of identifiers for all
open connections; this allows applications, for example, to broadcast to all
Finally, the connection factories also provide a new method
closeConnection(String connectionId) which allows applications
to explicitly close a connection using its ID.
For more information see Section 29.5, “TCP Connection Events”.
<int:inbound-channel-adapter/> now supports
<script/> sub-elements to create a
MessageSource; see Section 3.3.3, “Channel Adapter Expressions and Scripts”.
The Content Enricher now provides configuration for
sub-elements, to enrich the outbound Message with headers based on the reply Message from the underlying
message flow. For more information see Section 6.2.3, “Payload Enricher”.
Previously, message ids were generated using the JDK
UUID.randomUUID() method. With this
release, the default mechanism has been changed to use a more efficient algorithm which
is significantly faster. In addition, the ability to change
the strategy used to generate message ids has been added.
For more information see the section called “Message ID Generation”.
GatewayMethodMetadatais now public class and it makes possible flexibly to configure the
GatewayProxyFactoryBeanprogrammatically from Java code.
For more information see Section 7.2, “Messaging Gateways”.
<http:outbound-channel-adapter/>now provide an
encode-uriattribute to allow disabling the encoding of the URI object before sending the request.
<http:inbound-channel-adapter/>now have a
merge-with-default-convertersattribute to include the list of default
HttpMessageConverters after the custom message converters.
DefaultHttpHeaderMapper. Now, in addition correcting that issue,
DefaultHttpHeaderMapperprovides date parsing from formatted strings for any HTTP headers that accept date-time values.
<http:inbound-channel-adapter/>now support additional useful variables: #matrixVariables, #requestAttributes, #requestHeaders and #cookies. These variables are available in both payload and header expressions.
uri-variables-expressionattribute to specify an
Expressionto evaluate a
Mapfor all URI variable placeholders within URL template. This allows selection of a different map of expressions based on the outgoing message.
For more information see Chapter 16, HTTP Support.
JsonToObjectTransformernow emit/consume headers containing type information.
For more information, see 'JSON Transformers' in Section 6.1, “Transformer”.
Previously, the id attribute for elements within a
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: 'fooChain$child.fooTransformer.handler'.
For more information see Section 5.6, “Message Handler Chain”.
AbstractCorrelatingMessageHandler provides a new property
to allow empty group expiry to run on a longer schedule than expiring partial groups. Empty groups will
not be removed from the
MessageStore until they have not been modified
for at least this number of milliseconds. For more information see Section 5.4.4, “Configuring an Aggregator”.
FileListFilters that use a persistent
now available. These can be used to prevent duplicate files after a system restart. See
Section 13.2, “Reading Files”, Section 14.3, “FTP Inbound Channel Adapter”, and Section 26.5, “SFTP Inbound Channel Adapter” for more information.
variables attribute has been introduced for scripting components.
In addition, variable bindings are now allowed for inline scripts.
See Section 7.6, “Groovy support” and Section 7.5, “Scripting support” for more information.
Previously, when configuring
LoadBalancingStrategy on the channel's 'dispatcher' sub-element,
the only available option was to use a pre-defined enumeration of values which did not allow one to set a custom implementation
LoadBalancingStrategy. You can now use
load-balancer-ref to provide
a reference to a custom implementation of the
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
MessagingTemplate, this would result in an exception being thrown.
PublishSubscribeChannel has a property
minSubscribers (default 0). If the message is sent to at least the minimum
number of subscribers, the send is deemed to be successful (even if zero). If an application
is expecting to get an exception under these conditions, set the minimum subscribers to at
The FTP, SFTP and FTPS endpoints no longer cache sessions by default
cached-sessions attribute has been removed from all endpoints.
Previously, the embedded caching mechanism controlled by this attribute's value didn't
provide a way to limit the size of the cache, which could
grow indefinitely. The
CachingConnectionFactory was introduced in
release 2.1 and it became the preferred (and is now the only) way to cache sessions.
CachingConnectionFactory now provides a new method
resetCache(). This immediately closes idle sessions and causes in-use
sessions to be closed as and when they are returned to the cache.
DefaultSftpSessionFactory (in conjunction with a
CachingSessionFactory) now supports multiplexing channels over
a single SSH connection (SFTP Only).
FTP, SFTP and FTPS Inbound Adapters
Previously, there was no way to override the default filter used to process files retrieved
from a remote server. The
filter attribute determines which files are retrieved
FileReadingMessageSource uses an
AcceptOnceFileListFilter. This means that if a new copy of a file
is retrieved, with the same name as a previously copied file, no message was sent from the
With this release, a new attribute
local-filter allows you to override the
default filter, for example with an
AcceptAllFileListFilter, or some
other custom filter.
For users that wish the behavior of the
to be maintained across JVM executions, a custom filter that retains state, perhaps on
the file system, can now be configured.
Inbound Channel Adapters now support the
preserve-timestamp attribute, which
sets the local file modified timestamp to the timestamp from the server (default false).
FTP, SFTP and FTPS Gateways
local-filename-generator-expressionattribute is now supported, enabling the naming of local files during retrieval. By default, the same name as the remote file is used.
local-directory-expressionattribute is now supported, enabling the naming of local directories during retrieval based on the remote directory.
Remote File Template
A new higher-level abstraction (
RemoteFileTemplate) is provided over the
Session implementations used by the FTP and SFTP modules. While it is
used internally by endpoints, this abstraction can also be used programmatically and, like all
*Template implementations, reliably closes the underlying session while allowing
low level access to the session when needed.
All Outbound Gateways (e.g.
are designed for 'request-reply' scenarios. A response is expected from the external service and
will be 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, e.g. a
<jdbc:outbound-gateway/>, when a SELECT ends with an empty
or, say, a Web Service is One-Way. An option is therefore needed to configure whether or not a
reply is required.
For this purpose, the requires-reply attribute has been introduced for Outbound Gateway components.
In most cases, the default value for requires-reply is
true and, if there is not any result,
ReplyRequiredException will be thrown. Changing the value to
means that, if an external service doesn't return anything, the message-flow will end at that point,
similar to an Outbound Channel Adapter.
The WebService outbound gateway has an additional attribute |
requiresReply property was previously present in the
but set to
false, and there wasn't any way to configure it on Outbound Gateways using the XML namespace.
Previously, a gateway receiving no reply would silently end the flow (with a DEBUG log message); with this change an
exception will now be thrown by default by most gateways. To revert to the previous behavior,
Previously, the <int-amqp:outbound-gateway/> mapped headers before invoking the message
converter, and the converter could overwrite headers such as
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
content-encoding. Custom message converters
may set other headers.
For more complex database-specific types, not supported by the standard
CallableStatement.getObject method, 2 new additional
attributes were introduced to the
element with OUT-direction:
row-mapper attribute of the Stored Procedure Inbound Channel Adapter
now supports a reference to a
definition. Previously, it contained just a class name (which is still supported).
For more information see Section 17.5, “Stored Procedures”.
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 31.4, “Outbound URI Configuration”.
serializerproperty, with the raw data being the message payload.
topic-expressionproperty to determine the Redis topic against the Message at runtime.
topicsattribute, now has the
For more information, see Chapter 23, 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
discard-channel). The filter element now has an attribute
true), to allow the discard action to
be performed after the advice chain completes. See Section 7.7.4, “Advising Filters”.
Request Handler Advice Chains can now be configured using annotations. See Section 7.7.5, “Advising Endpoints Using Annotations”.
This transformer now correctly transforms
String. For more information see Section 6.1, “Transformer”.
Payloads to persist or
merge can now be of type
In that case, each object returned by the
Iterable is treated as
an entity and persisted or merged using the underlying
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
to the gateway definition. Section 18.6.3, “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, the
max-results attribute has been introduced to replace
max-number-of-results, which has been deprecated.
are used to provide the maximum number of results,
or an expression to compute the maximum number of results, respectively, in the
For more information see Chapter 18, JPA Support.
<delayer> provided a
to determine the delay value at runtime. In complex cases it was necessary
to precede the
<delayer> with a
Spring Integration 3.0 introduced the
expression attribute and
sub-element for dynamic delay determination. The
delay-header-name attribute is now deprecated
because the header evaluation can be specified in the
expression. In addition,
ignore-expression-failures was introduced to control the behavior when an
expression evaluation fails.
For more information see Section 7.4, “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, please see Section 17.4.1, “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
Applications can obtain these events using an
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
enables the selection of the headers, and an appropriate (de)serializer needs to be
configured to write the resulting
Map to the
TCP stream. A
MapJsonSerializer is provided as a convenient
mechanism to transfer headers and payload over TCP.
For more information see Section 29.8.4, “Transferring Headers”.
Previously, when configuring a
<message-driven-channel-adapter/>, if you wished to
use a specific
TaskExecutor, it was necessary to declare a container
bean and provide it to the adapter using the
container attribute. The
task-executor is now provided, allowing it to 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 25.3, “Inbound RMI”.
You can now specify the transformer factory class name using the
transformer-factory-class attribute. See the section called “XsltPayloadTransformer”
Spring Integration now has RedisStore Inbound and Outbound Channel Adapters allowing you to write and read Message payloads to/from Redis collection(s). For more information please see Section 23.7, “RedisStore Outbound Channel Adapter” and Section 23.6, “RedisStore Inbound Channel Adapter”.
Spring Integration now has MongoDB Inbound and Outbound Channel Adapters allowing you to write and read Message payloads to/from a MongoDB document store. For more information please see Section 21.5, “MongoDB Outbound Channel Adapter” and Section 21.4, “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 please see Chapter 18, JPA Support
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, say, retry, to an individual endpoint. The 2.2. release introduces the <request-handler-advice-chain/> to many endpoints.
In addition, 3 standard Advice classes have been provided for this purpose:
For more information, see Section 7.7, “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, these features can be enabled when there is not a 'real' transaction present,
by means of a
For more information see Section C.3, “Transaction Synchronization”.
When using the File Oubound Channel Adapter or the File Outbound Gateway, a new mode property was added. Prior to Spring Integration 2.2, target files were replaced when they existed. Now you can specify the following options:
For more information please see Section 13.3.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...
When using the Stored Procedure components of the Spring Integration JDBC Adapter, you can now provide Stored Procedure Names or Stored Function Names using Spring Expression Language (SpEL).
This allows you to specify the Stored Procedures to be invoked at runtime. For example, you can provide Stored Procedure names that you would like to execute via Message Headers. For more information please see Section 17.5, “Stored Procedures”.
The Stored Procedure components now provide basic JMX support, exposing some of their properties as MBeans:
When using the JDBC Outbound Gateway, the update query is no longer mandatory. You can now provide solely a select query using the request message as a source of parameters.
A new Message Channel-specific Message Store Implementation has been added, providing a more scalable solution using database-specific SQL queries. For more information please see: Section 17.4.2, “Backing Message Channels”.
stopActiveComponents() has been
added to the IntegrationMBeanExporter. This 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.
The JMS Outbound Gateway can now be configured to use a
MessageListener container to receive
replies. This can improve performance of the gateway.
ObjectToJsonTransformer now sets the
content-type header to application/json
by default. For more information see Section 6.1, “Transformer”.
Java serialization over HTTP is no longer enabled by default. Previously, when
expected-response-type to a
Accept header was not properly set up. The
SerializingHttpMessageConverter has now been updated
to set the Accept header to
However, because this could cause incompatibility with existing applications,
it was decided to no longer automatically add this converter to the HTTP endpoints.
If you wish to use Java serialization, you will need to add the
SerializingHttpMessageConverter to the appropriate
endpoints, using the
message-converters attribute, when using
XML configuration, or using the
Alternatively, you may wish to consider using JSON instead which is enabled
by simply having
Jackson on the classpath.
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:
For further details please see Section 7.5, “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
implementations. Spring integration leverages
the Spring Gemfire project, providing a thin wrapper over its
For further details please see Chapter 15, GemFire 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 10, AMQP 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.
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 23, Redis Support.
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 24.2, “Resource Inbound Channel Adapter”.
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
class and consequently supports stored procedures for:
The Stored Procedure components also support Sql Functions for the following databases:
For further details please see Section 17.5, “Stored Procedures”.
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.
Since Spring Integration 2.1, the Payload Enricher is provided. A
Payload Enricher defines an endpoint that typically passes a
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”.
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.
As of version 2.1, we have exposed more flexibility with regards to session management for remote file adapters (e.g., FTP, SFTP etc).
cache-sessions attribute, which is
available via the XML namespace support, is now
deprecated. Alternatively, we added the
attributes on the
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
attribute has been removed in favor of consolidating its behavior
resolution-required attribute. Also,
resolution-required attribute now defaults to
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
if no channel was determined (or an attempt to send was not successful).
If, however, you do desire to drop messages silently, simply set
|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”
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="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>
Declaring a Spring Integration namespace using 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, 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: https://github.com/SpringSource/spring-integration/
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:
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:
For a detailed migration guide in regards to upgrading an existing application that uses Spring Integration older than version 2.0, please see:
Spring Integration 2.0 is built on top of Spring 3.0.5 and makes many of its features available to our users.
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.
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.
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.
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 16.3, “Http Outbound Gateway” for more details.
Also in 2.0 we have added support for even more of the patterns described in Hohpe and Woolf's Enterprise Integration Patterns book.
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.
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
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.
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.5, “Control Bus” and Section 7.6.2, “Control Bus” for more details.
We have added several new Channel Adapters and Messaging Gateways in Spring Integration 2.0.
We have added Channel Adapters for receiving and sending messages over the TCP and UDP internet protocols. See Chapter 29, TCP and UDP Support for more details. Also, you can checkout the following blog: TCP/UDP support
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 30, Twitter Support for more details.
The new XMPP adapters support both Chat Messages and Presence events. See Chapter 33, XMPP Support for more details.
Inbound and outbound File transfer support over FTP/FTPS is now available. See Chapter 14, FTP/FTPS Adapters for more details.
Inbound and outbound File transfer support over SFTP is now available. See Chapter 26, SFTP Adapters for more details.
We have also added Channel Adapters for receiving news feeds (ATOM/RSS). See Chapter 12, Feed Adapter for more details.
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.
These symmetrical transformers convert payload objects to and from a Map. See Section 6.1, “Transformer” for more details.
These symmetrical transformers convert payload objects to and from JSON. See Section 6.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 have been added as of Spring 3.0.5. See Section 6.1, “Transformer” for more details.
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 16.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").
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: http://git.springsource.org/spring-integration. We have also switched our build system to Gradle.
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.
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: