Ich möchte JSF 2.3 für meine Anwendung verwenden, aber WildFly verwendet die 2 JAR-Variante für 2.2.
Oracle hat hier Ссылка gesagt, das keine 2.3 2 JAR-Variante veröffentlichen wird.
Hier ist das manuelle Verfahren:
Extrahieren Sie javax.faces.jar mit einem ZIP-Tool. Sie erhalten 3 Ordner com , javax und META-INF .
Pack com und META-INF Ordner in jsf-impl.jar mit einem ZIP-Tool.
Löschen Sie dann 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 JARs fortfahren: Upgrade JSF / Mojarra in JBoss AS / EAP / WildFly .
JBoss AS und WildFly verfügen intern über eine modulare Trennung von Java EE-basierten APIs und impl-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 in com.sun.faces.* package 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 Buildsystems den Java EE Maven-Regeln entspricht, wurden sowohl die API als auch die Implementierungsklassen in einer einzigen javax.faces.jar -Datei zusammengeführt, siehe auch Ausgabe 2028 (begonnen mit Mojarra 2.1.6 im Dezember 2011). Seit Mojarra 2.3 werden die getrennten JAR-Dateien nicht mehr erstellt.