-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Wrong content type in reply message #3089
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
Comments
artembilan
added a commit
to artembilan/spring-integration
that referenced
this issue
Oct 28, 2019
Fixes spring-projects#3089 In some use-case we would like to control when headers from SI message should be populated into an AMQP message. One of the use-case is like a `SimpleMessageConverter` and its `plain/text` for the String reply, meanwhile we know that this content is an `application/json`. So, with a new `replyHeadersMappedLast` we can override the mentioned `content-type` header, populated by the `MessageConverter` with an actual value from the message headers populated in the flow upstream * Introduce an `AmqpInboundGateway.replyHeadersMappedLast`; expose it on the DSL and XML level * Use newly introduced `MappingUtils.mapReplyMessage()` * Optimize `DefaultAmqpHeaderMapper` to not parse JSON headers at all when `JsonHeaders.TYPE_ID` is already present (e.g. `MessageConverter` result) * Also skip `JsonHeaders` when we `populateUserDefinedHeader()` **Cherry-pick to 5.1.x**
artembilan
added a commit
to artembilan/spring-integration
that referenced
this issue
Oct 31, 2019
Fixes spring-projects#3089 In some use-case we would like to control when headers from SI message should be populated into an AMQP message. One of the use-case is like a `SimpleMessageConverter` and its `plain/text` for the String reply, meanwhile we know that this content is an `application/json`. So, with a new `replyHeadersMappedLast` we can override the mentioned `content-type` header, populated by the `MessageConverter` with an actual value from the message headers populated in the flow upstream * Introduce an `AmqpInboundGateway.replyHeadersMappedLast`; expose it on the DSL and XML level * Use newly introduced `MappingUtils.mapReplyMessage()` * Optimize `DefaultAmqpHeaderMapper` to not parse JSON headers at all when `JsonHeaders.TYPE_ID` is already present (e.g. `MessageConverter` result) * Also skip `JsonHeaders` when we `populateUserDefinedHeader()` **Cherry-pick to 5.1.x**
garyrussell
pushed a commit
that referenced
this issue
Oct 31, 2019
* GH-3089: Add AmqpInGateway.replyHeadersMappedLast Fixes #3089 In some use-case we would like to control when headers from SI message should be populated into an AMQP message. One of the use-case is like a `SimpleMessageConverter` and its `plain/text` for the String reply, meanwhile we know that this content is an `application/json`. So, with a new `replyHeadersMappedLast` we can override the mentioned `content-type` header, populated by the `MessageConverter` with an actual value from the message headers populated in the flow upstream * Introduce an `AmqpInboundGateway.replyHeadersMappedLast`; expose it on the DSL and XML level * Use newly introduced `MappingUtils.mapReplyMessage()` * Optimize `DefaultAmqpHeaderMapper` to not parse JSON headers at all when `JsonHeaders.TYPE_ID` is already present (e.g. `MessageConverter` result) * Also skip `JsonHeaders` when we `populateUserDefinedHeader()` **Cherry-pick to 5.1.x** * * Fix language and package typos * Add missed `@param` in JavaDoc of the `AmqpBaseInboundGatewaySpec.batchingStrategy()` * Extract a `RabbitTemplate` `MessageConverter` to use for reply messages conversion - pursue a backward compatibility
garyrussell
pushed a commit
that referenced
this issue
Oct 31, 2019
* GH-3089: Add AmqpInGateway.replyHeadersMappedLast Fixes #3089 In some use-case we would like to control when headers from SI message should be populated into an AMQP message. One of the use-case is like a `SimpleMessageConverter` and its `plain/text` for the String reply, meanwhile we know that this content is an `application/json`. So, with a new `replyHeadersMappedLast` we can override the mentioned `content-type` header, populated by the `MessageConverter` with an actual value from the message headers populated in the flow upstream * Introduce an `AmqpInboundGateway.replyHeadersMappedLast`; expose it on the DSL and XML level * Use newly introduced `MappingUtils.mapReplyMessage()` * Optimize `DefaultAmqpHeaderMapper` to not parse JSON headers at all when `JsonHeaders.TYPE_ID` is already present (e.g. `MessageConverter` result) * Also skip `JsonHeaders` when we `populateUserDefinedHeader()` **Cherry-pick to 5.1.x** * * Fix language and package typos * Add missed `@param` in JavaDoc of the `AmqpBaseInboundGatewaySpec.batchingStrategy()` * Extract a `RabbitTemplate` `MessageConverter` to use for reply messages conversion - pursue a backward compatibility
garyrussell
added a commit
that referenced
this issue
Oct 31, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@mvh77 commented on Sun Oct 27 2019
Verisions: Spring AMQP 2.2.0, Spring 5.2.0
I have the following simple test:
I managed to make this work by overriding Jackson2JsonMessageConverter#fromMessage that sets the content type before processing. However, the content type in the RabbitMQ reply message is text/plain. Here's what the RabbitMQ firehose log shows:
Here's the Spring logs:
I feel like there's a problem here where the new MessageProperties have a contentType of text/plain. I don't see how to configure this since the toMessage method of Jackson2JsonMessageConverter cannot be overriden.
@garyrussell commented on Sun Oct 27 2019
This is a Spring Integration issue, not Spring AMQP.
Your inbound gateway needs to be configured with the jackson converter (and remove the transformers). The gateway has a
SimpleMessageConverter
by default when it just sees a String it sets the content type to text/plain.The outbound endpoints have a property
headersMappedLast
which allows the content type header from the message to be used.We should have a similar property for the reply handling in the inbound gateway.
Moving this to Spring Integration.
The text was updated successfully, but these errors were encountered: