Sto lavorando con un’app piuttosto grande scritta in JSF 1.2 . JSF 1.2 ha circa 6 anni ora. Devo effettuare l’aggiornamento a JSF 2.0. Quanto sarà doloroso questo? Ho notato che alcuni attributi nei tag personalizzati sono stati modificati, ecc.
La sofferenza dell’aggiornamento di JSF da 1.2 a 2.0 dipende dalla tecnologia di visualizzazione che si sta attualmente utilizzando e che si desidera utilizzare.
Indipendentemente dallo switch della tecnologia di visualizzazione, è necessario eseguire almeno le seguenti operazioni:
/WEB-INF/lib (se presente). /WEB-INF/lib (se JSF 1.2 era fornito da servlet container, è ansible modificare la politica di caricamento classi per caricare le librerie Webapp prima delle librerie servlet container, vedere anche Problemi di caricamento classi JSF2 nei server applicazioni ). Aggiornare la dichiarazione radice di faces-config.xml per soddisfare le specifiche JSF 2.0.
Assicurarsi che la dichiarazione radice di web.xml sia già conforms almeno al servlet 2.5. JSF 2.0 non funzionerà su 2.4 o inferiore ( anche se è hackerabile ).
Se si utilizza JSP 2.x e si desidera continuare a utilizzarlo, in pratica non è necessario modificare altro.
Se stai già utilizzando un suffisso url-pattern per il FacesServlet , come *.jsf , allora è bene sapere che FacesServlet cercherà prima il file *.xhtml e se non è presente, *.jsp scansione per il file *.jsp . Ciò consente di convertire gradualmente da JSP a Facelets dietro le quinte senza modificare gli URL.
Ma se stai usando un prefisso url-pattern , come /faces/* e vuoi passare gradualmente da JSP a Facelets, devi davvero cambiarlo in *.jsf e possibilmente anche in tutti i link nelle pagine JSP esistenti.
Hai solo bisogno di tenere a mente che il nuovo JSF 2.0 fornito navigazione implicita non ricerca la presenza del file, andrà comunque a risultato.xhtml. Quindi, se vuoi venire da o andare su *.jsp , devi comunque includerlo nel viewid del modo JSF 1.x.
Se si utilizza Facelets 1.x come tecnologia di visualizzazione e si desidera utilizzare Facelets 2.0 di JSF 2.0 , è necessario eseguire i seguenti passaggi aggiuntivi:
/WEB-INF/lib . FaceletViewHandler da faces-config.xml . FaceletViewHandler implementazione personalizzata di FaceletViewHandler per estendere ViewHandlerWrapper . web.xml che è già predefinito in Facelets 2.0, come javax.faces.DEFAULT_SUFFIX con valore di *.xhtml . Aggiornare la dichiarazione di root degli XML di Facelet taglib esistenti per conformarsi a Facelets 2.0.
Questo dovrebbe essere fondamentalmente.
Se si utilizza JSP 2.x come tecnologia di visualizzazione e si desidera eseguire immediatamente l’aggiornamento a Facelets 2.0 , è necessario apportare molte modifiche prima che il sito possa essere pubblicato. In pratica stai cambiando la tecnologia di visualizzazione qui.
Su ogni pagina master, è necessario modificare il seguente modello JSP di base.
<%@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"%> JSP page
… al seguente modello Facelets di base:
XHTML page
Se le tue pagine JSP esistenti sono ben progettate, non dovresti avere alcuna linea di codice scriptlet e dovresti anche avere solo
a
Il JSP di base include il modello di pagina di ..
<%@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"%>
.. deve essere cambiato con il seguente modello di pagina di base Facelets:
È necessario modificare i file TLD JSP in file TLD Facelets come descritto in questa Guida alla migrazione di Mojarra .
Indipendentemente dall’approccio alla migrazione, è ansible eliminare gradualmente faces-config.xml dalle nuove annotazioni JSF 2.0. Qualsiasi @ManagedBean :
@ManagedBean(name="managedBeanName") @RequestScoped public class SomeBean {}
Accanto a @RequestScoped , sono disponibili anche @ViewScoped , @SessionScoped e @ApplicationScoped . Se si omette l’attributo name di @ManagedBean , il name predefinito sarà classname con il 1 ° carattere in minuscolo.
@ManagedBean @RequestScoped public class SomeBean {}
In questo particolare esempio, sarà #{someBean} .
Qualsiasi @ManagedProperty :
@ManagedProperty("#{otherBean}") private OtherBean otherBean;
Qualsiasi @FacesValidator :
@FacesValidator("someValidator") public class SomeValidator implements Validator {}
Qualsiasi @FacesConverter
@FacesConverter("someConverter") public class SomeConverter implements Converter {}
Qualsiasi @FacesRenderer
@FacesRenderer(componentFamily="someComponentFamily", rendererType="someRendererType") public class SomeRenderer extends Renderer {}
Qualsiasi
Infine, qualsiasi bean con scope di sessione che è stato inserito nella sessione con il solo motivo per conservare i dati del bean nelle richieste successive nella stessa scheda / finestra può essere meglio contrassegnato con @ViewScoped , perché in questo modo il bean non sarà influenzato quando il utente finale apre la stessa pagina in diverse tabs / windows.
Nota che in questa risposta non prendo in considerazione alcuna libreria di componenti di terze parti come PrimeFaces / RichFaces / IceFaces, sarebbe quindi imansible scrivere una risposta affidabile poiché in pratica si riduce a “dipende”. In generale è sufficiente aggiornare semplicemente la libreria dei componenti a una versione compatibile con JSF 2.0, come da loro indicato. La cosa migliore è semplicemente scrivere test unitari, eseguirli prima e dopo l’aggiornamento e risolvere individualmente eventuali problemi.
Ecco almeno alcuni link utili per quanto riguarda la migrazione della libreria di componenti specifici:
PrimeFaces non ha una guida di migrazione per PrimeFaces 1.x a 2.x poiché PrimeFaces 1.x richiede già Facelets 1.x, quindi è sufficiente seguire i passaggi di migrazione da Facelets 1.x a 2.x. Tuttavia, esiste una guida alla migrazione di PrimeFaces 2.x a 3.x che potrebbe essere applicata anche alla migrazione da PrimeFaces 1.x a 3.x. Tomahawk non ha nemmeno una guida alla migrazione. Fondamentalmente, l’unico che è necessario modificare sono i JAR e, se necessario, eliminare tutti i riferimenti
Una cosa da dire è che se qualcuno sta usando JSTL con JSF 1.2, allora quando si aggiorna a JSF2 si dovrebbe cambiare lo spazio dei nomi da:
a:
JSF 2.0 ha molte nuove funzionalità e componenti e non ritengo che la migrazione sarà dolorosa. L’unica area che troverai difficile è usare le librerie di thrid party. Se la tua applicazione dipende in larga misura da librerie come Richfaces, dovrai affrontare un problema. Non tutti i componenti di Richfaces 3 sono portati su Richfaces 4.
Questo potrebbe anche aiutare la migrazione dell’applicazione JSF 1.2 a JSF 2.0
Controlla anche ciò che c’è di nuovo in JSF 2?
web.xml
Add the jars 1. jsf-api-2.0.jar 2. jsf-impl.2.0.2.jar
Passaggio 1: modifica web.xml
facesServlet javax.faces.webapp.FacesServlet 1 facesServlet /faces/* facesServlet *.jsf facesServlet *.faces facesServlet *.xhtml
Passaggio 2: webmvc-config.xml
Fase 3: facess-config.xml
Se si utilizza Apache Trinidad, è necessario aggiornarlo alla versione 2.0 in modo che supporti JSF 2.0. Ci sono altre informazioni su Hacker’s Valhalla .