-
-
Notifications
You must be signed in to change notification settings - Fork 312
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable sending String payloads with JSON content type in SqsTemplate #1144
Comments
@tomazfernandes Below is the code I used, with some modifications from the SQS sample code in this project.
Can you tell me if there's something wrong with my code or give me an example of a situation where it would be double serialize? |
@imsosleepy, please try to receive a |
@tomazfernandes After modifying the code as per your advice, I proceeded to test it again.
Then, I am getting the error message below.
However, this seems to be natural: the error message says that the jsonString and the SampleRecord don't match. Still, double serialization didn't occur. I think I need a more detailed guide. |
@imsosleepy I get a different error here:
I remember seeing the double serialization at some point, but I might have got it wrong, or it might only happen with some specific configuration. But that's ok - the overall goal is to be able to send raw JSON with the template and have it be properly deserialized to a POJO / record in the listener, requiring as few changes / configurations as possible. Please let me know if that helps. Thanks. |
@tomazfernandes I identified what the issue was and created a PR that fixed it. This issue was not a case of double serialization, but simply an incorrectly created String that could not be deserialized to an Object. Please see the images below.
To fix this issue, I implemented the getPayloadToDeserialize method of MessagingMessageConverter to create the body of the message as an ObjectNode and then convert it back to a String. However, I need to verify if it is appropriate to have an ObjectMapper in its current location. Further testing might be necessary, but I would appreciate any advice on the best location for it. I may need to test it further, but I would appreciate any advice on where to put it. The PR is here : #1168 |
Hey @imsosleepy, Perhaps a better way would be making the Would it be possible for you to create an integration test to assert this solution in fact resolves the problem? Also, since this is an edge case, it would probably be best if we could only do this extra step if necessary. Let me know your thoughts, thanks. |
Hey @imsosleepy, looking at this again, I wonder if maybe the right way to go would be making it so that the message is not sent with the line breaks. Otherwise we may fix this for our listeners, but if the message is read by a consumer using other language / library that can't read both formats it might get confusing. We'd need to check what exactly is adding the line breaks and make sure they're not added to the final payload. What do you think? |
I think it is appropriate to resolve this issue on the receiving side. The current cause of the failure in object conversion lies not only in the strings that contain line breaks but also in the process of determining the targetType. Even if the correct type is assigned to JavaType in the part where the type of the payload is determined, if the payload is a JsonString, it is identified as a string, causing an issue in object conversion. Therefore, the sending side cannot fully resolve the issue. Please review the final PR : #1168 |
I am also getting same error |
Currently due to Spring Messaging internals if we send a
String
message containing a JSON without specifying aContent-Type
it'll default totext/plain
in theStringMessageConverter
.If we set
.header(MessageHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON)
, it will be mapped byMappingJackson2MessageConverter
which will double serialize the payload, which won't be readable.We should look into a way of enabling users to send a String json with
APPLICATION_JSON
content type so it can be properly deserialized by the consumer.The text was updated successfully, but these errors were encountered: