If consumer and producer agree on the content type of a message coercion should be automatic

If a consumer and producer don’t specify a content type (via spring.cloud.stream.bindings.*.contentType) then as long as they share a class definition for the payload (a domain object) then the message will flow. That’s uncomfortable for 2 reasons: first it forces them to share the domain class (or have an identical class with the same FQCN), and second it uses a default content type which is not interopable (Java serialization basically, not JSON or protobuf or whatever).

As soon as you specify the content type (e.g. as application/json for interop / human readable messages), the system breaks because JSON gets converted to a String and the receiver can’t process it as a domain object any more (he has to manually convert the String to a domain object, going through 2 layers of conversion, from String to JSON to Object).

I propose that if the consumer and producer agree on the content type (e.g. application/json) then Spring Cloud Stream (or Spring Integration) should be able to handle the conversion and type coercion.

Marius has pointed out that you have a similar situation in REST endpoints where the solution is HttpMessageConverters that are mime-type as well as Java type aware. The payload is essentially bytes (or Strings) as far as the “dumb pipes” model is concerned (Spring Cloud Stream), but it carries content type headers, a bit like an HTTP request.

[artembilan]

The @Filter and other Messaging Annotations configuration, or even better - any POJO method invocation, will support content negotiation since Spring Integration 5.0: https://jira.spring.io/browse/INT-4225

[dsyer]

@Filter is not a Spring Cloud Stream annotation. It does not support content negotiation.