This commit effectively reverts the changes introduced in
d9f8653e42. Basically, removing
the changes introduced for supporting multi binders when
binders are registered through spring.factories. Binders
are still expected to provide spring.binders to register them.
More native compilation support for Kafka Streams and multi binder environments.
Although these changes directly do not reflect anything native related, these
are mainly to support the usage of spring.factories in Kafka Streams binder
instead of spring.binders. We are only supporting the spring.factories model
for finding the binders in spring-native based Spring Cloud Stream applications.
resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2161Resolves#2162
- Instead of injecting `AbstractMappingMessageRouter[]`, inject it as a container
type using `List<>`. This is because the former uses reflection behind the scenes
and causes issues with graal native compilation (unless provided as a native hint).
- Instead of autowiring `Map<String, BindingTargetFactory>` in
`AbstractBindableProxyFactory`, programmatically populate `BindingTargetFactory`
beans by doing a `BeanFactory` lookup in a new method. Then the subclasses of
`AbstractBindableProxyFactory` call this method to pouplate the avaialble
`BindingTargetFactory` beans in their `afterPropertiesSet` method.
- Convert array injection of `BindableProxyFactory[]` in functionInitailzer bean
in `FunctionConfiguration` to use container based injejction (`List<>`).
- Cleanup unused injection in functionInitializer bean in `FunctionConfiguration`.
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2154Resolves#2155
Typically output type conversion would happen in s-c-function which is a bit too early for cases when user uses SpEL on the output payload (e.g., Rabbit routing-key)
This defers this type conversion
Resolves#2145
Appears to create problem in native images, but since we do not intend to support annotation-based programming model, we can just ignore this exception until we can remove this code all together.
. . . to ensure that any exceptions resulting from custom implementation of ApplicationLstener does not harm the application
There will now be a WARN message and the stacj trace under DEBUG, but the application will continue to function.
Resolves#2118
SubscribableChannelBindingTargetFactory now capable of dealing with channels that may have been created outside of the normal process. In other words if channel exists as bean it will only cofigure it
Resolves#2132
Updated documentation to clarify the differences between the retry mechanisms of different programming models (e.g., imperative vs. reactive).
Resolves#2073
