# Open Liberty: Serverstart verifiziert, automatisches EAR-Deployment (noch) nicht **Modul:** `novaris-policy-ear`, Maven-Profil `liberty-verify` (siehe dessen pom.xml-Kommentare fuer alle Details), Konfiguration in `src/main/liberty/config/server.xml`. ## Was tatsaechlich verifiziert ist Mit `mvn verify -Pliberty-verify` installiert und startet ein **echter Open-Liberty-Server** mit dem vollen Feature-Set dieses Projekts (`ejbLite-3.2`, `mdb-3.2`, `jpa-2.1`, `jndi-1.0`, `jdbc-4.2`, `wmqJmsClient-2.0`, `servlet-4.0`, `jsf-2.3`, `appSecurity-2.0`) - kein Mock, keine Attrappe. Der Kernel startet zuverlaessig und reproduzierbar: ``` CWWKF0011I: Der Server novarisPolicyServer ist fuer die Ausfuehrung von Smarter Planet bereit. Der Server novarisPolicyServer ist nach 8,924 Sekunden gestartet. ``` Das beweist: die gesamte Feature-Konfiguration ist gueltig, mit einer echten Open-Liberty- Runtime (26.0.0.7) kompatibel, und der Server selbst - inklusive Security-Subsystem (JAAS/LTPA-Schluesselerzeugung) - initialisiert fehlerfrei. ## Vier echte, nacheinander gefundene und behobene Konfigurationsfehler Der Weg dorthin war selbst lehrreich - jeder Fehler war ein reales, mit der Plugin-eigenen `plugin.xml` verifiziertes Konfigurationsproblem, keine Umgebungslimitierung: 1. **`assemblyArtifact` mit der eigenen Anwendung statt der Liberty-Runtime verwechselt** - `assemblyArtifact` (Alias: `runtimeArtifact`) bezeichnet die zu installierende Open-Liberty-**Runtime**, nicht die eigene EAR. Das Plugin versuchte daraufhin, `com.novaris.legacy:novaris-policy-ear:zip` (nicht existent) als Runtime zu installieren. 2. **Unnoetiges `install-feature`-Goal** - beim Einsatz des VOLLSTAENDIGEN `io.openliberty:openliberty-runtime`-Artefakts (372 MB, alle Standard-Features bereits enthalten) scheiterte `install-feature`, weil es versuchte, jedes Feature zusaetzlich einzeln aus einem Feature-Repository nachzuladen - unnoetig und fehleranfaellig bei einer bereits vollstaendigen Runtime. 3. **`application.xml`-Deskriptorversion zu hoch** - `version="8"` wurde vom aufgeloesten Feature-Set nur bis Version 7 unterstuetzt (`CWWKZ0113E`). Korrigiert auf `version="7"` (der Deskriptorinhalt selbst nutzt kein EE-8-spezifisches Vokabular). 4. **Lose Anwendungsdefinition (`looseApplication`, Default `true`) findet Modulpfade nicht** - Liberty deployt standardmaessig ueber eine XML-Datei, die auf die einzelnen Modul- Pfade im Reactor verweist, statt eine physische EAR-Kopie zu erstellen. In diesem Multi-Modul-Reactor loeste das die EJB-/Web-Modulpfade nicht auf (`CWWKZ0117E`, "Modul ... nicht gefunden"). `looseApplication=false` erzwingt stattdessen das Deployment der tatsaechlich gebauten `novaris-policy.ear`-Datei - aendert am Symptom bislang nichts, siehe unten. ## Was (noch) offen ist Trotz `looseApplication=false` bleibt der Anwendungsstart selbst mit demselben Fehler stehen: ``` CWWKZ0117E: Die Anwendung novaris-policy hat das Modul novaris-policy-core.jar des Typs ejb nicht gefunden. CWWKZ0117E: Die Anwendung novaris-policy hat das Modul novaris-policy-web-legacy-jsf.war des Typs web nicht gefunden. CWWKZ0012I: Die Anwendung novaris-policy wurde nicht gestartet. ``` Der **Server selbst startet weiterhin einwandfrei** (`CWWKF0011I` bleibt bestehen) - nur die Anwendung selbst wird nicht gefunden/gestartet. Das ist ein spezifisches Problem der `liberty-maven-plugin`-Modul-Pfadaufloesung in dieser Multi-Modul-Reactor-Struktur, keine Umgebungslimitierung wie bei DB2 (siehe `docs/40-persistence-oracle-db2/02-db2-nur-dokumentiert.md`) - es waere mit weiterer, gezielter Untersuchung (vermutlich ein explizit konfigurierter ``-Pfad oder ein vorgelagertes `mvn clean`, um zwischen den Deployment-Modi nicht wiederverwendete Zwischenstaende zu vermeiden) loesbar. **Bewusste Entscheidung, hier zu stoppen:** Die beiden explizit fuer diese Phase priorisierten Ziele - echtes Oracle (`OraclePersistenceIT`) und echtes IBM MQ (`IbmMqRequestReplyIT`) - sind vollstaendig verifiziert (siehe `docs/40-persistence-oracle-db2/03-jpa-gegen-echtes-oracle-verifiziert.md` und `docs/30-jms-mq/04-ibm-mq-vs-activemq-ersatz.md`). Das vollautomatisierte EAR-Deployment gegen eine laufende Liberty-Instanz ist ein wertvoller, aber nachgelagerter Ausbauschritt - genau wie bei DB2 wird diese Grenze hier bewusst und transparent dokumentiert, statt sie durch beliebig viele weitere Konfigurationsversuche zu verschleiern. ## Reproduzieren ```bash mvn -pl novaris-policy-ear -am verify -Pliberty-verify ``` Serverkonfiguration: `novaris-policy-ear/src/main/liberty/config/server.xml`. Server-Logs nach einem Lauf unter `novaris-policy-ear/target/liberty/wlp/usr/servers/novarisPolicyServer/logs/messages.log`.