- Update IntegrationFlowFunctionSupport with the necessary changes to bind function, consumer, supplier
- Add changes to AbstractMessageChannelBinder to add appropriate input/output message channel configuration to accommodate
function support
- Upate tests
Resolves#1480Resolves#1475
Test demonstrating the issue
Revert extra diffs
Updated changes
If we repeatedly call String#replaceAll, we internally repeatedly call the regular expression pattern compilation every time as following:
```java
public String replaceAll(String regex, String replacement) {
return Pattern.compile(regex).matcher(this).replaceAll(replacement);
}
```
The modifications are to keep the compiled pattern.
Therefore, compiling a relatively expensive regular expression pattern does not have to be done every time.
Resolves#1486
Currenlty, we only support default properties for core producer/consumer (spring.cloud.stream.default.producer|consumer...).
These changes add support for configuring default properties for extended producer and consumer properties.
For example, if the binder type is foo, then this allows the applications to configure default properties across
multiple producer or consumer bindings in the form of spring.cloud.stream.foo.default.producer|consumer.property.
The default prefixes for the extended properties are dictated by the respective binder implementations.
Resolves#1360
Manual merging for Map in MergableProperties
Handling values with defaults in extended producer/consumer properties
Removed BinderFunctionSupport in favor of private method (at least for now)
Removed 'context.getBean()` from IntegrationFlowFunctionSupport in favor of propper DI
Resolves#1465
Move IntegrationFlowFunctionSupport injection to AbstractBinder
Add function support in TestSupportBinder and fix *FunctionsSupportTests
Use BeanPostProcessor and revert TestSupportBinder
Clean up
Set errorChannel in afterPropertiesSet
Refactor IntegrationFlowFunctionSupportWiring
Close context
Revert context.close()
Added support for binding Suppliers, Function and Consumers as message producers and handlers for apps annotated with EnableBinding
Changed '.name' property to '.definition'
Resolves#1445
Resolvesspring-cloud/spring-cloud-stream#1440
Added initial support and configuration to create Source apps by simply
providing a Supplier bean while also benefiting from composition
provided by SCF
Refactored/renamed some of the new classes/methods
addressed PR comments
* Polishing code style and fix typos
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
