Skip to content

Spring Integration 5.4 to 5.5 Migration Guide

Jump to bottom
Artem Bilan edited this page Mar 18, 2021 · 13 revisions

Table of Contents

Global Error Channel

The global default errorCahnnel, created by the Framework automatically (if doesn't exists), now supplied with two configuration properties:

  • spring.integration.channels.error.requireSubscribers=true global property is added to indicate that global default errorChannel must be configured with the requireSubscribers option (or not);
  • spring.integration.channels.error.ignoreFailures=true global property is added to indicate that global default errorChannel must ignore (or not) dispatching errors and pass the message to the next handler.

They are made as true by default for better end-user experience when there is no subscribers to handle errors or when one of the subscribers fails and the rest should process an error yet. If the application logic is based on a default (false) value for those options, it is better to reconsider configuration in favor of custom error channel (not global), or change those properties in the META-INF/spring.integration.properties file.

HTTP Outbound Endpoint and Content-Type header

The HTTP request Content-Type header is not populated as an application/x-java-serialized-object fallback value in the HTTP Outbound Gateway and Channel Adapter. Now the final decision how to convert a request body and what Content-Type header to populate is deferred to the RestTemplate and its HttpMessageConverter set. For example if you'd like to have your payload sent as a JSON, a MappingJackson2HttpMessageConverter should be provided to the RestTemplate or via HttpRequestExecutingMessageHandler.setMessageConverters(). This way the payload is going to be serialized as a JSON and application/json is set to the Content-Type request header. Previously we had to use a HeaderEnricher upfront providing an explicit contentType header to enforce a specific converter in the target HTTP Outbound Endpoint.

0 for maxMessagesPerPoll

An AbstractPollingEndpoint (source polling channel adapter and polling consumer) treats maxMessagesPerPoll == 0 as to skip calling the source. It can be changed to different value later on, e.g. via a Control Bus. Previously 0 had the same meaning as negative value - retrieve unlimited messages until the source returns null.

IntegrationProperties

The global integration properties have to be configured as a bean (if any) of an IntegrationProperties instance instead of now deprecated java.util.Properties representation. This becomes easier to configure via predefined setters on the IntegrationProperties instead of trying to discover what exactly property entries have to be provided for the java.util.Properties bean definition. The META-INF/spring.integration.properties file configuration is still supported. See Global Properties documentation for more information.

Fail fast in the JmsMessageDrivenEndpoint

Previously the JmsMessageDrivenEndpoint only logs a warn about already provided listener. Turns out this is not enough for end-users and they may miss the warn message in the logs somehow having some problems at runtime trying to determine find out the root of unexpected behavior. The warn message has been changed to the Assert.isNull() to fail fast, so end-user . Same is done in the KafkaMessageDrivenChannelAdapter & AmqpInboundChannelAdapter

JUnit 4 is optional dependency

The spring-integration-test-support has change its api dependency for the JUnit 4 to the optionalApi one since more and more projects rely now on JUnit 5 and therefore they must exclude JUnit 4 to avoid classpath confusion during development.

Clone this wiki locally