Version mit nur einer Handler-Methode

`JsonDeserializer` ohne `ErrorHandlingDeserializer`

* Der `ErrorHandlingDeserializer` wird nicht nur benötigt, um die
  Informationen aufzuzeichnen, auf deren Basis der
  `DeadLetterPublishingRecoverer` die fehlgeschlagenen Nachrichten für
  das Dead-Letter-Topic serialisiert.
* Er sorgt auch dafür, das ein Fehler nur einmal aufschlägt.
* Ohne den `ErrorHandlingDeserializer` gerät die Anwendung daher in
  eine Endlosschleife, wenn eine Poison-Pill auf den `JsonDeserializer`
  trifft, und kommt aus dieser auch durch einen Neustart nicht mehr
  heraus!

DLT-Konfiguration aus der vereinfachten Version entfernt

* DLT-Konfiguration entfernt, um zu einer möglichst einfachen
  Anfangs-Lösung zu gelangen.

Throttling aus dem `ApplicationRecordHandler` entfernt

* Den Mechanismus zum künstlichen Ausbremsen der Verarbeitung und die
  zugehörige Konfigurations-Option aus dem `ApplicationRecordHandler`
  entfernt, um zu einer möglichst einfachen Anfangs-Lösung zu gelangen.

Vereinfachte Version der auf Spring Kafka basierenden Implementierung

Service ergänzt, der das Dead-Letter-Topic ausliest

Test repariert: Explizite Consumer-Konfiguration für DLT-Consumer

* Der `DeadLetterTopicConsumer` wird jetzt explizit mit einem Consumer
  konfiguriert, der alle Nachrichten schlicht als `String` deserialisiert.
* Dadurch kommt es beim Einlesen der Nachrichten nicht mehr zu Fehlern
  und der Test arbeitet wie erwartet.
* Die Definitionen des Type-Mappings für den Producer werden daher
  nicht mehr benötigt.

Der Test prüft die Anzahl der Einträge im DLT

* Der Test schlägt fehl, weil die Überprüfung aufdeckt, dass der
  `DeadLetterTopicConsumer wegen einer Fehlkonfiguration nicht in der
  Lage ist, die Poistion-Pill-Nachrichten einzulesen.
* Dies liegt daran, dass er die Consumer-Konfiguration der Anwendung
  verwendet und deswegen auch genau wie diese am Deserialisieren dieser
  Nachrichten scheitert.

@KafkaListener im Test ergänzt, der das DLT mit liest

DLT auf Basis des `DeadLetterPublishingRecoverer` konfiguriert

* Der `DeadLetterPublishingRecoverer` muss explizit instanziiert werden.
* Um ihm den Spring-Kafka-Beans bekannt zu machen, muss die
  `DefaultErrorHandler`-Bean überschrieben werden.
* Der Recoverer wird dem Handler zusammen mit einer BackOff-Strategie
  übergeben.
* Damit der `DeadLetterPublishingRecoverer` die weiterzuleitenden
  Nachrichten senden kann, muss
* Der Producer benötigt scheinbar einen separaten Eintrag für
  `bootstrap-servers` unter `spring.kafka.producer`. Der Eintrag
  `spring.kafa.bootstrap-servers` wird hier nicht übernommen!

Anzahl der Fehler für die Test-Logik verfügbar gemacht

Anwendung auf den Default-ErrorHandler umgestellt

* Die Tests mussten entsprechend angepasst werden, da die Methode
  `EndlessConsumer.exitStatus()` aufgrund der Umstellung nicht mehr
  verfügbar ist.
* Die Logik der Tests wurde aber nicht geändert.
* Die Tests zeigen nur, dass die Anwendung sich nicht wie zuvor beendet.
* Durch manuelle Versuchen wurden folgende Erkenntnisse gewonnen:
** Im Fall eines Deserialisierungs-Fehlers begibt sich die Anwendung in
   eine Endlosschleife.
** Da, in der Fehlersituation keine Commits durchgeführt werden, hängt
   die Anwendung dann auch nach einem Neustart weiter in der
   Fehlerschleife.
** Im Fall eines Logik-Fehlers Startet ein Back-Off mit 10 Versuchen.
** Dabei werden nach jedem Fehler die Offsets für alle Partitionen für die
   der letzte `poll()` Nachrichten geliefert hatte, die noch nicht
   verarbeitet wurden, auf die nächste unverarbeitete Nachricht zurück
   gesetzt und anchließend wird `poll()` neu ausgeführt.
** Nach dem letzten Versuch springt die Anwendung über den Fehler hinweg.

`EndlessConsumer` auf `@KafkaHandler` umgestellt

* Mit `@KafkaHandler` können separate Handler-Methoden für die
  unterschiedlichen Nachrichten-Typen definiert werden, die die
  Anwendung empfängt (hier: über ein Topic, auch mögich: über
  verschiedene Topics).
* Die Tests mussten an die geänderte Implementierung angepasst werden.

`EndlessConsumer` nimmt jetzt einzelne `ConsumerRecord`s entgegen

* `@KafkaHandler` von Batch-Verarbeitung auf Einzel-Verarbeitung umgestellt.
* Den `ApplicationErrorHandler` um eine passende Fehler-Verarbeitung für
  die einzelne Verarbeitung der Nachrichten ergänzt
* Da der `MessageListenerContainer` nicht dazu zu bewegen ist, die
  Offset-Commits im Fehlerfall zu unterlassen, wird explizit ein Seek auf
  die Offset-Positionen der noch nicht verarbeiteten Nachrichten
  durchgeführt.
* Dabei wurde ein von Spring Kafka abgeschauter Trick verwendet: Es genügt,
  die bisher unverarbeiteten Nachrichten durchzugehen und jeweils den
  Offset der ersten Nachricht, die zu einer Partition gesehen wird, für
  den Seek vorzumerken. Denn wenn dabei für eine Partition keine Nachricht
  gefunden wird, hat entweder das letzte `poll() keine Nachricht zu der
  Partition geliefert, oder alle Nachrichten, die zu der Partition gehört
  haben, wurden erfolgreich verarbeitet. In beiden Fällen stimmt der
  Offset bereits, den die Kafka-Bibliothek intern pflegt, so dass kein
  Seek durchgeführt werden muss!
* Der Testfall wurde entsprechend angepasst und läuft daher in dieser
  Variante auch ohne Fehler, da der gespeicherte Zustand dadurch zu den
  bestätigten Offsets passt.

Auf `@KafkaHandler` umgestellt

* Die Autoconfiguration über die Annotation `@EnableKafka` aktiviert
* Da die Autoconfiguration von Spring Kafka zieht, vereinfacht sich die
  Konfiguration:
** Spring Kafka erzeugt den benötigten `MessageListenerContainer`, der
   für die Anbindung der mit `@KafkaHandler` annotierten Methode
   benötigt wird automatisch und versorgt ihn mit einem passenden
   `KafkaConsumer`, so dass letzterer nicht mehr explizit erzeugt werden
   muss.
** Der Scheduler wird von Spring Kafka erzeugt und verwaltet, so dass
   nicht mehr explizit ein `ExecutorService` erzeugt und beendet werden
   muss.
** Der Rebalance-Listener wird automatisch eingebunden, der
   `ApplicationRebalanceListener` muss allerdings von der richtigen
   Spring-Klasse ableiten, damit er von der Autoconfiguration gefunden
   wird.
* Um das von dem Testfall erwartete Default-Verhalten des `KafkaConsumer`
  mit dem `MessageListenerContainer` zu simulieren, musste ein
  angepasster `ErrorHandler` implementiert werden.
* Der Code zum Exception-Handling und zum Schließen des `KafkaConsumer`
  in `EndlessConsumer` entfällt.
* Der Code zum Starten/Stoppen in `EndlessConsumer` kann einfach die
  entsprechende Methoden des `MessageListenerContainers aufrufen. Dafür
  muss er allerdings erst die passende Instanz aus einer Registry über
  die Client-ID erfragen.
* Der Testfall musste an die Autoconfiguration angepasst werden:
** Die `KafkaAutoConfiguration` muss hier explizit eingebunden werden.
** Da auch der Test einen `KafkaConsumer` benötigt, muss die in der
   Anwendung nicht mehr benötigte Factory jetzt explizit für den Test
   bereitgestellt werden.

Der Test verwendet die `@Bean` von `EndlessConsumer`

* Per `git cherry-pick` vom Branch `deserialization` gepflückt.
* Conflicts:
** src/main/java/de/juplo/kafka/ApplicationConfiguration.java
** src/test/java/de/juplo/kafka/ApplicationTests.java
** src/test/java/de/juplo/kafka/GenericApplicationTests.java

Springify: Der Kafka-`Consumer` wird über die Spring-Factory erzeugt

* Per `git cherry-pick` aus `springified-consumer--config' übernommen.
* Conflicts:
** src/main/java/de/juplo/kafka/ApplicationConfiguration.java
** src/test/java/de/juplo/kafka/ApplicationTests.java
* Damit Spring Kafka den Consumer instanziieren kann, musste insbesondere
  noch der Teil der Konfiguration, der fix ist, aus der Konfig-Klasse
  `ApplicationConfiguration` in die YAML-Datei `application.yml` verschoben
  werden:
** Die Auswahl des `StickyAssignor` als Partition-Assignment-Strategy
** Die Konfiguration der Deserialisierer

Springify: Konfiguration erfolgt über `KafkaProperties`

* Per `git cherry-pick` aus `springified-consumer--config' übernommen.
* Conflicts:
** src/main/java/de/juplo/kafka/ApplicationConfiguration.java
** src/main/java/de/juplo/kafka/ApplicationProperties.java
** src/main/resources/application.yml
** src/test/java/de/juplo/kafka/ApplicationTests.java
* Anpassungen an `README.sh`, `docker-compose.yml` und `pom.xml` nachgeholt.

Separate Artefakt-/Image-ID für die JSON-Version des requests-Services

* Die Version des Addierer-Services, die JSON-Nachrichten verarbeitet,
  hat jetzt eine explizite eigene Artefakt- und Image-ID.
* Außerdem wurde das Compose-Setup so umgestellt, dass es explizit die
  JSON-Version des Requests- und des Adder-Services verwendet.

Der Adder verarbeitet zwei Typen von JSON-Nachrichten anstatt String

* Bisher waren alle Nachrichten vom Typ `String`.
* Jetzt verarbeitet der Adder zwei unterschiedliche Typen von Nachrichten.
* Die Nachrichten werden als JSON übertragen und mit Hilfe des
  `JsonDeserializer` von Spring Kafka in zwei unterschiedliche
  Spezialisierungen einer Basis-Klasse deserialisiert.
* Die für die Deserialisierung benötigte Typen-Information wird von dem
  Spring-Kafka-Tooling über den die `__TypeId__` transportiert.
* D.h., damit die Nachrichten korrekt deserialisiert werden können, ist es
  _nicht_ nötig, dass der Typ der Nachricht von Jackson aus der Nachricht
  selbst abgeleitet werden kann, sondern dass sich Sender und Empfänger
  darüber verständigen, welchen Hinweis sie in dem `__TypeId__`-Header
  hinterlegen.
* Die Verarbeitung der zwei Nachrichten-Typen wurde in Unter-Methoden
  ausgelagert, da dies die Vergleichbarkeit des Codes zur der Variante
  mit `@KafkaHandler` erhöht.

`maven-failsafe-plugin` aktiviert und den `ApplicationIT` repariert

* Das `maven-failsafe-plugin war nich scharf geschaltet, so dass nicht
  aufgefallen war, dass der Integration-Test `ApplicationIT` wegen
  fehlender Anpassungen gar nicht mehr lauffähig war.
* Anpassungen an dem Integration-Test nachgeholt.

Wechsel auf den `StickyAssignor` löst die Rebalance-Fehler

* Die durch Rebalances ausgelösten Zustand-Fehler bei regulären
  "Staffelübergaben" lassen sich vollständig durch ein Downgrade des
  `CooperativeStickyAssignor` auf den `StickyAssignor` lösen.
* *Achtung:* Der `StickyAssignor` verwendet das Eager-Protokoll.
* D.h., ein Down-Grade auf den `StickyAssignor` benötigt einen Reset
  der Gruppe, ist also nicht per Rolling Upgrade im laufenden Betrieb
  möglich.
* Vorführ-Skript so angepasst, dass man sofort sieht, dass diese
  Version alle regulären Rebalance-Fälle ohne Fehler durchführen kann.

Rückbau auf einen Consumer, der in `onPartitionsRevoked()` nicht committed

* Dadurch sollte es bei einem Rebalance i.d.R. zu Fehlern in dem
  mitgeführten Zustand kommen, da die Verarbeitung nur im Zufall an dem
  Offset fortegführt wird, für den der Zustand gespeichert wurde.
* Um das vorherige Verhalten der Implementierung wiederherzustellen,
  müssen insbesondere die commits im Falle eines ordentlichen
  Herunterfahrens und eines Deserialisierungs-Fehlers wieder
  ergänzt werden. Denn ansonsten bestätigt die Implementierung die
  Offsets für die zuletzt erfolgreich verarbeiteten Nachrichten nicht.
* Vorführ-Skript so angepasst, dass man sofort sieht, dass in dieser
  Version schon eine reguläre "Staffelübergabe" - also auch schon ein
  normales Rebalance, das einfach durch das Starten eines zweiten
  Consumers ausgelöst wurde - ein Fehler auftritt.

Klar erkennbar gemacht, dass Staffelübergabe nur im Regelfall klappt

Vorführ-Skript überarbeitet: Vorgang durch andere Reihenfolge beschleunigt

* Dadurch das beide Consumer 1x ordentlich gestoppt werden, wird sowohl für
  `peter` als auch für `klaus` mal die Resultate in der Mongo-DB gespeichert.
* Da dies zuvor nur für einen der Nutzer geschehen ist, hat das Skript nach
  dem außerordentlichen Beenden eines Consumer sehr lange warten müssen,
  bis nach dem Neustart die Verarbeitung der angelaufenen Daten so weit
  fortgeschritten war, dass erste Resultate für beide Consumer sichtbar
  geworden sind.

Vorführ-Skript überarbeitet: Vereinfachte Abfrage für User-Zustand

Rückbau auf einen Consumer, der in `onPartitionsRevoked()` immer committed

* Entfernt wird hier das erweiterte Interface, für den Rebalance-Listener
  über den die Consumer-Implementierung die Commits für den Fehlerfall
  explizit deaktivieren kann.
* Die Staffelübergabe sollte damit weiterhin normal funktionieren. D.h.,
  solange der Consumer ordentlich heruntergefahren wird und nicht ein
  besonders hohes Nachrichten-Aufkommen angelegt wird.
* Vorführ-Skript so angepasst, dass deutlich wird, dass die
  "Staffelübergabe" nun funktioniert, wenn Consumer ordentlich gestopped
  werden, aber weiterhin Fehler auftreten, wenn ein Consumer
  außerordentlich beendet (hier: getötet) wird.

Funktionsunabhängiger Name für das erweiterte Interface RebalanceListener

Falsch platzierte Methode aus RecordHandler entfernt

`ApplicationRecordHandler` gibt auch die Client-ID aus

* Conflicts:
** src/main/java/de/juplo/kafka/ApplicationRecordHandler.java

Fehler in Test-Implementierung korrigiert

Fehler im Commit-Verhalten korrigiert: Bei Logik-Fehler, kein Commit

* Die Implementierung sieht vor, dass bei einer unerwarteten Exception
  (i.d.R. ein Fehler in der Fachlogik) kein Commit durchgeführt wird.
* Ansonsten müsste in der Situation ein expliziter Seek der Offstes auf
  die Positionen der vor dem Auftreten des Fehlers verarbeiteten
  Nachrichten durchgeführt werden, damit es nicht zu einem Verlust von
  Nachrichten kommt.
* Dieses Verhalten wurde durch die Verlagerung des Commits in den
  Rebalance-Listener unterwandert, da der Commit dort auch im Falle
  einer unerwarteten Exception durchgeführt wurde.
* Als Korrektur wurde hier eine Methode eingeführt, über die der
  Commit im Rebalance in dieser Situation unterdrückt werden kann.

Code an die Implementierung in 'sumup-adder' angeglichen

Im `ConsumerRebalanceListener` _muss_ `commitSync()` verwendet werden

* Genaugenommen ist auch `commitAsync()` möglich.
* Es ist jedoch nicht möglich, wie hier zuvor implementiert, `commitAsync()`
  mit einem `OffsetCallback` aufzurufen, in der Zwischenzeit die restlichen
  Aufräumarbeiten durchzuführen und anschließend auf den Callback zu warten.
* Grund: Die Callbacks werden von Kafka nicht direkt aufgerufen, wenn die
  Ergebnisse eintreffen, sondern erst, wenn das nächste mal `poll()`
  aufgerufen wird.

`commitAsync()` in `onPartitionsRevoked()`

* Der Rebalance-Listener führt jetzt einen (zusätzlichen) Commit der
  Offsets durch.
* Ohne diesen Commit, kann es bei sehr hohem Nachrichten-Aufkommen dazu
  kommen, dass nicht die letztendliche Offset-Position gespeichert wird.
* Da jetzt implizit ein Commit in `onPartitionsRevoked()` durchgeführt
  wird, ist kein expliziter Commit mehr nötig, wenn der Consumer durch
  eine Exception unterbrochen wird, bei der sichergestellt ist, dass die
  zuletzt durch `poll()` gelieferten Nachrichten vollständig verarbeitet
  wurden.
** Bei einer `WakeupException` ist dies klar, da diese in `poll()`
   geworfen wurde, also _nachdem_ die Implementierung durch den Aufruf
   von `poll()` signalisiert hat, dass sie alle zuvor gelieferten
   Nachrichten vollständig verarbeitet hat.
** Bei einer `RecordDeserializationException` ist dies klar, da ein
   Fehler während der Deserialisierung der vom Broker empfangenen
   Nachrichten dazu führt, dass die Kafka-Client-Library die zuvor
   fehlerfrei deserialisierten Nachrichten ausliefert und dies auch
   entsprechend in den intern mitgeführten Offset-Positionen reflektiert.
* Der Commit wird hier asynchron durchgeführt.
* TODO: Das führt dazu, dass die Implementierung in dem Rebalance
  einfriert, da der Callback, auf den sie wartet, dort nie aufgerufen
  wird, da die Commit-Callbacks nur "synchron" abgearbeitet werden, wenn
  die `poll()`-Methode aufgerufen wird!

.editorconfig ergänzt - siehe: ttps://editorconfig.org/

* Einziger gangbarer Weg, um IntelliJ beizubiegen, Leerzeichen für die
  Einrückung zu verwenden!
* ...aber auch für einige andere Dinge ganz praktisch...

Konfig-Parameter zum künstlichen Verzögern der Verabeitung eingebaut

README.sh: Ausgabe der Ergebnisse der \`adder\`-Services verbessert

* Übersichtlichere Ausgabe: sie wird nicht mehr umgebrochen und eingerückt.
* Umbruch nach der Ausgabe eines vollständiges Ergebnisses (durch das
  Ausschalten von `--pretty` erzeugt `http` diesen nicht mehr automatisch.

README.sh: `adder`-Services werden jetzt gelöscht anstatt gestoppt

* Dadurch ist immer nur das Log sichtbar, das durch/nach der letzten
  Ausführung des Skriptes erzeugt wurde.

Implementierung vereinfacht: Auf das Nötigste zusammengekürzt

* Das regelmäßige Speichern im Poll-Interval wird für die Übung nicht
  benötigt.
* Damit entfällt auch das Interface
  `PollIntervalAwareConsumerRebalanceListener`
* Die Vereinfachung hat eine Anpassung der Tests erfordert: Da in dem
  Test, der überprüft, ob die Offsets korrekt committed werde, wenn kein
  Fehler vorliegt, gar kein Rebalance auftritt, musste der Consumer
  gestoppt werden, damit die Ergebnisse für die Überprüfung sichtbar
  werden.

Log-Meldungen zu gespeichertem und wiederhergestelltem Zustand

Setup und Vorführ-Skript auf 2 adder- und requests-Services umgestellt

Log-Meldung für durchgeführte Berechnungen bei Revoke korrigiert

Compose-Setup und Vorführ-Skript an die Übung angepasst

* Die Mongo-DB muss vor dem Neu-Start gelöscht werden, da sie sonst noch
  den alten Zustand enthält.
* Außerdem muss der `adder`-Service dabei gestoppt sein, da er sonst den
  alten Zustand sofort neu anlegt, wenn die frisch erzeugte leere Mongo-DB
  erreichbar wird.
* Das Skript außerdem weniger, timing-anfällig gemacht, indem es wartet,
  bis der Zustand für den im Skript benutzten User sichtbar wird.
* Das Skript fasst das ausgegebene JSON außerdem mit `jq` und `uniq` so
  zusammen, dass sofort erkennbar ist, ob es zu falschen Berechnungen
  gekommen ist.
* Der im Skript benutzte User `peter` wartet jetzt zwischen den
  Berechnungs-Anfragen nicht mehr und stellt größere Anfragen, damit es
  sicherer zu falschen Berechnungen kommt -- (sonst kam es dazu, dass
  der Consumer eh die letzte Berechnung vollständig ausgeführt hatte und
  dann auf weitere Nachrichten gewartet und einen Commit gemacht hatte,
  bevor er abgeschossen wurde, so dass alle Berechnungen vollständig waren)
* Der Auto-Commit von Kafka wurde auf 3 Sekunden verkürzt, und das Skript
  an diese Zeit angepasst, so dass auf jeden Fall ein Commit erfolgt ist,
  bevor der Consumer getötet wird.

ROT: (Erwartet!) Merge der Korrigierten Test-Logik und Erwartungen

* Merge branch 'sumup-adder' into sumup-adder--ohne--stored-offsets
* ROT: Es wird erwartet, dass der Test anschlägt, da der Consumer bei
  einem Logik-Fehler Nachrichten doppelt liest, so dass sich ein von
  den Erwartungen abweichender Zustand ergibt.

GRÜN: Korrektur der falsch formulierten Erwartungen zu dem Consumer-Zustand

ROT: Merge der korrigierten Test-Logik deserialization -> into sumup-adder

* Der Merge korrigiert die grundsätzlichen Fehler der Test-Logik in
  `GenericApplicationTests` durch den Merge des Fixes aus dem Branch
  `deserialization`.
* Zusammen mit dem Merge von `sumup-adder--ohne--stored-offsets` der
  einen Fehler der fachlichen Test-Logik in `ApplicationTests` korrigiert,
  korrigiert dies die technichschen Fehler in der Test-Logik.
* ROT: Der Test schlägt trotzdem noch fehl, da die Annahmen über den
  Zustand des Consumers falsch formuliert wurden.

ROT: Korrigierten/Verbesserten Test und Überarbeitetes Setup gemerged

* Merge branch 'sumup-adder--ohne--stored-offsets' into sumup-adder.
* In dem gemergten Branch ist es nicht wichtig, wann genau die
  Mongo-DB zwischen den Tests zurückgesetzt wird, da sie nur den Zustand
  des Consumers enthält.
* Wenn die Offsets mit in der Mongo-DB gespeichert werden, ist es
  wesentlich, an zu welchem Zeitpunkt während der Test-Vorbereitung
  diese zurückgesetzt wird!
* ROT: Der verbesserte/verschärfte Test deckt Fehler in der Test-Logik auf.

GRÜN: Fehler in der Test-Logik korrigiert

* Die Assertion, dass nach einem wiederholten Versuch, den Logik-Fehler
  zu konsumieren nicht mehr Nachrichten konsumiert wurden, als für den
  Test generiert wurden ist nicht gültig, da bei einem Logik-Fehler ja
  gerade _kein_ Commit der zuletzt gelesenen Nachrichten erfolgt, da
  dies dazu führt, dass der Offset für Partitionen erhöht wird, für die
  vor dem Eintreten des Fehlers noch nicht alle Nachrichten gelesen
  wurden, wenn nicht explizti Seek's für diese Partitionen durchgeführt
  werden.
* Die Assertion, dass die Offset-Position nach einem Fehler der Offset-
  Position _vor_ der Ausführung der Fachlogik entspricht ist falsch, da
  durchaus Commits durchgeführt werden können, bevor der Fehler auftritt.
  Daher wird jetzt explizit geprüft, dass
** Die Offset-Position für keine Partition größer ist, als der Offset
   der dort zuletzt gesehenen Nachricht.
** UND mindestens eine Partition existiert, deren Offset _kleiner_ ist,
   als der Offset der zuletzt gesehenen Nachricht.

ROT: Fehler in Test-Logik aufgedeckt

* Einige Assertions in dem Test für die Offset-Position nach einem
  Logik-Fehler waren fehlerhaft.
* Dies ist bisher nicht aufgefallen, weil der Test nicht scharf genug
  war: Er hat so wenig Nachrichten gesendet, dass die fehlerhaften
  Assertions nicht aufgefallen sind, weil es nie zu einem Commit gekommen
  ist, bevor der Fehler ausgelöst wurde.
* TODO: Der Test ist wahrscheinlich immer noch in hohem Maße abhängig
  von der Ausführungsgeschwindigkeit auf dem Test-System. Besser wäre
  es, wenn die Verarbeitung künstlich gedrosselt würde, so dass die
  Timing-Annahmen zu den asynchron ablaufenden Operationen nicht auf
  das Testsystem abgestimmt werden müssen.

ROT: (Ohne stored-offsets) Überprüfung der Fachlogik korrigiert

* Der ursprüungliche Test ist nicht korrekt angeschlangen
* Der Test Schlug nicht an, weil geprüft wurde, dass `AdderResults`
  eine Teilmenge der insgesamt erwarteten Ergebnisse enthält, aber nicht
  mehr und/oder andere Ergebnisse.
* Problem: `AdderResult` hat zum Zeitpunkt der Überprüfung überhaupt keine
  Ergebnisse enthalten, da der Consumer nach dem Fehler alle Partitionen
  abgegeben hat und entsprechend die Ergebnisse aus `AdderResult` entfernt
  und gespeichert wurden.
* Daher wird jetzt gegen die in der Mongo-DB gespeicherten Ergebnisse
  verglichen.
* Unterwegs verbessert / korrigiert:
** Falsches Assert-Statement entfernt (beim 2. Durchlauf können durchaus
   mehr Nachrichten als erwartet empfangen werden, nämlich 2x weniger
   als erwartet ;)
** Commit erfolgt alle 500ms
** Test realistischer gestaltet: Viel mehr Nachrichten und durcheinander.
** Der Fehler wird nicht nach der ersten Hand voll Nachrichten erzeugt,
   sondern erst gegen Ende der generierten Nachrichten.

README.sh-Skript zur Demonstration des Setups überarbeitet

Verbesserungen und Fachlogik-Test aus 'sumup-adder' gemerged

test: Überprüfung der Fachlogik ergänzt

* Überall, wo die Fachlogik geprüft wird, wird jetzt sichergestellt,
  dass die berechneten Ergebnisse den Erwartungen entsprechen.
* Überprüft, werden nur die zu dem Zeitpunkt tatsächlich vollständig
  berechneten Ergebnisse. Dadurch wird durch die Überprüfung kein Fehler
  ausgelöst, wenn wegen einem simulierten Fehler noch nicht alle durch
  die erzeugten Nachrichten angeforderten Berechnungen erfolgt sind.

refactor: Inline-Klasse in `ApplicationTests` ist jetzt statische Klasse

* Diese Refaktorisierung ist nötig, damit dem `RecordGenerator`
  der Zugriff auf die Ergebnisse der Fachlogik in `AdderResults`
  ermöglicht werden kann.
* Grund: Wenn der `RecordGenerator` bereits im Konstruktor erzeugt wird,
  kann er nicht auf die `this`-Referenz von `ApplicationTests` zugreifen.

Die Ergebnisse werden gespeichert und sind via REST abrufbar

GRÜN: Implementierung der Erwartungen inkl. Anpassungen an der Anwendung

* Neue Erwartungen an `AdderBusinessLogic` implementiert.
* Die Implementierung hat sich über die nicht von den Unit-Tests
  abgedeckte Methode auch auf andere Teile der Anwendung ausgewirkt.
* `AdderBusinessLogic.getState()` liefert jetzt in der Map die neue
  Klasse `AdderResult` und benötigt diese auch als Konstruktor-Argument.
* Über die Integration-Tests ist sichergestellt, dass die Datenhaltung
  trotz der Umstellung von `Long` auf `AdderResult` funktioniert.

ROT: Zur Summe soll die Zahl ausgegeben werden - Logik + Test angepasst

* `AdderBusinessLogic` gibt jetzt ein `AdderResult` zurück, das die Summe
  zusammen mit der zugehörigen Zahl ausgibt.
* Anwendung (insbesondere die Signatur von `AdderBusinessLogic`!)
  entsprechend angepasst.
* Erwartungen an `AdderBusinessLogic` entsprechend überarbeitet.

GRÜN: Neue Erwartungen umgesetzt

ROT: Signatur für `AdderBusinessLogic` und neue Erwartungen formuliert

* Anwendung so überarbeitet, dass sie weniger motzig ist, dafür aber
  einfach Rechenfehler produziert - weil diese bei Experimenten leichter
  nachvollziehbar sind.
* Dafür eine neue Signatur für `AdderBusinessLogic` entwickelt, die
  Implementierung aber noch nicht angepasst.
* Die neuen Erwartungen an `AdderBusinessLogic` formuliert.

fix: Fehlerhafte Erwartung korrigiert

GRÜN: (ungewollt!) - Unabhängigkeit der Tests wieder hergestellt

* Die Mongo-DB wird jetzt zwischen den Tests gewaltsam mit `drop()`
  geleert.
* Dadurch wirkt sich der Test, bei dem die Verarbeitung durch einen
  Logik-Fehler unterbrochen wird, nicht mehr auf den/die anderen Tests aus.

ROT: Rückbau auf automatische Commits - Testfälle laufen nicht mehr

* Rückbau von sumup-adder auf automatische Commits, so wie in dem
  Branch stored-state - D.h., nur noch der Zustand wird in der Mongo-DB
  gespeichert.
* Durch den Umbau schlägt `ApplicationTests` fehl, obwohl sich eigentlich
  nichts an der Logik geändert hat.
* Dies ist so "gewollt": Es zeigt, dass bei automatischen Commits im
  Fehlerfall der gespeicherte Zustand und der Stand der verarbeiteten
  Nachrichten auseinander laufen.
* _Unschön:_ Die Tets sind nicht mehr unabhängig voneinander.
** Eigentlich war erwartet, dass der Test, der den Fehler erzeugt
   beim 2. Anlauf fehlschlägt, weil durch die doppelt gelesenen
   Nachrichten weitere Fehler auftreten - diese unterscheiden sich aus
   der Sicht des Test-Codes aber gar nicht von den vorherigen Fehlern.
** Als _ungewollter_ Seiteneffekt bleibt aber der Zustand in der Mongo-DB
   zurück, der zwischen den Tests nicht zurückgesetzt wird.
** Dadurch scheitert dann der folgende Test, der eigentlich durchlaufen
   sollte.
** Genauer: Ob und/oder Welche Tests fehlschlagen, hängt von der
   Ausführungs-Reihenfolge ab!
* *Idee:* `AdderBusinessLogic` weniger motzig implementieren, indem
  anstatt von getrennten START- und STOP-Nachrichten nur noch eine
  CALC-Nachricht verwendet wird, die die Summe der zuvor aufgelaufenen
  Zahlen ausgibt.
** Passt besser zu der ursprünglichen Idee, dass an den falchen Summen
   leicht gezeigt werden kann, dass Nachrichten doppelt verarbeitet wurden
** Die Idee mit den ungültigen Zuständen führt davon ab! Bei doppelt
   verarbeiteten Nachrichten ist dann nur noch der invalide Zustand
   sichtbar, zu den mit der Gauß-Summenformel leicht als falsch zu
   entlarvenden Summen kommt es dann gar nicht mehr...

Benennung vereinheitlicht und projektunabhängig gemacht

fix: In `onPartitionsAssigned()` wurde der Kafka-Offset ausgegeben

GRÜN: Korrektur des über die verschärften Tests aufgedeckten Fehlers

ROT: Verbesserungen aus 'deserialization' in 'sumup-adder' gemerged

* Dabei: Die Verbesserungen aus 'deserialization' genutzt, um in
  `ApplicationTests` einen angepassten `RecordGenerator` zu
  implementieren.
* Da der Service derzeit mit `String` für Schlüssel und Nachricht
  arbeitet, kann keine Poison-Pill erzeugt werden (null-Nachrichten
  führen nicht zu einer `DeserializationException` und alles andere
  lässt sich in einen - fachlich ggf. sinnfreien - String konvertieren).
* Der Test für Logik-Fehler schlägt fehl, weil er einen Fehler in der
  Implementierung aufdeckt!
* Alle bisherigen Versionen von `EndlessConsumer`, die ihre Offsets in
  der Mongo-DB mit speichern führen bei einer `DeserializationException`
  einen Offset-Commit durch, wenn ihnen durch das darauf folgende
  `unsubscribe()` die Partitionen entzogen werden.
* D.h., bisher wurden in dieser Situation Nachrichten verloren!

Methode zu prüfen der Fachlogik in `RecordGenerator` ergänzt und angebunden

Signatur und Handling des `RecordGenerator` vereinfacht/überarbeitet

* Der `RecordGenerator` darf jetzt selbst bestimmen, wie viele Nachrichten
  er erzeugt und wo wieviele Poison-Pills oder Logik-Fehler erzeugt
  werden, wenn der Test dies anfordert.
* Dafür git der `RecordGenerator` jetzt die Anzahl der tatsächlich
  erzeugten Nachrichten zurück, damit die Tests richtig reagieren können.

Anzahl der erzeugten Test-Nachrichten wird vom `RecordGenerator` bestimmt

GRÜN: Erwartungen implementiert

ROT: Übersehene Erwartung an SumBusinesLogic.endSum(String) ergänzt

refactor: Benennung der Fachlogik-Tests vereinheitlicht

Implementierung des Adders für SumUp

* `AdderRecordHandler` und `AdderRebalanceListener` implementiert, die
  die separat entwickelte Fachlogik anbinden.
* `StatisticsDocument` in `StateDocument` umbenannt und angepasst.
* Als Zustand wird zunächst nur der interne Zustand der Fachlogik
  ausgegeben.
* Später sollen statdessen die für die Benutzer durchgeführten
  Berechnungen ausgegeben werden, damit diese validiert werden können.

Namen der Test-Klassen korrigiert

`GenericApplicationTest` überspring Tests, wenn Fehler nicht verfügbar

* Über eine Annotation wird für Tests, die einen bestimmten Fehler-Typ
  benötigen bei dem `RecordGenerator` nachgefragt, ob der Fehler-Typ
  erzeugt werden kann.
* Wenn der Fehler-Typ nicht zur Verfügung steht, wird der Test
  übersprungen.

Tests aus gemerged springified-consumer--serialization -> deserialization

* Es wurde nur der hinzugefügte Test übernommen.
* Der hinzugefügte Test wurde an das von Spring-Kafka abweichende
  Verhalten bei einem Logik-Fehler angepasst: Kafka führt nicht automatisch
  Seeks oder einene Commit durch. Da `EndlessConsumer` bei einem
  Logik-Fehler explizit ein `unsubscribe()` durchführt, wird kein
  Offset-Commit durchgefürt, so dass die alten Offset-Positionen gültig
  bleiben.
* Der Test wurde entsprechend umbenannt.
* `RecordGenerator` wurde um einen weiteren Integer-Set erweitert, über
  den die Indizes der zu erzeugenden Logik-Fehler gesetzt werden können.
* Der hinzugefügte Test wurde auf die überarbeitete Methode zur Erzeugung
  der Test-Nachrichten umgestellt.
* `ApplicationTest` wurde so ergänzt, dass der für den hinzugefügten Test
  benötigte Logik-Fehler erzeugt wird.

Typisierung in `GenericApplicationTest` nur noch, wo wirklich nötig

* Es wird nur noch dort mit Typisierung gearbeitet, wo dies unumgänglich
  ist, weil die typisierte Implementierung angesprochen wird.
* Das Versenden der Test-Nachrichten erfolgt als `Bytes` für Schlüssel
  und Nachricht.
* Dadurch muss der `RecordGenerator` nicht mehr typisiert werden.
* Dafür muss die typisierte Implementierung des Testfalls dann Schlüssel
  und Nachricht mit einem passenden Serializer in eine `Bytes`-Payload
  umwandeln.

`ApplicationTest` auf basis der typisierbaren Basis neu implementiert

Typisierbare Basis-Klasse `GenericApplicationTests` eingeführt

GRÜN: Erwartungen implementiert

ROT: Erwartungen an SumBusinessLogic.addToSum(String, Integer)

GRÜN: Erwartungen implementiert

ROT: Erwartungen an SumBusinessLogic.endSum(String)

GRÜN: Erwartungen implementiert

ROT: Erwartungen an SumBusinessLogic.getSum(String)

GRÜN: Erwartungen implementiert

ROT: Erwartungen an SumBusinessLogic.startSum(String)

Demonstration für das Wordcount-Beispiel angepasst

Demonstration in README.sh gepimped

Verbesserte/Erweiterte Tests aus 'stored-offsets' nach 'wordcount' gemerged

Der Integration-Test prüft auch, ob der HealthIndicator 'UP' zurückgibt

Integration-Test hinzugefügt, um die Lauffähigkeit der App sicherzustellen

Fixes für Setup/README.sh aus 'deserialization' in 'stored-offsets' gemerged

Compose-Setup und README.sh für dieses Beispiel repariert

* Zuvor war in dem Setup noch ein Producer konfiguriert, der Nachrichten
  vom Typ `String` geschrieben hat, so dass der Consumer _sofort_ das
  zeitliche gesegnet hat.
* Im README-Skript wurde nicht darauf gewartet, dass der Consumer
  gemeldet hat, dass er ordentlich gestartet ist, bevor er nach der
  vermeintlichen Konsumption der Poison-Pill wieder neu gestartet wurde.

Verbesserungen aus 'deserialization' nach 'stored-offsets' gemerged

Refaktorisierungen aus 'wordcount' nach 'stored-offsets' zurück portiert

refactor: Alle Kafka-Belange in den `WordcountRebalanceListener` verschoben

* Dafür neues Interface `PollIntervalAwareRebalanceListener` eingeführt.
* `WordcountRebalanceListener` implementiert das neue Interface und
  kümmert sich um alle Kafka-Belange.
* `WordcountRecordHandler` kümmert sich nur noch um die Fachlogik.

refactor: Handling der Partitionen in WordcountRebalanceListener

refactor: RebalanceListener als eigenständige Klasse