厳密なメッセージ順序を参照してください。

java.util.function インターフェースでは、フレームワークコンポーネントの統合サポートが改善されました。また、Kotlin ラムダをハンドラーおよびソースメソッドに使用できるようになりました。

java.util.function インターフェースのサポートを参照してください。

JUnit 5 @LongRunningTest 条件付きアノテーションが提供され、RUN_LONG_INTEGRATION_TESTS エントリの環境またはシステムプロパティを true の値でチェックして、テストを実行するかスキップするかを決定します。

JUnit のルールと条件を参照してください。

IntegrationFlowContext はインターフェースになり、IntegrationFlowRegistration は IntegrationFlowContext の内部インターフェースになりました。

新しい logAndReply() 演算子は、リクエスト / 応答構成のフローの最後にログを記録する場合に便利なように導入されました。これにより、一方向のエンドフローコンポーネントとして扱われる log() との混乱を回避できます。

統合フロー内の NamedComponent に対して生成された Bean 名は、視覚ツール、ログアナライザー、メトリクスコレクターから読みやすくするために、コンポーネント型に基づいています。

GenericHandler.handle() は、2 番目の引数の MessageHeaders 型を除きます。

AbstractDispatcher がキャッチして再スローした例外の一貫性が向上しました。

以前:

グローバルチャネルインターセプターは、Java DSL または beanFactory.initializeBean() を使用して初期化された Bean を使用する場合、IntegrationFlowContext を介するなど、動的に登録されたチャネルに適用されるようになりました。以前は、アプリケーションコンテキストがリフレッシュされた後に Bean が作成された場合、インターセプターは適用されませんでした。

メッセージが受信されない場合、ChannelInterceptor.postReceive() は呼び出されなくなりました。null Message<?> をチェックする必要はなくなりました。以前は、メソッドが呼び出されていました。以前の動作に依存するインターセプターがある場合は、代わりに afterReceiveCompleted() を実装してください。これは、メッセージが受信されたかどうかに関係なく、そのメソッドが呼び出されるためです。さらに、PolledAmqpChannel および PolledJmsChannel は、以前は null で afterReceiveCompleted() を呼び出しませんでした。彼らは今そうします。

ObjectToJsonTransformer に新しい ResultType.BYTES モードが導入されました。

詳細については、JSONTransformers を参照してください。

バージョン 5.0.5 から、IntegrationFlow のコンポーネント用に生成された Bean 名には、接頭部としてフロー Bean 名とそれに続くドットが含まれます。例: フロー Bean の名前が flowBean の場合、生成された Bean の名前は flowBean.generatedBean になります。

詳細については、メッセージフローの操作を参照してください。

groupTimeout が負の値に評価される場合、アグリゲーターはすぐにグループを期限切れにします。null のみが、現在のメッセージに対して何もしないシグナルと見なされます。

（デフォルトで）出力メッセージの MessageBuilder.popSequenceDetails() を呼び出すことができる新しい popSequence プロパティが導入されました。また、AbstractAggregatingMessageGroupProcessor は、最適化のために Message 全体ではなく AbstractIntegrationMessageBuilder を返すようになりました。

詳細については、アグリゲーターを参照してください。

バージョン 5.1 から、@EnablePublisher を使用するか、<int:annotation-config> の <int:enable-publisher> 子要素を使用して、@Publisher AOP 機能を明示的にオンにする必要があります。また、ProxyFactory 構成を調整するために、proxy-target-class および order 属性が追加されました。

詳細については、@Publisher アノテーションを使用したアノテーション駆動型の構成を参照してください。

別の Spring Integration Java DSL [GitHub] (英語) プロジェクトがコア Spring Integration プロジェクトにマージされました。チャネルアダプターとゲートウェイの IntegrationComponentSpec 実装は、特定のモジュールに配布されます。Java DSL サポートの詳細については、Java DSL を参照してください。Spring Integration 5.0 への移行 [GitHub] (英語) に必要な手順については、4.3 から 5.0 への移行ガイド [GitHub] (英語) も参照してください。

Spring Integration アプリケーションのテストに役立つ新しい Spring Integration テストフレームワークを作成しました。テストクラスの @SpringIntegrationTest アノテーションと MockIntegration ファクトリにより、統合フローの JUnit テストを多少簡単にできるようになりました。

詳細については、テストサポートを参照してください。

新しい MongoDbOutboundGateway では、リクエストチャネルにメッセージを送信することにより、データベースにオンデマンドでクエリを実行できます。

詳細については、MongoDB 送信ゲートウェイを参照してください。

Spring WebFlux フレームワークゲートウェイおよびチャネルアダプター用の新しい WebFlux サポートモジュールを導入しました。

詳細については、WebFlux サポートを参照してください。

サービスメソッド呼び出しに新しい InvocableHandlerMethod ベースのインフラストラクチャを使用したため、ペイロードからターゲットメソッド引数への contentType 変換を実行できます。

詳細については、コンテンツ型の変換を参照してください。

ErrorMessage インスタンスを作成するために ErrorMessagePublisher と ErrorMessageStrategy を追加しました。

詳細については、エラー処理を参照してください。

MetadataStore 実装の JDBC 実装を追加しました。これは、メタデータのトランザクション境界を確保する必要がある場合に役立ちます。

詳細については、JDBC メタデータストアを参照してください。

@Poller アノテーションには、基になる MessagePublishingErrorHandler の構成を容易にするための errorChannel 属性が含まれています。詳細については、アノテーションサポートを参照してください。

すべてのリクエスト / 応答エンドポイント（AbstractReplyProducingMessageHandler に基づく）がトランザクションを開始できるようになったため、ダウンストリームフロー全体がトランザクション対応になりました。詳細については、トランザクションサポートを参照してください。

SmartLifecycleRoleController は、ロール内のエンドポイントのステータスを取得するメソッドを提供するようになりました。詳細については、エンドポイントのロールを参照してください。

デフォルトでは、POJO メソッドは InvocableHandlerMethod を使用して呼び出されるようになりましたが、以前のように SpEL を使用するように設定できます。詳細については、POJO メソッドの呼び出しを参照してください。

POJO メソッドをメッセージハンドラーとしてターゲットにする場合、サービスメソッドの 1 つを @Default アノテーションでマークして、一致しない条件にフォールバックメカニズムを提供できるようになりました。詳細については、Service Activator の構成を参照してください。

ポーリングされたメッセージを常に現在のトランザクションコンテキストに保存するために、簡単な PassThroughTransactionSynchronizationFactory を追加しました。このメッセージは、MessagingException の failedMessage プロパティとして使用され、トランザクションの完了中にスローされた生の例外をラップします。詳細については、トランザクションの同期を参照してください。

アグリゲーター式ベースの ReleaseStrategy は、Message<?> のコレクションだけでなく、MessageGroup に対して式を評価するようになりました。詳細については、アグリゲーターと Spring 式言語 (SpEL) を参照してください。

これで、ObjectToMapTransformer にカスタマイズされた JsonObjectMapper を提供できます。

詳細については、アグリゲーターと Spring 式言語 (SpEL) を参照してください。

@GlobalChannelInterceptor アノテーションと <int:channel-interceptor> は、コンポーネント名のマッチングのために負のパターン（! を先頭に付加する）をサポートするようになりました。詳細については、グローバルチャネルインターセプターの構成を参照してください。

候補がロックの取得に失敗した場合、LockRegistryLeaderInitiator は DefaultLeaderEventPublisher を介して新しい OnFailedToAcquireMutexEvent を発行します。詳細については、Leadership Event Handling を参照してください。

ゲートウェイメソッドに void 戻り型があり、エラーチャネルが提供される場合、ゲートウェイは errorChannel ヘッダーを正しく設定するようになりました。以前は、ヘッダーは読み込まれていませんでした。これにより、同期ダウンストリームフロー（呼び出しスレッドで実行）が構成済みチャネルに例外を送信しますが、非同期ダウンストリームフローの例外は代わりにデフォルト errorChannel に送信されます。

RequestReplyExchanger インターフェースには、提案されたメッセージ交換契約を満たすために throws MessagingException 節があります。

SpEL 式を使用して、リクエストと応答のタイムアウトを指定できるようになりました。詳細については、メッセージングゲートウェイを参照してください。

デフォルトでは、アグリゲーターは SimpleSequenceSizeReleaseStrategy を使用するようになりました。これは、特に大規模なグループではより効率的です。empty-group-min-timeout の後、空のグループが削除されるようになりました。詳細については、アグリゲーターを参照してください。

スプリッターコンポーネントは、Java Stream および Reactive Streams Publisher オブジェクトを処理および分割できるようになりました。出力チャネルが ReactiveStreamsSubscribableChannel の場合、AbstractMessageSplitter は、分割されるオブジェクトに関係なく、通常の Iterator の代わりに、後続の反復のために Flux を構築します。さらに、AbstractMessageSplitter は、可能であれば Iterable および Iterator オブジェクトのサイズを判別できる protected obtainSizeIfPossible() メソッドを提供します。詳細については、スプリッターを参照してください。

以前は、Spring Integration JMS XML 構成は JMS 接続ファクトリに connectionFactory のデフォルト Bean 名を使用していたため、コンポーネント定義からプロパティを省略できました。名前を jmsConnectionFactory に変更しました。これは、JMS 接続ファクトリ Bean を自動構成するために Spring Boot が使用する Bean 名です。

アプリケーションが以前の動作に依存している場合、connectionFactory Bean の名前を jmsConnectionFactory に変更するか、現在の名前を使用して Bean を使用するようにコンポーネントを明確に構成できます。詳細については、JMS サポートを参照してください。

IMAP メールコンテンツのレンダリングに関するいくつかの矛盾が解決されました。詳細については、「メール受信チャネルアダプター」セクションの注意を参照してください。

ROME で非推奨となった com.rometools.fetcher.FeedFetcher の代わりに、FeedEntryMessageSource に新しい Resource プロパティを導入しました。詳細については、フィードアダプターを参照してください。

FileReadingMessageSource の相対パスを表す新しい FileHeaders.RELATIVE_PATH メッセージヘッダーを導入しました。

テールアダプターは、idleEventInterval をサポートし、その期間中にファイルにデータがない場合にイベントを発行するようになりました。

FileWritingMessageHandler のフラッシュ述語には、追加のパラメーターが追加されました。

ファイル送信チャネルアダプターとゲートウェイ（FileWritingMessageHandler）が REPLACE_IF_MODIFIED FileExistsMode をサポートするようになりました。

また、新しく書き込まれたファイルに対するファイル許可の設定もサポートするようになりました。

新しい FileSystemMarkerFilePresentFileListFilter が利用可能になりました。詳細については、不完全なデータの処理を参照してください。

FileSplitter は、コンテンツの最初の行を残りの行に送信されるメッセージのヘッダーとして運ぶための firstLineAsHeader オプションを提供するようになりました。

詳細については、ファイルサポートを参照してください。

現在、受信チャネルアダプターには max-fetch-size というプロパティがあります。これは、ローカルディレクトリにファイルが現在ない場合に、ポーリング中にフェッチされるファイルの数を制限するために使用されます。デフォルトでは、local-filter の FileSystemPersistentAcceptOnceFileListFilter で構成されます。

また、新しく導入された scanner 属性を設定することにより、受信チャネルアダプターにカスタム DirectoryScanner 実装を提供できます。

常にディレクトリを渡すように正規表現とパターンフィルターを構成できるようになりました。これは、送信ゲートウェイで再帰を使用する場合に役立ちます。

デフォルトでは、すべての受信チャネルアダプター（ストリーミングおよび同期ベース）は適切な AbstractPersistentAcceptOnceFileListFilter 実装を使用して、リモートファイルの重複ダウンロードを防止します。

FTP および SFTP 送信ゲートウェイは、リモートファイルをフェッチするときに REPLACE_IF_MODIFIED FileExistsMode をサポートするようになりました。

FTP および SFTP ストリーミング受信チャネルアダプターは、リモートファイル情報をメッセージヘッダーに追加するようになりました。

FTP および SFTP 送信チャネルアダプター（および送信ゲートウェイ用の PUT コマンド）は、InputStream を payload としてもサポートするようになりました。

受信チャネルアダプターは、新しく導入された RecursiveDirectoryScanner を使用して、ローカルでファイルツリーを構築できるようになりました。注入については、FTP 受信チャネルアダプターセクションの scanner オプションを参照してください。また、代わりにこれらのアダプターを WatchService に切り替えることができます。

NLST コマンドを AbstractRemoteFileOutboundGateway に追加して、ファイル名リストリモートコマンドを実行しました。

FtpOutboundGateway に workingDirExpression を提供して、現在のリクエストメッセージの FTP クライアント作業ディレクトリを変更できるようになりました。

現在、RemoteFileTemplate には invoke(OperationsCallback<F, T> action) が提供されており、同じスレッド境界の Session のスコープ内で複数の RemoteFileOperations 呼び出しを実行します。

不完全なリモートファイルを検出するための新しいフィルターを追加しました。

FtpOutboundGateway および SftpOutboundGateway は、GET または MGET コマンドを使用して正常に転送された後にリモートファイルを削除するオプションをサポートするようになりました。

詳細については、FTP/FTPS アダプターおよび SFTP アダプターを参照してください。

バージョン 4.3.2 では、新しい spring.integration.readOnly.headers グローバルプロパティが追加され、MessageBuilder によって新しく作成された Message にコピーしないヘッダーのリストをカスタマイズできるようになりました。詳細については、グローバルプロパティを参照してください。

CharacterStreamReadingMessageSource に新しいオプションを追加して、stdin を「パイプ」し、パイプが閉じられたときにアプリケーションイベントを公開できるようにしました。詳細については、ストリームからの読み取りを参照してください。

BarrierMessageHandler は、遅延到着トリガーメッセージが送信される破棄チャネルをサポートするようになりました。詳細については、スレッドバリアを参照してください。

AMQP 送信エンドポイントは、RabbitMQ Delayed Message Exchange プラグインを使用する場合の遅延式の設定をサポートするようになりました。

受信エンドポイントは Spring AMQP DirectMessageListenerContainer をサポートするようになりました。

ポーリング可能な AMQP-backed チャネルは、ポーラーの構成済み receiveTimeout のポーラースレッドをブロックするようになりました（デフォルト: 1 秒）。

メッセージコンバーターによってメッセージプロパティに追加される contentType などのヘッダーが、最終メッセージで使用されるようになりました。以前は、最終ヘッダーにどのヘッダーとメッセージプロパティが表示されるかはコンバーター型に依存していました。コンバーターによって設定されたヘッダーをオーバーライドするには、headersMappedLast プロパティを true に設定します。詳細については、AMQP サポートを参照してください。

デフォルトでは、DefaultHttpHeaderMapper.userDefinedHeaderPrefix プロパティは X- ではなく空の文字列になりました。詳細については、HTTP ヘッダーマッピングを参照してください。

デフォルトでは、uriVariablesExpression は SimpleEvaluationContext を使用するようになりました（5.0.4 以降）。

詳細については、URI 変数のマッピングを参照してください。

アプリケーションがメッセージを中継するときに、送信メッセージへの不注意な伝播を回避するために、受信メッセージが RECEIVED_TOPIC、RECEIVED_QOS、RECEIVED_RETAINED ヘッダーにマップされるようになりました。

送信チャネルアダプターは、トピック、qos、保持プロパティの式をサポートするようになりました。デフォルトは同じままです。詳細については、MQTT サポートを参照してください。

Project Reactor 3.1 および reactor-netty 拡張に基づいて、ReactorNettyTcpStompClient を使用するように STOMP モジュールを変更しました。ReactorNettyTcpStompClient の基礎に従って、Reactor2TcpStompSessionManager を ReactorNettyTcpStompSessionManager に名前変更しました。詳細については、STOMP サポートを参照してください。

WebServiceOutboundGateway インスタンスに外部で構成された WebServiceTemplate インスタンスを提供できるようになりました。

DefaultSoapHeaderMapper は、javax.xml.transform.Source ユーザー定義ヘッダーを SOAP ヘッダー要素にマップできるようになりました。

シンプルな WebService 受信および送信ゲートウェイは、完全な WebServiceMessage を payload として処理できるようになり、MTOM 添付ファイルの操作が可能になりました。

詳細については、Web サービスのサポートを参照してください。

RedisStoreWritingMessageHandler には、SpEL 式用の追加の String ベースの setter が提供されています（Java 構成の便宜上）。RedisStoreWritingMessageHandler でも zsetIncrementExpression を構成できるようになりました。さらに、ZADD Redis コマンドの INCR オプションはオプションであるため、このプロパティは true から false に変更されました。

Redis リスナー呼び出しを実行するために、RedisInboundChannelAdapter に Executor を提供できるようになりました。さらに、受信したメッセージには、メッセージのソース（トピックまたはパターン）を示す RedisHeaders.MESSAGE_SOURCE ヘッダーが含まれるようになりました。

詳細については、Redis サポートを参照してください。

TCP 接続をスレッドにバインドする新しい ThreadAffinityClientConnectionFactory を追加しました。

PushbackInputStream インスタンスをサポートするように TCP 接続ファクトリを構成して、デシリアライザーが「先読み」後にバイトを「未読」（プッシュバック）できるようになりました。

必要に応じて、受信データを制御およびバッファリングするために、maxMessageSize なしの ByteArrayElasticRawDeserializer を追加しました。

詳細については、TCP および UDP のサポートを参照してください。

GemfireMetadataStore は ListenableMetadataStore を実装し、ストアに MetadataStoreListener インスタンスを提供することでキャッシュイベントをリッスンできるようになりました。詳細については、重要な GemFire および Apache Geode サポートを参照してください。

JdbcMessageChannelStore は ChannelMessageStorePreparedStatementSetter に setter を提供するようになり、ストアへのメッセージ挿入をカスタマイズできるようになりました。

ExpressionEvaluatingSqlParameterSourceFactory は sqlParameterTypes に setter を提供するようになり、パラメーターの SQL 型をカスタマイズできるようになりました。

詳細については、JDBC サポートを参照してください。

Micrometer (英語) アプリケーション監視がサポートされるようになりました（バージョン 5.0.2 以降）。詳細については、Micrometer 統合を参照してください。

バージョン 5.0.4 で導入されたこのアノテーションは、Java 構成を使用する場合に Bean 命名の制御を提供します。詳細については、エンドポイント Bean 名を参照してください。

非同期送信ゲートウェイを参照してください。

MessageGroupStore ロジックで MessageGroup インスタンスを制御できるように、MessageGroupFactory 戦略を導入しました。SimpleMessageGroup に SimpleMessageGroupFactory 実装を追加し、GroupType.HASH_SET を標準 MessageGroupStore 実装のデフォルトファクトリとして追加しました。詳細については、メッセージストアを参照してください。

lazyLoadMessageGroups が true （デフォルト）の場合、getMessageGroup() のこのインスタンスを返す永続的な MessageGroupStore インスタンスに PersistentMessageGroup （遅延負荷プロキシ）実装を追加しました。詳細については、メッセージストアを参照してください。

各ファイルに対して InputStream を返す受信チャネルアダプターを追加し、リモートファイルをローカルファイルシステムに書き込まずに取得できるようにしました。詳細については、FTP ストリーミング受信チャネルアダプターおよび SFTP ストリーミング受信チャネルアダプターを参照してください。

StreamTransformer を追加して、InputStream ペイロードを byte[] または String に変換しました。詳細については、ストリームトランスを参照してください。

IntegrationGraphController REST サービスとともに IntegrationGraphServer を追加して、Spring Integration アプリケーションの実行時モデルをグラフとして公開しました。詳細については、統合グラフを参照してください。

データベーステーブルを介して共有される分散ロックに JdbcLockRegistry を追加しました。詳細については、JDBC ロックレジストリを参照してください。

LockRegistry 戦略に基づいて LeaderInitiator 実装を追加しました。詳細については、リーダーシップイベントの取り扱いを参照してください。

このセクションでは、Spring Integration のコアに対する一般的な変更について説明します。

このセクションでは、Spring Integration メール機能の一般的な変更について説明します。

このセクションでは、Spring Integration JMS 機能に対する一般的な変更について説明します。

POJO アグリゲーターが Message<?> オブジェクトのコレクションをリリースするときの動作に変更があります。これはまれですが、アプリケーションがそれを行う場合、POJO に小さな変更を加える必要があります。この IMPORTANT: SimpleMessageGroup.getMessages() メソッドは unmodifiableCollection を返しますを参照してください。詳細については注意してください。

このセクションでは、Spring Integration TCP/UDP 機能の一般的な変更について説明します。

このセクションでは、Spring Integration ファイル機能の一般的な変更について説明します。

このセクションでは、Spring Integration AMQP 機能の一般的な変更について説明します。

このセクションでは、Spring Integration Redis 機能の一般的な変更について説明します。

以前は、content-type ヘッダーのない本文（POST など）が含まれるリクエストでは、本文は無視されていました。このリリースでは、RFC 2616 で推奨されているように、このようなリクエストのコンテンツ型は application/octet-stream と見なされます。詳細については、HTTP 受信コンポーネントを参照してください。

uriVariablesExpression は、デフォルトで SimpleEvaluationContext を使用するようになりました（4.3.15 以降）。詳細については、URI 変数のマッピングを参照してください。

このセクションでは、Spring Integration SFTP 機能の一般的な変更について説明します。

このセクションでは、Spring Integration FTP 機能の一般的な変更について説明します。

ErrorMessageExceptionTypeRouter は、Exception スーパークラスマッピングをサポートするようになり、複数の継承が存在する場合に同じチャネルが重複するのを防ぎます。このため、ErrorMessageExceptionTypeRouter は初期化中にマッピングクラスをロードして、ClassNotFoundException のフェイルファーストを行います。

詳細については、ルーターを参照してください。

このセクションでは、バージョン 4.2 および 4.3 間のヘッダーマッピングの変更について説明します。

compile-static ヒントまたはその他の CompilerConfiguration オプションを使用して、groovy スクリプトを構成できるようになりました。詳細については、Groovy の設定を参照してください。

@InboundChannelAdapter には、通常の value のエイリアス channel 属性があります。さらに、ターゲット SourcePollingChannelAdapter コンポーネントは、指定された名前（outputChannelName オプション）からレイトバインディング方式でターゲット outputChannel Bean を解決できるようになりました。詳細については、アノテーションサポートを参照してください。

XMPP チャネルアダプターは、XMPP 拡張機能（XEP）をサポートするようになりました。詳細については、XMPP 拡張を参照してください。

WireTap ChannelInterceptor は、最初のアクティブなインターセプター操作中に、後でターゲット MessageChannel に解決される channelName を受け入れることができるようになりました。詳細については、ワイヤータップを参照してください。

ChannelMessageStoreQueryProvider は、H2 データベースをサポートするようになりました。詳細については、バッキングメッセージチャネルを参照してください。

ServerWebSocketContainer は allowedOrigins オプションを公開し、SockJsServiceOptions は suppressCors オプションを公開します。詳細については、WebSockets サポートを参照してください。

新しい MetricsFactory 戦略インターフェースが追加されました。この変更は、JMX および管理インフラストラクチャの他の変更とともに、管理構成および実行時パフォーマンスをはるかに制御します。

ただし、これには（一部の）ユーザー環境にとって重要な意味があります。

詳細については、指標と管理および JMX の改善を参照してください。

MongoDbMetadataStore が利用可能になりました。詳細については、MongoDB メタデータストアを参照してください。

非推奨の ChannelSecurityInterceptorFactoryBean を置き換える @SecuredChannel アノテーションを導入しました。詳細については、Spring Integration のセキュリティを参照してください。

あるメッセージフローのスレッドから別のスレッドへの SecurityContext 伝播に SecurityContextPropagationChannelInterceptor を導入しました。詳細については、Spring Integration のセキュリティを参照してください。

4.1.2 では、テキストファイルを行に分割する FileSplitter を追加しました。int-file: 名前空間で完全にサポートされるようになりました。詳細については、ファイル分割を参照してください。

クラスター環境またはマルチホスト環境での実行を支援するために、Zookeeper サポートをフレームワークに追加しました。この変更は次の機能に影響します。

詳細については、Zookeeper サポートを参照してください。

新しいスレッド <int:barrier/> コンポーネントが使用可能になり、非同期イベントが発生するまでスレッドを中断できます。詳細については、スレッドバリアを参照してください。

受信および送信のチャネルアダプターペアとして、STOMP サポートをフレームワークに追加しました。詳細については、STOMP サポートを参照してください。

オブジェクトを byte[] との間でエンコードおよびデコードするために、新しい Codec 抽象化が導入されました。Kryo を使用する実装を追加しました。コーデックベースのトランスフォーマーとメッセージコンバーターも追加しました。詳細については、コーデックを参照してください。

SqlParameterSourceFactory を使用して requestMessage コンテキストを使用して PreparedStatement のパラメーターを設定する代わりに、JdbcMessageHandler （<int-jdbc:outbound-gateway> および <int-jdbc:outbound-channel-adapter>）の新しい MessagePreparedStatementSetter 関数インターフェースコールバックを使用できます。詳細については、送信チャネルアダプターを参照してください。

既存の selector 属性の代替として、<wire-tap/> 要素は selector-expression 属性をサポートするようになりました。

これらの変更の詳細については、ファイルサポートを参照してください。

ScatterGatherHandler クラスを org.springframework.integration.handler から org.springframework.integration.scattergather に移動しました。

このセクションでは、Spring Integration TCP 機能の一般的な変更について説明します。

以前は、受信チャネルアダプターの @Poller は、maxMessagesPerPoll 属性を -1 （無限大）にデフォルト設定していました。これは、1 にデフォルト設定されている <inbound-channel-adapter/> の XML 構成と矛盾していました。アノテーションでは、この属性のデフォルトが 1 になりました。

o.s.integration.util.FunctionIterator では、reactor.function.Function ではなく o.s.integration.util.Function が必要になりました。これは、Reactor への不要なハード依存性を削除するために行われました。このイテレータを使用する場合は、インポートを変更する必要があります。

Reactor は、Promise ゲートウェイなどの機能で引き続きサポートされています。依存関係は、それを必要としないユーザーのために削除されました。

このセクションでは、Spring Integration TCP 機能の一般的な変更について説明します。

動的ポーリングの柔軟性が大幅に向上しました。

詳細については、メッセージソースの条件付きポーラーを参照してください。

このセクションでは、Spring Integration AMQP 機能の一般的な変更について説明します。

XPathMessageSplitter （<int-xml:xpath-splitter>）は、内部 javax.xml.transform.Transformer の output-properties の構成を可能にし、XPath 評価 org.w3c.dom.NodeList の結果の Iterator モード（デフォルトは true）をサポートします。

詳細については、XML メッセージの分割を参照してください。

このセクションでは、Spring Integration HTTP 機能に対する一般的な変更について説明します。

このセクションでは、Spring Integration ゲートウェイ機能の一般的な変更について説明します。

このセクションでは、Spring Integration アグリゲーター機能の一般的な変更について説明します。

このセクションでは、Spring Integration FTP および SFTP 機能の一般的な変更について説明します。

ServerWebSocketContainer に WebSocketHandlerDecoratorFactory サポートを追加して、内部 WebSocketHandler の連鎖カスタマイズを可能にしました。詳細については、WebSockets 名前空間のサポートを参照してください。

ApplicationEvent アダプターは、payload で event として動作できるようになり、カスタム ApplicationEvent 拡張機能を直接省略できるようになりました。この目的のために、publish-payload ブール属性が <int-event:outbound-channel-adapter> に導入されました。詳細については、Spring ApplicationEvent のサポートを参照してください。

メッセージングゲートウェイメソッドは、Reactor Promise 戻り型をサポートするようになりました。非同期ゲートウェイを参照してください。

WebSocket モジュールが利用可能になりました。Spring WebSocket および Spring メッセージングモジュールに完全に基づいており、<inbound-channel-adapter> および <outbound-channel-adapter> を提供します。詳細については、WebSockets サポートを参照してください。

分散収集エンタープライズ統合パターンを実装しました。詳細については、スキャッターギャザーを参照してください。

ルーティングスリップ EIP パターンの実装を追加しました。詳細については、ルーティングスリップを参照してください。

XML の <idempotent-receiver> コンポーネントまたは Java 構成用の IdempotentReceiverInterceptor および IdempotentReceiver アノテーションを追加することにより、べき等レシーバーエンタープライズ統合パターンの実装を追加しました。詳細については、べき等レシーバーエンタープライズ統合パターンおよび Javadoc を参照してください。

JSON トランスフォーマーに Boon JsonObjectMapper を追加しました。詳細については、Transformer を参照してください。

<redis-queue-inbound-gateway> および <redis-queue-outbound-gateway> コンポーネントを追加しました。Redis キュー受信ゲートウェイおよび Redis キュー送信ゲートウェイを参照してください。

PollSkipAdvice を追加しました。PollSkipAdvice は、<poller> の <advice-chain> 内で使用して、PollSkipStrategy で実装する何らかの条件によって現在のポーリングを抑制する（スキップする）かどうかを決定できます。詳細については、ポーラーを参照してください。

メッセージリスナコンテナー（受信エンドポイントとチャネル）を使用する要素は、missing-queues-fatal 属性をサポートするようになりました。詳細については、AMQP サポートを参照してください。

AMQP 送信エンドポイントは、lazy-connect と呼ばれる新しいプロパティをサポートします（デフォルト: true）。true の場合、ブローカーへの接続は最初のメッセージが到着するまで確立されません（受信エンドポイントがなく、起動時に常に接続を確立しようとします）。false に設定すると、アプリケーションの起動時に接続の確立が試行されます。詳細については、AMQP サポートを参照してください。

SimpleMessageStore は、getMessageGroup() を呼び出したときにグループのコピーを作成しなくなりました。詳細については、[WARNING] を参照してください。

<ws:outbound-gateway/> は、リクエストを送信する前に URI オブジェクトのエンコードを無効にできる encode-uri 属性を提供するようになりました。

<http:inbound-channel-adapter> を status-code-expression で構成して、デフォルトの 200 OK ステータスを上書きできるようになりました。詳細については、HTTP 名前空間のサポートを参照してください。

複数のサーバーに接続するように MQTT チャネルアダプターを構成できるようになりました。たとえば、高可用性（HA）をサポートするためです。詳細については、MQTT サポートを参照してください。

MQTT メッセージ駆動型チャネルアダプターは、各サブスクリプションの QoS 設定の指定をサポートするようになりました。詳細については、受信（メッセージ駆動型）チャネルアダプターを参照してください。

MQTT 送信チャネルアダプターは非同期送信をサポートするようになり、配信が確認されるまでブロックされなくなりました。詳細については、送信チャネルアダプターを参照してください。

実行時にプログラムでトピックをサブスクライブおよびサブスクライブ解除できるようになりました。詳細については、受信（メッセージ駆動型）チャネルアダプターを参照してください。

FTP および SFTP 送信チャネルアダプターは、リモートファイルへの追加と、リモートファイルがすでに存在する場合の特定のアクションの実行をサポートするようになりました。リモートファイルテンプレートは、これと rmdir() および exists() もサポートするようになりました。さらに、リモートファイルテンプレートは、基礎となるクライアントオブジェクトへのアクセスを提供し、低レベル API へのアクセスを可能にします。

詳細については、FTP/FTPS アダプターおよび SFTP アダプターを参照してください。

Splitter コンポーネントは、出力メッセージを生成するための結果オブジェクトとして Iterator をサポートするようになりました。詳細については、スプリッターを参照してください。

Aggregator インスタンスは、新しい属性 expire-groups-upon-timeout をサポートするようになりました。詳細については、アグリゲーターを参照してください。

null-result-expression 属性を追加しました。これは、<enricher> が null を返す場合に評価されて返されます。<header> および <property> に追加できます。詳細については、コンテンツエンリッチャーを参照してください。

error-channel 属性を追加しました。これは、Exception が request-channel の下流で発生した場合にエラーフローを処理するために使用されます。これにより、濃縮に使用する代替オブジェクトを返すことができます。詳細については、コンテンツエンリッチャーを参照してください。

<header-enricher/> 要素の <header-channels-to-string/> 子要素は、チャネルマッピングを保持するヘッダーチャネルレジストリのデフォルト時間をオーバーライドできるようになりました。詳細については、ヘッダーチャネルレジストリを参照してください。

正常なシャットダウンアルゴリズムを改善しました。詳細については、正常なシャットダウンを参照してください。

RecipientListRouter は、実行時に受信者を構成するためのいくつかの管理操作を提供するようになりました。これにより、最初から <recipient> なしで <recipient-list-router> を構成できます。詳細については、RecipientListRouterManagement を参照してください。

AbstractHeaderMapper 実装は、デフォルトではマッピングされないユーザー定義ヘッダーをマッピングするために、追加の NON_STANDARD_HEADERS トークンを提供するようになりました。詳細については、AMQP メッセージヘッダーを参照してください。

AMQP MessageChannel インスタンスに template-channel-transacted 属性を導入しました。詳細については、AMQP-backed メッセージチャネルを参照してください。

デフォルトの syslog メッセージコンバーターには、ヘッダーを設定しながら、ペイロードに元のメッセージを保持するオプションがあります。詳細については、Syslog Inbound Channel Adapter を参照してください。

前述の Promise 戻り型に加えて、ゲートウェイメソッドは Spring Framework 4.0 で導入された ListenableFuture を返すようになりました。ゲートウェイで非同期処理を無効にして、ダウンストリームフローが Future を直接返すようにすることもできます。非同期ゲートウェイを参照してください。

Aggregator および Resequencer は、<expire-advice-chain/> および <expire-transactional/> の子要素をサポートするようになり、forceComplete の操作を通知します。詳細については、XML を使用したアグリゲーターの構成を参照してください。

<int:outbound-channel-adapter/> は、<script/> 子要素をサポートするようになりました。基礎となるスクリプトは、void 戻り値型または null を返す必要があります。Groovy サポートおよびスクリプトのサポートを参照してください。

リシーケンサ内のメッセージグループがタイムアウトになった場合（group-timeout または MessageGroupStoreReaper を使用）、遅延到着メッセージはデフォルトですぐに破棄されるようになりました。リシーケンサーを参照してください。

Spring Integration は Java 8 の Optional 型を一貫して処理するようになりました。Service Activator の構成を参照してください。

QueueChannel がサポートする Queue type は、BlockingQueue からより一般的な Queue に変更されました。この変更により、外部 Queue 実装（たとえば、Reactor の PersistentQueue）を使用できます。QueueChannel の構成を参照してください。

ChannelInterceptor は、追加の afterSendCompletion() および afterReceiveCompletion() メソッドをサポートするようになりました。チャネルインターセプターを参照してください。

バージョン 4.1.1 以降、mail.[protocol].peek JavaMail プロパティを明示的に false に設定した場合（[protocol] は imap または imaps）、動作が変更されます。[IMPORTANT] を参照してください。

MQTT チャネルアダプター（以前は Spring Integration Extensions リポジトリで利用可能）が、通常の Spring Integration ディストリビューションの一部として利用可能になりました。MQTT サポートを参照してください。

@Configuration クラスを使用するときに標準 Spring Integration Bean の宣言を許可するために、@EnableIntegration アノテーションを追加しました。詳細については、アノテーションサポートを参照してください。

@IntegrationComponentScan アノテーションを追加して、Spring Integration 固有のコンポーネントのクラスパススキャンを許可しました。詳細については、アノテーションサポートを参照してください。

@Configuration クラスの @EnableMessageHistory アノテーションを使用してメッセージ履歴を有効にできるようになりました。さらに、JMXMBean はメッセージ履歴設定を変更できます。また、MessageHistory は、アノテーション付きエンドポイント（@ServiceActivator、@Splitter など）の自動作成された MessageHandler インスタンスを追跡できます。詳細については、メッセージ履歴を参照してください。

メッセージングゲートウェイインターフェースを @MessagingGateway アノテーションで構成できるようになりました。これは、<int:gateway/> XML 要素の類似物です。詳細については、@MessagingGateway アノテーションを参照してください。

前述の @EnableIntegration アノテーションに加えて、Spring Integration インフラストラクチャ Bean を Spring Boot の @EnableAutoConfiguration アノテーションで構成できるようにするフックを導入しました。詳細については、Spring Boot リファレンスガイドの “自動構成” を参照してください。

上記の @EnableIntegration アノテーションと同様に、@GlobalChannelInterceptor アノテーションを導入しました。詳細については、アノテーションサポートを参照してください。

<int:converter/> コンポーネントの類似物として @IntegrationConverter アノテーションを導入しました。詳細については、アノテーションサポートを参照してください。

@EnablePublisher アノテーションを追加して、@Publisher アノテーションに default-publisher-channel を指定できるようにしました。詳細については、アノテーションサポートを参照してください。

永続性のために QueueChannel をバッキングするときに使用するために最適化された Redis MessageGroupStore を追加しました。詳細については、Redis チャネルメッセージストアを参照してください。

Redis ChannelPriorityMessageStore を追加しました。これを使用して、優先度ごとにメッセージを取得できます。詳細については、Redis チャネルメッセージストアを参照してください。

MongoDB サポートは、チャネル固有の MessageStore 実装である MongoDbChannelMessageStore を提供するようになりました。priorityEnabled = true では、<int:priority-queue> 要素でそれを使用して、持続メッセージの優先順位ポーリングを実現できます。詳細については、MongoDB チャネルメッセージストアを参照してください。

これで、@Configuration クラスで @EnableIntegrationMBeanExport アノテーションを使用して IntegrationMBeanExporter を有効にできます。詳細については、MBean エクスポーターを参照してください。

ChannelSecurityInterceptorFactoryBean は、@Configuration クラスを使用するメッセージチャネルの Spring Security の構成をサポートするようになりました。詳細については、Spring Integration のセキュリティを参照してください。

Redis サポートは、RedisConnection#execute メソッドを使用して汎用 Redis コマンドを実行する <outbound-gateway> コンポーネントを提供するようになりました。詳細については、Redis 送信コマンドゲートウェイを参照してください。

RedisLockRegistry および GemfireLockRegistry は、複数のアプリケーションインスタンスおよびサーバーから見えるグローバルロックをサポートするようになりました。これらは、複数のアプリケーションインスタンス間でメッセージハンドラーを集約し、1 つのインスタンスのみでグループ解放が行われるように使用できます。詳細については、Redis ロックレジストリ、Gemfire Lock レジストリ、アグリゲーターを参照してください。

アノテーションベースのメッセージング構成で poller 属性を使用できるようになりました。これは、@ServiceActivator、@Aggregator、同様のアノテーションが付けられたメソッドが、PollableChannel への参照である inputChannel を使用できることを意味します。詳細については、アノテーションサポートを参照してください。

@InboundChannelAdapter メソッドアノテーションを追加しました。これは、<int:inbound-channel-adapter> XML コンポーネントの類似物です。さらに、すべてのメッセージングアノテーションが SmartLifecycle オプションを提供するようになりました。詳細については、アノテーションサポートを参照してください。

新しい twitter エンドポイント <int-twitter-search-outbound-gateway/> を追加しました。毎回同じ検索クエリを使用してポーリングする検索受信アダプターとは異なり、送信ゲートウェイではオンデマンドのカスタマイズされたクエリが許可されます。詳細については、Spring Integration ソーシャル Twitter [GitHub] (英語) を参照してください。

GemfireMetadataStore を追加して、たとえば、複数のアプリケーションインスタンスまたはサーバー環境の AbstractPersistentAcceptOnceFileListFilter 実装で使用できるようにしました。詳細については、メタデータストア、ファイルを読む、FTP 受信チャネルアダプター、SFTP 受信チャネルアダプターを参照してください。

@Configuration クラスの MessageChannel Bean をマークするために、@BridgeFrom および @BridgeTo @Bean メソッドアノテーションを導入しました。詳細については、アノテーションサポートを参照してください。

メッセージングアノテーション（@ServiceActivator、@Router、@MessagingGateway など）を、ユーザー定義のメッセージングアノテーションのメタアノテーションとして構成できるようになりました。さらに、ユーザー定義のアノテーションは同じ属性（inputChannel、@Poller、autoStartup など）を持つことができます。詳細については、アノテーションサポートを参照してください。

コアメッセージングの抽象化（Message、MessageChannel など）を Spring Framework spring-messaging モジュールに移動しました。3.0 から 4.0 への移行ガイド [GitHub] (英語) の最初のセクションに従って、コードでこれらのクラスを直接参照する開発者は、変更を加える必要があります。

<int-xml:xpath-header-enricher> の header 子要素に header-type 属性を導入しました。この属性は、ヘッダー値のターゲット型を提供します（XPath 式評価の結果はこの値に変換されます）。詳細については、XPath ヘッダーエンリッチャーを参照してください。

<int:object-to-json-transformer> に result-type 属性を導入しました。この属性は、オブジェクトを JSON にマッピングした結果のターゲット型を提供します。STRING （デフォルト）および NODE をサポートします。詳細については、バージョン 3.0 以降、Spring Integration は式で使用するための組み込み #xpath SpEL 関数も提供します。を参照してください。

DefaultJmsHeaderMapper は、受信 JMSPriority ヘッダーを Spring Integration priority ヘッダーにマップするようになりました。以前は、priority は送信メッセージに対してのみ考慮されていました。詳細については、JMS メッセージとの間のメッセージヘッダーのマッピングを参照してください。

JMS 発信チャネルアダプターは、session-transacted 属性をサポートするようになりました（デフォルト: false）。以前は、カスタマイズされた JmsTemplate を挿入してトランザクションを使用する必要がありました。送信チャネルアダプターを参照してください。

JMS 受信チャネルアダプターは、session-transacted 属性をサポートするようになりました（デフォルト: false）。以前は、カスタマイズされた JmsTemplate を挿入してトランザクションを使用する必要がありました。アダプターは acknowledgeMode で「トランザクション」を許可しましたが、これは正しくなく、機能しませんでした。この値は許可されなくなりました。受信チャネルアダプターを参照してください。

（必要な場合）ペイロードをデータ型チャネルで受け入れられた datatype インスタンスの 1 つに変換するときに使用する MessageConverter を指定できるようになりました。詳細については、データ型チャネルの構成を参照してください。

RequestHandlerRetryAdvice を構成するための簡略化された名前空間サポートを追加しました。詳細については、再試行アドバイスの構成を参照してください。

相互に排他的な group-timeout および group-timeout-expression 属性を <int:aggregator> および <int:resequencer> に追加しました。これらの属性により、ReleaseStrategy がグループを解放せず、指定された時間内にそれ以上メッセージが到着しない場合、部分的な MessageGroup を強制的に完了できます。詳細については、XML を使用したアグリゲーターの構成を参照してください。

RedisMetadataStore は ConcurrentMetadataStore を実装するようになり、たとえば、複数のアプリケーションインスタンスまたはサーバー環境の AbstractPersistentAcceptOnceFileListFilter 実装で使用できるようになりました。詳細については、Redis メタデータストア、ファイルを読む、FTP 受信チャネルアダプター、SFTP 受信チャネルアダプターを参照してください。

T `JdbcChannelMessageStore` は PriorityCapableChannelMessageStore を実装するようになり、priority-queue インスタンスの message-store 参照として使用できるようになりました。詳細については、バッキングメッセージチャネルを参照してください。

Spring AMQP は、デフォルトで、ブローカー上に永続メッセージを作成します。amqp_deliveryMode ヘッダーを設定するか、マッパーをカスタマイズすることにより、この動作をオーバーライドできます。この重要な設定を簡単に構成できるように、便利な default-delivery-mode 属性をアダプターに追加しました。詳細については、送信チャネルアダプターおよび送信ゲートウェイを参照してください。

DefaultFtpSessionFactory は connectTimeout、defaultTimeout、dataTimeout プロパティを公開するようになり、これらの共通プロパティを設定するためにファクトリをサブクラス化する必要がなくなりました。postProcess* メソッドは、より高度な構成で引き続き使用できます。詳細については、FTP セッションファクトリを参照してください。

StatusUpdatingMessageHandler （<int-twitter:outbound-channel-adapter>）は、タイムラインステータスを更新するための org.springframework.social.twitter.api.TweetData オブジェクトを作成するために tweet-data-expression 属性をサポートするようになりました。この機能により、たとえばイメージを添付できます。詳細については、Spring Integration ソーシャル Twitter [GitHub] (英語) を参照してください。

EntityManager.find(Class entityClass, Object primaryKey) を実行するために、<int-jpa:retrieving-outbound-gateway> に id-expression 属性を導入しました。詳細については、送信ゲートウェイの取得を参照してください。

標準デシリアライザーの 1 つが入力ストリームをメッセージにデコードする際に問題を検出すると、TcpDeserializationExceptionEvent を出力するようになり、例外が発生したポイントでアプリケーションがデータを検査できるようになりました。詳細については、TCP 接続イベントを参照してください。

@Configuration クラスの @Bean 定義でメッセージングアノテーション（@ServiceActivator、@Router、@InboundChannelAdapter など）を構成できるようになりました。詳細については、アノテーションサポートを参照してください。

HTTP モジュールは、受信 エンドポイントに対して強力なリクエストマッピングサポートを提供するようになりました。UriPathHandlerMapping クラスを IntegrationRequestMappingHandlerMapping に置き換えました。これは、アプリケーションコンテキストで integrationRequestMappingHandlerMapping の Bean 名で登録されています。HTTP 受信 エンドポイントの解析時に、新しい IntegrationRequestMappingHandlerMapping Bean が登録されるか、既存の Bean が再利用されます。柔軟なリクエストマッピング構成を実現するために、Spring Integration は <http:inbound-channel-adapter/> および <http:inbound-gateway/> に <request-mapping/> 子要素を提供します。現在、両方の HTTP 受信 エンドポイントは、Spring MVC 3.1 で導入されたリクエストマッピングインフラストラクチャに完全に基づいています。例: 単一の受信 エンドポイントで複数のパスがサポートされます。詳細については、HTTP 名前空間のサポートを参照してください。

新しい IntegrationEvaluationContextFactoryBean を追加して、フレームワーク全体で SpEL 式で使用するカスタム PropertyAccessor 実装および関数を構成できるようにしました。詳細については、Spring 式言語 (SpEL) を参照してください。

静的 Method 関数を使用して SpEL EvaluationContext をカスタマイズするために、<spel-function/> コンポーネントを導入しました。また、2 つの組み込み関数 #jsonPath および #xpath を追加しました。詳細については、SpEL 関数を参照してください。

SpEL EvaluationContext を PropertyAccessor 実装でカスタマイズするために、<spel-property-accessors/> コンポーネントを追加しました。詳細については、プロパティアクセサーを参照してください。

新しい Redis ベースの MetadataStore (Javadoc) 実装を追加しました。RedisMetadataStore を使用して、アプリケーションの再起動後も MetadataStore の状態を維持できます。この新しい MetadataStore 実装は、次のようなアダプターで使用できます。

新しいキューベースのコンポーネントを追加しました。<int-redis:queue-inbound-channel-adapter/> および <int-redis:queue-outbound-channel-adapter/> コンポーネントを追加して、それぞれ Redis リストで「右ポップ」および「左プッシュ」操作を実行しました。

詳細については、"Redis サポート" を参照してください。

後で解決するために、応答チャネルとエラーチャネルをレジストリに保存するようにフレームワークに指示できるようになりました。これは、replyChannel または errorChannel が失われる可能性がある場合（たとえば、メッセージを直列化する場合）に役立ちます。詳細については、ヘッダーエンリッチャーを参照してください。

既存の eMongoDbMessageStore に加えて、新しい ConfigurableMongoDbMessageStore を導入しました。これにより、MongoDB 用の MessageStore のより堅牢で柔軟な実装が提供されます。既存のストアとの下位互換性はありませんが、新しいアプリケーションに使用することをお勧めします。既存のアプリケーションで使用できますが、古いストアのメッセージは使用できません。詳細については、MongoDb サポートを参照してください。

2.2 SyslogToMapTransformer に基づいて、Spring Integration 3.0 は、特に SYSLOG メッセージを受信するように調整された UDP および TCP 受信チャネルアダプターを導入します。詳細については、syslog サポートを参照してください。

テキストファイルの末尾に行が追加されたときに tail コマンドを使用してメッセージを生成するファイル受信チャネルアダプターを追加しました。 "tail" ファイルを参照してください。

<int-jmx:tree-polling-channel-adapter/> を追加しました。このアダプターは、JMX MBean ツリーにクエリを実行し、クエリに一致するオブジェクトのグラフであるペイロードを含むメッセージを送信します。デフォルトでは、MBean はプリミティブおよび単純なオブジェクト（Map、List、配列など）にマップされます。これにより、JSON などへの簡単な変換が可能になります。

IntegrationMBeanExporter では、naming-strategy 属性を使用してカスタム ObjectNamingStrategy を構成できるようになりました。

詳しくは、JMX サポートを参照してください。

TcpConnection インスタンスは、接続がオープンまたはクローズされたとき、または例外が発生したときに ApplicationEvent インスタンス（特に TcpConnectionEvent インスタンス）を発行するようになりました。この変更により、通常の Spring ApplicationListener メカニズムを使用して、アプリケーションに TCP 接続の変更を通知できます。

AbstractTcpConnection の名前を TcpConnectionSupport に変更しました。このクラスのサブクラスであるカスタム接続は、そのメソッドを使用してイベントを公開できます。同様に、AbstractTcpConnectionInterceptor の名前を TcpConnectionInterceptorSupport に変更しました。

さらに、<int-ip:tcp-connection-event-inbound-channel-adapter/> を追加しました。デフォルトでは、このアダプターはすべての TcpConnectionEvent インスタンスを Channel に送信します。

さらに、TCP 接続ファクトリは、現在開いているすべての接続の識別子のリストを返す getOpenConnectionIds() と呼ばれる新しいメソッドを提供します。これにより、アプリケーションは、特に使用中のすべての開いている接続にブロードキャストできます。

最後に、接続ファクトリは closeConnection(String connectionId) と呼ばれる新しいメソッドも提供します。これにより、アプリケーションは ID を使用して明示的に接続を閉じることができます。

詳細については、TCP 接続イベントを参照してください。

<int:inbound-channel-adapter/> は、<expression/> および <script/> 子要素を使用して MessageSource を作成できるようになりました。チャネルアダプターの式とスクリプトを参照してください。

コンテンツエンリッチャーは、<header/> 子要素の構成を提供し、基になるメッセージフローからの応答メッセージに基づいてヘッダーで送信メッセージを強化します。詳細については、ペイロードエンリッチャーを参照してください。

以前は、JDK UUID.randomUUID() メソッドを使用してメッセージ ID が生成されていました。このリリースでは、デフォルトのメカニズムが変更され、より効率的で非常に高速なアルゴリズムが使用されるようになりました。さらに、メッセージ ID の生成に使用される戦略を変更する機能を追加しました。詳細については、メッセージ ID 生成を参照してください。

すべてのゲートウェイメソッドに共通のヘッダーを設定できるようになり、どのメソッドが呼び出されたかに関する情報をメッセージに追加するためのオプションが追加されました。

ゲートウェイメソッド呼び出しをメッセージにマップする方法を完全にカスタマイズできるようになりました。

GatewayMethodMetadata は現在、パブリッククラスです。Java から GatewayProxyFactoryBean をプログラムで構成できます。

詳しくは、メッセージングゲートウェイを参照してください。

詳しくは、HTTP サポートを参照してください。

詳細については、Transformer の "JSONTransformers" を参照してください。

以前は、<chain> 内の要素の id 属性は無視され、場合によっては許可されませんでした。現在、<chain> 内のすべての要素に対して id 属性が許可されています。チェーン要素の Bean 名は、周囲のチェーンの id と要素自体の id の組み合わせです。例: "myChain$child.myTransformer.handler"。詳細については、メッセージハンドラーチェーンを参照してください。

AbstractCorrelatingMessageHandler は empty-group-min-timeout と呼ばれる新しいプロパティを提供し、空のグループの有効期限を部分的なグループの有効期限よりも長いスケジュールで実行できるようにします。空のグループは、少なくともこのミリ秒数の間変更されない限り、MessageStore から削除されません。詳細については、XML を使用したアグリゲーターの構成を参照してください。

永続的な MetadataStore を使用する新しい FileListFilter 実装が利用可能になりました。これらを使用して、システムの再起動後のファイルの重複を防ぐことができます。詳細については、ファイルを読む、FTP 受信チャネルアダプター、SFTP 受信チャネルアダプターを参照してください。

スクリプトコンポーネント用の新しい variables 属性を導入しました。さらに、インラインスクリプトで変数のバインドが許可されるようになりました。詳細については、Groovy サポートおよびスクリプトのサポートを参照してください。

以前は、チャンネルの dispatcher 子要素で LoadBalancingStrategy を構成するとき、利用可能な唯一のオプションは、開発者が LoadBalancingStrategy のカスタム実装を設定できない事前定義された値の列挙を使用することでした。load-balancer-ref を使用して、LoadBalancingStrategy のカスタム実装への参照を提供できるようになりました。詳細については、DirectChannel を参照してください。

以前は、サブスクライバーのない <publish-subscribe-channel/> に送信すると、false の結果が返されていました。MessagingTemplate と組み合わせて使用すると、例外がスローされます。現在、PublishSubscribeChannel には minSubscribers （デフォルト: 0）というプロパティがあります。メッセージが少なくとも最小数のサブスクライバーに送信された場合、送信操作は（数がゼロであっても）成功したと見なされます。これらの条件下でアプリケーションが例外を取得することが予想される場合、最小サブスクライバーを少なくとも 1 に設定します。

FTP、SFTP、FTPS エンドポイントは、デフォルトでセッションをキャッシュしなくなりました。

非推奨の cached-sessions 属性をすべてのエンドポイントから削除しました。以前は、この属性の値によって制御される組み込みキャッシュメカニズムは、キャッシュのサイズを制限する方法を提供していませんでした。キャッシュのサイズは無限に大きくなる可能性がありました。リリース 2.1 は CachingConnectionFactory を導入し、セッションをキャッシュするための推奨される（そして現在唯一の）方法になりました。

CachingConnectionFactory は、新しいメソッド resetCache() を提供するようになりました。このメソッドは、アイドル状態のセッションをすぐに閉じ、使用中のセッションがキャッシュに戻されるときに閉じられます。

DefaultSftpSessionFactory は（CachingSessionFactory と組み合わせて）単一の SSH 接続でのチャネルの多重化をサポートするようになりました（SFTP のみ）。

すべての送信ゲートウェイ（<jdbc:outbound-gateway/> や <jms:outbound-gateway/> など）は、「リクエストレスポンス」シナリオ用に設計されています。外部サービスからのレスポンスが予想され、reply-channel または replyChannel メッセージヘッダーに公開されます。ただし、外部システムが常に結果を返すとは限らない場合があります（たとえば、SELECT が空の ResultSet で終わる場合は <jdbc:outbound-gateway/> またはおそらく一方向の Web サービス）。そのため、開発者は返信が必要かどうかを設定するオプションが必要でした。この目的のために、送信ゲートウェイコンポーネントに requires-reply 属性を導入しました。ほとんどの場合、requires-reply のデフォルト値は true です。結果がない場合、ReplyRequiredException がスローされます。値を false に変更すると、外部サービスが何も返さない場合、送信チャネルアダプターと同様に、その時点でメッセージフローが終了します。

requiresReply プロパティは以前から存在していましたが、AbstractReplyProducingMessageHandler では false に設定されていたため、XML 名前空間を使用して送信ゲートウェイで設定する方法はありませんでした。

以前は、<int-amqp:outbound-gateway/> はメッセージコンバーターを呼び出す前にヘッダーをマップし、コンバーターは content-type などのヘッダーを上書きできました。送信アダプターは、変換後にヘッダーをマッピングします。つまり、送信 Message （存在する場合）からの content-type などのヘッダーが使用されます。

このリリース以降、ゲートウェイはメッセージ変換後にヘッダーをマップするようになり、アダプターと一致します。アプリケーションが以前の動作に依存している場合（コンバーターのヘッダーがマッピングされたヘッダーを上書きする場合）、それらのヘッダーをフィルタリングする（メッセージがゲートウェイに到達する前に）か、適切に設定する必要があります。SimpleMessageConverter の影響を受けるヘッダーは content-type と content-encoding です。カスタムメッセージコンバーターは他のヘッダーを設定できます。

標準の CallableStatement.getObject メソッドではサポートされていない、より複雑なデータベース固有の型については、OUT 方向の <sql-parameter-definition/> 要素に 2 つの新しい追加属性を導入しました。

ストアドプロシージャの受信チャネルアダプター <returning-resultset/> 子要素の row-mapper 属性は、RowMapper Bean 定義への参照をサポートするようになりました。以前は、クラス名のみが含まれていました（まだサポートされています）。

詳しくは、ストアドプロシージャーを参照してください。

Web サービスの送信ゲートウェイ 'uri' 属性は、Spring Web Services でサポートされるすべての URI スキームの <uri-variable/> 置換をサポートするようになりました。詳細については、送信 URI 設定を参照してください。

Redis 受信チャネルアダプターは、serializer プロパティに null 値を使用できるようになりました。生データはメッセージペイロードです。

Redis 送信チャネルアダプターには、topic-expression プロパティがあり、実行時に Message の Redis トピックを決定します。

Redis 受信チャネルアダプターは、既存の topics 属性に加えて、topic-patterns 属性を備えています。

詳しくは、Redis サポートを参照してください。

以前は、<filter/> に <request-handler-advice-chain/> があった場合、破棄アクションはすべて、アドバイスチェーンの範囲内で実行されました（discard-channel のダウンストリームフローを含む）。フィルター要素には、discard-within-advice （デフォルト: true）という属性があり、破棄アクションを実行できるようになりました after the アドバイスチェーンが完了します。アドバイスフィルターを参照してください。

リクエストハンドラーのアドバイスチェーンは、アノテーションを使用して構成できるようになりました。アノテーションを使用したエンドポイントへのアドバイスを参照してください。

このトランスフォーマーは、byte[] および char[] ペイロードを String に正しく変換します。詳細については、Transformer を参照してください。

持続またはマージするペイロードは、型 java.lang.Iterable (標準 Javadoc) (英語) になりました。

その場合、Iterable によって返された各オブジェクトはエンティティとして扱われ、基になる EntityManager を使用して永続化またはマージされます。イテレータから返された null 値は無視されます。

JPA アダプターには、永続操作を実行した後に、オプションで関連する永続コンテキストからエンティティをフラッシュおよびクリアするための追加属性があります。

ゲートウェイの取得には、取得する最初のレコードを指定するメカニズムがありませんでした。これは一般的な使用例です。検索ゲートウェイは、first-result および first-result-expression 属性をゲートウェイ定義に追加することにより、このパラメーターの指定をサポートするようになりました。詳細については、送信ゲートウェイの取得を参照してください。

JPA 取得ゲートウェイと受信アダプターには、結果セットの結果の最大数を式として指定する属性があります。さらに、非推奨となった max-number-of-results を置き換える max-results 属性を導入しました。max-results および max-results-expression は、それぞれ結果セット内の最大結果数または最大結果数を計算する式を提供するために使用されます。

詳しくは、JPA サポートを参照してください。

以前は、<delayer> は delay-header-name 属性を提供して、実行時の遅延値を決定していました。複雑なケースでは、<delayer> の前に <header-enricher> を付ける必要がありました。Spring Integration 3.0 は、動的遅延を決定するために expression 属性と expression 子要素を導入しました。expression でヘッダー評価を指定できるため、delay-header-name 属性は非推奨になりました。さらに、式の評価が失敗したときの動作を制御する ignore-expression-failures を導入しました。詳細については、遅延器を参照してください。

Spring Integration 3.0 は、MySQL バージョン 5.6.4 以降用の DDL スクリプトの新しいセットを追加します。MySQL は小数秒をサポートするようになり、MySQL ベースのメッセージストアからポーリングする際の FIFO の順序が改善されています。詳細については、汎用 JDBC メッセージストアを参照してください。

以前は、IMAP アイドル接続が失敗するとログに記録されましたが、アプリケーションに通知するメカニズムがありませんでした。このような例外により、ApplicationEvent インスタンスが生成されるようになりました。アプリケーションは、<int-event:inbound-channel-adapter> または ImapIdleExceptionEvent （またはそのスーパークラスの 1 つ）を受信するように構成された ApplicationListener を使用して、これらのイベントを取得できます。

TCP 接続ファクトリにより、選択されたヘッダー（およびペイロード）を TCP 経由で転送するための柔軟なメカニズムの構成が可能になりました。新しい TcpMessageMapper を使用すると、ヘッダーを選択できます。適切なシリアライザーまたはデシリアライザーを構成して、結果の Map を TCP ストリームに書き込む必要があります。TCP 経由でヘッダーとペイロードを転送する便利なメカニズムとして MapJsonSerializer を追加しました。詳細については、ヘッダーの転送を参照してください。

以前は、特定の TaskExecutor を使用する場合は、<message-driven-channel-adapter/> を構成するときに、コンテナー Bean を宣言し、container 属性を設定してアダプターに提供する必要がありました。task-executor を追加し、アダプターに直接設定できるようにしました。これは、すでに利用可能であった他のいくつかのコンテナー属性に追加されます。

RMI 受信ゲートウェイは、error-channel 属性をサポートするようになりました。受信 RMI を参照してください。

transformer-factory-class 属性を設定して、トランスフォーマーファクトリクラス名を指定できるようになりました。XsltPayloadTransformer を参照してください。

Spring Integration に RedisStore 受信および送信チャネルアダプターが追加され、Redis コレクションとの間で Message ペイロードを読み書きできるようになりました。詳細については、RedisStore 送信チャネルアダプターおよび Redis ストア受信チャネルアダプターを参照してください。

Spring Integration には MongoDB 受信および送信チャネルアダプターがあり、MongoDB ドキュメントストアとの間で Message ペイロードを読み書きできるようになりました。詳細については、MongoDB 送信チャネルアダプターおよび MongoDB 受信チャネルアダプターを参照してください。

Spring Integration には、JPA エンティティオブジェクトを取得および永続化する Java Persistence API（JPA）のコンポーネントが含まれるようになりました。JPA アダプターには、次のコンポーネントが含まれています。

詳しくは、JPA サポートを参照してください。

Spring Integration は Spring 3.1 を使用するようになりました。

<advice-chain/> をポーラーに追加する機能はしばらくの間利用可能です。ただし、これによって追加される動作は、統合フロー全体に影響します。個々のエンドポイントに（たとえば）再試行を追加する機能については言及していません。2.2 リリースは、多くのエンドポイントに <request-handler-advice-chain/> を導入しました。

さらに、この目的のために 3 つの標準アドバイスクラスを追加しました。

詳しくは、エンドポイントへの動作の追加を参照してください。

ポーラーは、Spring のトランザクション同期機能に参加できるようになりました。これにより、トランザクションがコミットするかロールバックするかに応じて、受信チャネルアダプターによるファイル名の変更などの操作を同期できます。

さらに、PseudoTransactionManager を使用して、「実際の」トランザクションが存在しないときにこれらの機能を有効にできます。

詳しくは、トランザクションの同期を参照してください。

ファイル送信チャネルアダプターまたはファイル送信ゲートウェイを使用する場合、新しい mode プロパティを使用できます。Spring Integration 2.2 より前のバージョンでは、ターゲットファイルが存在する場合、それらが置き換えられました。これで、次のオプションを指定できます。

詳しくは、既存の宛先ファイルの処理を参照してください。

XML 名前空間のサポートにより、reply-timeout 属性が次の送信ゲートウェイに追加されます。

Spring Integration は Spring AMQP 1.1 を使用するようになりました。これにより、Spring Integration アプリケーション内で次のようないくつかの機能を使用できます。

JDBC 送信ゲートウェイを使用する場合、更新クエリは必須ではなくなりました。リクエストメッセージをパラメーターのソースとして使用して、選択クエリのみを提供できるようになりました。

新しいメッセージチャネル固有のメッセージストア実装を追加し、データベース固有の SQL クエリを使用したよりスケーラブルなソリューションを提供しました。詳細については、バッキングメッセージチャネルを参照してください。

stopActiveComponents() というメソッドを IntegrationMBeanExporter に追加しました。これにより、Spring Integration アプリケーションを正常にシャットダウンし、特定のアダプターへの新しい受信メッセージを許可せず、飛行中のメッセージが完了するまでしばらく待つことができます。

これで、MessageListener コンテナーを使用して応答を受信するように JMS 送信ゲートウェイを構成できます。そうすることで、ゲートウェイのパフォーマンスを改善できます。

デフォルトでは、ObjectToJsonTransformer は content-type ヘッダーを application/json に設定するようになりました。詳細については、Transformer を参照してください。

HTTP を介した Java 直列化は、デフォルトでは無効になっています。以前は、Serializable オブジェクトに expected-response-type を設定するときに、Accept ヘッダーが正しく設定されていませんでした。SerializingHttpMessageConverter を更新して、Accept ヘッダーを application/x-java-serialized-object に設定しました。ただし、これにより既存のアプリケーションとの非互換性が生じる可能性があるため、このコンバーターを HTTP エンドポイントに自動的に追加しないことにしました。

Java 直列化を使用する場合は、message-converters 属性（XML 構成を使用する場合）または setMessageConverters() メソッド（Java）を使用して、SerializingHttpMessageConverter を適切なエンドポイントに追加する必要があります。

または、代わりに JSON の使用を検討することもできます。クラスパスに Jackson を置くことで有効になります。

Spring Integration 2.0 では、Groovy (英語) のサポートを追加しました。Spring Integration 2.1 では、JSR-223 (英語) （「Java ™プラットフォームのスクリプト」）のサポートを実装することにより、追加の言語のサポートを大幅に拡張しました。これで、JSR-223 をサポートする次のようなスクリプト言語を使用できるようになります。

詳細については、スクリプトのサポートを参照してください。

Spring Integration は、エントリおよび連続照会イベント用の受信・アダプター、エントリをキャッシュに書き込む送信・アダプター、MessageStore (Javadoc) および MessageGroupStore (Javadoc) 実装を提供することにより、GemFire のサポートを提供します。Spring 統合は、Spring Gemfire プロジェクトを活用して、コンポーネントの薄いラッパーを提供します。

詳細については、重要な GemFire および Apache Geode サポートを参照してください。

Spring Integration 2.1 は、高度なメッセージキュープロトコル (英語) （AMQP）を使用してメッセージを送受信するためのいくつかのチャネルアダプターを追加しました。さらに、Spring Integration は、ポイントツーポイントメッセージチャネルとパブリッシュサブスクライブメッセージチャネルも提供します。どちらも AMQP Exchange とキューによってサポートされています。

詳細については、AMQP サポートを参照してください。

バージョン 2.1 の時点で、Spring Integration は MongoDB ベースの MessageStore を提供することにより、MongoDB (英語) のサポートを提供します。

詳細については、MongoDb サポートを参照してください。

バージョン 2.1 の時点で、Spring Integration は、Redis ベースの MessageStore およびパブリッシュ / サブスクライブメッセージングアダプターを提供することにより、高度なキーバリューストアである Redis (英語) をサポートします。

詳細については、Redis サポートを参照してください。

バージョン 2.1 では、Spring のリソース抽象化に基づいて構築される新しいリソース受信チャネルアダプターを導入し、ファイル、URL、クラスパスリソースなど、さまざまな実際の型の基礎となるリソース全体の柔軟性をサポートします。ファイル受信チャネルアダプターに似ていますが、より一般的です。

詳細については、リソース受信チャネルアダプターを参照してください。

Spring Integration 2.1 を使用すると、JDBC モジュールは、受信および送信のチャネルアダプターや送信ゲートウェイなどのいくつかの新しいコンポーネントを追加することで、ストアドプロシージャのサポートも提供します。ストアドプロシージャのサポートは、Spring の SimpleJdbcCall (Javadoc) クラスを活用し、その結果、次のストアドプロシージャをサポートします。

ストアドプロシージャコンポーネントは、次のデータベースの SQL 関数もサポートしています。

詳細については、ストアドプロシージャーを参照してください。

Spring Integration 2.1 は、新しい XPath ベースのメッセージフィルターを提供します。XML モジュールの一部です。XPath フィルターを使用すると、XPath 式を使用してメッセージをフィルター処理できます。XML 検証フィルターのドキュメントも追加しました。

詳細については、XPath フィルターの使用および XML 検証フィルターを参照してください。

Spring Integration 2.1 以降、ペイロードエンリッチャーを追加しました。ペイロードエンリッチャーは、公開されたリクエストチャネルに通常 Message (Javadoc) を渡し、応答メッセージを予期するエンドポイントを定義します。次に、応答メッセージは、式を評価してターゲットペイロードを強化するためのルートオブジェクトになります。

詳細については、ペイロードエンリッチャーを参照してください。

Spring Integration 2.1 は、リモートファイル転送プロトコル（FTP）またはセキュアファイル転送プロトコル（SFT）サーバーと対話するための 2 つの新しい送信ゲートウェイを提供します。これら 2 つのゲートウェイを使用すると、リモートコマンドの限られたセットを直接実行できます。

たとえば、これらの送信ゲートウェイを使用して、リモートファイルをリスト、取得、削除し、Spring Integration メッセージの流れをリモートサーバーのレスポンスで継続させることができます。

詳細については、FTP 送信ゲートウェイおよび SFTP 送信ゲートウェイを参照してください。

バージョン 2.1 の時点で、リモートファイルアダプター（FTP、SFTP など）のセッション管理に関して、より柔軟に対応しています。

具体的には、cache-sessions 属性を廃止しました（XML 名前空間のサポートを介して利用可能です）。別の方法として、sessionCacheSize および sessionWaitTimeout 属性を CachingSessionFactory に追加しました。

詳細については、FTP セッションキャッシングおよび SFTP セッションキャッシングを参照してください。

より一貫したユーザーエクスペリエンスを提供するために、Spring Integration 2.1 を使用してすべてのルーター実装にわたってルーターパラメーターを標準化しました。

Spring Integration 2.1 では、ignore-channel-name-resolution-failures 属性を削除して、その動作を resolution-required 属性に統合しました。また、resolution-required 属性のデフォルトは true になりました。

Spring Integration 2.1 以降、デフォルトの出力チャネルが定義されていない場合、ルーターはメッセージを表示することなくメッセージをドロップしなくなりました。つまり、デフォルトでは、ルーターは少なくとも 1 つの解決済みチャネルを必要とし（default-output-channel が設定されていない場合）、チャネルが決定されなかった（または送信の試行が成功しなかった）場合、デフォルトで MessageDeliveryException をスローします。

ただし、メッセージをサイレントにドロップする場合は、default-output-channel="nullChannel" を設定できます。

詳細については、Routers を参照してください。

Spring Integration 2.1 には、更新された XML スキーマ (バージョン 2.1) が付属しています。前述した Router の標準化など、多くの改善が加えられています。

今後、開発者は常に最新の XML スキーマ（現在のバージョン 2.1）を宣言する必要があります。または、バージョンなしのスキーマを使用できます。一般的に、最良のオプションは、バージョンなしの名前空間を使用することです。これらは、Spring Integration の利用可能な最新バージョンを自動的に使用するためです。

次の例では、バージョンのない Spring Integration 名前空間を宣言しています。

次の例では、明示的なバージョンで Spring Integration 名前空間を宣言しています。

古い 1.0 および 2.0 スキーマはまだあります。ただし、アプリケーションコンテキストがこれらの非推奨スキーマのいずれかをまだ参照している場合、バリデーターは初期化に失敗します。

バージョン 2.0 以降、Spring Integration プロジェクトはバージョン管理に Git (英語) を使用します。コミュニティの可視性をさらに高めるために、プロジェクトは SpringSource がホストする Git リポジトリから Github (英語) に移動されました。Spring Integration Git リポジトリは、spring-integration にあり [GitHub] (英語) ます。

このプロジェクトでは、コードの提供プロセスも改善しました。さらに、すべてのコミットがピアレビューされるようにします。実際、コアコミッターはコントリビューターと同じプロセスに従います。詳細については、コントリビュートする [GitHub] (英語) を参照してください。

ソースコードの可視性を向上させ、結果として Spring Integration のソースコードの品質を監視するために、ソナー (英語) のインスタンスを設定しました。メトリクスを毎晩収集し、sonar.spring.io (英語) で利用できるようにします。

データ型チャネル (英語) などの多くの Spring Integration コンポーネントを構成しながら、Spring で提供される変換サービスのサポートを利用できるようになりました。メッセージチャネルの実装およびサービスアクティベーターを参照してください。また、前のポイントで述べた SpEL サポートも変換サービスに依存しています。コンバーターを一度登録すると、SpEL 式を使用する場所であればどこでも利用できます。

Spring 3.0 は、スケジューリングに関連する 2 つの新しい戦略 TaskScheduler と Trigger を定義しています。Spring Integration（これは多くのスケジューリングを使用します）はこれらに基づいています。実際、Spring Integration 1.0 は元々一部のコンポーネント（CronTrigger など）を定義しており、現在は Spring 3.0 のコア API に移行されています。これで、（Spring Integration 構成だけでなく）アプリケーションコンテキスト全体で同じコンポーネントを再利用するメリットが得られます。また、レート、遅延、cron 式、トリガー参照を直接構成するための属性を提供することにより、Spring Integration ポーラーの構成を大幅に簡素化しました。構成例については、チャンネルアダプターを参照してください。

送信 HTTP アダプターは、Spring の RestTemplate に委譲して、HTTP リクエストを実行し、そのレスポンスを処理します。これは、カスタム HttpMessageConverter 実装を再利用できることも意味します。詳細については、HTTP 送信コンポーネントを参照してください。

メッセージ履歴 (英語) パターンをサポートするようになりました。これにより、各チャネルとエンドポイントの名前、そのトラバースのタイムスタンプなど、トラバースされたすべてのコンポーネントを追跡できます。詳細については、メッセージ履歴を参照してください。

メッセージストア (英語) パターンのサポートを提供するようになりました。メッセージストアは、アグリゲーターやリシーケンサーなど、スコープが単一のトランザクションを超えて広がるプロセスに代わってメッセージを永続化するための戦略を提供します。このガイドの多くのセクションには、Spring Integration のいくつかの領域に影響するため、メッセージストアの使用方法のサンプルが含まれています。詳細については、メッセージストア、クレームチェック、メッセージチャンネル、アグリゲーター、JDBC サポート `"、およびリシーケンサーを参照してください。

クレームチェック (英語) パターンの実装を追加しました。クレームチェックパターンの背景となる考え方は、メッセージペイロードを「クレームチケット」と交換できるということです。これにより、帯域幅を削減し、チャネル間でメッセージを送信する際の潜在的なセキュリティ課題を回避できます。詳細については、クレームチェックを参照してください。

制御バス (英語) パターンの実装を提供しており、メッセージングを使用してエンドポイントとチャネルを管理および監視できます。実装には、SpEL ベースのアプローチと Groovy スクリプトを実行するアプローチの両方が含まれます。詳細については、制御バスおよび制御バスを参照してください。

TCP および UDP インターネットプロトコルを介してメッセージを送受信するためのチャネルアダプターを追加しました。詳細については、TCP および UDP のサポートを参照してください。次のブログも参照してください: “Spring Integration 2.0 M3 での UDP および TCP アダプターの使用” (英語) 。

Twitter アダプターは、Twitter ステータスの更新とダイレクトメッセージの送受信をサポートします。受信チャネルアダプターを使用して Twitter 検索を実行することもできます。詳細については、Spring Integration ソーシャル Twitter [GitHub] (英語) を参照してください。

新しい XMPP アダプターは、チャットメッセージとプレゼンスイベントの両方をサポートします。詳細については、XMPP サポートを参照してください。

FTP および FTPS を介した受信および送信のファイル転送サポートが利用可能になりました。詳細については、FTP/FTPS アダプターを参照してください。

SFTP を介した受信および送信のファイル転送サポートが利用可能になりました。詳細については、SFTP アダプターを参照してください。

ニュースフィード（ATOM および RSS）を受信するためのチャネルアダプターも追加しました。詳細については、フィードアダプターを参照してください。

Spring Integration 2.0 は Groovy サポートを追加し、Groovy スクリプト言語を使用して統合およびビジネスロジックを提供できるようにしました。詳細については、Groovy サポートを参照してください。

これらの対称トランスフォーマーは、ペイロードオブジェクトを Map オブジェクトとの間で変換します。詳細については、Transformer を参照してください。

これらの対称トランスフォーマーは、ペイロードオブジェクトと JSON を相互に変換します。詳細については、Transformer を参照してください。

これらの対称トランスフォーマーは、ペイロードオブジェクトをバイト配列との間で変換します。また、Spring 3.0.5 が追加したシリアライザおよびデシリアライザ戦略インターフェースもサポートしています。詳細については、Transformer を参照してください。