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 |
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.
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.
Siehe docs/50-websphere-config/03-liberty-serverstart-verifiziert.md fuer den aktuellen
Stand der Liberty-Verifikation in dieser Phase.
Die CLI ist runtime-neutral. Standard ist docker; fuer Podman wird die Runtime gesetzt:
$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:
mvn -pl novaris-integration-tests -am verify