web-dev-qa-db-fra.com

Mettre à niveau JSF / Mojarra dans JBoss AS / EAP / WildFly

Comment mettre à niveau Mojarra sur le serveur JBoss et lui dire d'utiliser les JAR Mojarra 2.x donnés au lieu de JBoss propre jboss-jsf-api_2.1_spec-2.0.1.Final.jar comme indiqué dans le journal de démarrage?

Si cela est pertinent, j'utilise actuellement JBoss AS 7.1.

33
user2172625

La procédure ci-dessous s'applique à JBoss AS 7.2 +, JBoss EAP 6.1 + et JBoss WildFly 8 + et suppose que vous avez un contrôle total sur l'installation et la configuration du serveur. Cela met à niveau l'ensemble du serveur par défaut Version JSF:

  • Téléchargez les fichiers Mojarra API et impl individuels (et donc pas le seul javax.faces.jar fichier). La dernière version 2.1.x actuelle est 2.1.29 et la dernière version 2.2.x actuelle est 2.2.14. Supposons que vous souhaitiez passer à la version 2.2.x. Vous pouvez les télécharger individuellement depuis leur référentiel Maven:
  • Assurez-vous que JBoss est arrêté.
  • Mettre à jour l'API JSF dans /modules/system/layers/base/javax/faces/api/main:
    • Supprimez ou sauvegardez l'ancien fichier JAR (ne le conservez PAS dans le même dossier, même pas renommé!).
    • Mettez jsf-api-2.2.14.jar fichier là-dedans.
    • Ouvert module.xml fichier et modifier <resource-root> pour spécifier le nouveau nom de fichier comme dans <resource-root path="jsf-api-2.2.14.jar"/>
  • Mettre à jour l'impl JSF dans /modules/system/layers/base/com/Sun/jsf-impl/main:
    • Supprimez ou sauvegardez l'ancien fichier JAR (ne le conservez PAS dans le même dossier, même pas renommé!).
    • Mettez jsf-impl-2.2.14.jar fichier là-dedans.
    • Ouvert module.xml fichier et modifier <resource-root> pour spécifier le nouveau nom de fichier comme dans <resource-root path="jsf-impl-2.2.14.jar"/>
  • Nettoyez le cache JBoss/les données de travail juste pour vous assurer qu'aucune ancienne copie des fichiers JAR des déploiements précédents ne s'y accroche qui ne pourrait entrer en collision qu'avec les nouveaux fichiers JAR:
    • Corbeille tout le contenu de /standalone/data (sauf pour les dossiers de données personnalisés comme le dossier contenant les fichiers téléchargés, bien sûr)
    • Corbeille tout le contenu de /standalone/deployments
    • Corbeille tout le contenu de /standalone/tmp
  • Démarrez JBoss. Il devrait désormais utiliser la nouvelle version JSF pour tous les déploiements.

La même procédure s'applique à JBoss AS 7.0/7.1 et JBoss EAP 6.0, il vous suffit de naviguer dans /modules/* au lieu de /modules/system/layers/base/*, et vous devez supprimer explicitement l'ancien .index fichier là-bas, le cas échéant (JBoss en créera automatiquement un). De plus, si le module.xml dans le dossier API manque <module name="com.Sun.jsf-impl"/> à l'intérieur <dependencies>, vous devez ensuite l'ajouter manuellement.

Remarque importante: les versions de Mojarra 2.2.x antérieures à 2.2.7 échoueront dans AS/EAP lors du déploiement, à l'exception suivante: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.faces.flow.builder.FlowDefinition. Vous avez alors essentiellement 2 options: rétrograder vers Mojarra 2.1.x, ou passer à au moins 2.2.7 ou plus récent.

Si vous souhaitez passer à Mojarra 2.3, qui ne propose plus de variante 2-JAR sur Maven, vous devez créer manuellement la variante 2-JAR basée sur javax.faces.jar fichier selon cette procédure: Comment installer une variante de jar de JSF (javax.faces.jar) sur WildFly .

64
BalusC