-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Spring Integration 5.0 to 5.1 Migration Guide
- Class and Package Tangles
- IntegrationFlowContext
- Dispatcher Exceptions
- Integration Evaluation Context Bean
- Gemfire Module
- AMQP contentType Header Mapping
- Aggregator group timeout
- @Publisher annotation processing
- Streaming Remote File Source Comparators
- GenericHandler and MessageHeaders
- move
StaticMessageHeaderAccessorto rootintegrationpackage - move acknowledgment related classes to a new
ackspackage - move
MMIHtohandler.support, alongside argument resolvers, alsoHandlerMethodArgumentResolversHolder - move
ErrorMessagePublishertocore - move
PatternMatchUtilstosupport.utils - move
MessageSourceManagementtosupport.management - remove direct reference to
MicrometerMetricsCapterfromIntegrationManagementSupport - add new class
MetricsCaptorLoader - move
OperationsCallbackto inner interface inRemoteFileOperations - move
HttpContextUtilstoconfig - move
IntegrationManagementConfigurerfrommanagementtoconfig - make
grapha top-level package - move classes from
config.dslpackage todslone - rename core
eventpackage toevents
The IntegrationFlowContext is now an interface and IntegrationFlowRegistration is an inner interface of the IntegrationFlowContext.
Exceptions caught and re-thrown by AbstractDispatcher are now more consistent:
- A
MessagingExceptionof any kind, with afailedMessageproperty, is re-thrown unchanged - All other exceptions are wrapped in a
MessageDeliveryExceptionwith thefailedMessageproperty set
Previously:
- A
MessagingExceptionof any kind, with afailedMessageproperty, was re-thrown unchanged - A
MessagingException, with nofailedMessageproperty, was wrapped in aMessagingExceptionwith thefailedMessageproperty set - Other
RuntimeExceptions were re-thrown unchanged - Checked exceptions were wrapped in a
MessageDeliveryExceptionwith thefailedMessageproperty set
An integrationSimpleEvaluationContext bean for the SimpleEvaluationContext is now registered along with the integrationEvaluationContext bean for the StandardEvaluationContext. Therefore an injection for the EvaluationContext should be reconsidered for the appropriate bean to use.
Right now this module is based on the Open Source Spring Data for Apache Geode project as transitive dependency.
To switch to the commercial Pivotal GemFire based Spring Data for Pivotal GemFire, exclude spring-data-geode from dependencies and add spring-data-gemfire:
<dependency>
<groupId>org.springframework.integration</groupId>
<artifactId>spring-integration-gemfire</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-geode</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-gemfire</artifactId>
</dependency>The contentType header is no longer incorrectly mapped as an entry in the MessageProperties.headers map; it is only mapped to the MessageProperties.contentType property (which is represented as content_type in RabbitMQ).
Previously the header was mapped in both places.
Now a negative groupTimeout results in the immediate group expiration functionality without any scheduling.
Only the null result of the groupTimeout calculation is treated as like "do nothing" for the current message to process.
Now to enable a @Publisher annotation AOP proxying, the @EnablePublisher must be declared on some @Configuration class.
The work which is done by the PublisherAnnotationBeanPostProcessor to scan classes for the @Publisher annotation is too heavy, so the Framework doesn't register it by default any more.
With the XML configuration, for the same purpose, the <int:enable-publisher> sub-element must be declared on the <int:annotation-config>.
Comparators used to sort remote file lists for streaming inbound channel adapters are now applied to the raw object representing the remote file, rather than an AbstractFileInfo object.
e.g. for FTP, use Comparator<FTPFile> and for SFTP, use Comparator<LsEntry>.
The GenericHandler.handle() now expects a MessageHeaders type for the second argument instead of plain Map<String, Object>.
This is done for better end-user experience, especially for type-safe retrieval.
The existing lambdas in the Java DSL's .handle() is fully compatible.
Only direct GenericHandler interface implementations have to be changed accordingly a new API.