AWS SQS support more flexible deserialization

[kerkhofsd]

version: smallrye-reactive-messaging-aws-sqs:4.24.0

Observed behaviour

Deserialization of SQS body/payload is tightly coupled to the _classname message attribute.
Observations for deserialization to a Message<T> instance:

• If the _classname attribute is not present, the payload is deserialized as a String. ( Documented )
• If the _classname attribute is present, default deserialization is possible only to the exact class referenced in the key of this value. Will result in a ClassNotFoundException if it's not available.

Desired behaviour

It would be nice to provide a bit more flexibility here. Ideally, allowing a deserialization for any Class<T> available in the consuming application classpath. (Assuming ofcourse the message body can be deserialized to that specific class.)

Arguments:

• As far as I can tell the propagation of the _classname SQS attribute is a custom concept, introduced by this library?
• AS-IS behaviour tightly couples consumers to producers, expecting the use of identical classes / package structure / technology?

Workaround

I'm currently using following workaround:

1. Include custom SqsReceiveMessageRequestCustomizer to bypass the hardcoded inclusion of _classname header.

@Identifier("my-customizer")
@ApplicationScoped
public class IgnoreClassnameSqsReceiveMessageRequestCustomizer implements SqsReceiveMessageRequestCustomizer {

    @Override
    public void customize(ReceiveMessageRequest.Builder builder) {
        builder.messageAttributeNames(Collections.emptyList());
    }
}

3. Consume Message<String>
4. Manual deserialization from String to "type T" using ObjectMapper