Skip to content

Spring Integration 5.x to 6.0 Migration Guide

Jump to bottom
Artem Bilan edited this page Sep 30, 2022 · 18 revisions

Table of Contents

Introduction

First of all it is Java 17 base line for all the code based including main. This also include Kotlin 1.6 upgrade for Java 17 compatibility. Along side with the Spring Framework 6.0 upgrade, we moved to Jakarta EE 9 and respective fresh library dependencies.

Jakarta Namespace

Many Java EE 8 libraries have moved to the jakarta namespace in Jakarta EE 9. This includes JPA, JMS, Mail, JTA, Servlet etc. Therefore, imports in the target projects have to be changed from javax to jakarta. For example, javax.mail.Message to jakarta.mail.Message, when the spring-integration-mail module is used for integration flows with Mail channel adapters. And so on for spring-integration-jpa, spring-integration-jms, spring-integration-ws, spring-integration-http, and spring-integration-websocket modules. In most cases, this is not necessary because Spring Integration encapsulates the low-level APIs in its channel adapters and supporting components.

No spring-integration-rmi

The previously deprecated spring-integration-rmi module was removed due to RMI having a lot of network vulnerabilities. A suggested replacement is REST, WebSockets, RSockets or gRPC.

No array for poller annotation attribute

The messaging annotations no longer require an array of @Poller in their poller attribute. Previously, an array approach was taken for representing a default value of an empty array for no poller configuration. Now the default value is Poller poller() default @Poller(ValueConstants.DEFAULT_NONE);. This becomes especially convenient for Kotlin configuration, which does not allow a single entry for an array annotation attribute.

Smack 4.4.x upgrade

The spring-integration-xmpp module has been upgraded to the latest Ignite Realtime Smack XMPP library and the XmppHeaderMapper contract has been changed from the org.jivesoftware.smack.packet.Message to the org.jivesoftware.smack.packet.MessageBuilder. See DefaultXmppHeaderMapper changes if you use some custom strategy.

log() at the end of a flow

Now, the log() operator of the Java DSL is no longer terminal at the end of flow. Its behavior is aligned with the usage in the middle of the flow - as a continuation of the messaging process. In terms of subsequent message handling, the flow will now behave the same even whether or not a log() operator appears at the end of the flow. If there is a need to stop the flow after the log() at the end, adding nullChannel() is the recommended way to do that. logAndReply() is now deprecated as its behavior is included to the regular log() in the end of flow.

Collection<Message<?>> as an Aggregator output

If an aggregator MessageGroupProcessor is not a SimpleMessageGroupProcessor and it returns a Collection<Message<?>>, such a collection is not split and emitted as a payload of a single reply message. The SimpleMessageGroupProcessor was designed exactly for a use-case where an aggregator may behave as a barrier to park messages until their group conditions are not fulfilled. Previously any Collection<Message<?>> output process result was split into individual messages which does not fit into canonical aggregator functionality.

No lookup DNS host by default

The org.springframework.integration.ip.tcp.connection.AbstractConnectionFactory and org.springframework.integration.ip.udp.DatagramPacketMessageMapper don't set their lookupHost property to true by default anymore. The DNS might not be configured in all the modern environments (e.g. Docker or Kubernetes), so reverse lookup may cause some delay during connection setup. Now, by default, only the IP address of the host is used as a host name. This value is used as a prefix for internal connectionId and also as a IpHeaders.HOSTNAME message header and does not have any active logic based on a name in the framework. The DNS must be configured properly in the deployment environment if lookupHost = true is a preferred way to deal with connections and messages based on them.

Deprecated the IntegrationFlows class

The IntegrationFlows factory is now deprecated in favor of the same methods relocated directly to the IntegrationFlow interface. This way end-user experience should be improved with an importing only one single place for core Java DSL API.

Rename CONDITION column to GROUP_CONDITION

Previously the INT_MESSAGE_GROUP table has had a CONDITION column which is, essentially, a key word for some RDBMS vendors. Now this column is renamed to the GROUP_CONDITION to avoid vendor-specific quoting.

Migrate SFTP module from JSch to Apache MINA

The SFTP modules has been fully reworked from outdated JCraft JSch library to more robust and modern org.apache.sshd:sshd-sftp module of the Apache MINA project. This causes a major breaking changes in the framework components. Mostly it is a migration from the com.jcraft.jsch.ChannelSftp.LsEntry in the generic argument of all the supporting components to the org.apache.sshd.sftp.client.SftpClient.DirEntry. However the impact is minimal if configuration is provided via Java DSL. The most critical change has happened with the DefaultSftpSessionFactory which now requires an SshClient or some of its general configuration properties.

Clone this wiki locally