Consider a Mechanism to Convey @RabbitListener Parameter Type to Jackson2JsonMessageConverter [AMQP-549]

[spring-operator]

Gary Russell opened AMQP-549 and commented

Slack conversation:

We are using @RabbitListener, and would like to ignore __TypeId__ and instead use the class which the listener expects

an example would be that the publisher sends a com.example.publisher.Patient message, and we would like the consumer to deserialize a com.example.consumer.Patient.

is this possible?

...

For JSON, the inbound converter needs to know what object to create. There's nothing inherent in JSON to help. If you don't use the typeid header you need some other mechanism. If it's always the same type, you can use a class mapper. Otherwise you need to convey type info in the message.

...

Invoking the @RabbitListener is downstream of the conversion so the method signature can't be used to select the type. You have to configure the converter and inject it into the container factory.

...

Since you are (or seem to be) using JSON, I presume you already figured out how to configure the JSON message converter in the listener container factory (ref). The Jackson2JsonMessageConverter has a property classMapper. You can inject a DefaultClassMapper with its defaultType set to your Patient class. This will support messages with a single payload type. As I said, if the queue contains messages with different payload types, you will need to convey the type with the message; the converter is quite flexible as to how to do that (aside from the default __TypeId__ header); then, you can use the multi-method listener that Artem Bilan pointed you to.

I have some ideas (for a single method @RabbitListener) as to how we might be able to provide the type information implicitly, but it’s not supported at this time.

Some possibilities:

1. Add converter to the @RabbitListener so the converter can more easily be configured per listener rather than having to configure a separate container factory for each that needs a different converter.

2. Somehow convey the parameter type (either non-annotated or @Payload ) to a TypeCapableMesssageConverter. (This would require a converter factory so each container gets a specific instance).

#2 might be combined with a more friendly way of configuring the @SendTo for replies where the inbound has no replyTo. Currently, because of the separation of concerns, this uses a ThreadLocal to convey the replyTo back to the listener adapter.

---

Issue Links:

• Make target type available to MessageConverter if it can be derived from available handler methods [AMQP-586] #2142 Make target type available to MessageConverter if it can be derived from available handler methods
  ("is duplicated by")
• convert to different javatype when use @RabbitListener annonation [AMQP-461] #2018 convert to different javatype when use @RabbitListener annonation

Referenced from: pull request #390