Skip to content

Spring Integration 5.x to 6.0 Migration Guide

Jump to bottom
Artem Bilan 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 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 the javax to jakarta. For example javax.mail.Message to jakarta.mail.Message, when 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, spring-integration-websocket modules. In most cases this is not necessary because Spring Integration encapsulates low-level API in its channel adapters and supporting components.

No spring-integration-rmi

The deprecated before spring-integration-rmi module was removed having a lot of network vulnerabilities. The replacement now days is REST, WebSockets, RSockets or gRPC.

No array for poller annotation attribute

The messaging annotations don't require an array of @Poller into their poller attribute any more. 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 reactive() 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.

The log() in the end of flow

Now the log() operator of Java DSL is not a terminal one in the end of flow. Its behavior is aligned with with the usage in the middle of the flow - as continuation of the messaging process. The flow now behaves the same even if log() operator is removed from the configuration. Even there is a need to stop the flow after the log() in the end, the nullChannel() is recommended way to do that from now on. The logAndReply() is now deprecated as its behavior is included to the regular log() in the end of flow.

Clone this wiki locally