Fixes: https://github.com/spring-cloud/spring-functions-catalog/issues/107
When we have a composition like this:
```
spring.cloud.function.definition = fileSupplier|splitterFunction
```
Then final "function" signature is like this `Supplier<Flux<Message<List<Message<?>>>>>`.
And that is exactly what we don't expected from the splitter in the end of the composition.
While Spring Cloud Stream supports de-batching, it works for a `List` output only if function is bound by itself.
In case of composition we got just a `Supplier`.
* Rework `SplitterFunctionConfiguration` for `splitterFunction` from `Function<Message<?>, List<Message<?>>>`
to `Function<Flux<Message<?>>, Flux<Message<?>>>` signature to support every possible simple and composed bindings
in Spring Cloud Stream
* Rework `SplitterFunctionApplicationTests` for new expected `Function<Flux<Message<?>>, Flux<Message<?>>>` signature
* Rework `zip-split-rabbit-binder` sample to not use a `flattenFunction` workaround
and fully rely on whatever is new for the `splitterFunction`
* Fix `ZipSplitRabbitBinderApplicationTests` moving the `@RabbitListener` into a `@TestConfiguration`.
Apparently in a new Spring Boot version the test class is registered as a bean much later than normal application context startup.
Therefore, even if the `@RabbitListener` parsed and registered properly, the `RabbitAdmin` bean
has been already started to see our extra bean definition for the `@QueueBinding`
Changing signature for the splitterFunction to reactive types would make it working even with a Supplier composition.
Fix JDBC & MongoDB suppliers to deal with a new version of Splitter function
Fix Checkstyle violations
Use `IntegrationReactiveUtils.messageSourceToFlux()` API
The `IntegrationReactiveUtils.messageSourceToFlux()` provides convenient API to represent a `MessageSource`
as a `Flux` to poll this source.
The API has an error handling logic and delay when no data emitted by the source
* Remove `org.springframework.cloud` dependencies from the project
since we don't use `@PollableBean` anymore, which comes from the `spring-cloud-function-context`
* Simplify `JdbcSupplierConfiguration` and `MongodbSupplierConfiguration` code more: more injections to the respective bean method.
* Use `(__) ->` lambda syntax for unused argument
* Remove unused `ThreadLocalFluxSinkMessageChannel` internal class
* Update Copyrights of the classes in this change
Upgrade to Gradle `8.12`
* Upgrade to the latest dependencies
* Remove wrong JMS dependencies from the `spring-twitter-supplier`: there is really nothing to do with JMS
* Fix `CassandraTestContainer` to use new `CassandraContainer` class version: essentially, a deprecation of the previous one has led here
* Remove `apicurio` dependencies from the `spring-debezium-autoconfigure`.
We really don't need them for our logic and if there is a requirement in the target project, they can add such a dependency manually.
* Remove `commons-compress`, `avro` & `json` dependencies from the `spring-debezium-supplier`,
since they are just transitive dependencies for not any managed `apicurio` dependency
* Add explicit version for the `com.squareup.okhttp3:mockwebserver` since Spring Boot does not manage this dependency anymore
* Use Hazelcast `5.4.0` version since managed by Spring Boot `5.5.0` has a CP subsystem as a commercial offering only
* `@MockBean` to `@MockitoBean` in the `AbstractAwsS3ConsumerMockTests` since the first one is deprecated in Spring Boot, in favor of the second one
* Fix `ZeroMqConsumerConfiguration` to start `ZeroMqMessageHandler` from the `Flux` of function input
* Upgrade samples to the latest dependencies
Fixes: https://github.com/spring-cloud/spring-functions-catalog/issues/106
The `AbstractMessageSplitter messageSplitter` injection is too wide,
and if target application has its own splitter bean, it becomes as a candidate.
Since `SplitterFunctionConfiguration` expects only its own beans, rework the logic for `@Qualifier`
and `Optional` to be explicit for expected beans from the `SplitterFunctionConfiguration`.
* Remove `MessageChannel` beans whenever their really don't need to be exposed into the target application context.
Use local property definition instead in the configuration class
* Make Twitter `Consumer` configurations conditional on their required properties
to avoid auto-configuration for those bean which are not going to be used in the target application
This commit updates the spring-boot-dependencies version to `3.3.0-M1`.
This update also transitively updates the AssertJ core library to
version `3.25.1` which introduces a deprecation for
`AbstractAssert#toList`. As such, these deprecated usages are replaced
in several tests with `AbstractAssert#asInstanceOf`.
Resolves#10
This commit removes the following Tensorflow 1.0 related modules:
- spring-tensorflow-common
- spring-image-recognition-function
- spring-object-detection-function
- spring-semantic-segmentation-function
These may be resurrected at a later date but re-implemented with
either DeepJavaLibrary or TensorFlow 2.0.
* Remove Tensorflow modules from README.adoc
* Remove protobuf - was only used by Tensorflow
* Fix Checkstyle violations in this module
* Make all the Twitter function auto-configurations as conditional on their specific properties
to avoid extra beans not expected in the target application
* Fix README respectively
* Also make a `spring-spel-function`, `spring-filter-function` as auto-config
* Fix Checkstyle violations in those module, as well as in the `spring-payload-converter-function`
* Add `spring-` prefix to function names
Fixes: #9
This commit renames each sub-module in the common, consumer, function
and supplier groups with a prefix of `spring-`.
* Update README.adoc links to new prefixed names
* Add `com.github.spotbugs` plugin to avoid warnings about missed nullability annotations
* Make `TimeSupplierConfiguration` as an auto-configuration
* Add `io.debezium:debezium-bom` as the first one to let others override its deps versions
* Move `org.springframework.boot:spring-boot-dependencies` after `io.awspring.cloud:spring-cloud-aws-dependencies`
to override its deps versions (e.g. `jakarta.mail` `1.0.0` > `2.0.2`)
Fixes https://github.com/spring-cloud/stream-applications/issues/500
When `listeners` are provided for `DefaultKafkaConsumerFactory`,
the target `KafkaConsumer` instance is proxied.
The `java.lang.reflect.Proxy` is `Serializable`,
but the value it is wrapping is not.
When the `MessageHeaders` is serialized (e.g. into persistent `MessageStore`),
it checks for `Serializable` type only on top-level object of the header.
Therefore, the `Proxy` is passing condition, but eventually we fail
with `NotSerializableException`, since the proxied object is not like that
* Remove `kafka_consumer` from a message before it reaches an aggregator
with its logic to serialize message into the store
This is a workaround until Spring for Apache Kafka is released
with the fix: https://github.com/spring-projects/spring-kafka/pull/2822
Fixes https://github.com/spring-cloud/stream-applications/issues/275
Many functions make use of `ComponentCustomizer` ot let end-user
to provide any custom configuration for target component used by the function.
First of all for use-case which are not covered by standard configuration
properties and secondly for those options which cannot be represented
as a configuration option.
* Add a sentence to READMEs of those functions which make use of `ComponentCustomizer`
with an expected generic argument type
* Add README into `rabbit-supplier` where it is fully missed at the moment
Add `JsonBytesToMap` function to allow conversion between byte[] and JSON Map.
Fixes https://github.com/spring-cloud/stream-applications/issues/441
* Introduce a `JsonBytesToMap` as a part of a `payload-converter-function` module
which is auto-discovered by Spring Cloud Function scanning algorithm - the `functions` package.
* Add a `payload-converter-function` as dependency into an `aggregator-function`
* Compose `jsonBytesToMap|aggregatorFunction` for the `aggregator-processor`
* Verify a `JsonBytesToMap` function in action with an `AggregatorProcessorTests`
* Mentioned such a payload conversion in the `aggregator-processor` README
