Spring Integration 7.1 to 7.2 Migration Guide

• Paho-based MQTT support
• Error message headers
• AMQP publisher confirms
• Feed entries without dates
• JDBC
  • Metadata store schema
  • Apache Derby deprecation
• HTTP
  • RestTemplate-based outbound configuration
  • SerializingHttpMessageConverter
• JMS messages with no payload

Paho-based MQTT support

The spring-integration-mqtt module and its types are deprecated for removal in Spring Integration 7.2. Use the spring-integration-mqtt-client module, which is based on the HiveMQ MQTT client, for new MQTT integrations.

When migrating an existing integration, replace the org.springframework.integration:spring-integration-mqtt dependency with org.springframework.integration:spring-integration-mqtt-client. Update the Spring Integration MQTT components to use the org.springframework.integration.mqtt.client packages and adapt client configuration to the HiveMQ API. For example, the new module provides Mqtt3ClientManager and Mqtt5ClientManager instead of Mqttv3ClientManager and Mqttv5ClientManager. It also provides Mqtt3MessageDrivenChannelAdapter and Mqtt5MessageDrivenChannelAdapter for inbound adapters. Paho connection options and callback implementations need to be adapted to the corresponding HiveMQ APIs.

See MQTT Support

Error message headers

The DefaultErrorMessageStrategy now copies the original message headers into the ErrorMessage when an input message is available in the error context. Previously, the original message was available through ErrorMessage.getOriginalMessage(), but its headers were not copied to the error message itself.

Review error-handling flows, header-based routers, and tests that assume error messages do not contain the original headers, including replyChannel and errorChannel. If an error flow must not propagate particular headers, remove them explicitly; use a custom ErrorMessageStrategy if the previous header behavior is required.

See Error Handling.

AMQP publisher confirms

The AMQP outbound channel adapter now honors wait-for-confirm="true" with simple publisher confirms, even when a message has no correlation data. In this case, sending uses RabbitTemplate.invoke() and waits for confirmation with waitForConfirmsOrDie().

If an existing adapter has this option enabled with simple confirms, sends that previously did not wait now block for confirmation and can fail on a negative acknowledgment or timeout. Review the confirm timeout and error handling, or disable wait-for-confirm if waiting is not intended. The connection factory must support publisher confirms; otherwise, the option only produces a warning and no confirmations are awaited.

See AMQP Outbound Channel Adapter.

Feed entries without dates

The FeedEntryMessageSource now falls back to the feed's published date when none of its entries has an updated or published date. All such entries are emitted again when the feed's date advances; a feed that uses its generation time can therefore cause entries to be emitted on every poll. In feeds containing both dated and undated entries, undated entries are sorted last and can be emitted again alongside new dated entries.

If downstream processing requires each entry to be handled only once, add an Idempotent Receiver keyed by SyndEntry.getUri() or another stable entry identifier instead of relying only on timestamp-based duplicate detection.

See Duplicate Entries.

JDBC

Metadata store schema

The METADATA_VALUE column in the JdbcMetadataStore schema scripts is now NOT NULL. For an existing database, remove rows whose METADATA_VALUE is NULL, then alter the column to NOT NULL using the appropriate DDL for the database. The default table name is INT_METADATA_STORE; account for any configured table prefix. Updating the dependency does not alter an existing table, so include this change in the application's database migration.

See JDBC Metadata Store.

Apache Derby deprecation

The DerbyChannelMessageStoreQueryProvider and schema-derby.sql are deprecated for removal. Spring Framework 7.1 also deprecates EmbeddedDatabaseType.DERBY. They remain available in this release, but applications using Derby should plan to migrate their database, schema initialization, and message-store query provider to another supported database. For embedded tests, use H2 or HSQLDB and the matching schema scripts and query provider.

HTTP

RestTemplate-based outbound configuration

The RestTemplate-based configuration for the outbound gateway and outbound channel adapter is deprecated for removal. Replace the XML rest-template attribute with rest-client, and replace the corresponding Java DSL and constructor arguments with their RestClient alternatives. Existing RestTemplate customizations can be carried over with RestClient.create(restTemplate) while migrating to direct RestClient configuration.

Replace the deprecated ResponseErrorHandler-based setErrorHandler() or Java DSL errorHandler() configuration with RestClient.ResponseSpec.ErrorHandler via setDefaultStatusHandler() or the Java DSL defaultStatusHandler() methods. When supplying an external RestClient, configure status handlers on its builder rather than on the endpoint. The deprecated configuration remains available for backward compatibility in 7.2.

See HTTP Outbound Components.

SerializingHttpMessageConverter

The no-argument constructor and setAllowedPatterns() method of SerializingHttpMessageConverter are deprecated for removal. Pass a non-empty list of trusted class or package patterns to the constructor instead, for example:

new SerializingHttpMessageConverter("com.example.orders.*");

Use addAllowedPatterns() to extend the list if needed. Ensure the patterns cover the application types in the serialized object graph; classes outside the allow list are rejected, apart from the converter's always-allowed basic types. The deprecated no-argument constructor retains unrestricted deserialization when no patterns are configured, so the upgrade alone does not enable an allow list.

See HTTP Java Serialization.

JMS messages with no payload

Spring Framework's JMS MessageConverter implementations may now return null from fromMessage() for a JMS message with no payload. Spring Integration treats a null conversion result as a conversion failure and raises a MessageConversionException, which may be wrapped or routed through the component's error handling. This affects AbstractJmsChannel, JmsDestinationPollingSource, ChannelPublishingJmsMessageListener, and JmsOutboundGateway.

Review producers and custom converters to ensure messages intended for payload extraction produce a non-null payload, and adjust error handling and tests for body-less messages. If a flow intentionally handles the raw JMS message, disable payload extraction where supported: extract-payload for an inbound channel adapter, extract-request-payload for an inbound gateway, or extract-reply-payload for an outbound gateway. Downstream components must then handle a jakarta.jms.Message payload rather than its converted body.

See JMS Support.