novaris-policy-core-modern

Spring-Boot-Gegenstueck zu novaris-legacy-parent/novaris-policy-core. Baut dieselbe Fachlogik (Policenverwaltung, Praemienberechnung, Audit, Verlaengerungspruefung, Antragswizard, Billing-Anbindung, Security) neu auf Spring-Bausteinen auf statt auf EJB/WebSphere - siehe docs/70-migration/02-component-mapping.md fuer die vollstaendige Abbildungstabelle und docs/70-migration/06-refactoring-taxonomie.md fuer die genaue Unterscheidung Migration/Refactoring/Bugfix, die im Javadoc jeder Klasse als Leitzeile markiert ist.

Seit Migrationsphase M4: Java 17, Spring Boot 3.2, jakarta.*-Namespace (Etappe B, siehe docs/70-migration/01-versionsstrategie.md). Seit Migrationsphase M6: fuenf weitere Erweiterungen (Draft-Cleanup-Scheduler, Kafka-DLT, echte DB2-Anbindung, Tracing, OIDC/Keycloak) - siehe docs/70-migration/08-11*.md und 04-phasenroadmap.md.

Inhalt

Paket	Inhalt	Legacy-Gegenstueck
`policy.domain`	`Policy`, `PolicyStatus`, `NewPolicyRequest`, `PolicyApplicationDraft`, `DraftStep` (JPA)	`policy.domain`, `PolicyApplicationWizardBean`-Zustand
`policy.repository`	`PolicyJpaRepository`, `PolicyApplicationDraftRepository` (Spring Data JPA)	`PolicyRepository` (Stateless + EntityManager)
`policy.service`	`PolicyManagementService`, `PremiumCalculationService`, `PolicyApplicationDraftService`, `SoapBillingIntegrationAdapter`, Ports (`BillingIntegrationPort`, `PolicyEventPublisherPort`, `LegacyBenchmarkPort`)	`PolicyManagementBean`, `PremiumCalculationBean`, `PolicyApplicationWizardBean`, `BillingIntegrationBean`
`policy.config`	`BillingClientConfig` (JAX-WS-Client via `jakarta.xml.ws.Service`)	`@WebServiceRef`-Feld in `BillingIntegrationBean`
`policy.messaging`	`ClaimIntakeKafkaListener`, `KafkaPolicyEventPublisherAdapter`, `KafkaProducerConfig`	`ClaimIntakeMDB`, `PolicyEventPublisherBean`
`policy.security`	`SecurityConfig` (OAuth2 Resource Server + Keycloak-JWT, `@PreAuthorize`-Method-Security)	JAAS Custom Login Module (`novaris-policy-web-legacy-jsf`)
`policy.audit`	`AuditAspect` (Spring AOP), `AuditLogEntry`/`AuditLogRepository`	`AuditInterceptor` (EJB-Interceptor)
`policy.scheduling`	`PolicyRenewalScheduler`, `PolicyDraftCleanupScheduler` (`@Scheduled` + `TaskScheduler`)	`PolicyRenewalTimerBean` (EJB Timer Service)
`policy.legacydb`	`Db2DataSourceConfig`, `Db2LegacyBenchmarkPort` (echter JDBC-Zugriff auf DB2 `CTR_MASTER`)	`LegacyContractDao`
`policy.exception`	`PolicyNotFoundException`, `UnderwritingRejectedException`, `DraftNotFoundException`, `GlobalExceptionHandler`	`policy.exception`
`policy.web`	`PolicyController`, `PolicyApplicationController` (REST)	`PolicyManagementLocal`/`Remote`, JSF-Backing-Beans

Anschlusspunkte: was real angebunden ist, was noch Platzhalter ist

Billing (SOAP): seit M2 real angebunden - SoapBillingIntegrationAdapter + BillingClientConfig (jakarta.xml.ws.Service.create()/.getPort(), siehe unten).
Events (Kafka): seit M3 real angebunden - KafkaPolicyEventPublisherAdapter, seit M6 mit Dead-Letter-Topic fuer den eingehenden ClaimIntakeKafkaListener (siehe docs/70-migration/09-offene-punkte-geschlossen.md).
Security: seit M4 real angebunden, seit M6 OAuth2 Resource Server + Keycloak statt HTTP Basic (siehe unten).
DB2-Benchmark: seit M6 real angebunden - Db2LegacyBenchmarkPort (echter JDBC-Zugriff, gegen H2 als strukturgleiches Substitut getestet, nie gegen echtes DB2 - siehe docs/70-migration/09-offene-punkte-geschlossen.md). DB2 selbst bleibt laut Migrationsplan technologisch unveraendert.

Sicherheit (Migrationsphase M4, seit M6 OIDC/Keycloak)

Seit M6 validiert SecurityConfig JWTs eines OAuth2 Resource Servers statt HTTP Basic + In-Memory-Benutzer - siehe docs/70-migration/11-oidc-keycloak.md fuer die vollstaendige Begruendung und den real gefundenen Keycloak-24-Konfigurationsfallstrick. Realm-Import unter novaris-modern-parent/keycloak/novaris-realm.json, drei Test-Benutzer mit identischer Rollenverteilung wie zuvor unter HTTP Basic:

Benutzer	Passwortquelle	Rollen
`admin`	lokaler Setup-Schritt	PolicyAdmin, Underwriter, CustomerServiceRep
`underwriter`	lokaler Setup-Schritt	Underwriter, CustomerServiceRep
`csr`	lokaler Setup-Schritt	CustomerServiceRep

Per echtem End-to-End-Lauf gegen einen laufenden Keycloak-Container mit echten, Password-Grant-ausgestellten JWTs verifiziert: 401 ohne Token, 403 bei fehlender Rolle, 200/201 mit passender Rolle (inkl. einer real angelegten Police), 204 bei erlaubter Stornierung, 401 bei ungueltigem Token.

Seit M7 zusaetzlich SecurityConfig.corsConfigurationSource() (nur http://localhost:5173 erlaubt) fuer novaris-policy-web-modern-spa, deren Authorization-Code-+-PKCE-Login denselben Realm nutzt - siehe docs/70-migration/13-frontend-spa.md.

Bauen, testen, lokal starten

# aus novaris-modern-parent/:
mvn -pl novaris-policy-core-modern -am test

# lauffaehiger Fat-Jar mit eingebettetem Tomcat + In-Memory-H2 (kein externes Oracle noetig):
mvn -pl novaris-policy-core-modern -am package
java -jar novaris-policy-core-modern/target/novaris-policy-core-modern-1.0.0-SNAPSHOT.jar

Fuer einen echten End-to-End-Lauf inklusive SOAP-Billing-Aufruf muss zusaetzlich novaris-billing-soap (bzw. eine Endpoint.publish(...)-Instanz davon) unter http://localhost:9099/novaris/billing erreichbar sein - konfigurierbar ueber novaris.billing.endpoint-address.

Seit M6 validiert die Anwendung Requests gegen den konfigurierten OIDC-Issuer (NOVARIS_OIDC_ISSUER_URI, Default http://localhost:8081/realms/novaris). Der Boot selbst gelingt auch ohne erreichbaren Keycloak (verzoegerter JwtDecoder, siehe docs/70-migration/11-oidc-keycloak.md), authentifizierte Requests liefern in dem Fall aber 401 statt eines erfolgreichen Logins - fuer echte Auth-Faelle lokal per podman run ... quay.io/keycloak/keycloak:24.0 start-dev --import-realm mit novaris-modern-parent/keycloak/novaris-realm.json als Import-Datei starten.

Container-Image

Dockerfile (mehrstufiger Build: Maven-Build-Stage + Spring-Boot-Layertools-Extraktion, non-root User) - siehe Kopfkommentar der Datei fuer den genauen Aufbau und den Build-Aufruf (Build-Kontext ist der Reactor, nicht dieses Modulverzeichnis).

Ehrliche Grenze, real getestet: Ein tatsaechlicher docker build wurde in dieser Entwicklungsumgebung mehrfach versucht und schlug jedes Mal an genau der Stelle fehl, an der der Container-interne Maven-Prozess versucht, Abhaengigkeiten von Maven Central/Docker Hub zu laden (Connect timed out, dial tcp: lookup registry-1.docker.io: no such host) - obwohl der Host selbst durchgehend problemlosen Internetzugriff hat und alle Tests/Builds ausserhalb von Docker in dieser Session anstandslos liefen. Dasselbe Muster wie das bereits in novaris-integration-tests/README.md (Legacy-Reactor) dokumentierte Testcontainers-Problem: der Docker-Container-Netzwerkzugriff dieser Sandbox-Umgebung ist unzuverlaessig, waehrend Docker selbst (Image-Pull, Container-Start) und der Host-Netzwerkzugriff funktionieren. Das Dockerfile folgt Standard-Best-Practice (mehrstufiger Build, Layertools, non-root), ist aber in dieser Umgebung nicht bis zum fertigen Image durchgetestet - siehe docs/70-migration/04-phasenroadmap.md fuer den vollstaendigen Befund.

Real gefundene und behobene Bugs

Siehe docs/70-migration/06-refactoring-taxonomie.md fuer die Kategorie "Bugfix":

PolicyManagementService.generatePolicyNumber: aus dem Legacy-Original uebernommenes System.nanoTime() sprengte die 20-Zeichen-Spalte POLICY_NUMBER - im Legacy-Unit-Test (gemocktes Repository) nie sichtbar geworden.
PolicyApplicationDraft.riskFactors: LazyInitializationException beim JSON-Serialisieren ausserhalb der Hibernate-Session - behoben durch fetch = EAGER.
PolicyApplicationController.submitCoverageDetails: LocalDate-Query-Parameter ohne @DateTimeFormat scheiterten an der Spring-MVC-Konvertierung - behoben.
org.springframework.remoting.jaxws.JaxWsPortProxyFactoryBean wurde in Spring Framework 6 komplett entfernt (JAX-WS kein Jakarta-EE-Plattform-Bestandteil mehr) - BillingClientConfig baut den SOAP-Client seither direkt mit jakarta.xml.ws.Service.create()/.getPort() auf.
(M6) Mehrdeutige DataSource-Bean nach Hinzufuegen der zweiten (DB2-)Datenquelle brach die JPA-Dialekt-Autoerkennung - behoben per @Primary/@Qualifier, siehe docs/70-migration/09-offene-punkte-geschlossen.md.
(M6) Keycloak-24-Password-Grant scheiterte fuer alle Testnutzer an einer implizit durch fehlendes email-Attribut ausgeloesten VERIFY_PROFILE-Required-Action - kein sichtbarer Fehler in requiredActions, nur im Server-Log als resolve_required_actions erkennbar. Siehe docs/70-migration/11-oidc-keycloak.md.
KafkaPolicyEventPublisherAdapter.publish: blockierte den HTTP-Thread von activatePolicy bis zu ~60s ohne erreichbaren Kafka-Broker (KafkaTemplate.send() blockiert intern vor Rueckgabe des Futures) - behoben per @Async + gebundenem max.block.ms/spring.kafka.admin.properties. Dabei zwei weitere reale Funde (unbounded KafkaAdmin-Timeout, Exceptions entkamen der eigenen Fehlerbehandlung) und ein strukturell identischer zweiter Bug (Db2LegacyBenchmarkPort blockierte createPolicy 30,76s via HikariCPs connectionTimeout-Default). Siehe docs/70-migration/12-blocking-bugs-behoben.md.

Wichtigste strukturelle Unterschiede zum Legacy-Modul

Ein REST-Controller statt zwei getrennter Local-/Remote-Interfaces.
Konstruktor-Injection statt @EJB-Feldinjection.
Der Antragswizard ist eine persistierte, per ID adressierte Entity statt eines Session-gebundenen Stateful-Session-Bean-Instanzzustands, mit @Scheduled-Cleanup-Job (PolicyDraftCleanupScheduler) als Ersatz fuer den weggefallenen Session-Timeout.
OAuth2 Resource Server + Keycloak-JWT + @PreAuthorize statt JAAS Custom Login Module + LTPA.
Kafka Dead-Letter-Topic statt JMSXDeliveryCount-basiertem MQ-Backout.
Alle Ports-&-Adapters-Schnitte sind mittlerweile real angebunden (Billing, Events, Security, DB2-Benchmark) - keine Platzhalteradapter mehr im Modul.

⌂ Cockpit