TMP
--
Als Holzweg erachtet.
Es ist eigentlich viel einfacher, nur einen Thread zu pfelgen.
Das sollte mit weniger Boilerplate-Code möglich sein, als dieser Ansatz.
Der eigentlich Auslöser für den Abbruch war aber ein mysteriöses Problem beim Debugging.
Beim Shutdown wurde immer der Default von 30 Sekunden auf die Bean `applicationTaskExecutor` gewartet.
Das macht eigentlich gar keinen Sinn, weil (die letzen verzweifelten Commits) eigentlich noch mal sicher gestellt hatten, dass _alle_ explizit ausgeführten Beans wirklich beendet werden.
Es war also die Frage, auf welche Beans gewartet wird.
Warten tut da `DefaultLifecycleProcessor#stop`.
Genau dort werden die Log-Messages vor und nach den 30 Sekunden produziert.
Hier haben aber die Breakpoints von Intellij nicht gezogen!
Auch in `ExecutorConfigurationSupport` und `ThreadPoolExecutor` nicht!
Daher konnte ich nicht herausfinden, worauf da warum gewartet wird!

TMP

WIP

`rest-producer` in einen `spring-producer` zurückgebaut

GIT-Plugin hinzugefügt

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

Upgrade der verwendeten Kafka-Images auf 7.7.1

Upgrade der Java-Version auf 21

Upgrade des `docker-maven-plugin` auf 0.45.0

Upgrade auf Spring Boot 3.3.4

Racecondition in Test korrigiert

Durch Lombok ausgelösten Kompilierungs-Fehler mit dem JDK 21 korrigiert

Einheitliche Benennung des Producers -- ALIGN

Einheitliche Benennung des Producers -- MOVE

Vereinfachtes setup aus Grundlagen-Übungen übernommen

Implementierung zum Anfügen der Header wiederhergestellt

Setup-Verbesserungen aus grundlagen/docker übernommen

Aktualisierung auf Java 17

`git-commit-id-plugin` stört bei neuem (alten) Setup für Musterlösungen

AKHQ auf einen eindeutigeren Port verlegt

Übung überarbeitet: Gegenüberstellung von Key-Hashing und Fixed

Automatisches entfernen von Orphans beim Start

Implementierung der Header entfernt - Übung kommt jetzt später

Übung an die Docker-Übung angepasst

Docker-Setup in das Unterverzeichnis `docker` verschoben

Beispiele verwenden das Interface, um die erzeugte Instanz abzulegen

Tags für die Übung ergänzt

README.sh & Setup für die Übung `rest-producer--partitioning` umgestellt

Setup & Vorführskript verbessert und Tags für Übung ergänzt

Verbesserungen an Vorführskript aus producer/simple-producer übernommen

.editorconfig hinezugefügt

Compose-Setup auf KRAFT mit bitnami-Images umgestellt

Ausführung von README.sh resilienter

Validierung für ApplicationProperties aktiviert

refactor: `RestProducer` wird explizit erzeugt

* `ApplicationConfiguration` eingeführt.
* Um eine bessere Kontrolle über die verwendeten Parameter zu erhalten,
  wird `RestProducer` jetzt explizit in `ApplicationConfiguration` erzeugt.
* `KafkaProducer` wird in `ApplicationConfiguration` erzeugt und in
  `RestProducer` hereingereicht.

Merge der überarbeiteten Compose-Konfiguration (Branch 'customized')

Überarbeitungen von Setup/Übung aus Branch 'rest-producer' gemerged

* Überarbeitungen an die Übung 'customized' angepasst.

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.

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

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

Merge der überarbeiteten Compose-Konfiguration ('customized')

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 'customized')

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

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

Merge branch 'rest-producer' into customized

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

Der REST-Producer ergänzt Header (Header `X-id` und seine `client.id`)

Der Rest-Producer schreibt in eine fixe Partition, wenn so konfiguriert

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