After fixing https://jira.spring.io/browse/INT-4517 we don't need
a hack in the `ContentTypeConfiguration` about removal of the
`IntegrationContextUtils.ARGUMENT_RESOLVER_MESSAGE_CONVERTER_BEAN_NAME`
`BeanDefinition` and registering our own later
* Provide some code polishing for the `ContentTypeConfiguration`
removing some redundant code and providing consistency with
components it uses
* Add `ElementType.PARAMETER` target for the `StreamMessageConverter`
annotation to let the list of appropriate converters to be inject
via method parameters in the `@Bean` definition
* Tentative use SI `5.1.0.BUILD-SNAPSHOT` until Spring Boot 2.1 M2
Resolvesspring-cloud/spring-cloud-stream#1437Resolvesspring-cloud/spring-cloud-stream#1438
Added initial set of supporting classes, tests and configuration
to support integration of Spring Cloud Function with the current
set of streaming binders.
This commit primarily addresses the Source aspect of such integration
addressed PR comments
* Polishing some code style
* Fix typos
* Removed MockBinderRegistryConfiguration
* Move necessary beans from `BindingServiceConfiguration` which is now auto configurable into
`BinderFactoryConfiguration` that is invoked by `EnableBinding` in order to avoid certain
cyclic dependency issues. The beans moved are binding target factories of type
`MessageSourceBindingTargetFactory` and `SubscribableChannelBindingTargetFactory` and their dependencies.
As a side effect, `ContentTypeConfiguration` is also brought back at the `EnableBinding` level through
`BinderFactoryConfiguration`.
* Restore `ServerController` bean in SchemaServerConfiguation as the removal of it
earlier introduced some connectivity issues with the schema registry server.
* Update copyrights
* After moving some bunch of beans from the `@EnableBinding` to the
auto-configuration for proper conditional lifecycle we need to be sure
that all those support beans are registered for each child context as
it was before after parsing imports on the `@EnableBinding`.
This way add `search = SearchStrategy.CURRENT` for all the conditions
in the `BindingServiceConfiguration`
* Fix `TestSupportBinderConfiguration` to rely only on the `Binder`
instance created once in the parent level.
This way when we use an aggregated application, only the parent context
creates for us a `TestSupportBinder` and all the child contexts reuse it.
* Register `BinderFactory` only once in parent ctx
* Instead of redefining `BinderTypeRegistry` as a bean in several tests, properly use spring.binders
to define mock binders and then choose a default binder in tests in case of multiple binders in
same spring.binders file.
* Remove `BindingServiceConfiguration` in `EnableBinding` and introduce it as a proper
Spring Boot autoconfiguration class. Added `BindingServiceConfiguration` to spring.factories.
* Move `BinderFactory` bean into `BindingServiceConfiguration` and add `ConditionalOnMissingBean`
on it so that downstream users can define new `BinderFactory` beans as part of autoconfiguration.
* Remove `ConditionalOnMissingBean` from the `BinderTypeRegistry` bean in `BinderFactoryConfiguration`
as we don't expect this bean to be overridden.
* Remove previously added property `spring.main.allow-bean-definition-overriding` in several tests.
* Since web/actuator is optional now, remove unncecessarily setting server.port to `0` in tests
* Ensure that `BindersHealthIndicatorAutoConfiguration` is autoconfigured after `BindingServiceConfiguration`
so that it has a `BinderFactory` available.
* Remove redefining `ServerController` bean in `SchemaServerConfiguration` as this is already created through
component scanning and causing the bean overriding exceptions.
* Tests cleanup and polishing.
Resolves#1429, #1430
Update more tests with bean overriding errors where they try to override the `BinderTypeRegistry` bean.
This is not very common in end user applications unless they are trying to define a new binder type.
If that is indeed the case, then they have to set `spring.main.allow-bean-definition-overriding` to `true`.
Remove where we define the bean `integrationArgumentResolverMessageConverter` in `ContentTypeConfiguration`
as this causes a conflict with the same bean from Spring Integration and thus causing bean overriding exception.
Insted of creating this through `@Bean`, manually register the bean after removing it from `BeanDefinitionRegistry`.
See: https://github.com/spring-cloud/spring-cloud-stream-binder-kafka/issues/309
Provide binders with access to the output channel so it can override the
partition count on the `PartitioningInterceptor` if it detects that the
actual partition count is different to that configured in the producer properties.
Resolves#1421
Currently when the binder configuration provide properties in a custom environment,
Spring Cloud Stream does not include any beans from the outer context.
This change will ensure that in such cases, the binder context will have access
to the outer context as a non-parent bean.
Resolves#1420Resolves#1423
Ensured that SpelExpressionConverterConfiguration is always present in the AC regardless of single or multi-binder application configuration
Polishing
Resolves#1412
Add spring-boot-autoconfigure-processor to spring-cloud-stream
and spring-cloud-stream-reactive modules for auto configuration optimization.
Resolves#1410Resolves#1411
Remove the ability to bind global error channel directly to a broker destination through error.destination property.
The preferred way to consume error messages in a brokder destination is through the binder specific DLQ mechanism.
Global error channel may still be consumed by a ServiceActivator or StreamListener, but it is not bound to a broker destination.
Remove the internal bridge channel from the global error channel that is used for content type conversion.
Remove tests associated with this feature.
Deprecate class `SingleBindingTargetBindable` as this is not used by the framework any longer.
Docs polishing.
Resolves#1398Resolves#1401Resolves#1269
Ensured that default property only takes affect if the actual binding property is not set.
For example if "spring.cloud.stream.bindings.output.producer.partitionCount=4" and "spring.cloud.stream.default.producer.partitionCount=1" are both set
the actual binidng property (i.e., 4) should take precedence
Resolves#1359
Set application's context as binder context once the binder is initialized to ensure identical behavior in i multi-environment scenarios.
Resolves#1384Resolves#1357
Fixesspring-cloud/spring-cloud-stream#1387
To be able to distinguish the `PartitioningInterceptor` in the
`MessageChannel` and remove it from the interceptor it would be better
to have its class as `public`
In some use-case like AWS Kinesis Binder it is important do not have
an SCSt partitioning logic, since the whole functionality is done
on the target system.
**Cherry-pick to 2.0.x**
Remove all the deprecated RxJava components from spring-cloud-stream-reactive module in favor
of using Project Reactor based types.
Fixes#1378Resolves#1379
Initial removal of parent/child context for Binders. This commit contains bare minimum of what's required while still supporting 'the old way'.
Basically implementor of a binder must do the following things:
- name your configuration file as the usual boot 'spring.factories` (no more spring.binders)
- add name attribute to the `@Bean` which declares the actual binders (e.g., `@Bean('rabbit')`)
This PR ensures that the existing functionality (the use of spring.binders) is preserved.
Resolves#1272Resolves#1361
polishing
If the binder implementation enables native multiple input binding, skip individual
consumer binding per binding target (for example - from a comma separated targets
provided as input destination property).
By default, native multiple input binding is disabled at the core framework level
and the binder implementation explicitly needs to override that to enable it.
Fixes#1365
Chaning the boolean flag for multiple input binding to multiplex
