# novaris-integration-tests

Verifiziert die Novaris-Landschaft gegen **echte Infrastruktur** statt Ersatz-Implementierungen:

| Ersatz (Phase 1-4) | Echte Infrastruktur (diese Phase) | Test |
|---|---|---|
| - (kein Ersatz, Unit-Tests mocken den JPA-Zugriff) | Oracle (`gvenzl/oracle-free`) | `OraclePersistenceIT` |
| Apache ActiveMQ (eingebettet) | IBM MQ (`icr.io/ibm-messaging/mq`) | `IbmMqRequestReplyIT` |
| - | DB2 | **nur dokumentiert, siehe unten** |
| - (nicht ausgefuehrt) | Open Liberty | siehe unten |

## Warum diese Tests nicht Testcontainers verwenden

Die Testcontainers-Bibliothek spricht die Docker Engine API direkt an (unter Windows ueber
eine Named Pipe). In der Umgebung, in der dieses Projekt entstanden ist, liefert dieser
direkte API-Zugriff nur eine leere Stub-Antwort zurueck - vermutlich eine Docker-Desktop-
interne Proxy-/Sicherheitsschicht dieser speziellen Installation. Die ganz normale
Container-CLI funktioniert dagegen einwandfrei (verifiziert). `support/DockerCli.java`
orchestriert Container deshalb genauso, wie ein Entwickler es manuell taete - `podman run`/
`podman logs`/`podman port`/`podman rm` ueber einen {@code ProcessBuilder}. Das Ergebnis sind
exakt dieselben echten Container, nur ohne die (hier nicht funktionierende)
Docker-API-Bibliothek dazwischen.

**Das ist selbst ein Lehrstueck:** Tooling, das "eigentlich einfach funktionieren sollte",
tut das in einer konkreten Umgebung manchmal nicht - und der pragmatische Ausweg ist nicht
"aufgeben", sondern auf eine Ebene zurueckzugehen, die nachweislich funktioniert (hier: die
CLI statt der REST-API). Dieselbe Haltung wie beim `wsimport`-Problem in Phase 2.

## Warum DB2 nur dokumentiert, aber nicht gestartet wird

Das offizielle IBM-Db2-Community-Edition-Image ist deutlich schwerer als Oracle/IBM MQ
(mehrere GB, haeufig 10+ Minuten Initialisierungszeit) und hat bekannte Eigenheiten unter
Windows-Container-Runtimes. Diese Entscheidung wurde bewusst und explizit mit dem Nutzer
abgestimmt, statt sie stillschweigend zu treffen. Die server.xml-Konfiguration fuer DB2
(`novaris-policy-core/src/main/liberty/config/server.xml`, `legacyContractDS`) ist bereits
vollstaendig vorhanden und strukturell identisch zur Oracle-Konfiguration - sie wird nur
nicht gegen einen tatsaechlich laufenden Container verifiziert. Eine Testcontainers-/
Container-CLI-Referenzkonfiguration fuer DB2 ist in
`docs/40-persistence-oracle-db2/02-db2-nur-dokumentiert.md` hinterlegt, falls das spaeter
nachgeholt werden soll.

## Open Liberty

Siehe `docs/50-websphere-config/03-liberty-serverstart-verifiziert.md` fuer den aktuellen
Stand der Liberty-Verifikation in dieser Phase.

## Ausfuehrung

Die CLI ist runtime-neutral. Standard ist `docker`; fuer Podman wird die Runtime gesetzt:

```powershell
$env:NOVARIS_CONTAINER_RUNTIME = "podman"
mvn -Pintegration verify
```

Der Harness ermittelt zuerst einen freien IPv4-Loopback-Port und bindet ihn mit
`-p 127.0.0.1:<host-port>:<container-port>`. Das vermeidet zwei
Laufzeitunterschiede: Podman lehnt den Docker-Platzhalter `0:<container-port>` ab,
und ein automatisch vergebener Podman-Port kann unter Windows nur über IPv6
erreichbar sein, während ältere Clients `localhost` als IPv4 auflösen.

Alternativ kann die Java-Systemproperty `-Dnovaris.container.runtime=podman` verwendet werden.

Diese Tests laufen **nicht** im normalen `mvn test`-Reactor-Lauf mit (Surefire ist fuer
dieses Modul deaktiviert) - sie brauchen Podman oder Docker und eine laufende Container-Machine, koennen
mehrere Minuten dauern (Image-Downloads, Datenbank-/Queue-Manager-Initialisierung) und
sollen den schnellen, containerfreien Entwicklerkreislauf der uebrigen Module nicht
verlangsamen. Explizit ausfuehren mit:

```bash
mvn -pl novaris-integration-tests -am verify
```