Skip to content

Spring Integration 5.x to 6.0 Migration Guide

Jump to bottom
Gary Russell edited this page Apr 7, 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.

Clone this wiki locally