* GH-350: Upgrade SI Cassandra; re-enable tests
Fixes https://github.com/spring-cloud/stream-applications/issues/350
* Use Testcontainers for Cassandra
* Adjust components code style a bit
* Convert `Book` testing entity to the `record`
* Use `@DynamicPropertySource` to expose Docker ENV to Spring Boot configuration properties
* Use switch expression for better code readability
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>
Fixes https://github.com/spring-cloud/stream-applications/issues/373
The fix in Spring Integration has made it into the latest SNAPSHOT.
See more info in the linked issue
* Update to the latest Testcontainers: it does not require credential for pull command any more
* Remove obsolete `MessageStoreType.GEMFIRE`
* Add `<doclint>syntax</doclint>` to ignore missed javadocs on public methods
Spring Boot `@AutoConfiguration` comes now with a `proxyBeanMethods = false`,
so we cannot call bean methods within the same configuration class.
* Rework `HeaderEnricherFunctionConfiguration` for bean methods autowiring
* Create an `ExpressionEvaluatingHeaderValueMessageProcessor` instances directly
in the `headerEnricher` bean definition and propagate an injected `BeanFactory`
* Re-enable disabled tests
Fixes#369
* GH-348: Resolve knownHostsExpression to Resource
Fixes https://github.com/spring-cloud/stream-applications/issues/348
Currently, SFTP modules use a `FileSystemResource` based on a resolved
location from knownHostsExpression.
This is not always true since the resource could be anywhere, not only in
the target file system.
The typical use-case is classpath or Secrets on the target platform
* Use `ResourceLoader` to resolve a location from the expression
to any possible `Resource`
* Disable DB init for JDBC Source and Sink
The `IntegrationAutoConfiguration` provides mechanism
to initialize DB with some out-of-the-box scripts.
The default behavior is `EMBEDDED` even if we don't use
any components for those DB objects, e.g. no `JdbcMessageStore` bean.
* Add `spring.integration.jdbc.initialize-schema=NEVER` to the
`jdbc-consumer` and `jdbc-supplier` to not attempt to initialize DB
* Fix Checkstyle violations in other modules
* 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
