Aggiornamento JSF/Mojarra in JBoss AS/EAP/WildFly

Question

Come aggiornare Mojarra nel server JBoss e dirlo utilizzare i propri JAR Mojarra 2.x anziché JBoss proprio jboss-jsf-api_2.1_spec-2.0.1.Final.jar come indicato nel log di avvio?

Se ciò è rilevante, attualmente utilizzo JBoss AS 7.1.

Answer 1

La procedura che segue vale per JBoss AS 7.2+, JBoss EAP 6.1+, e JBoss wildfly 8+ e si presuppone che hai il pieno controllo della installazione e la configurazione del server. Questo aggiorna la predefinita versione JSF in tutto il server:

• Scarica i singoli Mojarra API e impl file (e quindi non il singolo javax.faces.jar file). La versione 2.1.x attuale è la 2.1.29 e la versione 2.2.x attuale 2.2.14. Supponiamo che vogliate effettuare l'aggiornamento a 2.2.x. È possibile scaricare singolarmente dal loro repository Maven:
  • jsf-api-2.2.14.jar
  • jsf-impl-2.2.14.jar
• Assicurarsi che JBoss è l'arresto.
• Aggiornamento JSF API /modules/system/layers/base/javax/faces/api/main:
  • Eliminare o il backup del vecchio file JAR (non tenerlo nella stessa cartella, anche se non rinominato!).
  • Inserire il file jsf-api-2.2.14.jar lì.
  • Aprire module.xml del file e modificare <resource-root> per specificare il nome del nuovo file come in <resource-root path="jsf-api-2.2.14.jar"/> impl
• Aggiornamento JSF in /modules/system/layers/base/com/sun/jsf-impl/main:
  • Eliminare o di backup del file JAR vecchia (non tenere nella stessa cartella, anche non rinominata!).
  • Inserire il file jsf-impl-2.2.14.jar.
  • Aprire module.xml del file e modificare <resource-root> per specificare il nome del nuovo file come in <resource-root path="jsf-impl-2.2.14.jar"/> dati
• Cleanup JBoss Cache/lavoro solo per assicurarsi che non ci sia vecchia copia dei JAR da implementazioni precedenti appeso lì che avrebbe potenzialmente scontrarsi solo con i nuovi JAR:
  • Trash tutti i contenuti di /standalone/data (ad eccezione delle cartelle di dati personalizzati come cartella contenente i file caricati, ovviamente)
  • Trash tutti i contenuti del /standalone/deployments
  • Cestino tutti i contenuti di /standalone/tmp
• Avviare JBoss. Dovrebbe ora utilizzare la nuova versione JSF per tutte le distribuzioni.

La stessa procedura si applica a JBoss AS 7.0/7.1 e JBoss EAP 6.0, avete solo bisogno di navigare in /modules/* invece di /modules/system/layers/base/*, ed è necessario eliminare in modo esplicito il vecchio file .index lì, se del caso (JBoss ne autocreara uno). Inoltre, se nella cartella API dello module.xml manca il all'interno di , è necessario aggiungerlo manualmente.

Nota importante: le versioni Mojarra 2.2.x precedenti alla 2.2.7 non riusciranno in AS/EAP durante la distribuzione con la seguente eccezione: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.faces.flow.builder.FlowDefinition. In pratica hai 2 opzioni: esegui il downgrade a Mojarra 2.1.x, o esegui l'aggiornamento almeno al 2.2.7 o più recente.

Nel caso in cui si desidera effettuare l'aggiornamento a Mojarra 2.3, che non propone più una variante 2-JAR su Maven, avresti bisogno di creare manualmente la variante 2-JAR sulla base di javax.faces.jar file secondo questa procedura: How to install one jar variant of JSF (javax.faces.jar) on WildFly.