The `CompatibleStorageAmazonS3Configuration` and `AmazonS3Configuration`
are really auto-configurations, so they have to take an effect already
after end-user configurations processing
* Fix `AmazonS3ConfigurationTests` to configure an `ApplicationContextRunner`
in a proper way putting auto-configurations to their `AutoConfigurations.of()`
part and leaving only a `TestConfiguration.class` as a `UserConfiguration`
Fixes https://github.com/spring-cloud/stream-applications/issues/368
* Upgrade to `spring-cloud-aws-2.4.2`; fix respective package changes
* Remove `AutoConfigurationExclusionEnvironmentPostProcessor` since classes in the SC-AWS
are not considered as auto-configuration anymore.
Instead, add an explicit `@Import` into `AmazonS3Configuration`.
Not sure, though, why it was excluded before at all
* Fix `MetadataStoreAutoConfigurationTests` with the current state of code.
Looks like before it was designed for auto-configuration based on classpath content
* Re-enable other AWS S3 tests
This fix has helped to spot a bug in Spring Integration Testing framework:
e2d8eeb04d
Co-authored-by: Chris Bono <cbono@vmware.com>
* GH-276 Apply ComponentCustomizer in other modules
Fixes https://github.com/spring-cloud/stream-applications/issues/276
Some changes are straightforward as just a `ComponentCustomizer<?>`
injection and its optional usage for the target component customization.
Other changes are more drastic since it is better to use `proxyBeanMethods = false`,
so some direct bean method calls had to be reworked to the bean method argument
injections
* Fix some deprecations from Project Reactor
* Remove `UpdatingMongoDbMessageSource` since `MongoDbMessageSource`
supports now an `update` option in Spring Integration
NOTE: The `ZeroMqSupplierConfiguration` has its own customizer already
like `Consumer<ZMQ.Socket>`, so it can be revised to a more broader solution,
but in the future version.
Some modules just does not make sense to modify for more advance customization
since all their configuration is covered with plain configuration properties.
See `splitter-function` or `wavefront-consumer`
* * Use `ObjectProvider<WebClientCustomizer>` for `HttpRequestFunctionConfiguration`
instead of our own `ComponentCustomizer`.
Although this has to be revised in favor of fully auto-configured `WebClient.Builder`.
Even that `maximumBufferSize` is included into codecs configuration properties.
* The `MongoDbMessageSource` has now an `update` option in Spring Integration
therefore remove redundant already `UpdatingMongoDbMessageSource`
and populate `this.properties.getUpdateExpression()` directly ot the
`MongoDbMessageSource` bean
* Modify supplier configurations to avoid manual starts for endpoints on
reactive `Publisher` subscriptions.
Spring Integration provides now a `toReactivePublisher(true)` operator
to have all the endpoints stopped on start, but started automatically
when subscription happens to the provided `Publisher`
* Update Copyright to the current year for all the affected classes
* Use `@Nullable` instead of `ObjectProvider` in the `AggregatorFunctionConfiguration`
dependency injection for consistency
* Fix `LogConsumerConfiguration` to not have a `log()` in the end - it is not terminal
in Spring Integration anymore.
Use recommended `nullChannel()` terminating operator for use-cases like this.
* * Remove `beanName` from `ComponentCustomizer` contract
Co-authored-by: Chris Bono <cbono@vmware.com>
This proposal fixes many build warnings and is a general cleanup of the pom.xml files.
* Remove duplicate `dependency` entries from pom.xml files
* Remove duplicate `repository` entries from pom.xml files
* Replace deprecated use of `receive(long)` in `HttpSourceTests`
* Reduce logging for Twitter integration tests
Fixes#271
Since we still need to modify every single function, consumer & supplier
for previously introduced `@CustomizationAware`, it does not do too much
difference for us if we add a `ComponentCustomizer` dependency to the
bean for customization and call it manually.
One benefit of this change is to avoid a `static` confusion and performance
overhead with extra `BeanPostProcessor`.
* Remove `ComponentCustomizerBeanPostProcessor` and
respective `ComponentCustomizationAutoConfiguration`
* Use `@Nullable ComponentCustomizer<FileInboundChannelAdapterSpec>`
as dependency in the `FileSupplierConfiguration.fileMessageSource()` bean
Fixes#195
* Introduce a `ComponentCustomizer` contract to be exposed in
the end-user configuration for particular bean type
* introduce a `@CustomizationAware` annotation to mark a component
as customizable
* Introduce a `ComponentCustomizationBeanPostProcessor` as an auto-configured
bean to apply `ComponentCustomizer` to a matching `@CustomizationAware` (if any)
* Use `@CustomizationAware` in the `FileSupplierConfiguration`
and demonstrate `ComponentCustomizer` feature in its tests
* Move `config-common` to functions parent to make the mentioned auto-configuration
available for all the functions
* Remove some other duplicated dependencies from the affected poms
Fixes https://github.com/spring-cloud/stream-applications/issues/182
* Upgrade Debezium dependency to 1.7.1
* Remove explicit dependencies for DBs and remove excludes for them from Debezium deps;
rely fully on whatever Debezium connectors bring for us
* Fix `EmbeddedEngine` for compatibility with the Debezium 1.7.1
* Fix CDC tests for the current state of Debezium results
* Fix Checkstyle violations in the MQTT modules
Fixes https://github.com/spring-cloud/stream-applications/issues/183
* Add `MqttProperties.sslProperties` common MQTT configuration property as a `Map` structure
* Delegate a content fo the `MqttProperties.sslProperties` into `mqttConnectOptions.setSSLProperties()`
in the common `MqttConfiguration`
* Verify that SSL properties are applied in both `MqttSupplierTests` & `MqttConsumerTests`
* Document a new `MqttProperties.sslProperties` configuration property for both consumer and supplier
* Use `eclipse-mosquitto` Docker image for MQTT tests instead of RabbitMQ plugin: the Mosquitto starts much faster
Related to: https://github.com/spring-cloud/stream-applications/issues/171
It might not be necessary in real world, but with `SshServer` we fail
when we disconnect the session and cannot connect it back because
that server decides to die for a strange reason like no connections.
* Upgrade to SSHD 2.7.0
* Wrap default SFTP SF into a `CachingSessionFactory` to keep sessions opened
and don't let the server to die because on connections from clients
* Reenable SFTP Supplier tests
Fixes https://github.com/spring-cloud/stream-applications/issues/156
The `MessageSource.receive()` may produce `null`:
The `MessageSourceMutator` impl must honor such an input
* Add `MonoProcessor<Boolean> subscriptionBarrier` to delay
subscription to the source `Flux` until subscription happens
to the supplier's flux.
This way we don't have unexpected interaction with the source when
there are regular endpoints in the flow in between
Use spring test data geode in the geode integration tests
test to fork a separate geode process, instead of running
a geode server in a docker container.
STDG is faster than launching Geode through gfsh inside of a container.
- It doesn't run in docker
- It doesn't start management components necessary for gfsh
- It doesn't start extra gfsh shell processes
Removing the GeodeContainer test utility
* Fix MongoDb driver problem.
Probably we need to think about upgrading Debezium support to the latest
version, so its MongoDb connector is based on the latest Mongo Driver
which already is pulled by Spring Boot
* Use `debezium/example-mysql:latest` image in the `CdcBootStarterIntegrationTest`
to avoid failing when some transitive dependency does not exist any more
- Fix cdc_key header string wrapping issue that causes problems with the spring.cloud.stream.kafka.default.producer.messageKeyExpression.
- Rename Flattering property to the correct Flattening.
- Remove wrong dependencies.
