Phasenroadmap M0-M7

Spiegelt den bewaehrten Phasenrhythmus des Legacy-Aufbaus (Phase 0-5, je 2-3 thematische Commits pro Phase).

M0 - Fundament (fertig)

• Neuer Branch feature/spring-jakarta-openshift-migration.
• novaris-modern-parent-Reactor-Skeleton (Parent-POM auf spring-boot-starter-parent:2.7.18, Java 11).
• Diese Doku (docs/70-migration/).
• 05-git-workflow.md - dokumentiert den gh/git-Workflow aus dem vorangegangenen Jenkins-Feature-Branch (offener Punkt aus einer frueheren Anfrage).

M1 - Policy Core (fertig)

• novaris-common-modern: Kafka-Topic-Konstanten, JSON-DTOs, UpstreamSystemUnavailableException.
• novaris-policy-core-modern: PolicyManagementService, PremiumCalculationService, AuditAspect, PolicyRenewalScheduler, REST-Controller, JPA-Repository, Ports-&-Adapters-Schnitt fuer Billing/Events/DB2-Benchmark (Platzhalter-Adapter, echte Anbindung folgt in M2/M3).
• Verifiziert per echtem End-to-End-Lauf (embedded Tomcat + H2): Policenerstellung, Aktivierung, Abfrage, Underwriting-Ablehnung (422), Police-nicht-gefunden (404), kundenbezogene Aktivpolicenliste. Dabei einen realen, aus dem Legacy-Original uebernommenen Bug gefunden und im modernen Modul behoben (siehe novaris-policy-core-modern/README.md).
• 8 Unit-Tests, containerfrei (Mockito), analog zum Legacy-Teststil.

M2 - SOAP-Client-Integration + Antragswizard (fertig)

• BillingIntegrationPort real an novaris-billing-soap angebunden: SoapBillingIntegrationAdapter + BillingClientConfig (JaxWsPortProxyFactoryBean), client-seitiger, wire-kompatibler SEI-Nachbau des Vertrags in novaris-common-modern.common.billing.contract (bewusst eigenstaendig statt aus novaris-common-legacy wiederverwendet - siehe Klassen-Javadoc). LoggingBillingIntegrationAdapter-Platzhalter entfernt.
• Stateful-Wizard-Ersatz: PolicyApplicationDraft (persistierte, per ID adressierte Entity)
• PolicyApplicationDraftService + PolicyApplicationController - siehe 02-component-mapping.md fuer die Architekturbegruendung.
• Verifiziert per echtem End-to-End-Lauf gegen eine per Endpoint.publish(...) lokal gestartete novaris-billing-soap-Instanz: kompletter Wizard-Ablauf (start -> coverage -> underwriting-answers -> bind) inklusive echtem SOAP-Roundtrip beim Bind-Schritt. Dabei drei reale Bugs gefunden und behoben (siehe novaris-policy-core-modern/README.md und 06-refactoring-taxonomie.md).
• 11 Unit-Tests insgesamt im modernen Reactor (vorher 8), weiterhin containerfrei.

M3 - Messaging-Redesign auf Kafka (fertig)

• Siehe 03-messaging-jms-zu-kafka.md fuer die vollstaendige Begruendung.
• novaris-policy-core-modern: ClaimIntakeKafkaListener (Ersatz fuer ClaimIntakeMDB), KafkaPolicyEventPublisherAdapter (Ersatz fuer LoggingPolicyEventPublisherAdapter- Platzhalter und PolicyEventPublisherBean), KafkaProducerConfig.
• Neues Modul novaris-claims-modern (Ersatz fuer novaris-claims-mq): ClaimSubmissionKafkaClient + KafkaClaimClientConfig (ReplyingKafkaTemplate).
• Neues Modul novaris-notification-modern (Ersatz fuer novaris-notification-jms): PolicyDocumentGenerationListener + CustomerNotificationListener, zwei unabhaengige Consumer-Groups auf demselben Topic statt zweier durable JMS-Subscriptions.
• Verifiziert per echtem eingebettetem Kafka-Broker (spring-kafka-test, @EmbeddedKafka): vollstaendiger Request/Reply-Roundtrip (ClaimSubmissionKafkaClientTest) und Publish/Subscribe-Fan-out an zwei unabhaengige Consumer-Groups (NotificationTopicFanoutTest, Kafka-Gegenstueck zu NotificationTopicFanoutTest im Legacy-Teil). Zusaetzlich per echtem App-Boot gegen einen lokal laufenden Kafka-Broker bestaetigt (Consumer-Group-Beitritt erfolgreich).
• 14 Unit-/Integrationstests insgesamt im modernen Reactor (vorher 11), weiterhin ohne Docker.

M4 - Security, Versionssprung, Containerisierung (fertig)

• Etappe B der Versionsstrategie (01-versionsstrategie.md): Sprung auf Java 17 + Spring Boot 3.2 + jakarta.*-Namespace, vor Security/Containerisierung durchgefuehrt. Dabei ein echter, unerwarteter Breaking Change gefunden: org.springframework.remoting.jaxws.JaxWsPortProxyFactoryBean wurde in Spring Framework 6 ersatzlos entfernt (JAX-WS ist seit Jakarta EE 9 kein Plattform-Bestandteil mehr) - BillingClientConfig baut den SOAP-Client seither direkt mit jakarta.xml.ws.Service.create()/.getPort() auf. Per echtem End-to-End-Lauf verifiziert: der jakarta-basierte Client spricht erfolgreich mit dem unveraendert javax-basierten novaris-billing-soap-Server (SOAP ist ein Wire-Protokoll, der Java-seitige Namespace beider Seiten ist fuer Interop irrelevant).
• Spring Security (SecurityConfig) als Ersatz fuer JAAS Custom Login Module + LTPA - HTTP Basic statt Form-Login (Begruendung: reine JSON-REST-API ohne eigenes Frontend, siehe SecurityConfig-Javadoc), SessionCreationPolicy.STATELESS, rollenbasierte @PreAuthorize-Method-Security auf PolicyManagementService, rollengleich zum Legacy-@RolesAllowed. Per echtem End-to-End-Lauf verifiziert (401/403/201-Faelle).
• Container-Image: Dockerfile in novaris-policy-core-modern (mehrstufiger Build, Spring-Boot-Layertools, non-root User). Ein tatsaechlicher docker build schlug in dieser Entwicklungsumgebung mehrfach an Container-internem Netzwerkzugriff zu Maven Central/Docker Hub fehl (Connect timed out), obwohl der Host selbst durchgehend funktionierenden Internetzugriff hat - dasselbe Muster wie das bereits dokumentierte Testcontainers-Docker-Engine-API-Problem im Legacy-Reactor. Das Dockerfile folgt Standard-Best-Practice, ist aber nicht bis zum fertigen Image durchgetestet - ehrlich dokumentiert statt verschwiegen, siehe novaris-policy-core-modern/README.md.
• REST-API bleibt Basis fuer das bereits benannte novaris-policy-web-modern-spa-Ziel (noch kein eigenes Frontend gebaut).

M5 - OpenShift (fertig, letzter Schritt)

• Sieben OpenShift-/Strimzi-Manifeste in novaris-modern-parent/openshift/ (Namespace, Kafka-Cluster + drei Topics, ConfigMap, Secret-Template, drei Deployment/Service/Route) - siehe openshift/README.md und docs/70-migration/07-openshift-und-jenkins.md.
• Ein Dockerfile je Spring-Boot-Modul (mehrstufig, Spring-Boot-Layertools, non-root User).
• Eigenstaendiges novaris-modern-parent/Jenkinsfile (vier Stages local/test/qs/prod, strukturell identisch zum Legacy-Jenkinsfile) + ci/scripts/deploy-openshift.sh.
• Lokal verfuegbar, aber nicht gestartet: oc-CLI (OKD 4.21) und CRC (OpenShift Local) sind auf der Entwicklungsmaschine installiert. Ein CRC-Start wurde bewusst nicht durchgefuehrt (schwergewichtig, und dieselbe Netzwerk-Unzuverlaessigkeit dieser Sandbox, die bereits den docker build mehrfach scheitern liess, haette CRC vermutlich ebenso betroffen). Echte Verifikation stattdessen ueber YAML-Syntaxpruefung aller neun Manifeste und vollstaendige Fehlerpfad-/Erfolgspfad-Tests von deploy-openshift.sh - ehrlich als "geprueft, aber nicht gegen echten Cluster angewendet" dokumentiert, dieselbe Grenzziehung wie beim DB2- und Liberty-EAR-Deployment im Legacy-Teil.

M6 - Fuenf Erweiterungen nach M5 (fertig)

Nachtraeglich identifizierte, in M1-M5 bewusst offen gelassene Punkte - aus einer Ruecksprache nach Projektabschluss ("hast noch Besserungs- oder Lernvorschlag") als sinnvolle naechste Schritte benannt und auf Nutzerwunsch alle fuenf umgesetzt.

• Draft-Cleanup-Scheduler: @Scheduled-Job ersetzt den mit dem Wechsel weg von @Stateful-Session-Affinitaet weggefallenen automatischen Session-Timeout fuer liegen gebliebene Antragsentwuerfe. Siehe 08-draft-cleanup-scheduler.md.
• Kafka Dead-Letter-Topic: DefaultErrorHandler + DeadLetterPublishingRecoverer als Kafka-Aequivalent zur MQ-Backout-Queue des Legacy-ClaimIntakeMDB. Per echtem eingebettetem Broker (Retry-Backoff, echte Giftnachricht, echtes DLT-Topic) verifiziert. Siehe 09-offene-punkte-geschlossen.md.
• Echte DB2-JDBC-Anbindung: Db2LegacyBenchmarkPort ersetzt die bisherige No-Op-Platzhalterimplementierung durch echten JDBC-Zugriff. Dabei einen realen Spring-Bean-Mehrdeutigkeitsfehler gefunden und per @Primary/@Qualifier behoben. Siehe 09-offene-punkte-geschlossen.md.
• Observability: Micrometer Tracing + Zipkin ueber REST- und Kafka-Prozessgrenzen hinweg, inkl. eines real gefundenen und behobenen Zipkin-Sender-Fallback-Bugs in den Web-Starter-losen Modulen. Per echtem laufendem Zipkin-Container end-to-end verifiziert. Siehe 10-observability-tracing.md.
• OIDC/Keycloak: OAuth2 Resource Server + Keycloak-Realm-Rollen ersetzen HTTP Basic + In-Memory-Benutzerspeicher aus M4. Dabei einen realen Keycloak-24-Konfigurationsfallstrick gefunden (fehlendes email-Attribut blockiert Password-Grant) und behoben. Vollstaendige 401/403/200/204-Matrix mit echten, von einem laufenden Keycloak-Container ausgestellten JWTs verifiziert. Siehe 11-oidc-keycloak.md.

20 Unit-/Integrationstests insgesamt im modernen Reactor (vorher 14, real per mvn test-Lauf verifiziert: 0 Fehlschlaege), weiterhin ohne Docker fuer die Testsuite selbst (Docker wurde nur fuer die manuelle End-to-End-Verifikation gegen Kafka/Zipkin/Keycloak genutzt). Dabei einen realen Irrtum in der eigenen SecurityConfig-Dokumentation aufgedeckt und korrigiert: die Testsuite (und die Anwendung selbst) starten entgegen der urspruenglichen Annahme auch ohne erreichbaren Keycloak normal - siehe 11-oidc-keycloak.md.

M7 - Frontend + zwei Blocking-Bugs behoben (fertig)

Auf Nutzerwunsch nach M6 ("frontend und bug fixen") - zwei unabhaengige Punkte, hier gemeinsam als Phase gefuehrt, da beide im selben Durchlauf entstanden.

• Blocking-Bugs: KafkaPolicyEventPublisherAdapter.publish blockierte activatePolicy bis zu ~60s ohne erreichbaren Kafka-Broker (KafkaTemplate.send() blockiert intern vor Ruckgabe des Futures) - behoben per @Async + gebundenem max.block.ms. Dabei zwei weitere reale Funde (unbounded KafkaAdmin-Timeout, Exceptions entkamen der eigenen Fehlerbehandlung) und ein strukturell identischer zweiter Bug (Db2LegacyBenchmarkPort blockierte createPolicy real gemessene 30,76s via HikariCPs connectionTimeout-Default). Siehe 12-blocking-bugs-behoben.md.
• Frontend: novaris-policy-web-modern-spa - React/TypeScript-SPA, OIDC Authorization-Code-Flow + PKCE gegen Keycloak, CORS-Anbindung an novaris-policy-core-modern. Real end-to-end verifiziert per skriptbasierter Protokoll-Nachbildung (echter PKCE-Login-Flow, echte CORS-Preflight-Pruefung, echte autorisierte REST-Aufrufe) gegen echte laufende Instanzen - siehe 13-frontend-spa.md.
• 21 Unit-/Integrationstests insgesamt im modernen Reactor (vorher 20), weiterhin gruen.