Oto procedura obsługi:
Extract javax.faces.jar
z narzędziem ZIP. Dostaniesz 3 foldery: com
, javax
i META-INF
.
Zapakuj com
i META-INF
folderów do jsf-impl.jar
za pomocą narzędzia ZIP.
Następnie usunąć wszystkie pliki/podfoldery w META-INF
wyjątkiem z MANIFEST.MF
.
Zapakuj javax
i META-INF
folderów do jsf-api.jar
za pomocą narzędzia ZIP.
Kontynuuj tutaj z tymi JARami: Upgrade JSF/Mojarra in JBoss AS/EAP/WildFly.
Dla zainteresowanych, JBoss AS i JBoss Application Server posiada wewnętrznie modułową separację Java EE oparte API i plików IMPL. Oddzielone pliki JAR jsf-api.jar
i jsf-impl.jar
są nadal potrzebne. Powód nie jest tak naprawdę techniczny, ale tylko dodatkowa usługa wymuszająca na programistach programowanie przeciwko właściwym bibliotekom. Tylko moduły API są ujawniane w czasie kompilacji (zwykle za pomocą zintegrowanej wtyczki IDE, która dodaje je do "ścieżki budowania"). Powinno to zapobiec przypadkowemu wyszukiwaniu, importowaniu i stosowaniu klas implementacji, takich jak te w pakiecie com.sun.faces.*
.
Już od wersji 1.x, implementacja JSF Mojarra składała się z dwóch plików JAR: jsf-api.jar
i jsf-impl.jar
. JAR API zawierał klasy javax.faces.*
, a plik JAR implementacji zawierał klasy com.sun.faces.*
. Ponieważ zmiana systemu kompilacji jest zgodna z regułami Java EE Maven, zarówno API, jak i klasy implementacji zostały scalone w pojedynczy plik javax.faces.jar
, patrz także issue 2028 (rozpoczęty z Mojarra 2.1.6 na grudzień 2011). Od wersji Mojarra 2.3 oddzielone pliki JAR nie są już budowane.
A WildFly nie może korzystać z jednego wariantu słoika? Czy to gdzieś jest powiedziane? – Kukeltje
'javax.faces.jar' jest przeznaczone tylko dla GlassFish. Reszta jest podobna http://balusc.omnifaces.org/2014/10/jsf-22-tutorial-with-eclipse-and-wildfly.html#UpgradeMojarraInWildFly, http://stackoverflow.com/a/17085879/1391249 – Tiny