Fixes#1106
- This PR builds on the previous PR with commit hash 6c259be6... (pr/1112)
- Added support in AbstractBinderTests to create bindable channel based on determining channel input type based on it's name (i.e., *input*)
- Added LegacyContentTypeHeaderInterceptor to TestSupportBinder to restor the previous behavior of MessageCollector for cases
where Message's payload content type is a variant of 'text'.
- Restored tests that use MessageCollector to depend on proper payload type
- Added 'deserialize' routine back to MessageSerializationUtils
- Polished MessageConverterConfigurer.LegacyContentTypeHeaderInterceptor to remove conditional original-content-type header logic
- Removed default contentType from BindingProperties
- Restored tests that use MessageCollector to depend on proper payload type
- polishing
- fixed Kryo/Java serialization
- Fixed ser/de for "application/json" and contentType equals
- Fixed of ser/de of JSON strings to ensure that Strings are not re-quoted
- Fixed how we comparing contentTypes
- more polishing
- Fixed NPE in MessageSerializationUtils
- Make bindings and consumer groups in new tests added to AbstractBinderTests mutually exclusive
- Remove binding config property `legacyContentTypeHeaderEnabled` that was
introduced to enable legacy content type handling
- Enable LegacyContentTypeInterceptor in 2.0 always, but bypass any
legacy content type handling if the message received is from
a 2.0 producer by checking on the version header
- Introdce a new BinderHeader property for version
- Fix the LegacyContentType related tests
- Remove the check for originalContentType in ReceivingHandler when
the payload received is a byte[]
- Remove unnecessary deserializePayloadIfNecessary calls in ReceivingHandler
- Remove deprecated deserializePayload methods in AbstractBinder
and MessageSerializationUtils
Partly fixes#1106Fixes#1110
Added assertion to org.springframework.cloud.stream.binder.AbstractTestBinder to ensure that MessageChannels that are passed to any of the bind methods are configured with Message Interceptors
See https://github.com/spring-cloud/spring-cloud-stream-binder-kafka/issues/236
- add `none` as a synonym for `HeaderMode.raw`
- add `headers` meaning "use native headers"
- change the default header mode - `null`
- remove `supportsHeadersNatively` - allow binders to chose header mode for each binding
binders decide their own default when the property is null
- Rabbit will choose `headers` as default (but can be overridden to `none` for a binding)
`embeddedHeaders` will not be allowed
- Kafka will choose `embeddedHeaders` as default for compatibility with 1.x peer apps
- remove deprecations on header embedding code
Polishing; support fallback
- if the consumer side is configured to support embedded headers,
binders should look for native headers first and signal their presence
using the `BinderHeaders.NATIVE_HEADERS_PRESENT` header;
fall back to embedded headers if it appears the payload might contain
them
- remove support for XD embedded headers (first byte < 0xff)
- add a quick check for embedded headers by examining the first byte for 0xff
- change the log from error to debug when decoding embedded headers fails
- see the kafka binder PR for a test case with a consumer that can handle all
message flavors (native, embedded, and no headers).
- critiical -> critical;
- end 'etc' with a period; also consistently end etc in parentheses with
'etc.).';
- typo in 'application';
- applicaiton -> application;
Without explicitly naming the `inputChannel` and `outputChannel`, well get this error on startup org.springframework.integration.MessageDispatchingException: Dispatcher has no subscribers
Fixes#1057
Enable consumers to convert from originalContentType to contentType in the case of
legacy producers sending messages with originalContentType header.
By default, this conversion will not happen and only be acitvated by setting
`spring.cloud.stream.bindings.input.legacyContentTypeHeaderEnabled` to true.
Resolvesspring-cloud/spring-cloud-stream#1083
By default Spring Framework allows beans overriding via the same name.
The binding target definitions (`@Input` and `@Output`) populate beans as well
and when we use the same name for target we end up with unexpected behavior
but without errors.
Since it isn't so obvious via Spring Framework bean definition DSLs
(XML or Java & Annotations) how to override beans with the same name,
that is absolutely easy to use the same value for `@Input` and `@Output`
definitions even in different binding interfaces.
That's hard to analyze fro the target application since mostly
`@Input` and `@Output` produce `MessageChannel` beans.
* Fail fast with the `BeanDefinitionStoreException` when we meet existing
bean definition for the same name
* Add JavaDocs to the `@Input` and `@Output` to explain that their `value`
is a bean name, as well as destination by default
Since `@EnableBinding` is `@Inherited`, the inheritor picks up it from the
super class during configuration class parsing.
The parsing process logic is such that after the root class we go to parse its
super classes, and therefore come back to the `@EnableBinding` again.
In this case we process all the `@Import`s one more time and collect them to
the root `configurationClass`.
Essentially we get a duplication for the `ImportBeanDefinitionRegistrar`s
such as `BindingBeansRegistrar`.
The last one parsed `@EnableBinding` and registers appropriate beans for the
`@Input` and `@Output`, as well as for the binding interface - `BindableProxyFactory`.
But since we have it twice in the `configurationClass` we end up with
`BeanDefinitionStoreException` mentioned before.
That's how Spring Framework works with inheritance for configuration classes
and that's may be why it allows to override beans by default
* Skip parsing `@EnableBinding` one more time if the bean definition for
binding interface is already present in the `registry`
* Fix `AggregateWithMainTest` do not process `@ComponentScan` what causes
picking up the configuration classes for children contexts in the aggregation
* Fix `testBindableProxyFactoryCaching()` do not register `Source` and `Processor`
in the same application context because both of them cause registration for the
`Source.OUTPUT` bean
Conflicts:
spring-cloud-stream/src/test/java/org/springframework/cloud/stream/aggregation/AggregationTest.java
- Fixes#1072
- Added a new ContentTypeResolver that searches for originalContentType
as well as contentType headers
Conflicts:
spring-cloud-stream-schema/src/main/java/org/springframework/cloud/stream/schema/avro/AvroMessageConverterAutoConfiguration.java
Fixes#992, #1050, #1051, #1052
Adding custom jackson converter with some tests
Adds kryo message converter to replace codec
Checkstyle changes
Removing codec support
- Removed codec dependency from AbstractBinder
- MessageSerializationUtils is almost an empty shell for now, just to
keep code compiling until we get EmbeddedHeaders interceptors
- Updated Kryo tests
Removing codec module from build
Added a new Annotation for custom converters '@StreamConverter'
Fixed some tests with new expected behavior
Moved broken tests to a temporary package to keep track of progress
Fixed KryoConverter to fail based on headers
Fixed a couple of more tests
Making converters strict to only convert their corresponding contentType
Bypassing conversion for ErrorMessages
* Configuring SI ConfigurableCompositeMessageConverter
- Moved ContentType related beans into separate configuration
- Configured SI ConfigurableCompositeMessageConverter to use same
converters as Stream does (for ServiceActivator)
- TupleConverter should return byte[] as all other converters
- Fixed tests
* Fixes tests
- Revert to Boot 2.0.0.M3. Snapshots breaking actuator
- Checkstyle fixes
- Disable JsonUnmarshalling as a catch all converter
Fixing Schema tests
Fixing Metrics tests
Fixing reactive tests
applying checkstyle fixes
* Adding new content type tests
- Fixed ContentTypeInterceptor misusage of default mimeType
Changing contentType doc section
Improving doc section
Last minute polish
Fixing BinderTests to use bytes to compare messages
Applied changes to Base Binders test to use the new contentType handling mechanism
PR review fixes
Renaming StreamConverter -> StreamMessageConverter
- Pump up version to 2.0.0
- Some generic polish
- All changes around breakage with boot 2.x
- Some boot classes has been moved around
- You can't no longer have binding key ending with
camelCase.
- New Binder now has illegal keys.
- Some changes to tests as we can directly do end-to-end
testing with ENV_VAR_FORMAT as normal keys
- Spring data repo changes as now uses Optional
- Remove relaxed binder and its tests in favor of new Binder
- Some mockito api changes
- One Ingored test TextPlainToJsonConversionTest.testTextPlainToJsonConversionOnInput
- Relates to #935
Cache metric export properties
Add code formatting guidelines
Rearranged files
Resolvesspring-cloud/spring-cloud-stream#1083
By default Spring Framework allows beans overriding via the same name.
The binding target definitions (`@Input` and `@Output`) populate beans as well
and when we use the same name for target we end up with unexpected behavior
but without errors.
Since it isn't so obvious via Spring Framework bean definition DSLs
(XML or Java & Annotations) how to override beans with the same name,
that is absolutely easy to use the same value for `@Input` and `@Output`
definitions even in different binding interfaces.
That's hard to analyze fro the target application since mostly
`@Input` and `@Output` produce `MessageChannel` beans.
* Fail fast with the `BeanDefinitionStoreException` when we meet existing
bean definition for the same name
* Add JavaDocs to the `@Input` and `@Output` to explain that their `value`
is a bean name, as well as destination by default
Since `@EnableBinding` is `@Inherited`, the inheritor picks up it from the
super class during configuration class parsing.
The parsing process logic is such that after the root class we go to parse its
super classes, and therefore come back to the `@EnableBinding` again.
In this case we process all the `@Import`s one more time and collect them to
the root `configurationClass`.
Essentially we get a duplication for the `ImportBeanDefinitionRegistrar`s
such as `BindingBeansRegistrar`.
The last one parsed `@EnableBinding` and registers appropriate beans for the
`@Input` and `@Output`, as well as for the binding interface - `BindableProxyFactory`.
But since we have it twice in the `configurationClass` we end up with
`BeanDefinitionStoreException` mentioned before.
That's how Spring Framework works with inheritance for configuration classes
and that's may be why it allows to override beans by default
* Skip parsing `@EnableBinding` one more time if the bean definition for
binding interface is already present in the `registry`
* Fix `AggregateWithMainTest` do not process `@ComponentScan` what causes
picking up the configuration classes for children contexts in the aggregation
* Fix `testBindableProxyFactoryCaching()` do not register `Source` and `Processor`
in the same application context because both of them cause registration for the
`Source.OUTPUT` bean
Fix#1080
When class with `@StreamListener` method is proxied we end up
with the double target subscribers registration because we meet
the same method multiple times during `ReflectionUtils.doWithMethods()`
* Use `ReflectionUtils.getUniqueDeclaredMethods()` instead to extract
the list of method candidates
**Cherry-pick to 1.2.x**
* Add codecov support
Resolves#1043
* Remove unwanted service configs from travis
- Spring Cloud Stream doesn't use Redis/Kafka services as these were originally added to support their binder support in the same repo
Since we rely on the Checkstyle configs in the `spring-cloud-stream-tools`
module, we really need its artifact if we would like to use it as a
dependency for the `maven-checkstyle-plugin`.
But at the same time it is possible only if we run `package` phase.
During `compile/test` phase we don't have artifact yet and end up with
the error that no property set for Checkstyle.
* Use Checkstyle config files directly for the `maven-checkstyle-plugin`
properties.
This way we don't need any artifact to build in advance
Initial Commit for GH-916.
- register a pubsub error channel.
- register and subscribe a bridge handler to bridge it to the global error channel.
- pass the error channel to the implementation so it can wire it into the outbound endpoint.
- destroy the infrastructure when unbinding.
Javadoc Polishing
Add test case.
temp update to SI 4.3.12
GH-802 - Error Handling Documentation
Resolves#802
- Clarifies where @EnableBinding should be used
- Explains pubsub nature of @StreamListener and computing consumer of
other SI annotations
- Moved a comment in relevant section
- When binding the default BindingProperties, we use RelaxedDataBinder without any specific conversion service. This makes the `String` to SpEL `Expression` conversion failing when the producer properties such as `partitionKey/SelectorExpression` are bound.
- Update the underlying conversion service (which includes the SpELConverter via EnableBinding) into RelaxedDataBinder
- Update test
Resolves#1040
