Skip to content

Spring Integration 5.x to 6.0 Migration Guide

Artem Bilan edited this page Mar 21, 2023 · 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 change has been driven mostly for supporting new SSL algorithms. 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. At the same time there might be some incompatibilities with features provided by those two libraries, for example there is no (yet) HTTP and SOCKS proxies support in Apache MINA project.

Class and package tangles

To mitigate some class and package tangles these breaking changes have been introduced:

  • The MessagingAnnotationPostProcessor and MethodAnnotationPostProcessor implementations moved from the org.springframework.integration.config.annotation directly to org.springframework.integration.config package since they use now an AbstractSimpleMessageHandlerFactoryBean references.
  • The GenericHandler and GenericTransformer moved now to the org.springframework.integration.core due to their direct usage from the LambdaMessageProcessor.

GemFire module removal

The spring-integration-gemfire module has been removed due to dropped support from Spring Data project. The source code of the module migrated now to Spring Integration Exteensions project for future considerations.

JavaScript and GraalVM

The JSR223 engine implementation for JavaScript has been removed from Java since version 15. To be able to execute JavaScript, a GraalVM with a js component installed is required from now on.

Deprecation for ChannelSecurityInterceptor

The AOP ChannelSecurityInterceptor has been deprecated in favor of org.springframework.security.messaging.access.intercept.AuthorizationChannelInterceptor. The whole infrastructure around ChannelSecurityInterceptorm including a @SecuredChannel, is deprecated as well. Now you just need to add the mentioned ChannelInterceptor into a MessageChannel to secure or use a @GlobalChannelInterceptor for pattern matching:

@Bean
@GlobalChannelInterceptor(patterns = "secured*")
AuthorizationChannelInterceptor authorizationChannelInterceptor() {
    return new AuthorizationChannelInterceptor(AuthorityAuthorizationManager.hasAnyRole("ADMIN", "PRESIDENT"));
}

No #args and #gatewayMethod for gateway expressions

The #args and #gatewayMethod SpEL variables have been deprecated for a while for @MessagingGateway and @Gateway expressions. They have been removed in favor of MethodArgsHolder root of the evaluation context. This change optimize a gateway mapping logic the way that there is no need in evaluation context for every call: we can just reuse a global one. An old code like this:

@GatewayHeader(name = "calledMethod", expression = "#gatewayMethod.name")

has to be changed to this from now on:

 @GatewayHeader(name = "calledMethod", expression = "method.name")
Clone this wiki locally