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

Spring Boot von 2.6.5 auf 2.7.1 aktualisiert

Überflüssige Abhängigkeit entfernt

Das Topic wird über `spring.kafka.template.default-topic` konfiguriert

Das erzeugen des `ProducerRecord` wird dem `KafkaTemplate` überlassen

Für das Versenden wird das `KafkaTemplate` von Spring verwendet

* Dabei wird weiterhin ein `ProducerRecord` erzeugt und dem
  `KafkaTemplate` übergeben, um die Änderungen möglichst übersichtlich
  zu halten.
* Die zuvor über `ApplicationProperties` einstellbaren Parameter wurden
  in der `application.yml` entsprechend in dem `spring.kafka.*`-Namespace
  gesetzt.
* Eintragung in den per Actuator veröffentlichten Infos angepasst.

Für PUT anstelle von POST wird eine `FooMessage` als `foo` verschickt

Setup für die Demonstration des Springfied-Producer überarbeitet

Für den Nachrichten-Schlüssel wird `.trim()` aufgerufen

Springify: Can send multiple types of messages

* `ClientMessage` is send as `message`
* `Greeting` is send as `greeting`

Name und Beschreibung in POM getrennt

Springify: Type-Mapping für den Nachrichten-Typ ergänzt

Springify: Der Payload ist eine als JSON gerenderte Klasse

* Als Nachricht wird eine Instanz der Klasse `ClientMessage` verschickt
* Die Instanz wird mit Hilfe des `JsonSerializer` von Spring Kafka
  serialisiert.

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!

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