The NPE was a result of not following defensive programming practices and that is fixed.
Also, we already support both reader and writer schema being null where new ReflectDatumReader(type) is used in getDatumReader(..) operation.
That said there may still be conditions which are not supported and that is okay since in the end it's a MessageConverter and as such it is one
of the extension points of the framework allowing user to provide a custom one follwing instructions in 'User-defined Message Converters' of the reference guide.
Resolves#1294
Removed autowiring from StreamListenerAnnotationBeanPostProcessor in favor of late-binding callbacks
Fixed tests
Resolves#1146
polished for Java 1.7 compliance
Continue the work started in f53ff9585a
- simplified 'isDeclarativeMethodParameter(..) operation of StreamListenerAnnotationBeanPostProcessor
- aligned MessageChannelToInputFluxParameterAdapter and MessageChannelToInputObservableParameterAdapter around the actual Message
- Removed dependency and callbacks to 'BeanFactoryUtils.beansOfTypeIncludingAncestors' in
StreamListenerAnnotationBeanPostProcessor in favor of more appropriate and lazy DI
mechanism provided by Spring.
- Polishing
polishing as part of the cherry-picking
See https://github.com/spring-cloud/spring-cloud-stream-binder-kafka/issues/223
When using native encoding; NPE when no class name derived from the content type.
Do not attempt deserialization if `JavaClassMimeTypeUtils.classNameFromMimeType(contentType)`
returns `null`.
Test case in the Kafka binder.
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
