Skip to content

GH-3089: Add AmqpInGateway.replyHeadersMappedLast #3091

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

Merged
merged 2 commits into from
Oct 31, 2019

Conversation

artembilan
Copy link
Member

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

}

/**
* Map a reply o.s.Message to an o.s.a.core.Message. When using a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

o.s.m.Message

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**
* Add missed `@param` in JavaDoc of the `AmqpBaseInboundGatewaySpec.batchingStrategy()`
* Extract a `RabbitTemplate` `MessageConverter` to use for reply messages
conversion - pursue a backward compatibility
@artembilan
Copy link
Member Author

Pushed. Please, take a look!

@garyrussell garyrussell merged commit 6468ecc into spring-projects:master Oct 31, 2019
garyrussell pushed a commit that referenced this pull request 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
Copy link
Contributor

And cherry-picked as 54de7a2 after resolving conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wrong content type in reply message
2 participants