This chapter provides an overview of the new features and improvements that have been introduced with Spring
Integration 5.1.
If you are interested in more details, see the Issue Tracker tickets that were resolved as part of the 5.1 development process.
The following components are new in 5.1:
The following changes have been made in version 5.1:
The IntegrationFlowContext is now an interface and IntegrationFlowRegistration is an inner interface of IntegrationFlowContext.
A new logAndReply() operator has been introduced for convenience when you wish to log at the end of a flow for request-reply configurations.
This avoid confusion with log() which is treated as a one-way end flow component.
A generated bean name for any NamedComponent within an integration flow is now based on the component type for better readability from visual tools, logs analyzers and metrics collectors.
Exceptions caught and re-thrown by AbstractDispatcher are now more consistent:
MessagingException of any kind that has a failedMessage property is re-thrown unchanged.
MessageDeliveryException with the failedMessage property set.
Previously:
MessagingException of any kind that has a failedMessage property was re-thrown unchanged
MessagingException that had no failedMessage property was wrapped in a MessagingException with the failedMessage property set.
RuntimeException instances were re-thrown unchanged.
MessageDeliveryException with the failedMessage property set.
Global channel interceptors now apply to dynamically registered channels, such as through the IntegrationFlowContext when using the Java DSL or beans that are initialized using beanFactory.initializeBean().
Previously, when beans were created after the application context was refreshed, interceptors were not applied.
ChannelInterceptor.postReceive() is no longer called when no message is received; it is no longer necessary to check for a null Message<?>.
Previously, the method was called.
If you have an interceptor that relies on the previous behavior, implement afterReceiveCompleted() instead, since that method is invoked, regardless of whether a message is received or not.
Furthermore, the PolledAmqpChannel and PolledJmsChannel previously did not invoke afterReceiveCompleted() with null; they now do.
A new ResultType.BYTES mode is introduced for the ObjectToJsonTransformer.
See the section called “JSON Transformers” for more information.
Starting with version 5.0.5, generated bean names for the components in an IntegrationFlow include the flow bean name, followed by a dot, as a prefix. For example, if a flow bean were named flowBean, a generated bean might be named flowBean.generatedBean.
See Section 11.13, “Working With Message Flows” for more information.
If the groupTimeout is evaluated to a negative value, an aggregator now expires the group immediately.
Only null is considered as a signal to do nothing for the current message.
See Section 8.4, “Aggregator” for more information.
Starting with version 5.1, you must explicitly turn on the @Publisher AOP functionality by using @EnablePublisher or by using the <int:enable-publisher> child element on <int:annotation-config>.
See Section B.1.1, “Annotation-driven Configuration with the @Publisher Annotation” for more information.
If you are using FileExistsMode.APPEND or FileExistsMode.APPEND_NO_FLUSH you can provide a newFileCallback that will be called when creating a new file.
This callback receives the newly created file and the message that triggered the callback.
This could be used to write a CSV header, for an example.
The FileReadingMessageSource now doesn’t check and create a directory until its start() is called.
So, if an Inbound Channel Adapter for the FileReadingMessageSource has autoStartup = false, there are no failures against the file system during application start up.
See Chapter 17, File Support for more information.
We have made ID and Timestamp header mapping changes in the DefaultAmqpHeaderMapper.
See the note near the bottom of Section 14.12, “AMQP Message Headers” for more information.
The contentType header is now correctly mapped as an entry in the general headers map.
See Section 14.12.2, “contentType Header” for more information.
A confusing max-rows-per-poll property on the JDBC Inbound Channel Adapter and JDBC Outbound Gateway has been deprecated in favor of the newly introduced max-rows property.
The JdbcMessageHandler supports now a batchUpdate functionality when the payload of the request message is an instance of an Iterable type.
See Chapter 21, JDBC Support for more information.
A RotatingServerAdvice is now available to poll multiple servers and directories with the inbound channel adapters.
See Section 18.6, “Inbound Channel Adapters: Polling Multiple Servers and Directories” and Section 30.8, “Inbound Channel Adapters: Polling Multiple Servers and Directories” for more information.
Also, inbound adapter localFilenameExpression instances can contain the #remoteDirectory variable, which contains the remote directory being polled.
The generic type of the comparators (used to sort the fetched file list for the streaming adapters) has changed from Comparator<AbstractFileInfo<F>> to Comparator<F>.
See Section 18.5, “FTP Streaming Inbound Channel Adapter” and Section 30.7, “SFTP Streaming Inbound Channel Adapter” for more information.
In addition, the synchronizers for inbound channel adapters can now be provided with a Comparator.
This is useful when using maxFetchSize to limit the files retrieved.
When using SSL, host verification is now enabled, by default, to prevent man-in-the-middle attacks with a trusted certificate. See Section 34.10.2, “Host Verification” for more information.
In addition the key and trust store types can now be configured on the DefaultTcpSSLContextSupport.
Since the Spring Social project has moved to end of life status, Twitter support in Spring Integration has been moved to the Extensions project. See Spring Integration Social Twitter for more information.
The JmsSendingMessageHandler now provides deliveryModeExpression and timeToLiveExpression options to determine respective QoS options for JMS message to send at runtime.
The DefaultJmsHeaderMapper now allows to map inbound JMSDeliveryMode and JMSExpiration properties via setting to true respective setMapInboundDeliveryMode() and setMapInboundExpiration() options.
When a JmsMessageDrivenEndpoint or JmsInboundGateway is stopped, the associated listener container is now shut down; this closes its shared connection and any consumers.
You can configure the endpoints to revert to the previous behavior.
See Chapter 23, JMS Support for more information.