-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Spring Integration 5.4 to 5.5 Migration Guide
- Global Error Channel
- HTTP Outbound Endpoint and Content-Type header
- 0 for
maxMessagesPerPoll
IntegrationProperties
- Fail fast in the
JmsMessageDrivenEndpoint
- JUnit 4 is
optional
dependency MessageGroup.condition
option- Single
@EnablePublisher
- Single
@EnableMessageHistory
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 defaulterrorChannel
must be configured with therequireSubscribers
option (or not); -
spring.integration.channels.error.ignoreFailures=true
global property is added to indicate that global defaulterrorChannel
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.
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.
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.
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.
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
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.
To support the MessageGroup.condition
option, the SQL schema scripts for the INT_MESSAGE_GROUP
table have been changed to add a CONDITION VARCHAR(255)
column.
NOTE: Turns out the condition
word is reserved in many RDBMS vendors, e.g. MySQL reserved words.
Now it is quoted in the SQL scripts and in the JdbcMessageStore
, so, it is recommended to upgrade to Spring Integration 5.5.7
or later.
The existing MARKED BIGINT
column has been removed since it is out of use in the framework for a while.
You can enable @Publisher
now only from a single place: or one @EnablePublisher
on some @Configuration
or one <int:enable-publisher>
sub-element of the <int:annotation-config>
.
Previously they could be declared in several places, but must had the same default-publisher-channel
for proper merging.
Since there are other properties to consider, it becomes confusing for target projects which one has a precedence during merging.
So, better to disallow several @Publisher
enablers and advise end-user to configure it only from a single place.
You can enable Message History now only from a single place: or one @EnableMessageHistory
on some @Configuration
or one <int:message-history>
in the XML config.
Previously they could be declared in several places, but must had the same tracked-components
for proper merging.
Since there are other properties to consider, it becomes confusing for target projects which one has a precedence during merging.
So, better to disallow several message history enablers and advise end-users to configure it only from a single place.