Fixes https://github.com/spring-cloud/spring-cloud-stream-binder-rabbit/issues/156
The `SimpleMessageConverter` overwrote the `contentType` property with `application/octet-stream`.
`contentType` set by the stream converter should win.
- `setHeadersMappedLast(true)`
- replace the converter with a simple `byte[]` pass-through converter on both sides.
- if (for some reason) the stream converter produces something other than `byte[]` fall back to
the `SimpleMessageConverter`.
- remove the `afterPropertiesSet` since it's done by the abstract binder.
**cherry-pick to 2.0.x**
Resolves#157
Resolves https://github.com/spring-cloud/spring-cloud-stream-binder-rabbit/issues/149
When a consumer is multiplexed, configure the container to listen to multiple queues.
Not currently supported for the polled consumer.
When using a DLQ, determine the routing key from the queue in the failed message (unless
an explicit DLQ name has been provisioned - in which case, the same DLQ will be used
for all queues.
Given that is already checking for `properties.getExtension().isRepublishToDlq()` removing the IF from the configuration phase of the adapter with RetryTemplate ensures the consistency of the behavior for cases when local error handler is configured and RetryTemplate is used.
Resolves#141
- `RabbitBinderTests` automatically clean up but remove declaration of an unused queue
- `RabbitBinderModuleTests` didn't clean up properly.
Resolves#138
Fixes https://github.com/spring-cloud/spring-cloud-stream-binder-rabbit/issues/128
The binder incorrectly shuts down the connection factory `@Bean`, before the bindings
are stopped, preventing the container waiting for tasks to complete.
Code was added to destroy the CF in the case where we create one locally, which is
correct, but we should not destroy the CF managed by Spring.
Also see https://jira.spring.io/browse/AMQP-800
(cherry picked from commit eaad4d9)
When we don't specify the `host` property for the
`CachingConnectionFactory`, it is selected by the
`InetAddress.getLocalHost().getHostName()`, which might not be
"localhost" as it is allowed for the `guest` user on RabbitMQ.
This also may cause some unexpected loop-backs on the network interface
during connection attempt
**Cherry-pick to 1.3.x**
The Spring Boot's `RabbitProperties` populates the `host:port`
(default values) to the addresses property in the `determineAddresses()`.
This way we override provided by Cloud Connectors `host:port`
* Do not populated `addresses` to the CCF from the `RabbitProperties`
if the real `addresses` is null.
Only explicit `spring.rabbitmq.addresses` application property will have
effect
**Cherry-pick to 1.3.x**
The SC-Connectors `ServiceConnector` can be customized via
`ServiceConnectorConfig`.
* Allow end-user to specify such a bean and support its injection in the
`rabbitConnectionFactory` and `producerConnectionFactory` bean definitions
**Cherry-pick to 1.3.x**
Add `spring-cloud-spring-service-connector` dependency to be able to
request from the application context only specific `RabbitConnectionFactoryConfig`.
Use `ObjectProvider.getIfUnique()` for the case when we have not a single
`RabbitConnectionFactoryConfig` bean in the ctx
* Configure Cloud CCF via Boot's `RabbitProperties`
* Obtain from the Cloud only one CF service
The `RabbitMessageChannelBinder` creates an internal distinct
`ConnectionFactory` instance based on the `RabbitProperties` for the
non-transactional producers to avoid dead locks when connection
is blocked.
In case of Cloud Connectors the `ConnectionFactory` bean is overridden,
but not `RabbitProperties`.
Therefore the original `ConnectionFactory` for consumers is good,
cloud-based, but for producers it is still based on the `RabbitProperties`
from Spring Boot, in most cases with default options.
* Add one more `producerConnectionFactory` `@Bean` to the
`CloudConnectors` configuration to obtain a distinct `ConnectionFactory`
instance from the cloud provider
* When we ara not in the cloud profile, create a fresh `ConnectionFactory`
based on the `RabbitProperties`
* Inject the extra `producerConnectionFactory` instance into the
`RabbitMessageChannelBinder` instead of the internal non-stable solution
**Cherry-pick to 1.3.x**
Fixes https://github.com/spring-cloud/spring-cloud-stream-binder-rabbit/issues/83
Expressions for the routing key and delay (when using a delayed exhange) that
include the `payload` failed because they were evaluated after the payload was
serialized.
If either expression includes `payload`, add an interceptor to evaluate the expressions
before serialization and add the results as headers.
Polish tests
Resolves#83Resolves#111
