Spring amqp @RabbitListenerランタイム型の問題

Question

spring-amqpでnice @RabbitHandlerアノテーションを使用して、RestControllersのコーディングスタイルに似ていますが、フードの下でRabbitで動作するエンドポイントを作成しています。そのすべては非常に素晴らしく、すっきりしていて、シグネチャに基づいたメソッドハンドラの動的分解能が特に優れています。しかし、我々はここで少しの論争に直面している。 だから、次のような方法

@RabbitHandler 
public void handleEmailDto(EmailDto message) { 
    System.out.println(message); 
} 

これはMessagingMessageConverter.javaクラスにfromMessageメソッドによって処理されます想像してみてください。チェーンのある点では、ハンドラリゾルバがどのメソッドをメッセージのペイロードで呼び出すか、そしてペイロードをどのクラスにシリアライズするかを決定するために、メッセージの型情報が必要になります。問題は、MappingJackson2MessageConverterを使用していることです。それにもかかわらず、クラスの型の完全修飾名を使用して、メッセージの入力済みの____TypeId____小文字が必要です。それは問題でもない。非常にうまく設計され、考え出されています。

このクラスがクラスパス上にないと問題が発生します。これは実際にはマイクロサービス環境で作業しており、一部のサービスは完全に分離されているため、大きな苦痛です。つまり、私たちはデータドメインを保持する「共通の」アーチファクトを持ちたくないので、メッセージの送信者と受信者の両方で実行時に使用できます。コードをたどって、このホール型の状況がどのように処理されているのか、それがどのように行われているのかを確認します。

しかし、アーキテクチャ上の観点からすれば、これは非常に限定的です...つまり、シリアライゼーション/デシリアライズ/メソッド解決ロジックを満たすために、まったく分離されたマイクロサービス間でコードを共有する必要がありますか？

多分私は何かを見逃している、またはそれをやっている別の方法を見落としているかもしれません。そのような場合は、私は確かに提案に開かれています。助けを前にありがとう。

Answer 1

1.6はnew featureです。@RabbitListenerの引数タイプは、タイプIDヘッダーの代わりに使用できるJSONメッセージコンバータに供給されます。

残念ながら、のペイロードが変換された後にハンドラ方法がと決定されるため、このメカニズムは@RabbitHandlerとは機能しません。

クラスパスにソースタイプは必要ありません。異なるタイプを使用するようにコンバータを設定できます。 Foo1を送信し、Foo2を受け取る例については、this test caseを参照してください。

リスナーはhere、カスタマイズされたコンバーターを使用するリスナーファクトリの設定はhereです。 idClassMappingがFoo2タイプに変換されるように設定されている方法をご覧ください。

明らかに、タイプはソースタイプと互換性がなければなりませんが、同じクラスである必要はありません。