1.6 以降の 1.7 の変更点

AMQP クライアントライブラリ

Spring AMQP は、RabbitMQ チームが提供する amqp-client ライブラリの新しい 4.0.x バージョンを使用するようになりました。このクライアントには、デフォルトで自動回復が構成されています。RabbitMQ 自動接続 / トポロジリカバリを参照してください。

4.0.x クライアントは、デフォルトで自動回復を有効にします。この機能と互換性がありますが、Spring AMQP には独自の回復メカニズムがあり、通常、クライアント回復機能は必要ありません。ブローカーが使用可能であるが接続がまだ回復していない場合に AutoRecoverConnectionNotCurrentlyOpenException インスタンスを取得しないように、amqp-client 自動回復を無効にすることをお勧めします。バージョン 1.7.1 以降、独自の RabbitMQ 接続ファクトリを明示的に作成して CachingConnectionFactory に提供しない限り、Spring AMQP はそれを無効にします。RabbitConnectionFactoryBean によって作成された RabbitMQ ConnectionFactory インスタンスでも、このオプションはデフォルトで無効になっています。

Log4j 2 アップグレード

Log4j 2 の最小バージョン ( AmqpAppender の場合) は 2.7 になりました。フレームワークは以前のバージョンと互換性がなくなりました。詳細については、ロギングサブシステム AMQP アペンダを参照してください。

Logback アペンダー

このアペンダーは、デフォルトでは呼び出し元データ (メソッド、行番号) をキャプチャーしなくなりました。includeCallerData 構成オプションを設定することで、再度有効にすることができます。利用可能なログアペンダについては、ロギングサブシステム AMQP アペンダを参照してください。

Spring Retry アップグレード

最小の Spring Retry バージョンは 1.2 になりました。フレームワークは以前のバージョンと互換性がなくなりました。

シャットダウン動作

forceCloseChannel を true に設定できるようになりました。これにより、コンテナースレッドが shutdownTimeout 内のシャットダウンに応答しない場合、チャネルが強制的に閉じられ、確認応答されていないメッセージが再キューイングされます。詳細については、メッセージリスナーコンテナーの設定を参照してください。

FasterXML Jackson アップグレード

最小の Jackson バージョンは 2.8 になりました。フレームワークは以前のバージョンと互換性がなくなりました。

JUnit @Rules

以前はフレームワークによって内部的に使用されていたルールは、spring-rabbit-junit と呼ばれる別の jar で使用できるようになりました。詳細については、JUnit4 @Rules を参照してください。

コンテナーの条件付きロールバック

外部トランザクションマネージャー (JDBC など) を使用する場合、コンテナーにトランザクション属性を指定すると、ルールベースのロールバックがサポートされるようになりました。また、トランザクションアドバイスを使用する際の柔軟性も向上しました。

接続の命名方法

AbstractConnectionFactory からのターゲット RabbitMQ 接続のアプリケーション固有の ID を取り込むために、新しい ConnectionNameStrategy が提供されるようになりました。詳細については、接続とリソースの管理を参照してください。

リスナーコンテナーの変更

トランザクションのロールバック動作

トランザクションマネージャーが構成されているかどうかに関係なく、トランザクションロールバックでのメッセージの再キューイングを一貫性を保つように構成できるようになりました。詳細については、受信メッセージのロールバックに関する注意を参照してください。

JUnit4 @Rules

Spring AMQP バージョン 1.7 以降では、spring-rabbit-junit と呼ばれる追加の jar が提供されます。この jar には、JUnit4 テストの実行時に使用するユーティリティ @Rule インスタンスがいくつか含まれています。JUnit5 のテストについては、JUnit5 条件を参照してください。

BrokerRunning を使用する

BrokerRunning は、ブローカーが実行されていない場合 (デフォルトでは localhost 上) にテストを成功させるメカニズムを提供します。

また、キューを初期化して空にし、キューと交換を削除するためのユーティリティメソッドもあります。

次の例は、その使用箇所を示しています。

@ClassRule
public static BrokerRunning brokerRunning = BrokerRunning.isRunningWithEmptyQueues("foo", "bar");

@AfterClass
public static void tearDown() {
    brokerRunning.removeTestQueues("some.other.queue.too"); // removes foo, bar as well
}

ブローカーで管理プラグインが有効になっていることを確認する isBrokerAndManagementRunning() など、いくつかの isRunning…​ 静的メソッドがあります。