-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Spring Integration 4.2 to 4.3 Migration Guide
Previously, it was possible to specify a reply-channel on an <outbound-gateway> within a <chain>.
It was completely ignored; the gateway's reply goes to the next chain element, or to the chain's output-channel if the gateway is the last element.
This condition is now detected and disallowed.
If you have such configuration, simply remove the reply-channel.
The default serializer in the RedisQueueInboundGateway has been changed to a JdkSerializationRedisSerializer for compatibility with the RedisQueueOutboundGateway for client/server interaction scenarios. Previously it was (in the RedisQueueInboundGateway) a StringRedisSerializer by default; to restore that behavior provide a reference to a its bean.
In previous versions, the Integration property names had a typographical error (...integraton...); they have now been corrected (...integration...). So, the properties with their default values are now:
spring.integration.channels.autoCreate=true
spring.integration.channels.maxUnicastSubscribers=0x7fffffff
spring.integration.channels.maxBroadcastSubscribers=0x7fffffff
spring.integration.taskScheduler.poolSize=10
spring.integration.messagingTemplate.throwExceptionOnLateReply=false
spring.integration.messagingAnnotations.require.componentAnnotation=false
See the Reference Manual for more information.
Previously, the @MessageEndpoint stereotype annotation (or any other @Component) has been required on the class level to process Messaging Annotations like @ServiceActivator, @TRansformer, @InboundChannelAdapter, @Splitter etc. from the class methods.
This caused problems when such components were detected by component scans - such as an embedded inner class in a Spring Boot application; additional beans could be declared.
This restriction has been now been removed. In rare cases, this might cause unexpected behavior in that previously ignored annotations in classes that are not components will now be detected if such classes are declared as beans.
To restore the previous Spring Integration behavior, to require a class-level annotation, you can specify the Spring Integration property spring.integration.messagingAnnotations.require.componentAnnotation as true in the spring.integration.properties file.
Previously, the MailReceiver interface receive() method returned an array of javax.mail.Message objects, now it returns an Object[]. This facilitates a new feature to map the mail message to a Message<?> with the mail headers mapped to MessageHeaders. If that option is selected, the return type is an array of Message<?>; if not it is an array of javax.mail.Message.
Previously, having the local optimization, the RedisLockRegistry must be used like obtain() very close for the lock() to have as fresh state in the store as possible.
When it is used for the LockRegistryLeaderInitiator, the scenario doesn't work because that one uses only tryLock() repeatedly and the local optimization doesn't allow to refresh state in the store on lock re-entrance.
With all those flaws the RedisLockRegistry has been reworked to perform key refresh in the store on each lock re-entrance.
To be sure that only one instance gets access to the key, a unique clientId property has been added to the RedisLockRegistry.
The value structure in the Redis now is changed to the HMSET - alongside with the lock representation the clientId is stored as well to distinguish the owner of the lock in the cluster.