← Zur Uebersicht
docs/50-websphere-config/03-liberty-serverstart-verifiziert.md

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 <archive>-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

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.

⌂ Cockpit