Réponses:
La difficulté de la mise à niveau de JSF 1.2 vers 2.0 dépend de la technologie d'affichage que vous utilisez actuellement et que vous souhaitez utiliser.
Quel que soit le changement de technologie d'affichage, au moins les étapes suivantes doivent être effectuées:
/WEB-INF/lib
(le cas échéant)./WEB-INF/lib
(si JSF 1.2 était fourni par servletcontainer, vous souhaiterez peut-être modifier la politique de chargement de classes pour charger les bibliothèques d'applications Web avant les bibliothèques servletcontainer, voir également Problèmes de chargement de classes JSF2 dans les serveurs d'applications ).Mettez à jour la déclaration racine de faces-config.xml
pour se conformer aux spécifications 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: lorsque vous utilisez JSF 2.2 ou plus récent, utilisez le http://xmlns.jcp.org
domaine d'espace de noms au lieu de http://java.sun.com
tout le fragment XML ci-dessus.
Assurez-vous que la déclaration racine de web.xml
est déjà conforme au moins à Servlet 2.5. JSF 2.0 ne fonctionnera pas sur 2.4 ou version antérieure ( bien qu'il 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: lorsque vous utilisez Servlet 3.0 ou une version plus récente, utilisez le http://xmlns.jcp.org
domaine de l' espace de noms au lieu de http://java.sun.com
tout l'extrait de code XML ci-dessus.
Si vous utilisez JSP 2.x et que vous souhaitez continuer à l' utiliser, vous n'avez fondamentalement pas besoin de changer quoi que ce soit d'autre.
Si vous utilisez déjà un suffixe url-pattern
pour le FacesServlet
, comme *.jsf
, alors il est bon de savoir que le FacesServlet
recherchera d'abord le *.xhtml
fichier et s'il n'est pas présent, le recherchera ensuite *.jsp
. Cela vous permet de convertir progressivement de JSP en Facelets en coulisses sans changer les URL.
Mais si vous utilisez un préfixe url-pattern
, comme /faces/*
et que vous souhaitez progressivement passer de JSP à Facelets, vous devez vraiment le changer en *.jsf
et éventuellement aussi tous les liens dans les pages JSP existantes.
Il vous suffit de garder à l'esprit que la nouvelle navigation implicite fournie par JSF 2.0 ne recherche pas la présence du fichier, elle ira de outcome.xhtml
toute façon. Donc, si vous voulez venir ou aller vers *.jsp
, vous devez toujours l'inclure dans le viewid de la manière JSF 1.x.
Si vous utilisez Facelets 1.x comme technologie d'affichage et que vous souhaitez utiliser les Facelets 2.0 fournis par JSF 2.0 , vous devez suivre les étapes supplémentaires suivantes:
/WEB-INF/lib
.FaceletViewHandler
de faces-config.xml
.FaceletViewHandler
implémentation personnalisée doit être mise à jour pour être étendue à la ViewHandlerWrapper
place.<context-param>
valeurs liées à Facelets 1.x web.xml
qui sont déjà par défaut dans Facelets 2.0, comme la javax.faces.DEFAULT_SUFFIX
valeur with de *.xhtml
.Mettre à jour la déclaration racine des XML de taglib Facelet 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: lorsque vous utilisez JSF 2.2 ou plus récent, utilisez le http://xmlns.jcp.org
domaine d'espace de noms au lieu de http://java.sun.com
tout le fragment XML ci-dessus.
Cela devrait être essentiellement cela.
Si vous utilisez JSP 2.x comme technologie de visualisation et que vous souhaitez passer immédiatement à Facelets 2.0 , vous devez effectuer de nombreux changements avant que le site ne puisse être mis en ligne. Vous changez fondamentalement la technologie d'affichage ici.
Sur chaque page maître, 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 de Facelets suivant:
<!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: lorsque vous utilisez JSF 2.2 ou plus récent, utilisez le http://xmlns.jcp.org
domaine de l' espace de noms au lieu de l' http://java.sun.com
ensemble des extraits XHTML ci-dessus.
Si vos pages JSP existantes sont bien conçues, vous ne devriez avoir aucune ligne de code de scriptlet et vous ne devriez également avoir que <jsp:include>
la seule balise spécifique à JSP. Chacun de ceux-ci doit être changé de:
<jsp:include page="include.jsp" />
à
<ui:include src="include.xhtml" />
Le JSP de base inclut un modèle de page 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 d'inclusion de Facelets de base 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: lorsque vous utilisez JSF 2.2 ou plus récent, utilisez le http://xmlns.jcp.org
domaine de l' espace de noms au lieu de l' http://java.sun.com
ensemble des extraits XHTML ci-dessus.
Vous devez changer les fichiers JSP TLD en fichiers Facelets TLD comme décrit dans ce guide de migration Mojarra .
Quelle que soit l'approche de migration, vous pouvez progressivement éliminer le 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 {}
À côté @RequestScoped
, il y a aussi @ViewScoped
, @SessionScoped
et @ApplicationScoped
disponibles. Si vous omettez l' name
attribut de @ManagedBean
, il sera par défaut classname avec le premier caractère en minuscule.
@ManagedBean
@RequestScoped
public class SomeBean {}
Dans cet exemple particulier, ce sera le cas #{someBean}
.
Tout <managed-property>
peut être annoté en utilisant @ManagedProperty
:
@ManagedProperty("#{otherBean}")
private OtherBean otherBean;
Tout <validator>
peut être annoté en utilisant @FacesValidator
:
@FacesValidator("someValidator")
public class SomeValidator implements Validator {}
Tout <converter>
peut être annoté à l'aide de@FacesConverter
@FacesConverter("someConverter")
public class SomeConverter implements Converter {}
Tout <renderer>
peut être annoté à l'aide de@FacesRenderer
@FacesRenderer(componentFamily="someComponentFamily", rendererType="someRendererType")
public class SomeRenderer extends Renderer {}
Tout <navigation-case>
ce qui utilise le nom de fichier de la page XHTML comme les deux <from-outcome>
et <to-view-id>
peut être supprimé car cela sera fait implicitement . Cela peut être fait progressivement en modifiant 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 avec la seule raison de conserver les données du bean dans les demandes suivantes dans le même onglet / fenêtre peut mieux être marqué @ViewScoped
, car de cette façon le bean ne sera pas affecté lorsque l'utilisateur final s'ouvre la même page dans différents onglets / fenêtres.
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 car elle se résume essentiellement à "ça dépend". En général, il suffit de simplement mettre à niveau la bibliothèque de composants vers une version compatible JSF 2.0, vérifiée par eux-mêmes, conformément à leurs instructions. Le mieux est de simplement écrire des tests unitaires, de les exécuter avant et après la mise à niveau et de résoudre les problèmes individuellement.
Voici au moins quelques liens utiles concernant la migration de la bibliothèque de composants spécifiques:
PrimeFaces n'a pas de guide de migration pour PrimeFaces 1.x à 2.x car PrimeFaces 1.x nécessite déjà Facelets 1.x, il vous suffit donc de suivre les étapes de migration de Facelets 1.x à 2.x. Cependant, il existe un guide de migration PrimeFaces 2.x vers 3.x (et supérieur) qui peut également s'appliquer lors de la migration de PrimeFaces 1.x vers 3.x (ou supérieur). Tomahawk n'a pas non plus de guide de migration. Fondamentalement, les seuls que vous devez modifier sont les JAR et si nécessaire, supprimez toutes les <t:saveState>
références sur un bean à portée de requête en rendant la vue de bean étendue.
javax.faces.VALIDATE_EMPTY_FIELDS
paramètre sur false
pour obtenir la validation triée. Voir aussi: stackoverflow.com/questions/6113935/…
Une chose à mentionner est que si quelqu'un utilise JSTL avec JSF 1.2, lors de la mise à niveau vers JSF2, vous devez modifier l'espace de noms de:
à:
JSF 2.0 a de nombreuses nouvelles fonctionnalités et composants et je ne pense pas que la migration sera pénible. Le seul domaine que vous trouverez difficile est d'utiliser des bibliothèques de tiers. Si votre application dépend fortement de bibliothèques telles que Richfaces, vous serez confronté à un problème. Tous les composants de Richfaces 3 ne sont pas portés vers Richfaces 4.
Cela peut également aider la migration de l'application JSF 1.2 vers JSF 2.0
Vérifiez également ceci. Quoi de neuf dans JSF 2?
Web.xml
Add the jars
1. jsf-api-2.0.jar
2. jsf-impl.2.0.2.jar
Étape 1: Changez 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">
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. Il y a plus d'informations sur Hacker's Valhalla .