Der einzige Weg ist, geduldig zu sein...

* Die Logs der Broker sehen so aus, als ob das Topic im Fehlerfall von
  diesen als "nie angelegt" betrachtet wird, weil der für das Löschen
  des alten Topics zuständige Broker zu früh stopt und beim Neu-Verteilen
  dieser Aufgabe fälschlich das unter dem selben Namen neu erzeugte Topic
  gelöscht wird.
* Alle Versuche, dies durch Schreiben in das Topic zuverlässig zu
  verhindern, sind ins leere gelaufen.
* Helfen tut allein, nach dem Aufruf des `setup`-Services etwas zu
  warten, bis sich die Broker alle einig sind.

Vergeblicher Versuch, sicher zu stellen, dass das Topic bereit ist

Nicht benötigte Ausgaben entfernt

Sichergestellt, dass das neu erzeugte Topic angesprochen wird

mvn clean aus README.sh entfernt

Anpassungen an Setup und README.sh aus Branch 'origin/rest-producer'

Das Logging so überarbeitet/umkonfiguriert, dass man den Fehler sieht

Setup und README.sh für rest-producer überarbeitet

* Setup an das Ausgangs-Setup angeglichen.
* Das Setup verwendet jetzt `kafkacat` als Consumer.
* Das README.sh entsprechend der Übung und der Änderungen angepasst.

Compose-Setup an das Setup aus der Einführung angepasst

Später benötigten Konfiurations-Parameter `partition` hinzugefügt

Später benötigten Header zum Postmapping hinzugefügt

Merge der überarbeiteten Compose-Konfiguration ('setup-acks')

Merge der überarbeiteten Compose-Konfiguration ('setup-producer')

Merge der überarbeiteten Compose-Konfiguration ('rest-producer')

Merge der überarbeiteten Compose-Konfiguration ('endless-stream-producer')

Compose-Konfiguration unabhängig von Default-Konfiguration gemacht

* Damit Instanzen parallel über die IDE (mit voreingestelltem Default-Port)
  und Compose gestartet werden können, wurden den einzelnen Komponenten
  (Producer, Consumer etc.) jeweils unterschiedliche explizite
  Default-Ports zugewiesen.
* Dies führt leicht zu fehlern, in den Compose-Setups, da dort i.d.R.
  Port-Mappings für die gestarteten Instanzen definiert werden.
* Daher werden die Compose-Setups jetzt so umgestellt, dass sie den
  einkompilierten Default-Port der Komponenten explizit mit dem Port `8080`
  überschreiben, so dass alle Komponenten _innerhalb_ von Compose
  einheitlich (und so wie bei Spring-Boot standard) über `8080` ansprechbar
  sind.

Merge der Upgrades für Confluent/Spring-Boot (Branch 'acks-übungen')

Merge der Upgrades für Confluent/Spring-Boot (Branch 'producer-übungen')

Merge der Upgrades für Confluent/Spring-Boot (Branch 'rest-producer')

* Eigentlich lässt sich hier leichter der Branch 'first-contact' mergen
* Da es aber Verbesserungen des Setups im Branch 'rest-producer' gab,
  wurde dieser gemerged.

Merge der Upgrades für Confluent/Spring-Boot ('endless-stream-producer')

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

Name und Beschreibung in POM getrennt

Testfall, der die API aufruft und prüft, ob Nachrichten versendet werden

* Der Testfall verwendet `spring-kafka` als Abhängigkeit mit dem Scope
  `test`.
* Dies zeigt ein nicht zu unterschätzendes Anwendungsfeld für Spring
  Kafka, seblst wenn das eigentliche Projekt gar nicht auf Spring Kafka
  aufsetzt: Einfache Implementierung von Integration-Tests.

Info-Endpoint des Actuator korrigiert

* Der `kafka`-Eintrag hatte noch den veralteten Parameter `throttle-ms`
  des Endless Consumer enthalten
* Der `kafka`-Eintrag hatte noch nicht alle über `ApplicationProperties`
  konfigurierbaren Parameter ausgegeben.

Merge branch 'endless-stream-producer' into rest-producer

shutdown-Endpoint aktiviert

Informationen zur Kafka-Konfiguration im info-Endpoint sichtbar gemacht

Informationen zur Java-Umgebung im info-Endpoint aktiviert

Das Git-Commit-Id-Plugin generiert eine git.properties

Das Spring-Boot-Maven-Plugin generiert Build-Info

Default-Konfiguration überarbeitet

* Eine über die IDE bzw. Maven gestartete Instanz soll klar als solche
  erkennbar sein (`client.id` = DEV).
* Bisher gab es häufig Port-Konflikte, wenn über die IDE bzw. über Maven
  parallel zu einem Compose-Setup eine Instanz gestartet wurde. Daher wird
  jetzt hier explizit auf einen abweichenden Port (8880) ausgewichen.

Falschen Status-Code bei start/stop-Fehler korrigiert

Setup von counting-consumer auf endless-consumer umgestellt

* Da der Counting-Consumer von den Teilnehmern als Verbesserung des
  Endless-Consumer entwickelt wird, sollte dieser auch unter der selben
  Artefakt-ID abgelegt wird
* Ansonsten kommt es bei der Ausführung späterer Setups ggf. zu Fehlern,
  wenn diese weiterhin die Abweichende Artefakt-ID counting-consumer
  enthalten, obwohl folgende Verbesserungen wieder unter endless-consumer
  entwickelt wurden!

Setup von counting-consumer auf endless-consumer umgestellt

* Da der Counting-Consumer von den Teilnehmern als Verbesserung des
  Endless-Consumer entwickelt wird, sollte dieser auch unter der selben
  Artefakt-ID abgelegt wird
* Ansonsten kommt es bei der Ausführung späterer Setups ggf. zu Fehlern,
  wenn diese weiterhin die Abweichende Artefakt-ID counting-consumer
  enthalten, obwohl folgende Verbesserungen wieder unter endless-consumer
  entwickelt wurden!

Tags für die Übung ergänzt

Experimente zu acks-0 aus der Übung entfernt, weil sie nicht funzten

Setup für die Übungen "acks"

Basis-Setup für die acks-Übungen

Basis-Setup für Übungen zur Producer-Konfiguration

HTTPie gibt nicht nur den Response, sondern auch den Request aus

Merge des Upgrades der Confluent-Images auf 7.0.2

Merge des Upgrades der Confluent-Images auf 7.0.2

Upgrade der Images von Confluent 6.2.0 auf 7.0.2

Delivery-Timeout für den REST-Producer herabgesetzt

* Der Timeout für `delivery.timeout.ms` wurde von 2 Minuten auf 20
  Sekunden heruntergesetzt
* Grund: Die HTTP-Verbindungen der Clients laufen nach 30 Sekunden in
  den Default-Timeout, so dass die Fehler sonst nicht sichtbar werden!
* Achtung: Parallel musste dafür `request.timeout.ms` auf 10 Sekunden
  herabgesetzt werden, da `delivery.timeout.ms` größer oder gleich
  `request.timeout.ms` + `linger.ms` sein muss!
* Die 10s Spiel zwischen `delivery.timeout.ms` und `request.timeout.ms`
  werden für die Übungen benötigt, in denen mit `linger.ms` experimentiert
  werden soll...

Setup für die Demonstration des Rest-Producers überarbeitet

EndlessProducer in RestProducer umgearbeitet

* Der Producer nimmt die zu versendende Nachricht über ein POST entgegen
* Als Schlüssel wird der Pfad des POST-Aufrufs verwendet
* Die Anfragen werden mit einem DeferredResult asynchron verarbeitet
* Der Producer antwortet erst mit 200-OK, wenn die Nachricht bestätigt wurde
* Wenn der Broker mit einem Fehler antwortet, wird 500 zurückgegeben
* Wenn der Broker nicht erreicht werden kann, wird 400 zurückgegeben

EndlessProducer in RestProducer umbenannt

* Ohne die Umbenennung _vor_ der Veränderung würde die Versions-Historie
  der Klasse verloren gehen!

Korrekturen des README-Skriptes auf first-contact übernommen

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

Fehlerkorrektur aus first-contact gemerged

Fälschlich hartkodiertes Topic gegen Variable getauscht

Verständliche Fehlermeldungen für DriverController

Synchronisation bei Start/Stop repariert und Ausgabe für Fehler ergänzt

Reorganisierten Code aus first-contact gemerged

SimpleProducer in Endless Producer umbenannt

* Nötig, um die GIT-Historie zu reparieren, so dass Änderungen über die
  Umbenennung hinaus von GIT erkannt werden können.

Code reorganisiert, um Änderungen vergleichbarer zu machen

Obsoletes Klassen-Attribut entfernt

Merge der Aktualisierungen aus first-contact

Upgrade für Spring Boot 2.6.0 -> 2.6.5

* Kafka: 3.0.1
* Spring Kafka: 2.8.4

Endless Producer: a simple producer, implemented as Spring-Boot-App

First Contact: Simple Producer & Consumer