- Both the producer and consumer properties have `HeaderMode`
- Handle the case of embeddedHeaders and raw for both the Sending/ReceivingHandlers in Redis binder
This resolves#408
Move message values extraction to superclass
- Add necessary assertions on the type of message channels for input/output
- Make sure to support message channel of type `MessageChannel` for @Output-annotated channels
- support message channel of type `SubscribableChannel` for @Input-annotated channels and if the type is exactly equal to `MessageChannel` type then create subscribable channel
- Remove references of creating PollableChannel for binding
This resolves#469
Remove bridging of shared channel
- For the message converters that use Jackson ObjectMapper, autowire the ObjectMapper from JacksonAutoConfiguration
- This will allow configuration of ObjectMapper using boot configuration properties `JacksonProperties`
- Add test
This resolves#466
- When the AggregateApplicationBuilder doesn't have constructor args set, then invoke parent configuration setup with no args.
- This will make sure to set the parent context for the child application contexts
This resolves#464
This resolves#425
Address review comments
- Update AssertTrue conditional logic
- Modify the message
Changes after rebase
- Changes after extendedProperties addition
- Set the default destination name when it is not explicitly set
- The producer/consumer properties would also be shown via BindingProperties
- Handle JSON serialization when the value is of type Expression
This resolves#406#426
* Add parameterized ExtendedConsumerProperties and ExtendedProducerProperties;
* Added ExtendedPropertiesBinder with the ability of managing per-binding property extensions and interacting the core service;
* Add extensions for Kafka and Rabbit
Addressing PR comments
Changed binder-specific binding prefix to `spring.cloud.stream.binderType.bindings`
Removing kafka-binder.properties
Fixes#156
- Supports Spring Messaging infrastructure for argument mapping and type conversion, sharing the same configured converters as the ones configured on input/output channels;
- Also: refactored AbstractFromMessageConverter to return only payload - conversion to a message enriched with the content type of the channel is done by a separate wrapping converter;
- Update MessageConverterConfigurer that uses a channel interceptor to check if the message contentType header is missing and if there is a binding property for `contentType` header is provided, then set that value as the message contentType header
This resolves#397
Add test
- renamed MessageConverterUtils.getJavaType to MessageConverterUtils.getJavaTypeForJavaObjectContentType and restricted usage only to 'application/x-java-object' types
- Autowire custom message converters into MessageConverterConfigurer
- When configuring the message channel, set the `datatypes` of the channel based on the `supported` datatypes of all the matching message converters
This resolves#381