Skip to content

Spring Integration 2.2 to 3.0 Migration Guide

Jump to bottom
Artem Bilan edited this page Dec 15, 2013 · 26 revisions

##MessageGroupCallback

This interface is now an inner interface of MessageGroupStore; everything remains the same, just change the import.

##integrationConversionService

Spring Integration no longer falls back to the BeanFactory's ConversionService, however there is still falling back to the creation of DefaultConversionService where it is appropriate, if there is no registered integrationConversionService bean. If there is really a reason to use conversionService as integrationConversionService, simply add the following to the Application Context:

<alias name="conversionService" alias="integrationConversionService"/>

##Aggregator & Resequencer

The <aggregator> no longer iterates over message groups in the AggregatingMessageHandler#setExpireGroupsUponCompletion to remove complete groups. It could lead to an overload on application start up when there wer a large number of messages/groups in theMessageStore. Similar logic is present on the AbstractCorrelatingMessageHandler#forceComplete, when expiring message groups.

For expiring groups and removing empty groups, you need to configure a MessageGroupStoreReaper for the MessageStore used by the <aggregator> or the <resequencer>.

Empty groups can be retained to detect (and possibly reject) late arriving messages.

With this release, an empty-group-min-timeout attribute was introduced for the <aggregator> and the <resequencer>. If you wish to run empty group deletion on a longer schedule than expiring partial groups, set this property. Empty groups will then not be removed from the MessageStore until they have not been modified for at least this number of milliseconds.

XML Module

Removed xpath-selector

In prior versions of Spring Integration the functionality of the XPath Filter was configured using the xpath-selector element. However, in order to provide a more consistent behavior within the Spring Integration Framework, the xpath-selector element has been removed.

Please use the xpath-filter instead. It provides the same set of functionality. In fact it still uses the same MessageSelectors internally.

##JSON Transformers

A new abstraction for JSON conversion has been introduced: JsonObjectMapper. Implementations for Jackson 1.x and Jackson 2 are currently provided (JacksonJsonObjectMapper and Jackson2JsonObjectMapper resp.), with the version being determined by presence on the classpath. Usage of Jackson 1.x ObjectMapper for <object-to-json-transformer> and <json-to-object-transformer> is still supported, but it is deprecated and will be removed in future releases. JsonInboundMessageMapper and JsonOutboundMessageMapper have been changed to use new JSON strategy too. JsonInboundMessageMapper now requires an implementation of JsonInboundMessageMapper.JsonMessageParser as one of constructor arguments. JacksonJsonMessageParser and Jackson2JsonMessageParser implementations are provided out of the box.

##Core module packages refactoring

To avoid packages tangle and classes cycling there were introduced new packages: org.springframework.integration.support.context and org.springframework.integration.support.json. The NamedComponent class and JSON infrustruscture classes (e.g. JsonObjectMapper abstraction) were moved to new packages respectively.

##FTP, SFTP, and FTPS Session Caching

Sessions are no longer cached by default; the cache-sessions attribute is no longer available on these endpoints; see the What's New? section of the reference manual.

##HTTP Header Mapping

Previously, the if-modified-since header was incorrectly mapped as a String representation of a Date instead of a long; also if-unmodified-since header (inbound) contained the wrong value (from if-modified-since).

If your application uses the if-modified-since header, please be aware of the format change.

Previously, the connection header was not mapped to the Response Headers automatically. Now it is one of standard headers, which are transferred as is between MessageHeaders and HTTP Request and Response. With that now you can say Connection: close in any place of the HTTP downstream integration flow.

##JdbcMessageStore

In Spring Integration 2.2 the JDBC Message Store did not correctly execute the queries when using Regions. In order to fix the issue, the REGION column was added to the INT_GROUP_TO_MESSAGE table. Furthermore, the REGION column is now part of the primary key. With Spring Integration 3.0, the queries will now always use the GROUP_KEY and the REGION.

Therefore, please verify that the table structure used for your JDBC Message Store is updated. In the spring-integration-jdbc JAR file you will find updated DDL scripts in the org.springframework.integration.jdbc package. For further information, please see chapter 17.4.3 Initializing the Database of the reference guide.

Stored Procedure Adapters

Previously, the row-mapper attribute of <int-jdbc:returning-resultset/> supported only a fully qualified class name. To provide more flexibility and to allow a RowMapper to be configured as a generic bean, this attribute was converted to bean reference. Note, for backward compatibility, the row-mapper attribute continues to support class name.

RequestHandlerRetryAdvice

Previously, during retry, any business exception thrown by the handler was wrapped in a MessagingException. This precluded the use of conditional exception retries because the classifier would look at the MessagingException not the underlying exception. With this release, the retry now gets the underlying business exception instead. If you currently have a retry advice that is configured for conditional exception retries, you may need to adjust the configuration to reflect this change.

HTTP Request Mapping

The HTTP module now provides powerful Request Mapping support for Inbound Endpoints. Class UriPathHandlerMapping was replaced by IntegrationRequestMappingHandlerMapping, which is registered under the bean name integrationRequestMappingHandlerMapping in the application context. Upon parsing of the HTTP Inbound Endpoint, a new IntegrationRequestMappingHandlerMapping bean is either registered or an existing bean is being reused. To achieve flexible Request Mapping configuration, Spring Integration provides the <request-mapping/> sub-element for <http:inbound-channel-adapter/> and <http:inbound-gateway/>. Both HTTP Inbound Endpoints are now fully based on the Request Mapping infrastructure that was introduced with Spring MVC 3.1.

AbstractReplyProducingMessageHandler onInit() Method

Previously, this method was declared protected void onInit() enabling subclasses to override it so they can participate in the endpoint initialization.

However, this does not enforce subclasses to invoke super.onInit(), which is required to enable features such as the <request-handler-advice-chain/> on endpoints. At least one Spring Integration Extension project failed to do this. Starting with 3.0, this method is now final and subclasses cannot override it. To participate in bean initialization, subclasses must implement doInit() instead, which is invoked by the final onInit() method.

Twitter Inbound Channel Adapter Rate Limiting

Previously, a hard-coded limit within the adapters was used to ensure the polling interval could not be less than 15 seconds. This is no longer the case and the poller configuration is applied directly. For mere information see: https://dev.twitter.com/docs/rate-limiting/1.1

Removed Deprecations from previous versions

Several deprecations from earlier releases have been removed in the 3.0 release:

  • Routers' configuration channel-resolver attribute - in favor of using SpEL via expression attribute
  • Channels' configuration dispatcher attribute - in favor of using dispatcher sub-element
  • Method StoredProcExecutor#setFunction - in favor of using StoredProcExecutor#setIsFunction
  • Methods of StoredProcMessageHandler and StoredProcOutboundGateway - which had been moved to StoredProcExecutor before
  • Constructors of StoredProcMessageHandler, StoredProcOutboundGateway and StoredProcPollingChannelAdapter with parameters dataSource and storedProcedureName - in favor of using constructor with parameter storedProcExecutor, respectively
  • Constants XmppHeaders CHAT_TO and CHAT_THREAD_ID - in favor of using TO and THREAD, respectively
  • Method AbstractXmppConnectionAwareEndpoint#setRequestChannel - in favor of using the setOutputChannel method
Clone this wiki locally