Hier ist das manuelle Verfahren:
Extract javax.faces.jar
mit einem ZIP-Tool. Sie erhalten 3 Ordner com
, javax
und META-INF
.
Pack com
und META-INF
Ordnern in jsf-impl.jar
mit einem ZIP-Tool.
Dann löschen Sie alle Dateien/Unterordner in META-INF
außer von MANIFEST.MF
.
Pack javax
und META-INF
Ordner in jsf-api.jar
mit einem ZIP-Tool.
Hier mit den folgenden JARs fortfahren: Upgrade JSF/Mojarra in JBoss AS/EAP/WildFly.
Für den interessierten, JBoss AS und Wildfly hat intern eine modulare Trennung von Java EE-basierte API und Umsetz-Dateien. Die getrennten JAR-Dateien jsf-api.jar
und jsf-impl.jar
werden weiterhin benötigt. Der Grund ist nicht wirklich technisch, sondern nur ein zusätzlicher Service, um Entwickler zu zwingen, gegen die richtigen Bibliotheken zu programmieren. Nur die API-Module werden während der Kompilierungszeit offen gelegt (normalerweise über das IDE-integrierte Plugin, das sie zu "build path" hinzufügt). Dies sollte verhindern, dass Starter versehentlich Implementierungsklassen wie die im Paket com.sun.faces.*
finden, importieren und verwenden.
Bereits seit der Version 1.x bestand die JSF-Implementierung Mojarra aus zwei JAR-Dateien: jsf-api.jar
und jsf-impl.jar
. Die API-JAR enthielt die Klassen javax.faces.*
und die Implementierungs-JAR enthielt die Klassen com.sun.faces.*
. Da die Änderung des Build-Systems den Java EE Maven-Regeln entspricht, wurden sowohl die API als auch die Implementierungsklassen zu einer einzelnen javax.faces.jar
-Datei zusammengeführt, siehe auch issue 2028 (mit Mojarra 2.1.6 am Dez 2011 gestartet). Seit Mojarra 2.3 werden die getrennten JAR-Dateien nicht mehr erstellt.
Und WildFly kann nicht eine Ein-Glas-Variante verwenden? Ist das irgendwo angegeben? – Kukeltje
'javax.faces.jar' ist nur für GlassFish gedacht. Der Rest ist ähnlich http://balusc.omnifaces.org/2014/10/jsf-22-tutorial-with-eclipse-and-wildfly.html#UpgradeMojarraInWildFly, http://Stackoverflow.com/a/17085879/1391249 – Tiny