splitter: 1.0.0-spring-ingetration - fixed the ordering of the messages

* Added a `ChannelInterceptor` to the `KafkaSubscribableChannel`, that
  adds the value of the `key`-Header as Header `kafka_messageKey`).
* This fixes the ordering, because now, all words, that are split of from
  a recording of a user are send with the same key.

splitter: 1.0.0-spring-ingetration - test case for the order of messages

* Refined the tests, to show the disturbed order of the received messages.
* Sending more words.
* Added a new test, that sends recordings for several users.

splitter: 1.0.0-spring-ingetration - added an interceptor for logging

* Added a global interceptor, that uses `WireTap` to copy the messages
  to a special channel for logging, named `messageLog`.
* Added a `LoggingHandler`, that logs the messages, that are accumulated
  in the new channel `messageLog`.

splitter: 1.0.0-spring-ingetration - kafka-backed channels

* This configuration uses `SubscribableKafkaChannel` to configure
  kafka-backed channels for the message-channels `recordings` and `words`.
* Since the header `kafka_messageKey` is not set, the messages are send
  with `null`-keys. Hence, the order of the messages will be lost for
  topics with more than one partition.

splitter: 1.0.0-spring-ingetration - extract the key on the inbound channel

* The key of the Kafka-Message is extracted on the inbound channel with
  a `HeaderEnricher`.
* This way, the key is propagated to dreived messages automatically.

splitter: 1.0.0-spring-ingetration - message-driven channel-adapter

* Instead of the `@InboundChannelAdapter`-annotation, a
  `KafkaMessageDrivenChannelAdapter` can be instanciated.
* The adapter takes a `AbstractMessageListenerContainer` as constructor
  argument.
* The output-channel must be set explicitly on the created instance.
* This approach is advantageous, if technical details are important,
  because the used `MessageListenerContainer` can be configured explicitly.

splitter: 1.0.0-spring-ingetration - using a `message-key-expression`

* The configuration can be simplified
* The `ChannelInterceptor` can be omitted, if a `message-key-expression`
  is specivied for the outbound channel.

splitter: 1.0.0-spring-integration - refactored configuration

splitter: 1.0.0-spring-integration - Added the key of the incoming message

* Added a `ChannelInterceptor`, that copies the key from the received
  message to the outgoing message.
* This fixes the test.

splitter: 1.0.0-spring-integration - Inital implementation (incomplete)

* "Implementing" the splitter with Spring Integration mainly is a
  configuration task.
* This version does not yet send the messages with the correct key.
* Managment of transactions is not yet considered.
* The test fails, because the key is missing.

splitter: Implemented a test that proofs the splitting process

splitter: 1.0.0-vanilla-kafka - Fixed shutdown

* The shutdown was blocked, because tSplitterStreamProcessor.stop()
  was called twice.
* The second time, it could no longer reach the cluster, hence, blocking
  the shutdown process.

splitter: 1.0.0-vanilla-kafka - Factored out splitting logic

splitter: 1.0.0-vanilla-kafka - Fixed the test "Context Loads"

* Added `spring-kafka-test` as dependency.
* Added `@EmbeddedKafka` to the integration test.
* Configured the test to support transactions (replication factor == 1).
* Fixed the `SplitterStreamProcessor`: the application logic is executed
  in a background thread, because it blocks the startup of Spring Boot
  otherwise.

splitter: 1.0.0-vanilla-kafka - upgraded Spring Boot to 2.7.2

splitter: 1.0.0-vanilla-kafka - splits up the recorded sentences into words

* Simple implementation of the splitter without Kafka Streams
* This version does not record its position
* Hence, in case of an error, it will most likly reprocess some messages,
  leading to wrong countings

recorder: 1.0.1 - changed default-port and exposed all actuator-endpoints

recorder:1.0.0 - send recordings keyed by username

Generated empty project on start.spring.io