2.2 および 3.0 間の変更

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 を追加し、アダプターに直接設定できるようにしました。これは、すでに利用可能であった他のいくつかのコンテナー属性に追加されます。

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