Handling der Nachricht in das Interface `RecordHandler` verlegt

Version des ``spring-consumer``, der Deserialisierungs-Fehler überspringt

Version des ``spring-consumer``, die ``long``-Werte erwartet

Das Docker-Setup verwendet den `spring-producer`

* Die Konfiguration wurde außerdem so überarbeitet, dass der Producer
  mehr Nachrichten verschickt (ca. 10 Nachrichten pro Sekunde) und diese
  in Batches à ca. 6 Nachrichten verpackt.

Ungefangene Exceptions im `ExampleConsumer` lösen das Beenden der App aus

Fix: `close()` muss noch vom `ExampleConsumer` aufgerufen werden

* Der Aufruf von `close()` löst die Abmeldung der Instanz bei dem
  GroupCoordinator aus.
* Dieser Vorgang sollte noch unter der Kontrolle des Anwendungscodes
  erfolgen!
* Wenn die Methode erst von Spring aufgerufen wird, werden dann ggf. noch
  Seiteneffekte ausgelöst, die dann noch im Kontext der Instanz laufen,
  obwohl diese eigentlich schon beendet wurde!

Consumerspezifische Properties werden in eigener nested Class verwaltet

* Dadurch wird der Code übersichtlicher, wenn spätere Implementierungen
  _sowohl_ als Consumer, _als auch_ als Producer agieren!

`ExampleConsumer` in eine Spring-Boot App umgebaut (ohne Spring Kafka)

Handling der Records wie in abgeleiteten Versionen in eigener Methode

`metadata.maxage.ms` auf 5 Sekunden heruntergesetzt

`simple-producer` in `simple-consumer` verwandelt -- ALIGN

`simple-producer` in `simple-consumer` verwandelt -- COPY

`metadata.maxage.ms` auf 5 Sekunden heruntergesetzt

Bei einem unerwarteten Fehler wird auch der Stacktrace mit ausgegeben

Der Nachrichten-Wert wird in allen Log-Meldungen mit ausgegeben

Logging-Pattern überarbeitet

Unnötige Kommandos aus der `README.sh` entfernt

`docker` in `simple-producer` verwandelt`

`log.retention.check.interval.ms` auf 10 Sekunden gesetzt

``version``-Eintrag in `docker-compose.yml` entfernt

"Final Newline" in `.editorconfig` gefordert (scheint vim zu entsprechen)

`.gitignore` und `.editorconfig` hinzugefügt

Schreibweise des CLI-Kommandos für Docker-Compose korrigiert

Upgrade der verwendeten Kafka-Images auf 7.7.1

ZooNavigator in den Demo-Stack aufgenommen

`README.sh` bricht ab, wenn `setup` nicht erfolgreich ist!

Start von Service `setup` startet auch `cli`

Der Service `setup` wartet bereits auf den Cluster

Grace-Period für Broker und cli/setup gesetzt

Schönere YAML-Syntax für `setup`-Service

Services `schema-registry` und `connect` hinzugefügt

Hilfs-Services `setup` überarbeitet

Volumes für die Log-/Config-Daten und Zookeeper hinzugefügt

Setup zurück auf Confluent (Version 7.5.1) mit Zookeeper umestellt

AKHQ auf einen eindeutigeren Port verlegt

Automatisches entfernen von Orphans beim Start

Docker-Setup in das Unterverzeichnis `docker` verschoben

Docker-Setup auf `bitnami/kafka:3.4` aktualisiert und vereinfacht

* Die Konfiguration musste an (undokumentierte?!) Änderungen in der
  version 3.4 von `bitnami/kafka` angepasst werden.
* Die drei Broker spielen jetzt gleichzeitig Controller. D.h., der
  Service `kafka-0`, der explizit Controller gespielt hat, fällt weg.

Bedienbarkeit des Setups verbessert

* Setup starten mit `docker-compose up -t0 -d cli`
** Dabei wird _nicht_ automatisch das Topic `test` neu angelegt
** D.h., die Daten gehen nicht unbeabsichtigt verloren, wenn man mit
   `up -d` prüft, ob noc alles läuft!
* Das Topic `test` kan mit `docker-compose restart -t0 setup` explizit
  gelöscht und neu angelegt (aka geleert) werden.

`docker-compose up setup` startet auch die cli

AKHQ zu dem Basis-Setup hinzugefügt

Compose-Setup auf bitnami mit KRAFT umgestellt

* Setup aus Unterschied zu `spring-consumer--json--adder` übernommen.
* Auch das `README.sh` entsprechend angepasst.

Für ordering-Übung werden zwei Partitionen benötigt!

Setup mit 3 Broker und Topic-Erzeugung mit Setup für acks-Übung

Merge der Upgrades für Confluent/Spring-Boot (Branch 'first-contact')

Upgrade von Spring Boot und den Confluent-Kafka-Images

* Upgrade der Kafk-Images von Confluent 7.0.2 auf 7.1.3
** Unterstützt Kafka 3.1.x (siehe https://docs.confluent.io/platform/current/installation/versions-interoperability.html[Versions-Matrix])
* Upgrade für Spring Boot von 2.6.5 auf 2.7.2
** Enthält Kafka: 3.1.1
** Enthält Spring Kafka: 2.8.8

Setup aus der Intro-Übung übernommen

Setup "entkernt": Implementierungen entfernt

Upgrade der Images von Confluent 6.2.0 auf 7.0.2

README.sh verwendet den cli-Service für Kommandos

Fälschlich hartkodiertes Topic gegen Variable getauscht

Code reorganisiert, um Änderungen vergleichbarer zu machen

Upgrade für Spring Boot 2.6.0 -> 2.6.5

* Kafka: 3.0.1
* Spring Kafka: 2.8.4

First Contact: Simple Producer & Consumer