@MessageMapping should support generically typed Message argument with converted payload [SPR-13288]

[spring-projects-issues]

pascal gehl opened SPR-13288 and commented

I have a @Controller method wired with a @MessagingGateway annotated service.

@MessageMapping(value = "/messages/save")
public void save(Message<ToBeSaved> msg) {
     service.save(msg);
 }

Unfortunately this does not work; I get

SimpAnnotationMethodMessageHandler -- Unhandled exception
MethodArgumentTypeMismatchException: Could not resolve method parameter at index 0 in method: public void MyEndpoint.save(Message<ToBeSaved>) The expected Message<?> payload type [ToBeSaved] does not match the actual payload type [[B]
	at org.springframework.messaging.handler.annotation.support.MessageMethodArgumentResolver.resolveArgument(MessageMethodArgumentResolver.java:59)

After investigation generic Message<CustomClass> is not understood as being a Message instance with ToBeSaved payload class but only Message<?> with Byte[] payload.

It would be nice if MessageMethodArgumentResolver was able to use MessageConverter the same way PayloadArgumentResolver can.

---

Affects: 4.1.7

Issue Links:

• JsonView support for JMS [SPR-13237] #17828 JsonView support for JMS
• Jackson @JsonView deserialization support for @MessageMapping payloads [SPR-13265] #17856 Jackson @JsonView deserialization support for @MessageMapping payloads
• Missing MessageMethodArgumentResolver default constructor [SPR-14616] #19183 Missing MessageMethodArgumentResolver default constructor
• AMQP-582 The MethodRabbitListenerEndpointTests.invalidMessagePayloadType() isn't compatible with SF-4.3

Referenced from: commits 416966d

1 votes, 7 watchers

[spring-projects-issues]

Juergen Hoeller commented

This actually goes even further: We don't support Message return types either, in particular not with to-be-converted payload objects. Both the incoming and the outgoing side are therefore limited in comparison to our @JmsListener model where do support application-level Message<MyPayload> handles for both purposes.

We intend to do a comprehensive revision for 4.3 here, bringing the JMS endpoint model and the STOMP endpoint model in sync to the best possible degree.

[spring-projects-issues]

Rossen Stoyanchev commented

With STOMP handling, the (Spring) Message which passes through message channels also contains processing headers, e.g. Principal, session attributes, etc (see SimpMessageHeaderAccessor) as well as STOMP native headers from the client. So in addition to converting the payload, we could also ensure the Message passed into the method contains only the STOMP headers that came from the client. Just wondering if that make sense for your use case?

[spring-projects-issues]

pascal gehl commented

some additional details: I have found a workaround using

@MessageMapping(value = "/messages/save")
public void save(@Payload ToBeSaved payload, @Headers MessageHeaders headers) {
     service.save(toMsg(payload, headers));
 }

protected <P> Message<P> toMsg(P payload, MessageHeaders headers) {
        return  org.springframework.messaging.support.MessageBuilder.createMessage(payload, headers);
}

This JIRA would save me the trouble to "decompose" the incoming message into @Payload and @Headers to later recreate a Message with them.

I'm actually happy with all the headers, not only STOMP ones, since my IntegrationFlow does access Principal header (simpUser if I recall correctly)

[spring-projects-issues]

Rossen Stoyanchev commented

Okay good to know, thanks.

[spring-projects-issues]

Rossen Stoyanchev commented

MessageMethodArgumentResolver now supports payload conversion.