Please be sure to also see the Migration Guide for important changes that might affect your applications. Migration guides for all versions back to 2.1 can be found on the Wiki.
The new MessageGroupFactory strategy has been introduced to allow a control over MessageGroup instances
in MessageGroupStore logic.
The SimpleMessageGroupFactory is provided for the SimpleMessageGroup with the GroupType.HASH_SET as the default
factory for the standard MessageGroupStore implementations.
See Section 10.4, “Message Store” for more information.
The PersistentMessageGroup, - lazy-load proxy, - implementation is provided for persistent MessageGroupStore s,
which return this instance for the getMessageGroup() when their lazyLoadMessageGroups is true (defaults).
See Section 10.4, “Message Store” for more information.
New inbound channel adapters are provided that return an InputStream for each file allowing you to retrieve remote
files without writing them to the local file system
See Section 16.5, “FTP Streaming Inbound Channel Adapter” and Section 28.8, “SFTP Streaming Inbound Channel Adapter” for more information.
A new StreamTransformer is provided to transform an InputStream payload to either a byte[] or String.
See the section called “Stream Transformer” for more information.
A new IntegrationGraphServer together with the IntegrationGraphController REST service are provided to expose the runtime model of a Spring Integration application as a graph.
See Section 10.8, “Integration Graph” for more information.
A new JdbcLockRegistry is provided for distributed locks shared through the data base table.
See Section 19.6, “JDBC Lock Registry” for more information.
A new LeaderInitiator implementation is provided based on the LockRegistry strategy.
See Section 8.3, “Leadership Event Handling” for more information.
Previously, it was possible to 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 to the chain’s output channel
if the gateway is the last element.
This condition is now detected and disallowed.
If you have such configuration, simply remove the reply-channel.
An option to make the Service Asynchronous has been added. See Section 8.5.3, “Asynchronous Service Activator” for more information.
The Messaging Annotation Support doesn’t require any more @MessageEndpoint (or any other @Component) annotation
declaration on the class level.
To restore the previous behaviour specify the spring.integration.messagingAnnotations.require.componentAnnotation of
spring.integration.properties as true.
See Section E.5, “Global Properties” and Section E.6, “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 using the XML namespace.
See Section 22.5, “Marking IMAP Messages When \Recent is Not Supported” for more information.
There is now an option to 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 22.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 21.6, “Mapping Message Headers to/from JMS Message” for more information.
The JMS Outbound gateway now has an async property.
See Section 21.5.2, “Async Gateway” for more information.
There is a change in behavior when a POJO aggregator releases a collection of Message<?> objects; this is rare but if
your application does that, you will need to make a small change to your POJO. See this Important note
for more information.
A new TcpConnectionServerListeningEvent is emitted when a server connection factory is started.
See Section 32.5, “TCP Connection Events” for more information.
The destination-expression and socket-expression are now available for the <int-ip:udp-outbound-channel-adapter>.
See Section 32.2, “UDP Adapters” for more information.
The various deserializers that can’t allocate the final buffer until the whole message has been assembled now support pooling of the raw buffer into which the data is received, rather than creating and discarding a buffer for each message. See Section 32.3, “TCP Connection Factories” for more information.
The message mapper now, optionally, sets a configured content type header. See Section 32.13, “IP Message Headers” for more information.
The generated file name for the FileWritingMessageHandler can represent sub-path to save the desired directory
structure for file in the target directory.
See Section 15.3.1, “Generating File Names” for more information.
The FileReadingMessageSource now hides the WatchService directory scanning logic in the inner class.
The use-watch-service and watch-events options are provided to enable such a behaviour.
The top level WatchServiceDirectoryScanner has been deprecated because of inconsistency around API.
See Section 15.2.2, “WatchServiceDirectoryScanner” for more information.
You can now avoid flushing files when appending and use a number of strategies to flush the data during idle periods. See Section 15.3.4, “Flushing Files When using APPEND_NO_FLUSH” for more information.
The outbound channel adapter can now be configured to set the destination file’s lastmodified timestamp.
See Section 15.3.5, “File Timestamps” for more information.
The FileSplitter will now automatically close an (S)FTP session when the file is completely read.
This applies when the outbound gateway returns an InputStream or the new (S)FTP streaming channel adapters are being used.
Also a new markers-json options has been introduced to convert FileSplitter.FileMarker to JSON String for relaxed downstream network interaction.
See Section 15.5, “File Splitter” for more information.
A new ChainFileListFilter is provided as an alternative to CompositeFileListFilter.
See Section 15.2, “Reading Files” for more information.
The outbound endpoints now support a RabbitTemplate configured with a ContentTypeDelegatingMessageConverter such
that the converter can be chosen based on the message content type.
See Section 12.9, “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 12.12, “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.
It is now possible to configure the reading and writing direction using rightPop and leftPush options for the
RedisQueueMessageDrivenEndpoint and RedisQueueOutboundChannelAdapter respectively.
See Section 25.3.4, “Redis Queue Inbound Channel Adapter” and Section 25.3.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 25.10, “Redis Queue Inbound Gateway” for more information.
Previously, with requests that had a body (such as POST) that had no content-type header, the body was ignored.
With this release, the content type of such requests is considered to be application/octet-stream as recommended
by RFC 2616.
See Section 18.2, “Http Inbound Components” for more information.
uriVariablesExpression now uses a SimpleEvaluationContext by default (since 4.3.15).
See Section 18.4.8, “Mapping URI Variables” for more information.
A new factory bean is provided to simplify the configuration of Jsch proxies for SFTP. See Section 28.3, “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 Section 28.11, “SFTP Outbound Channel Adapter” and Section 28.12, “SFTP Outbound Gateway” for more information.
The FtpSession now supports null for the list() and listNames() method, since it is possible by the
underlying FTP Client.
With that the FtpOutboundGateway can now be configured without remoteDirectory expression.
And the <int-ftp:inbound-channel-adapter> can be configured without remote-directory/remote-directory-expression.
See Chapter 16, FTP/FTPS Adapters for more information.
The ErrorMessageExceptionTypeRouter supports now the Exception superclass mappings to avoid duplication
for the same channel in case of several inheritors.
For this purpose the ErrorMessageExceptionTypeRouter loads mapping classes during initialization to fail-fast
for a ClassNotFoundException.
See Section 6.1, “Routers” for more information.
AMQP, WS and XMPP header mappings (e.g. request-header-mapping, reply-header-mapping) now support negated
patterns.
See Section 12.13, “AMQP Message Headers”, Section 36.5, “WS Message Headers”, and Section 38.6, “XMPP Message Headers” for more information.
Previously, only standard AMQP headers were mapped by default; users 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 12.13, “AMQP Message Headers” for more information.
Groovy scripts can now be configured with the compile-static hint or any other CompilerConfiguration options.
See Section 8.8.1, “Groovy configuration” for more information.
The @InboundChannelAdapter has now an alias channel attribute for regular value.
In addition the target SourcePollingChannelAdapter components can now resolve the target outputChannel bean
from its provided name (outputChannelName options) in late-binding manner.
See Section E.6, “Annotation Support” for more information.
The XMPP Extensions (XEP) are now supported by the XMPP channel adapters. See Section 38.7, “XMPP Extensions” for more information.
The WireTap ChannelInterceptor now can accept a channelName which is resolved to the target MessageChannel
later, during the first active interceptor operation.
See the section called “Wire Tap” for more information.
The ChannelMessageStoreQueryProvider now supports H2 database.
See Section 19.4.3, “Backing Message Channels” for more information.
The ServerWebSocketContainer now exposes allowedOrigins option and SockJsServiceOptions a suppressCors option.
See Chapter 35, WebSockets Support for more information.
Please be sure to also see the Migration Guide for important changes that might affect your applications. Migration guides for all versions back to 2.1 can be found on the Wiki.
A new MetricsFactory strategy interface has been introduced.
This, together with other changes in the JMX and management infrastructure provides much more control over management
configuration and runtime performance.
However, this has some important implications for (some) user environments.
For complete details, see Section 10.1, “Metrics and Management” and the section called “JMX Improvements”.
The MongoDbMetadataStore is now available. For more information, see Section 23.3.2, “MongoDB Metadata Store”.
The @SecuredChannel annotation has been introduced, replacing the deprecated ChannelSecurityInterceptorFactoryBean.
For more information, see Appendix D, Security in Spring Integration.
The SecurityContextPropagationChannelInterceptor has been
introduced for the SecurityContext propagation from one message flow’s Thread to another.
For more information, see Appendix D, Security in Spring Integration.
The FileSplitter, which splits text files into lines, was added in 4.1.2.
It now has full support in the int-file: namespace; see Section 15.5, “File Splitter” for more information.
Zookeeper support has been added to the framework to assist when running on a clustered/multi-host environment.
- ZookeeperMetadataStore
- ZookeeperLockRegistry
- Zookeeper Leadership
See Chapter 39, Zookeeper Support for more information.
A new thread <int:barrier/> component is available allowing a thread to be suspended until some asynchronous event
occurs.
See Section 6.8, “Thread Barrier” for more information.
STOMP support has been added to the framework as inbound and outbound channel adapters pair. See Chapter 29, STOMP Support for more information.
A new Codec abstraction has been introduced, to encode/decode objects to/from byte[].
An implementation that uses Kryo is provided.
Codec-based transformers and message converters are also provided.
See Section 7.4, “Codec” for more information.
A new MessagePreparedStatementSetter functional interface callback is available for the JdbcMessageHandler
(<int-jdbc:outbound-gateway> and <int-jdbc:outbound-channel-adapter>) as an alternative to the
SqlParameterSourceFactory to populate parameters on the PreparedStatement with the requestMessage context.
See Section 19.2, “Outbound Channel Adapter” for more information.
As an alternative to the existing selector attribute, the <wire-tap/> now supports the selector-expression attribute.
See Chapter 15, File Support for more information about these changes.
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.
The ignore-hidden attribute has been introduced for the <int-file:inbound-channel-adapter> to pick up or not
the hidden files from the source directory.
It is true by default.
The FileWritingMessageHandler now also accepts InputStream as a valid message payload type.
The ScatterGatherHandler class has been moved from the org.springframework.integration.handler to the org.springframework.integration.scattergather.
The TCP Serializers no longer flush() the OutputStream; this is now done by the TcpNxxConnection classes.
If you are using the serializers directly within user code, you may have to flush() the OutputStream.
TcpConnectionServerExceptionEvent s are now published whenever an unexpected exception occurs on a TCP server socket (also added to 4.1.3, 4.0.7).
See Section 32.5, “TCP Connection Events” for more information.
If a TCP server socket factory is configured to listen on a random port, the actual port chosen by the OS can now
be obtained using getPort().
getServerSocketAddress() is also available.
See Section 32.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 32.7, “TCP Outbound Gateway Attributes” for more information.
TcpConnection s now support getSslSession() to enable users to extract information from the session to add to
message headers.
See Section 32.13, “IP Message Headers” for more information.
New events are now published whenever a correlation exception occurs - for example sending a message to a non-existent socket.
The TcpConnectionEventListeningMessageProducer is deprecated; use the generic event adapter instead.
See Section 32.5, “TCP Connection Events” for more information.
Previously, the @Poller on an inbound channel adapter defaulted the maxMessagesPerPoll attribute to -1 (infinity).
This was inconsistent with the XML configuration of <inbound-channel-adapter/> s, which defaults to 1.
The annotation now defaults this attribute to 1.
o.s.integration.util.FunctionIterator now requires a o.s.integration.util.Function instead of a
reactor.function.Function.
This was done to remove an unnecessary hard dependency on Reactor.
Any uses of this iterator will need to change the import.
Of course, Reactor is still supported for functionality such as the Promise gateway; the dependency was removed for those users who don’t need it.
It is now possible to 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 21.5, “Outbound Gateway” for more information.
The error-channel now is used for the conversion errors, which have caused a transaction rollback and message redelivery previously.
See Section 21.2, “Message-Driven Channel Adapter” and Section 21.4, “Inbound Gateway” for more information.
When using an implicitly defined DefaultMessageListenerContainer, the default acknowledge is now transacted.
transacted is recommended 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 21.2, “Message-Driven Channel Adapter” and Section 21.4, “Inbound Gateway” for more information.
Namespace support for shared subscriptions (JMS 2.0) has been added to message-driven endpoints and the
<int-jms:publish-subscribe-channel>.
Previously, you had to wire up listener containers as <bean/> s to use shared connections.
See Chapter 21, JMS Support for more information.
Much more flexibility is now provided for dynamic polling.
See Section 4.2.4, “Conditional Pollers for Message Sources” for more information.
The <int-amqp:outbound-gateway> now supports confirm-correlation-expression and confirm-(n)ack-channel
attributes with similar purpose as for <int-amqp:outbound-channel-adapter>.
For both the outbound channel adapter and gateway, if the correlation data is a Message<?>, it will be the basis
of the message on the ack/nack channel, with the additional header(s) added.
Previously, any correlation data (including Message<?>) was returned as the payload of the ack/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 or even provide your own AmqpTemplate implementation.
In addition the default-reply-to is exposed to be used if request message doesn’t have replyTo property.
See Chapter 12, AMQP Support for more information.
The XPathMessageSplitter (<int-xml:xpath-splitter>) now allows the configuration of output-properties
for the internal javax.xml.transform.Transformer and supports an Iterator mode (defaults to true) for the xpath
evaluation org.w3c.dom.NodeList result.
See Section 37.5, “Splitting XML Messages” 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 18.4.4, “Cross-Origin Resource Sharing (CORS) Support” for more information.
The HTTP inbound gateway can be configured as to what status code to return when a request times out.
The default is now 500 Internal Server Error instead of 200 OK.
See Section 18.4.5, “Response StatusCode” for more information.
Documentation is provided for when proxying multipart/form-data requests.
See Chapter 18, 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 8.4.6, “@MessagingGateway Annotation”.
This release includes some performance improvements for aggregating components (aggregator, resequencer, etc),
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, JDBC, Redis and MongoDB message stores support this property.
When using a ref or inner bean for the aggregator, it is now possible to bind a MessageGroupProcessor directly.
In addition, a SimpleMessageGroupProcessor is provided that simply 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, were messages are held up
until they all arrive, and are then released individually. See Section 6.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 16, FTP/FTPS Adapters and Chapter 28, SFTP Adapters for more information.
When use FTP/SFTP outbound gateways to operate on multiple files (mget, mput), it is possible for an exception to
occur after part of the request is completed.
If such a condition occurs, a PartialSuccessException is thrown containing the partial results.
See Section 16.9, “FTP Outbound Gateway” and Section 28.12, “SFTP Outbound Gateway” for more information.
A delegating session factory is now available, enabling the selection of a particular session factory based on some thread context value.
See Section 16.3, “Delegating Session Factory” and Section 28.4, “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 28.2.1, “Configuration Properties” for more information.
The MessageSessionCallback<F, T> has been introduced to perform any custom Session operation(s) with the
requestMessage context in the <int-(s)ftp:outbound-gateway/>.
See Section 16.12, “MessageSessionCallback” and Section 28.14, “MessageSessionCallback” for more information.
WebSocketHandlerDecoratorFactory support has been added to the ServerWebSocketContainer
to allow chained customization for the internal WebSocketHandler.
See Section 35.5, “WebSockets Namespace Support” for more information.
The ApplicationEvent adapters can now operate with payload as event directly allow omitting custom
ApplicationEvent extensions.
The publish-payload boolean attribute has been introduced on the <int-event:outbound-channel-adapter> for this
purpose.
See Chapter 13, Spring ApplicationEvent Support for more information.
Please be sure to also see the Migration Guide for important changes that might affect your applications. Migration guides for all versions back to 2.1 can be found on the Wiki.
A Reactor Promise return type is now supported for Messaging Gateway methods.
See Section 8.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 35, WebSockets Support for more information.
The Scatter-Gather EIP pattern is now implemented. See Section 6.7, “Scatter-Gather” for more information.
The Routing Slip EIP pattern implementation is now provided. See the section called “Routing Slip” for more information.
The Idempotent Receiver EIP implementation is now provided via the <idempotent-receiver> component in XML, or the IdempotentReceiverInterceptor and IdempotentReceiver annotation when using Java Configuration.
See Section 8.9.11, “Idempotent Receiver Enterprise Integration Pattern” and their JavaDocs for more information.
The Boon JsonObjectMapper is now provided for the JSON transformers.
See Section 7.1, “Transformer” for more information.
The <redis-queue-inbound-gateway> and <redis-queue-outbound-gateway> components are now provided.
See Section 25.10, “Redis Queue Inbound Gateway” and Section 25.9, “Redis Queue Outbound Gateway”.
The PollSkipAdvice is now provided to be used within <advice-chain> of the <poller> to determine if the current poll should be suppressed (skipped) by some condition implemented with PollSkipStrategy.
See Section 4.2, “Poller” for more information.
Elements that utilize a message listener container (inbound endpoints, channel) now support the missing-queues-fatal attribute.
See Chapter 12, AMQP Support for more information.
The AMQP outbound endpoints support a new property 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 attempt to establish the connection during startup).
When set the false an attempt to establish the connection is made during application startup.
See Chapter 12, AMQP Support for more information.
The SimpleMessageStore no longer makes a copy of the group when calling getMessageGroup().
See Caution with 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 18.4, “HTTP Namespace Support” for more information.
The MQTT channel adapters can now be configured to connect to multiple servers, for example, to support High Availability (HA). See Chapter 24, MQTT Support for more information.
The MQTT message-driven channel adapter now supports specifying the QoS setting for each subscription. See Section 24.2, “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 24.3, “Outbound Channel Adapter” for more information.
It is now possible to programmatically subscribe to and unsubscribe from topics at runtime. See Section 24.2, “Inbound (message-driven) Channel Adapter” for more information.
The FTP and SFTP outbound channel adapters now support appending to remote files, as well as taking specific actions when a remote file already exists.
The remote file templates now also support 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 16, FTP/FTPS Adapters and Chapter 28, SFTP Adapters for more information.
Splitter components now support an Iterator as the result object for producing output messages.
See Section 6.3, “Splitter” for more information.
Aggregator s now support a new attribute expire-groups-upon-timeout.
See Section 6.4.4, “Configuring an Aggregator” for more information.
An null-result-expression attribute has been added, which is evaluated and returned if <enricher> returns null.
It can be added in <header> and <property>.
See Section 7.2, “Content Enricher” for more information.
An error-channel attribute has been added, which is used to handle an error flow if Exception occurs downstream of the request-channel.
This enable you to return an alternative object to use for enrichment.
See Section 7.2, “Content Enricher” for more information.
The <header-enricher/>'s <header-channels-to-string/> 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.
Improvements have been made to the orderly shutdown algorithm. See Section 10.7, “Orderly Shutdown” for more information.
The RecipientListRouter provides now several management operations to configure recipients at runtime.
With that the <recipient-list-router> can now be configured without any <recipient> from the start.
See the section called “RecipientListRouterManagement” for more information.
The AbstractHeaderMapper implementations now provides the additional NON_STANDARD_HEADERS token to map any user-defined headers, which aren’t mapped by default.
See Section 12.13, “AMQP Message Headers” for more information.
The new template-channel-transacted attribute has been introduced for AMQP MessageChannel s.
See Section 12.12, “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 31.2, “Syslog <inbound-channel-adapter>” for more information.
In addition to the Promise return type mentioned above, gateway methods may now return a ListenableFuture, introduced in Spring Framework 4.0.
You can also disable the async processing in the gateway, allowing a downstream flow to directly return a Future.
See Section 8.4.10, “Asynchronous Gateway”.
Aggregator s and Resequencer s now support an <expire-advice-chain/> and <expire-transactional/> sub-elements to advise the forceComplete operation.
See Section 6.4.4, “Configuring an Aggregator” for more information.
The <int:outbound-channel-adapter/> now supports the <script/> sub-element.
The underlying script must have a void return type or return null.
See Section 8.8, “Groovy support” and Section 8.7, “Scripting support”.
When a message group in a resequencer is timed out (using group-timeout or a MessageGroupStoreReaper), late arriving messages will now be discarded immediately by default.
See Section 6.5, “Resequencer”.
Now Spring Integration consistently handles the Java 8’s Optional type.
See Section 8.5.2, “Configuring Service Activator”.
The QueueChannel backed Queue type has been changed from BlockingQueue to the more generic Queue.
It 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 4.1.3, “Channel Interceptors”.
Since version 4.1.1 there is a change of behavior if you explicitly set the javamail property mail.[protocol].peek to false (where [protocol] is imap or imaps).
See Important: IMAP PEEK.
Please be sure to also see the Migration Guide for important changes that might affect your applications. Migration guides for all versions back to 2.1 can be found on the Wiki.
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 24, MQTT Support
The @EnableIntegration annotation has been added, to permit declaration of standard Spring Integration beans when using @Configuration classes.
See Section E.6, “Annotation Support” for more information.
The @IntegrationComponentScan annotation has been added, to permit classpath scanning for Spring Integration specific components.
See Section E.6, “Annotation Support” for more information.
Message history can now be enabled with the @EnableMessageHistory annotation in a @Configuration class; in addition the message history settings can be modified by a JMX MBean.
In addition auto-created MessageHandler s for annotated endpoints (e.g.
@ServiceActivator, @Splitter etc.) now are also trackable by MessageHistory.
For more information, see Section 10.3, “Message History”.
Messaging gateway interfaces can now be configured with the @MessagingGateway annotation.
It is an analogue of the <int:gateway/> xml element.
For more information, see Section 8.4.6, “@MessagingGateway Annotation”.
As well as the @EnableIntegration annotation mentioned above, a a hook has been introduced to allow the Spring Integration infrastructure beans to be configured using Spring Boot’s @EnableAutoConfiguration.
For more information seehttp://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-auto-configuration.html[Spring Boot - AutoConfigure].
As well as the @EnableIntegration annotation mentioned above, the @GlobalChannelInterceptor annotation has bean introduced.
For more information, see Section E.6, “Annotation Support”.
The @IntegrationConverter annotation has bean introduced, as an analogue of <int:converter/> component.
For more information, see Section E.6, “Annotation Support”.
The @EnablePublisher annotation has been added, to allow the specification of a default-publisher-channel for @Publisher annotations.
See Section E.6, “Annotation Support” for more information.
A new Redis MessageGroupStore, that is optimized for use when backing a QueueChannel for persistence, is now provided.
For more information, see Section 25.4.1, “Redis Channel Message Stores”.
A new Redis ChannelPriorityMessageStore is now provided.
This can be used to retrieve messages by priority.
For more information, see Section 25.4.1, “Redis Channel Message Stores”.
MongoDB support now provides the MongoDbChannelMessageStore - a channel specific MessageStore implementation.
With priorityEnabled = true, it can be used in <int:priority-queue> s to achieve priority order polling of persisted messages.
For more information see Section 23.3.1, “MongoDB Channel Message Store”.
The IntegrationMBeanExporter can now be enabled with the @EnableIntegrationMBeanExport annotation in a @Configuration class.
For more information, see Section 10.2.7, “MBean Exporter”.
Configuration of Spring Security for message channels using @Configuration classes is now supported by using a ChannelSecurityInterceptorFactoryBean.
For more information, see Appendix D, Security in Spring Integration.
The Redis support now provides the <outbound-gateway> component to perform generic Redis commands using the RedisConnection#execute method.
For more information, see Section 25.8, “Redis Outbound Command Gateway”.
The RedisLockRegistry and GemfireLockRegistry are now available supporting global locks visible to multiple application instances/servers.
These can be used with aggregating message handlers across multiple application instances such that group release will occur on only one instance.
For more information, see Section 25.11, “Redis Lock Registry”, Section 17.6, “Gemfire Lock Registry” and Section 6.4, “Aggregator”.
Annotation-based messaging configuration can now have a poller attribute.
This means that methods annotated with (@ServiceActivator, @Aggregator etc.) can now use an inputChannel that is a reference to a PollableChannel.
For more information, see Section E.6, “Annotation Support”.
The @InboundChannelAdapter method annotation is now available.
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.6, “Annotation Support”.
A new twitter endpoint <int-twitter-search-outbound-gateway/> has been added.
Unlike the search inbound adapter which polls using the same search query each time, the outbound gateway allows on-demand customized queries.
For more information, see Section 33.6, “Twitter Search Outbound Gateway”.
The GemfireMetadataStore is provided, allowing it to be used, for example, in a AbstractPersistentAcceptOnceFileListFilter implementation in a multiple application instance/server environment.
For more information, see Section 10.5, “Metadata Store”, Section 15.2, “Reading Files”, Section 16.4, “FTP Inbound Channel Adapter” and Section 28.7, “SFTP Inbound Channel Adapter”.
Annotation and Java configuration has introduced @BridgeFrom and @BridgeTo @Bean method annotations to mark MessageChannel beans in @Configuration classes.
For more information, see Section E.6, “Annotation Support”.
Messaging Annotations (@ServiceActivator, @Router, @MessagingGateway etc.) 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 etc.).
For more information, see Section E.6, “Annotation Support”.
Core messaging abstractions (Message, MessageChannel etc) have moved to the Spring Framework spring-messaging module.
Users who reference these classes directly in their code will need to make changes as described in the first section of the Migration Guide.
The header-type attribute has been introduced for the header sub-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 will be converted.
For more information see Section 37.7, “XPath Header Enricher”.
The result-type attribute has been introduced for the <int:object-to-json-transformer>.
This attribute provides the target type for the result of object mapping to JSON.
It supports STRING (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 21.6, “Mapping Message Headers to/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 21.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 21.1, “Inbound Channel Adapter”.
You can now specify a MessageConverter to be used when converting (if necessary) payloads to one of the accepted datatype s in a Datatype channel.
For more information see the section called “Datatype Channel Configuration”.
Simplified namespace support has been added to configure a RequestHandlerRetryAdvice.
For more information see the section called “Configuring the Retry Advice”.
The mutually exclusive group-timeout and group-timeout-expression attributes have been added to the <int:aggregator> and <int:resequencer>.
These attributes allow forced completion of a partial MessageGroup, if the ReleaseStrategy does not release a group and no further messages arrive within the time specified.
For more information see Section 6.4.4, “Configuring an Aggregator”.
The RedisMetadataStore now implements ConcurrentMetadataStore, allowing it to be used, for example, in a AbstractPersistentAcceptOnceFileListFilter implementation in a multiple application instance/server environment.
For more information, see Section 25.5, “Redis Metadata Store”, Section 15.2, “Reading Files”, Section 16.4, “FTP Inbound Channel Adapter” and Section 28.7, “SFTP Inbound Channel Adapter”.
The JdbcChannelMessageStore now implements PriorityCapableChannelMessageStore, allowing it to be used as a message-store reference for priority-queue s.
For more information, see Section 19.4.3, “Backing Message Channels”.
Spring AMQP, by default, creates persistent messages on the broker.
This behavior can be overridden by setting the amqp_deliveryMode header and/or customizing the mappers.
A convenient default-delivery-mode attribute has now been added to the adapters to provide easier configuration of this important setting.
For more information, see Section 12.6, “Outbound Channel Adapter” and Section 12.7, “Outbound Gateway”.
The DefaultFtpSessionFactory now exposes the connectTimeout, defaultTimeout and dataTimeout properties, avoiding the need to subclass the factory just to set these common properties.
The postProcess* methods are still available for more advanced configuration.
See Section 16.2, “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 allowing, for example, attaching an image.
See Section 33.5.1, “Twitter Outbound Update Channel Adapter” for more information.
The id-expression attribute has been introduced for <int-jpa:retrieving-outbound-gateway> to perform EntityManager.find(Class entityClass, Object primaryKey).
See Section 20.6.5, “Retrieving Outbound Gateway” for more information.
When one of the standard deserializers encounters a problem decoding the input stream to a message, it will now emit a TcpDeserializationExceptionEvent, allowing applications to examine the data at the point the exception occurred.
See Section 32.5, “TCP Connection Events” for more information.
Messaging Annotations (@ServiceActivator, @Router, @InboundChannelAdapter etc.) can now be configured on @Bean definitions in @Configuration classes.
For more information, see Section E.6, “Annotation Support”.
The HTTP module now provides powerful Request Mapping support for Inbound Endpoints.
Class UriPathHandlerMapping was replaced by IntegrationRequestMappingHandlerMapping, which is registered under the bean name integrationRequestMappingHandlerMapping in the application context.
Upon parsing of the HTTP Inbound Endpoint, a new IntegrationRequestMappingHandlerMapping bean is either registered or an existing bean is being reused.
To achieve flexible Request Mapping configuration, Spring Integration provides the <request-mapping/> sub-element for the <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 18.4, “HTTP Namespace Support”.
A new IntegrationEvaluationContextFactoryBean is provided to allow configuration of custom PropertyAccessor s 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 <spel-function/> component is introduced.
Two built-in functions are also provided (#jsonPath and #xpath).
For more information see Section A.3, “SpEL Functions”.
To customize the SpEL EvaluationContext with PropertyAccessor implementations the new <spel-property-accessors/> component is introduced.
For more information see Section A.4, “PropertyAccessors”.
A new Redis-based MetadataStore implementation has been added.
The RedisMetadataStore can be used to maintain state of a MetadataStore across application restarts.
This new MetadataStore implementation can be used with adapters such as:
- Twitter Inbound Adapters
- Feed Inbound Channel Adapter
New queue-based components have been added.
The <int-redis:queue-inbound-channel-adapter/> and 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 25, 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 the replyChannel or errorChannel might be lost; for example when serializing a message.
See Section 7.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 MessageStore for MongoDB.
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 23, MongoDb Support for more information.
Building on the 2.2 SyslogToMapTransformer Spring Integration 3.0 now introduces UDP and TCP inbound channel adapters especially tailored for receiving SYSLOG messages.
For more information, see Chapter 31, 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 15.2.6, “'Tail’ing Files”.
-
A new
<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. -
The
IntegrationMBeanExporternow allows the configuration of a customObjectNamingStrategyusing thenaming-strategyattribute.
For more information, see Section 10.2, “JMX Support”.
TcpConnection s now emit ApplicationEvent s (specifically TcpConnectionEvent s) when connections are opened, closed, or an exception occurs.
This allows applications to be informed of changes to TCP connections using the normal Spring ApplicationListener mechanism.
AbstractTcpConnection has been renamed TcpConnectionSupport; custom connections that are subclasses of this class, can use its methods to publish events.
Similarly, AbstractTcpConnectionInterceptor has been renamed to TcpConnectionInterceptorSupport.
In addition, a new <int-ip:tcp-connection-event-inbound-channel-adapter/> is provided; by default, this adapter sends all TcpConnectionEvent s to a Channel.
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 open connections.
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 32.5, “TCP Connection Events”.
The <int:inbound-channel-adapter/> now supports <expression/> and <script/> sub-elements to create a MessageSource; see Section 4.3.3, “Channel Adapter Expressions and Scripts”.
The Content Enricher now provides configuration for <header/> sub-elements, to enrich the outbound Message with headers based on the reply Message from the underlying message flow.
For more information see Section 7.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”.
- It is now possible to set common headers across all gateway methods, and more options are provided for adding, to the message, information about which method was invoked.
- It is now possible to entirely customize the way that gateway method calls are mapped to messages.
-
The
GatewayMethodMetadatais now public class and it makes possible flexibly to configure theGatewayProxyFactoryBeanprogrammatically from Java code.
For more information see Section 8.4, “Messaging Gateways”.
-
Outbound Endpoint encode-uri -
<http:outbound-gateway/>and<http:outbound-channel-adapter/>now provide anencode-uriattribute to allow disabling the encoding of the URI object before sending the request. -
Inbound Endpoint merge-with-default-converters -
<http:inbound-gateway/>and<http:inbound-channel-adapter/>now have amerge-with-default-convertersattribute to include the list of defaultHttpMessageConverters after the custom message converters. -
If-(Un)Modified-Since HTTP Headers - previously, If-Modified-Since and If-Unmodified-Since HTTP headers were incorrectly processed within from/to HTTP headers mapping in the
DefaultHttpHeaderMapper. Now, in addition correcting that issue,DefaultHttpHeaderMapperprovides date parsing from formatted strings for any HTTP headers that accept date-time values. -
Inbound Endpoint Expression Variables - In addition to the existing #requestParams and #pathVariables, the
<http:inbound-gateway/>and<http:inbound-channel-adapter/>now support additional useful variables: #matrixVariables, #requestAttributes, #requestHeaders and #cookies. These variables are available in both payload and header expressions. -
Outbound Endpoint uri-variables-expression - HTTP Outbound Endpoints now support the
uri-variables-expressionattribute to specify anExpressionto evaluate aMapfor 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 18, HTTP Support.
- A new abstraction for JSON conversion has been introduced. Implementations for Jackson 1.x and Jackson 2 are currently provided, with the version being determined by presence on the classpath. Previously, only Jackson 1.x was supported.
-
The
ObjectToJsonTransformerandJsonToObjectTransformernow emit/consume headers containing type information.
For more information, see JSON Transformers in Section 7.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: fooChain$child.fooTransformer.handler.
For more information see Section 6.6, “Message Handler Chain”.
The AbstractCorrelatingMessageHandler provides a new property empty-group-min-timeout 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 6.4.4, “Configuring an Aggregator”.
New FileListFilter s that use a persistent MetadataStore are now available.
These can be used to prevent duplicate files after a system restart.
See Section 15.2, “Reading Files”, Section 16.4, “FTP Inbound Channel Adapter”, and Section 28.7, “SFTP Inbound Channel Adapter” for more information.
A new variables attribute has been introduced for scripting components.
In addition, variable bindings are now allowed for inline scripts.
See Section 8.8, “Groovy support” and Section 8.7, “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 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 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 least 1.
The FTP, SFTP and FTPS endpoints no longer cache sessions by default
The deprecated 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.
The 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.
The 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 but the 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 adapter.
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 AcceptOnceFileListFilter 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
- The gateways now support the mv command, enabling the renaming of remote files.
- The gateways now support recursive ls and mget commands, enabling the retrieval of a remote file tree.
- The gateways now support put and mput commands, enabling sending file(s) to the remote server.
-
The
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. -
The
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 Spring *Template implementations, reliably closes the underlying session while allowing low level access to the session when needed.
For more information, see Chapter 16, FTP/FTPS Adapters and Chapter 28, SFTP Adapters.
All Outbound Gateways (e.g.
<jdbc:outbound-gateway/> or <jms:outbound-gateway/>) 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 ResultSet 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, a ReplyRequiredException will be thrown.
Changing the value to false means that, if an external service doesn’t return anything, the message-flow will end at that point, similar to an Outbound Channel Adapter.
![[Note]](images/note.png) | Note |
|---|---|
|
The WebService outbound gateway has an additional attribute |
Note, the requiresReply property was previously present in the AbstractReplyProducingMessageHandler but set to false, and there wasn’t any way to configure it on Outbound Gateways using the XML namespace.
![[Important]](images/important.png) | Important |
|---|---|
|
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, set |
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, 2 new additional attributes were introduced to the <sql-parameter-definition/> element with OUT-direction:
type-name
return-type
The row-mapper attribute of the Stored Procedure Inbound Channel Adapter <returning-resultset/> sub-element now supports a reference to a RowMapper bean definition.
Previously, it contained just a class name (which is still supported).
For more information see Section 19.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 36.4, “Outbound URI Configuration”.
The Redis Inbound Channel Adapter can now use a null value for 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 against 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 25, 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 discard-within-advice (default true), to allow the discard action to be performed after the advice chain completes.
See Section 8.9.7, “Advising Filters”.
Request Handler Advice Chains can now be configured using annotations. See Section 8.9.8, “Advising Endpoints Using Annotations”.
This transformer now correctly transforms byte[] and char[] payloads to String.
For more information see Section 7.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 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 using a first-result and first-result-expression attributes to the gateway definition.
Section 20.6.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, the max-results attribute has been introduced 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 20, JPA Support.
Previously, the <delayer> provided a delay-header-name attribute to determine the delay value at runtime.
In complex cases it was necessary to precede the <delayer> with a <header-enricher>.
Spring Integration 3.0 introduced the expression attribute and expression 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, the ignore-expression-failures was introduced to control the behavior when an expression evaluation fails.
For more information see Section 8.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, please see Section 19.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 s.
Applications can obtain these events 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 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 32.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 27.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 25.7, “RedisStore Outbound Channel Adapter” and Section 25.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 23.5, “MongoDB Outbound Channel Adapter” and Section 23.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 20, 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:
- MessageHandlerRetryAdvice
- MessageHandlerCircuitBreakerAdvice
- ExpressionEvaluatingMessageHandlerAdvice
For more information, see Section 8.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, these features can be enabled when there is not a real transaction present, by means of a PseudoTransactionManager.
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:
- REPLACE (Default)
- APPEND
- FAIL
- IGNORE
For more information please see Section 15.3.3, “Dealing with Existing Destination Files”.
The XML Namespace support adds the reply-timeout attribute to the following Outbound Gateways:
- Amqp Outbound Gateway
- File Outbound Gateway
- Ftp Outbound Gateway
- Sftp Outbound Gateway
- Ws Outbound Gateway
Spring Integration now uses Spring AMQP 1.1. This enables several features to be used within a Spring Integration application, including…
- A fixed reply queue for the outbound gateway
- HA (mirrored) queues
- Publisher Confirms
- Returned Messages
- Support for Dead Letter Exchanges/Dead Letter Queues
SpEL Support
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 19.5, “Stored Procedures”.
JMX Support
The Stored Procedure components now provide basic JMX support, exposing some of their properties as MBeans:
- Stored Procedure Name
- Stored Procedure Name Expression
- JdbcCallOperations Cache Statistics
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 19.4.3, “Backing Message Channels”.
A method 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.
The ObjectToJsonTransformer now sets the content-type header to application/json by default.
For more information see Section 7.1, “Transformer”.
Java serialization over HTTP is no longer enabled by default.
Previously, when setting a expected-response-type to a Serializable object, the Accept header was not properly set up.
The SerializingHttpMessageConverter has now been updated to set the Accept header to application/x-java-serialized-object.
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 setMessageConverters() method.
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:
- Javascript
- Ruby/JRuby
- Python/Jython
- Groovy
For further details please see Section 8.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 please see Chapter 17, GemFire Support.
Spring Integration 2.1 adds several Channel Adapters for receiving and sending messages using thehttp://www.amqp.org/[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 12, 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 23, 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 25, 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 26.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’shttp://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/jdbc/core/simple/SimpleJdbcCall.html[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 19.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.
For more details please see Section 37.8, “Using the XPath Filter” and Section 37.10, “XML Validating Filter”.
Since Spring Integration 2.1, the Payload Enricher is provided.
A Payload Enricher defines an endpoint that typically passes ahttp://static.springsource.org/spring-integration/api/org/springframework/integration/Message.html[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 7.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.
For further details please see Section 16.9, “FTP Outbound Gateway” and Section 28.12, “SFTP Outbound Gateway”.
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 16.10, “FTP Session Caching” and Section 28.5, “SFTP Session Caching”.
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".
| Important |
|---|---|
|
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 6.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: 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:
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 available 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:
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 1.0 to 2.0 Migration Guide
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 4.1.2, “Message Channel Implementations” as well Section 8.5.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 4.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 18.3, “Http Outbound Components” 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 10.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 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 10.4, “Message Store”, Section 7.3, “Claim Check”, Section 4.1, “Message Channels”, Section 6.4, “Aggregator”, Chapter 19, JDBC Support, and Section 6.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 7.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 10.6, “Control Bus” and Section 8.8.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 32, 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 33, Twitter Support for more details.
The new XMPP adapters support both Chat Messages and Presence events. See Chapter 38, XMPP Support for more details.
Inbound and outbound File transfer support over FTP/FTPS is now available. See Chapter 16, FTP/FTPS Adapters for more details.
Inbound and outbound File transfer support over SFTP is now available. See Chapter 28, SFTP Adapters for more details.
We have also added Channel Adapters for receiving news feeds (ATOM/RSS). See Chapter 14, 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 8.8, “Groovy support” for more details.
These symmetrical transformers convert payload objects to and from a Map. See Section 7.1, “Transformer” for more details.
These symmetrical transformers convert payload objects to and from JSON. See Section 7.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 7.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 6.1.5, “Dynamic Routers” , Section 8.4, “Messaging Gateways”, Section 18.3, “Http Outbound Components”, Section 5.1, “Message”, and Section 6.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: