-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Spring Integration 5.x to 6.0 Migration Guide
- Introduction
- Jakarta Namespace
- No spring-integration-rmi
- No array for
poller
annotation attribute - Smack 4.4.x upgrade
- The
log()
in the end of flow
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.
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.
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.
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.
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.
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.