-
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
log()
at the end of flowCollection<Message<?>>
as an Aggregator output- No lookup DNS host by default
- Deprecated the
IntegrationFlows
class
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 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.
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.
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.
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 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.
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.
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.
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.