Migrazione da JSF 1.2 a JSF 2.0

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.

    Dolore

    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.

    • JSP 2.x a JSP 2.x = Quasi nessuno sforzo.
    • Facelets 1.x a Facelets 2.0 = Piccolo sforzo.
    • JSP 2.x a Facelets 2.0 = Molto sforzo. Raddoppia se hai anche componenti personalizzati.

    Cambiamenti di base

    Indipendentemente dallo switch della tecnologia di visualizzazione, è necessario eseguire almeno le seguenti operazioni:

    • Rimuovere JAR JSF 1.2 da /WEB-INF/lib (se presente).
    • Rilasciare JAR JSF 2.0 in /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 ).

        

    JSP 2.x a JSP 2.x

    Se si utilizza JSP 2.x e si desidera continuare a utilizzarlo, in pratica non è necessario modificare altro.

    Aggiornamento graduale

    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.


    Facelets 1.x a Facelets 2.0

    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:

    • Rimuovi Facelets 1.x JAR da /WEB-INF/lib .
    • Rimuovere Facelet 1.x FaceletViewHandler da faces-config.xml .
    • È necessario aggiornare FaceletViewHandler implementazione personalizzata di FaceletViewHandler per estendere ViewHandlerWrapper .
    • Non necessario, ma solo per la pulizia, rimuovere qualsiasi valore di contest relativo a Facelets 1.x da 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.


    JSP 2.x a Facelets 2.0

    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.

    La pagina principale cambia

    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"%> < !DOCTYPE html>    JSP page       

    … al seguente modello Facelets di base:

     < !DOCTYPE html>   XHTML page      

    Includi cambi di pagina

    Se le tue pagine JSP esistenti sono ben progettate, non dovresti avere alcuna linea di codice scriptlet e dovresti anche avere solo come unico tag specifico JSP. Ognuno di questi deve essere cambiato da:

      

    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:

        

    Modifiche ai componenti personalizzate

    È necessario modificare i file TLD JSP in file TLD Facelets come descritto in questa Guida alla migrazione di Mojarra .


    conseguenze

    Indipendentemente dall’approccio alla migrazione, è ansible eliminare gradualmente faces-config.xml dalle nuove annotazioni JSF 2.0. Qualsiasi può essere annotato da @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 può essere annotata usando @ManagedProperty :

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

    Qualsiasi può essere annotato usando @FacesValidator :

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

    Qualsiasi può essere annotato usando @FacesConverter

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

    Qualsiasi può essere annotato usando @FacesRenderer

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

    Qualsiasi che utilizza il nome file della pagina XHTML come entrambi e può essere rimosso poiché ciò sarà implicitamente fatto. Questo può essere fatto gradualmente cambiando tutti i valori di risultato in modo che corrispondano al nome file della vista di destinazione.

    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.


    Librerie di componenti

    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:

    • Guida alla migrazione di RichFaces: migrazione da 3.3.x a 4.x.
    • IceFaces 2 Wiki – IceFaces 1.x Guida alla compatibilità

    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 su un bean con scope della richiesta rendendo la vista bean con ambito.

    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:

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

    a:

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

    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 .