Migrando do JSF 1.2 para o JSF 2.0

Eu estou trabalhando com um aplicativo bastante grande escrito no JSF 1.2 . O JSF 1.2 tem cerca de 6 anos agora. Eu preciso atualizar para o JSF 2.0. Quão doloroso será isto? Percebi que alguns atributos em tags personalizadas foram alterados, etc.

    Dolorosidade

    A dificuldade de atualizar o JSF 1.2 para 2.0 depende da tecnologia de visualização que você está usando atualmente e da qual deseja usar.

    • JSP 2.x para JSP 2.x = Quase sem esforço.
    • Facelets 1.x para Facelets 2.0 = Pouco esforço.
    • JSP 2.x para Facelets 2.0 = Muito esforço. Duplique isso se você também tiver componentes personalizados.

    Mudanças básicas

    Independentemente do interruptor da tecnologia de visualização, pelo menos, os seguintes passos devem ser feitos:

    • Remova os JARs do JSF 1.2 de /WEB-INF/lib (se houver).
    • Elimine os JARs do JSF 2.0 em /WEB-INF/lib (se o JSF 1.2 fosse fornecido pelo servletcontainer, talvez você queira alterar a política de carregamento de class para carregar as bibliotecas do webapp primeiro antes das bibliotecas do servletcontainer, consulte também Problemas de carregamento de class JSF2 nos servidores de aplicativos ).
    • Atualize a declaração da raiz do faces-config.xml para atender às especificações do JSF 2.0.

        
    • Assegure-se de que a declaração de raiz do web.xml já esteja em conformidade com pelo menos o Servlet 2.5. O JSF 2.0 não funciona em 2.4 ou menos ( embora seja hackável ).

        

    JSP 2.x para JSP 2.x

    Se você estiver usando o JSP 2.xe quiser continuar usando-o, então basicamente não precisará alterar mais nada.

    Atualizando gradualmente

    Se você já estiver usando um url-pattern sufixo para o FacesServlet , como *.jsf , então é bom saber que o FacesServlet irá primeiro verificar o arquivo *.xhtml e, se ele não estiver presente, procurar pelo arquivo *.jsp . Isso permite que você converta gradualmente de JSP para Facelets nos bastidores sem alterar as URLs.

    Mas se você estiver usando um url-pattern prefixo, como /faces/* e deseja atualizar gradualmente de JSP para Facelets, será necessário alterá-lo para *.jsf e possivelmente também todos os links nas páginas JSP existentes.

    Você só precisa ter em mente que a nova navegação implícita fornecida pelo JSF 2.0 não verifica a presença do arquivo, ele irá para o outcome.xhtml qualquer maneira. Então, se você quer vir ou ir para *.jsp , então você ainda precisa incluí-lo no viewid do modo JSF 1.x.


    Facelets 1.x para Facelets 2.0

    Se você estiver usando o Facelets 1.x como tecnologia de visualização e quiser usar o Facelets 2.0 fornecido pelo JSF 2.0 , será necessário executar as seguintes etapas adicionais:

    • Remova o JAR Facelets 1.x de /WEB-INF/lib .
    • Remova o Facelets 1.x FaceletViewHandler do faces-config.xml .
    • Qualquer implementação personalizada do FaceletViewHandler precisa ser atualizada para estender o ViewHandlerWrapper .
    • Não é necessário, mas apenas para limpeza, remova quaisquer valores relacionados ao Facelets 1.x do web.xml que já sejam padrão no Facelets 2.0, como o javax.faces.DEFAULT_SUFFIX com o valor de *.xhtml .
    • Atualize a declaração raiz dos XMLs taglib existentes do Facelet para atender ao Facelets 2.0.

        

    Isso deveria ser basicamente isso.


    JSP 2.x para Facelets 2.0

    Se você estiver usando o JSP 2.x como tecnologia de visualização e desejar atualizar para o Facelets 2.0 imediatamente, será necessário fazer muitas alterações antes de o site entrar em operação. Você está basicamente mudando a tecnologia de visualização aqui.

    Mudanças na página principal

    Em todas as páginas mestras, você precisa alterar o seguinte modelo JSP básico.

     < %@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       

    ..o seguinte modelo básico de Facelets:

     < !DOCTYPE html>   XHTML page      

    Incluir alterações de página

    Se as páginas JSP existentes forem bem projetadas, você não deverá ter nenhuma linha de código de scriptlet e também deverá ter apenas o como a única tag específica de JSP. Qualquer um desses itens precisa ser alterado de:

      

    para

      

    O JSP básico inclui o modelo de página 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"%>    

    .. deve ser alterado para os seguintes Facelets básicos incluem o modelo de página:

        

    Mudanças de componentes personalizados

    Você precisa alterar os arquivos TLD do JSP para arquivos TLD do Facelets, conforme descrito neste Guia de Migração do Mojarra .


    Rescaldo

    Independentemente da abordagem de migration, você pode eliminar gradualmente o faces-config.xml pelas novas annotations do JSF 2.0. Qualquer pode ser anotado por @ManagedBean :

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

    Ao lado de @RequestScoped , há também @ViewScoped , @SessionScoped e @ApplicationScoped disponíveis. Se você omitir o atributo name do @ManagedBean , ele será padronizado para classname com o primeiro caractere em minúsculo.

     @ManagedBean @RequestScoped public class SomeBean {} 

    Neste exemplo específico, será #{someBean} .

    Qualquer pode ser anotado usando @ManagedProperty :

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

    Qualquer pode ser anotado usando @FacesValidator :

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

    Qualquer pode ser anotado usando @FacesConverter

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

    Qualquer pode ser anotado usando @FacesRenderer

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

    Qualquer que use o nome do arquivo da página XHTML como e pode ser removido, pois isso será feito implicitamente . Isso pode ser feito gradualmente alterando todos os valores de resultado para corresponder ao nome do arquivo da visualização de destino.

    Finalmente, qualquer bean de escopo de session que foi colocado na session com a única razão para reter os dados de bean em solicitações subseqüentes na mesma aba / janela pode ser melhor marcado como @ViewScoped , porque dessa forma o bean não será afetado quando o enduser abre a mesma página em diferentes guias / janelas.


    Bibliotecas de componentes

    Note que eu não considero bibliotecas de componentes de terceiros como PrimeFaces / RichFaces / IceFaces nesta resposta, então seria impossível escrever uma resposta confiável, uma vez que basicamente se resume a “depende”. Em geral, basta atualizar a biblioteca de componentes para uma versão compatível verificada por JSF 2.0, conforme suas instruções. O melhor é apenas escrever testes de unidade, executá-los antes e depois da atualização e corrigir quaisquer problemas individualmente.

    Aqui estão pelo menos alguns links úteis com relação à migration da biblioteca de componentes específica:

    • Guia de migration do RichFaces – migration de 3.3.x para 4.x
    • IceFaces 2 Wiki – Guia de Compatibilidade do IceFaces 1.x

    O PrimeFaces não possui um guia de migration para o PrimeFaces 1.x para 2.x, já que o PrimeFaces 1.x requer o Facelets 1.x, portanto, você só precisa seguir as etapas de migration do Facelets 1.x para 2.x. No entanto, há um guia de migration do PrimeFaces 2.x para 3.x que também pode ser aplicado na migration do PrimeFaces 1.x para 3.x. Tomahawk também não tem guia de migration. Basicamente, o único que você precisa alterar são os JARs e, se necessário, livrar-se de todas as referências em um bean com escopo de solicitação, tornando a visualização do bean com escopo definido.

    Uma coisa a ser mencionada é que, se alguém estiver usando o JSTL com o JSF 1.2, ao atualizar para o JSF2, você deverá alterar o namespace de:

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

    para:

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

    O JSF 2.0 tem muitos novos resources e componentes e não sinto que a migration seja dolorosa. Apenas a área que você achará difícil é usar bibliotecas terceirizadas. Se o seu aplicativo for altamente dependente de bibliotecas como o Richfaces, você enfrentará problemas. Nem todos os componentes do Richfaces 3 são portados para o Richfaces 4.

    Isso também pode ajudar a migration do aplicativo JSF 1.2 para o JSF 2.0

    Também verifique isso O que há de novo no JSF 2?

    Web.xml

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

    Etapa 1: alterar o web.xml

       facesServlet javax.faces.webapp.FacesServlet 1   facesServlet /faces/*   facesServlet *.jsf   facesServlet *.faces   facesServlet *.xhtml  

    Etapa 2: webmvc-config.xml

            

    Passo 3: facess-config.xml

      

    Se você estiver usando o Apache Trinidad, você também terá que atualizá-lo para a versão 2.0 para que ele suporte o JSF 2.0. Há mais informações no Valhalla do Hacker .