141 votes

Migration de JSF 1.2 à JSF 2.0

Je travaille avec une application assez volumineuse écrite en JSF 1.2 . JSF 1.2 a environ 6 ans maintenant. Je dois passer à JSF 2.0. Est-ce que cela sera douloureux ? J'ai remarqué que certains attributs des balises personnalisées ont été modifiés, etc.

258voto

BalusC Points 498232

Douleur

La difficulté de la mise à niveau de JSF 1.2 vers 2.0 dépend de la technologie de visualisation que vous utilisez actuellement et de celle que vous souhaitez utiliser.

  • JSP 2.x vers JSP 2.x = Presque aucun effort.
  • Facelets 1.x à Facelets 2.0 = Peu d'efforts.
  • JSP 2.x vers Facelets 2.0 = Beaucoup d'efforts. Le double si vous avez aussi des composants personnalisés.

Changements de base

Quel que soit le changement de technologie de vue, au moins les étapes suivantes doivent être effectuées :

  • Supprimez les JAR de JSF 1.2 de l'application /WEB-INF/lib (le cas échéant).

  • Déposer les JARs de JSF 2.0 dans /WEB-INF/lib (si JSF 1.2 était fourni par servletcontainer, vous pourriez vouloir changer la politique de chargement des classes pour charger les bibliothèques de la webapp d'abord avant celles de servletcontainer, voir aussi Problèmes de chargement de classes JSF2 dans les serveurs d'application ).

  • Mise à jour de la déclaration Root de faces-config.xml pour se conformer à la spécification JSF 2.0.

    <faces-config
        xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
        version="2.0">

    Remarque : si vous utilisez JSF 2.2 ou une version plus récente, utilisez l'option http://xmlns.jcp.org au lieu de http://java.sun.com dans l'extrait XML ci-dessus.

  • Veiller à ce que la déclaration de racine de web.xml est déjà conforme au moins Servlet 2.5. JSF 2.0 ne fonctionnera pas sur les versions 2.4 ou inférieures ( bien que ce soit piratable ).

    <web-app 
        xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
        id="YourWebappID"
        version="2.5">

    Remarque : si vous utilisez Servlet 3.0 ou une version plus récente, utilisez la fonction http://xmlns.jcp.org au lieu de http://java.sun.com dans l'extrait XML ci-dessus.


JSP 2.x vers JSP 2.x

Si vous utilisez JSP 2.x et veulent garder l'utiliser, alors vous n'avez pas besoin de changer quoi que ce soit d'autre.

Mise à niveau progressive

Si vous utilisez déjà un suffixe url-pattern pour le FacesServlet comme *.jsf alors il est bon de savoir que la FacesServlet va d'abord rechercher *.xhtml et s'il n'est pas présent, il faut rechercher le fichier *.jsp fichier. Cela vous permet de convertir progressivement de JSP à Facelets en coulisse sans modifier les URL.

Mais si vous utilisez un préfixe url-pattern comme /faces/* et que vous voulez passer progressivement de JSP à Facelets, alors vous devez vraiment le changer en *.jsf et éventuellement aussi tous les liens dans les pages JSP existantes.

Il suffit de garder à l'esprit que la nouvelle navigation implicite fournie par JSF 2.0 ne vérifie pas la présence du fichier, elle se rendra à l'adresse suivante outcome.xhtml de toute façon. Donc si vous voulez venir de ou aller à *.jsp alors vous devez toujours l'inclure dans le viewid à la manière de JSF 1.x.


Facelets 1.x à Facelets 2.0

Si vous utilisez Facelets 1.x en tant que technologie de visualisation et que vous souhaitez utiliser l'interface JSF 2.0 fournie Facettes 2.0 vous devez alors effectuer les étapes supplémentaires suivantes :

  • Supprimer Facelets 1.x JAR de /WEB-INF/lib .
  • Suppression des Facelets 1.x FaceletViewHandler de faces-config.xml .
  • Toute personnalisation FaceletViewHandler doit être mise à jour pour étendre ViewHandlerWrapper à la place.
  • Ce n'est pas nécessaire, mais juste pour le nettoyage, supprimez toutes les Facelets 1.x liées <context-param> valeurs de web.xml qui sont déjà par défaut dans Facelets 2.0, comme l'option javax.faces.DEFAULT_SUFFIX avec une valeur de *.xhtml .
  • Mise à jour de la déclaration Root des Facelets taglib XML existants pour se conformer à Facelets 2.0.

    <facelet-taglib 
        xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd"
        version="2.0">

    Remarque : si vous utilisez JSF 2.2 ou une version plus récente, utilisez l'option http://xmlns.jcp.org au lieu de http://java.sun.com dans l'extrait XML ci-dessus.

C'est à peu près tout.


De JSP 2.x à Facelets 2.0

Si vous utilisez JSP 2.x comme technologie de visualisation et vous souhaitez passer à Facettes 2.0 immédiatement, alors vous devez faire beaucoup de changements avant que le site puisse être mis en ligne. Vous changez essentiellement la technologie d'affichage ici.

Modifications de la page principale

Sur chaque page principale, vous devez modifier le modèle JSP de base suivant

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
<!DOCTYPE html>
<f:view>
    <html lang="en">
        <head>
            <title>JSP page</title>
        </head>
        <body>
            <h:outputText value="JSF components here." />
        </body>
    </html>
</f:view>

..au modèle de base suivant de Facelets :

<!DOCTYPE html>
<html lang="en"
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:ui="http://java.sun.com/jsf/facelets">
    <h:head>
        <title>XHTML page</title>
    </h:head>
    <h:body>
        <h:outputText value="JSF components here." />
    </h:body>  
</html>

Remarque : si vous utilisez JSF 2.2 ou une version plus récente, utilisez l'option http://xmlns.jcp.org au lieu de http://java.sun.com dans les extraits XHTML ci-dessus.

Inclure les changements de page

Si vos pages JSP existantes sont bien conçues, vous ne devriez pas avoir de ligne de scriptlet et vous devriez également avoir seulement le <jsp:include> comme seule balise spécifique à JSP. N'importe laquelle d'entre elles doit être changée de :

<jsp:include page="include.jsp" />

à

<ui:include src="include.xhtml" />

Le modèle de base de la page d'inclusion JSP de

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
<f:subview id="include">
    <h:outputText value="JSF components here." />
</f:subview>

doit être remplacé par le modèle de page de base Facelets suivant :

<ui:composition
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:ui="http://java.sun.com/jsf/facelets">
    <h:outputText value="JSF components here." />
</ui:composition>

Remarque : si vous utilisez JSF 2.2 ou une version plus récente, utilisez l'option http://xmlns.jcp.org au lieu de http://java.sun.com dans les extraits XHTML ci-dessus.

Modification des composants personnalisés

Vous devez changer les fichiers TLD JSP en fichiers TLD Facelets comme décrit dans ce document. Guide de migration Mojarra .


Aftermath

Quelle que soit l'approche de la migration, vous pouvez éliminer progressivement les faces-config.xml par les nouvelles annotations JSF 2.0 ou même CDI . Tout <managed-bean> peut être annoté par @ManagedBean :

@ManagedBean(name="managedBeanName")
@RequestScoped
public class SomeBean {}

Suivant @RequestScoped il y a aussi @ViewScoped , @SessionScoped y @ApplicationScoped disponible. Si vous omettez le name de l'attribut @ManagedBean alors le nom de classe sera utilisé par défaut avec le premier caractère en minuscule.

@ManagedBean
@RequestScoped
public class SomeBean {}

Dans cet exemple particulier, ce sera #{someBean} .

Tout <managed-property> peuvent être annotés en utilisant @ManagedProperty :

@ManagedProperty("#{otherBean}")
private OtherBean otherBean;

Tout <validator> peuvent être annotés en utilisant @FacesValidator :

@FacesValidator("someValidator")
public class SomeValidator implements Validator {}

Tout <converter> peuvent être annotés en utilisant @FacesConverter

@FacesConverter("someConverter")
public class SomeConverter implements Converter {}

Tout <renderer> peuvent être annotés en utilisant @FacesRenderer

@FacesRenderer(componentFamily="someComponentFamily", rendererType="someRendererType")
public class SomeRenderer extends Renderer {}

Tout <navigation-case> qui utilise le nom de fichier de la page XHTML comme à la fois <from-outcome> y <to-view-id> peut être supprimée puisque ce sera implicitement fait. Cela peut être fait progressivement en changeant toutes les valeurs de résultat pour qu'elles correspondent au nom de fichier de la vue cible.

Enfin, tout bean à portée de session qui a été placé dans la session dans le seul but de conserver les données du bean lors de requêtes ultérieures dans le même onglet/fenêtre peut être marqué comme suit @ViewScoped En effet, de cette manière, le haricot ne sera pas affecté lorsque l'utilisateur final ouvrira la même page dans différents onglets/fenêtres.


Bibliothèques de composants

Notez que je ne prends pas en compte les bibliothèques de composants tiers comme PrimeFaces/RichFaces/IceFaces dans cette réponse, il serait alors impossible d'écrire une réponse fiable puisque cela se résume essentiellement à "ça dépend". En général, il suffit de mettre à niveau la bibliothèque de composants vers une version compatible avec JSF 2.0 - vérifiée par eux-mêmes - en suivant leurs instructions. Le mieux est d'écrire des tests unitaires, de les exécuter avant et après la mise à niveau et de corriger les problèmes individuellement.

Voici au moins quelques liens utiles concernant la migration de la bibliothèque de composants spécifique :

PrimeFaces n'a pas de guide de migration pour PrimeFaces 1.x vers 2.x car PrimeFaces 1.x nécessite déjà Facelets 1.x, vous devez donc suivre les étapes de migration de Facelets 1.x vers 2.x. Cependant, il existe un guide de migration PrimeFaces Guide de migration de 2.x à 3.x (et plus) qui pourrait également s'appliquer à la migration de PrimeFaces 1.x vers 3.x (ou plus). Tomahawk n'a pas non plus de guide de migration. En fait, les seuls éléments que vous devez modifier sont les JAR et, si nécessaire, vous débarrasser de tous les éléments de la base de données. <t:saveState> sur un bean à la portée de la demande en rendant la vue du bean à la portée de la demande.

0 votes

@ManagedBean(name="managedBeanName") @RequestScoped C'est ça :)

0 votes

Excellent article, qui m'a beaucoup aidé. Quelque chose à noter : quand on passe de jsf 1.2 à jsf 2, on peut être presque sûr que les gens ont utilisé a4j à partir de richfaces 3.3.x. J'ai décidé d'utiliser richfaces 3.3.3 avec jsf 2 car cela semblait être un changement médiocre à effectuer pour mettre à niveau vers richfaces 4.x . J'ai donc suivi votre guide (j'ai annulé toutes les choses liées aux facettes dans faces-config (j'ai activé viewhandler et supprimé l'annotation taglig), puis j'ai suivi les étapes suivantes community.jboss.org/wiki/RichFaces333AetJSF20 et j'ai finalement dû faire ceci stackoverflow.com/questions/85532/

0 votes

Excellente réponse. Dans mon cas, j'ai également dû définir le paramètre javax.faces.VALIDATE_EMPTY_FIELDS pour false pour obtenir la validation triée. Voir aussi : stackoverflow.com/questions/6113935/

7voto

R4J Points 62

Une chose à mentionner est que si quelqu'un utilise JSTL avec JSF 1.2, lors de la mise à niveau vers JSF2, vous devez changer l'espace de nom de :

http://java.sun.com/jstl/core

à :

http://java.sun.com/jsp/jstl/core

2 votes

Remarque : ceci ne s'applique que lorsque vous migrez de Facelets 1.x vers 2.x.

0 votes

Et pour 2.2 et plus, lisez stackoverflow.com/questions/31068678/

6voto

mvg Points 570

JSF 2.0 a beaucoup de nouvelles fonctionnalités et de nouveaux composants et je ne pense pas que la migration sera douloureuse. Le seul domaine dans lequel vous trouverez des difficultés est l'utilisation de bibliothèques tierces. Si votre application est fortement dépendante de bibliothèques comme Richfaces, vous serez confronté à un problème. Tous les composants de Richfaces 3 ne sont pas portés vers Richfaces 4.

Cela pourrait aussi aider Migration d'une application JSF 1.2 vers JSF 2.0

Regardez aussi ceci Quelles sont les nouveautés de JSF 2 ?

1 votes

Il en aurait été de même si vous aviez utilisé Richfaces avec JSF 1.x - vous vous êtes donné beaucoup de mal pour trouver comment intégrer des composants tiers avec JSF. L'approche de JSF 2.x n'est pas différente. C'est la "joie" de la programmation, n'est-ce pas ? :)

4voto

Pravin Points 172

Web.xml

 Add the jars
    1. jsf-api-2.0.jar 
    2. jsf-impl.2.0.2.jar

Étape 1 : Modifier le fichier web.xml

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
            xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
            id="WebApp_ID" version="2.5">

    <servlet>
            <servlet-name>facesServlet</servlet-name>
            <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
            <load-on-startup>1</load-on-startup>
        </servlet>

        <servlet-mapping>
            <servlet-name>facesServlet</servlet-name>
            <url-pattern>/faces/*</url-pattern>
        </servlet-mapping>
        <servlet-mapping>

            <servlet-name>facesServlet</servlet-name>
            <url-pattern>*.jsf</url-pattern>
        </servlet-mapping>

        <servlet-mapping>
            <servlet-name>facesServlet</servlet-name>
            <url-pattern>*.faces</url-pattern>
        </servlet-mapping>

        <servlet-mapping>
            <servlet-name>facesServlet</servlet-name>
        <url-pattern>*.xhtml</url-pattern>
        </servlet-mapping>

Étape 2 : webmvc-config.xml

<!-- Handles requests mapped to the Spring Web Flow system -->
    <bean id="flowController" class="org.springframework.webflow.mvc.servlet.FlowController">
        <property name="flowExecutor" ref="flowExecutor" />
        <property name="ajaxHandler">
            <bean class="org.springframework.faces.webflow.JsfAjaxHandler" />
        </property>
</bean>

Étape 3 : facess-config.xml

<faces-config xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd" version="2.0">

0voto

designatevoid Points 1

Si vous utilisez Apache Trinidad, vous devrez également le mettre à niveau vers la version 2.0 afin qu'il prenne en charge JSF 2.0. Vous trouverez plus d'informations à l'adresse suivante Le Valhalla des hackers .

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X