Marten Deinum opened SPR-16958 and commented

When using messaging there are MessageConverter implementations using Jackson to marshall message from/to JSON. However there doesn't seem to be one for GSON whereas there is GSON support in the web area. 

Now when using both messaging and web and when using GSON and want to use JSON for marshaling you need both providers on the class path. It would be nice if we could use GSON in the messaging area as well. 

Affects: 5.0.7

Referenced from: pull request https://github.com/spring-projects/spring-framework/pull/1863

Comment From: spring-projects-issues

Marten Deinum commented

Pull request available. 

Including: * Central management of GSON dependency * JMS based MessageConverter (introduced a base class for both GSON and Jackson based MessageConverter s * Generic MessageConverter * Tests

Comment From: fo0

pretty nice feature, any plans for merge/integration?

Comment From: gaxpay

I would love to see this included! Great contribution @mdeinum 👍

Comment From: jhoeller

In the meantime, we don't just have GSON to deal with but also JSON-B with Apache Johnzon as the common implementation. The number of message converter implementations would rise significantly... and I'm not sure all of them are destined to be first-class citizens in a 2020 scenario.

Which variants are you specifically interested in? If it is indeed GSON, would it be the JMS variant or the spring-messaging variant?

Comment From: mdeinum

I assume the question is for @gaxpay and not me. But the initial contribution was to align the supported JSON implementation from the web to messaging (and JMS) as well. Isn't it a bit strange to support something for the web but not for messaging in regards to first-class citizens? Wouldn't that also be a source of problems, especially in regards to auto-configuration as which JSON implementation would be used (GSON for the web and Jackson for messaging?).

Currently, it might make more sense to place them in spring-messaging instead of spring-jms for a broader application. The messaging ones can be adapted to JMS quite easily, the other way around not so much.

Comment From: jhoeller

The inconsistency is definitely worth addressing in some form; I just wonder where to draw the line.

The Jackson JMS converter is a bit special in terms of its type id handling, inferring the JSON type from the JMS message itself, whereas the spring-messaging converter arrangement assumes an explicit target class being given by the caller (like the web converter abstraction). I'm not sure about extending the JMS arrangement there at this late point, not least of it all because it is being mirrored in the Spring AMQP project where there is Jackson support with the same type id arrangement.

On a related note, we recently added Protobuf and Protobuf-JSON converter to spring-messaging (#24022), aligning with the ones in spring-web. From that perspective, adding GSON and JSON-B converters there as well would make a lot of sense from a consistency perspective. I'll see what we can do about that for 5.3 RC2 still.

Comment From: gaxpay

My view of it was the same as mentioned above, namely consistency across borders of web vs messaging and the auto-configurations. The proposed road ahead for aligning spring-messaging and spring-web makes sense.

Comment From: jhoeller

I've repurposed this issue for the Gson / JSON-B (Apache Johnzon) alignment in spring-messaging, with the primary target being WebSocket support. My local implementations are designed with a common base class, similar to the arrangement in spring-web, and similarly included in our default WebSocket configuration based on classpath presence. To be committed ASAP.