2. What’s new in Spring Integration 5.0?

This chapter provides an overview of the new features and improvements that have been introduced with Spring Integration 5.0. If you are interested in more details, please see the Issue Tracker tickets that were resolved as part of the 5.0 development process.

2.1 New Components

2.1.1 Java DSL

The separate Spring Integration Java DSL project has now been merged into the core Spring Integration project. The IntegrationComponentSpec implementations for channel adapters and gateways are distributed to their specific modules. See Part V, “Integration Endpoints” for more information about Java DSL support for target protocol integration. Also see the 4.3 to 5.0 Migration Guide for the required steps to move to Spring Integration 5.0.

2.1.2 Testing Support

A new Spring Integration Test Framework has been created to assist with testing Spring Integration applications. Now, with the @SpringIntegrationTest annotation on test class and MockIntegration factory you can make your JUnit tests for integration flows somewhat easier. See Appendix F, Testing support for more information.

2.1.3 MongoDB Outbound Gateway

The new MongoDbOutboundGateway allows you to make queries to the database on demand by sending a message to its request channel. See Section 22.6, “MongoDB Outbound Gateway” for more information.

2.1.4 HTTP Reactive Outbound Gateway and Channel Adapter

The new ReactiveHttpRequestExecutingMessageHandler adds support for WebFlux WebClient for outbound channel adapter and gateway. See Section 17.3, “Http Outbound Components” for more information.

2.1.5 Content Type Conversion

Now that we use the new InvocableHandlerMethod -based infrastructure for service method invocations, we can perform contentType conversion from payload to target method argument. See Section 8.1.7, “Content Type Conversion” for more information.

2.2 General Changes

Spring Integration is now fully based on Spring Framework 5.0 and Project Reactor 3.0. Previous Project Reactor versions are no longer supported.

2.2.1 Core Changes

The @Poller annotation now has the errorChannel attribute for easier configuration of the underlying MessagePublishingErrorHandler. See Section E.6, “Annotation Support” for more information.

All the request-reply endpoints (based on AbstractReplyProducingMessageHandler) can now start transaction and, therefore, make the whole downstream flow transactional. See Section 8.9.6, “Transaction Support” for more information.

The SmartLifecycleRoleController now provides methods to obtain status of endpoints in roles. See Section 8.2, “Endpoint Roles” for more information.

POJO methods are now invoked using an InvocableHandlerMethod by default, but can be configured to use SpEL as before. See Section 3.8, “POJO Method invocation” for more information.

When targeting POJO methods as message handlers, one of the service methods can now be marked with the @Default annotation to provide a fallback mechanism for non-matched conditions. See Section 8.5.2, “Configuring Service Activator” for more information.

A simple PassThroughTransactionSynchronizationFactory is provided to always store a polled message in the current transaction context. That message is used as a failedMessage property of the MessagingException which wraps a raw exception thrown during transaction completion. See Section C.3, “Transaction Synchronization” for more information.

The aggregator expression-based ReleaseStrategy now evaluates the expression against the MesageGroup instead of just the collection of Message<?>. See the section called “Aggregators and Spring Expression Language (SpEL)” for more information.

2.2.2 JMS Changes

Previously, Spring Integration JMS XML configuration used a default bean name connectionFactory for the JMS Connection Factory, allowing the property to be omitted from component definitions. It has now been renamed to jmsConnectionFactory, which is the bean name used by Spring Boot to auto-configure the JMS Connection Factory bean.

If your application is relying on the previous behavior, rename your connectionFactory bean to jmsConnectionFactory, or specifically configure your components to use your bean using its current name.

2.2.3 Gateway Changes

The gateway now correctly sets the errorChannel header when the gateway method has a void return type and an error channel is provided. Previously, the header was not populated. This had the effect that synchronous downstream flows (running on the calling thread) would send the exception to the configured channel but an exception on an async downstream flow would be sent to the default errorChannel instead.

The RequestReplyExchanger interface now has a throws MessagingException clause to meet all the proposed messages exchange contract.

See Section 8.4.8, “Error Handling” for more information.

2.2.4 Mail Changes

Some inconsistencies with rendering IMAP mail content have been resolved. See the note in the Mail-Receiving Channel Adapter Section for more information.

2.2.5 Feed Changes

Instead of the com.rometools.fetcher.FeedFetcher, which is deprecated in ROME, a new Resource property has been introduced to the FeedEntryMessageSource. See Chapter 13, Feed Adapter for more information.

2.2.6 File Changes

The new FileHeaders.RELATIVE_PATH Message header has been introduced to represent relative path in the FileReadingMessageSource. See Section 14.2, “Reading Files” for more information.

The tail adapter now supports idleEventInterval to emit events when there is no data in the file during that period. See Section 14.2.6, “'Tail’ing Files” for more information.

The flush predicates for the FileWritingMessageHandler now have an additional parameter. See Section 14.3.4, “Flushing Files When using APPEND_NO_FLUSH” for more information.

The file outbound channel adapter (FileWritingMessageHandler) now supports the REPLACE_IF_MODIFIED FileExistsMode.

2.2.7 (S)FTP Changes

The inbound channel adapters now have a property max-fetch-size which is used to limit the number of files fetched during a poll when there are no files currently in the local directory. They also are configured with a FileSystemPersistentAcceptOnceFileListFilter in the local-filter by default.

The regex and pattern filters can now be configured to always pass directories. This can be useful when using recursion in the outbound gateways.

All the Inbound Channel Adapters (streaming and synchronization-based) now use an appropriate AbstractPersistentAcceptOnceFileListFilter implementation by default to prevent remote files duplicate downloads.

The FTP and SFTP outbound gateways now support the REPLACE_IF_MODIFIED FileExistsMode when fetching remote files.

The (S)FTP streaming inbound channel adapters now add remote file information in a message header.

The FTP and SFTP outbound channel adapters, as well as PUT command of the outbound gateways, now support InputStream as payload, too.

The inbound channel adapters now can build file tree locally and use a new RecursiveDirectoryScanner by default for local directory. Also these adapters can now be switched to the WatchService instead.

See Chapter 15, FTP/FTPS Adapters and Chapter 27, SFTP Adapters for more information.

2.2.8 Integration Properties

Since version 4.3.2 a new spring.integration.readOnly.headers global property has been added to customize the list of headers which should not be copied to a newly created Message by the MessageBuilder. See Section E.5, “Global Properties” for more information.

2.2.9 Stream Changes

There is a new option on the CharacterStreamReadingMessageSource to allow it to be used to "pipe" stdin and publish an application event when the pipe is closed. See Section 29.2, “Reading from streams” for more information.

2.2.10 Barrier Changes

The BarrierMessageHandler now supports a discard channel to which late-arriving trigger messages are sent. See Section 6.8, “Thread Barrier” for more information.

2.2.11 AMQP Changes

The AMQP outbound endpoints now support setting a delay expression for when using the RabbitMQ Delayed Message Exchange plugin. See Section 11.10, “Delayed Message Exchange” for more information.

The inbound endpoints now support the Spring AMQP DirectMessageListenerContainer. See Section 11.2, “Inbound Channel Adapter” for more information.

Pollable AMQP-backed channels now block the poller thread for the poller’s configured receiveTimeout (default 1 second). See Section 11.11, “AMQP Backed Message Channels” for more information.

Headers, such as contentType that are added to message properties by the message converter are now used in the final message; previously, it depended on the converter type as to which headers/message properties appeared in the final message. To override headers set by the converter, set the headersMappedLast property to true. See Section 11.8, “Outbound Message Conversion” for more information.

2.2.12 HTTP Changes

The DefaultHttpHeaderMapper.userDefinedHeaderPrefix property is now an empty string by default instead of X-. See Section 17.8, “HTTP Header Mappings” for more information.

2.2.13 Aggregator Performance Changes

Aggregators now use a SimpleSequenceSizeReleaseStrategy by default, which is more efficient, especially with large groups. Empty groups are now scheduled for removal after empty-group-min-timeout. See Section 6.4, “Aggregator” for more information.

2.2.14 MQTT Changes

Inbound messages are now mapped with headers RECEIVED_TOPIC, RECEIVED_QOS and RECEIVED_RETAINED to avoid inadvertent propagation to outbound messages when an application is relaying messages.

The outbound channel adapter now supports expressions for the topic, qos and retained properties; the defaults remain the same.

See Chapter 23, MQTT Support for more information.

2.2.15 STOMP Changes

The STOMP module has been changed to use ReactorNettyTcpStompClient, based on the Project Reactor 3.0 and reactor-netty extension. The Reactor2TcpStompSessionManager has been renamed to the ReactorNettyTcpStompSessionManager according to the ReactorNettyTcpStompClient foundation.

See Chapter 28, STOMP Support for more information.

2.2.16 Web Services Changes

  • The WebServiceOutboundGateway s can now be supplied with an externally configured WebServiceTemplate instances.
  • The DefaultSoapHeaderMapper can now map a javax.xml.transform.Source user-defined header to a SOAP header element.
  • Simple WebService Inbound and Outbound gateways can now deal with the complete WebServiceMessage as a payload, allowing the manipulation of MTOM attachments.

See Chapter 34, Web Services Support for more information.