10. Aplicativo exemplo-06: rdvmedecins-pfm-spring

10.1. A migração

Agora vamos portar a aplicação anterior para um ambiente Spring/Tomcat:

Vamos nos basear em duas aplicações já desenvolvidas. Utilizaremos:

as camadas [DAO] e [JPA] da versão 02 JSF / Spring,
a camada [web] / Primefaces mobile da versão 05 PFM / EJB,
os arquivos de configuração do Spring da versão 02

Estamos realizando aqui um trabalho semelhante ao que foi feito para portar a aplicação JSF2 / EJB / Glassfish para um ambiente JSF2 / Spring Tomcat. Por isso, daremos menos explicações. O leitor pode, se necessário, consultar essa migração.

Colocamos todos os projetos necessários para a portabilidade em uma nova pasta [rdvmedecins-pfm-spring] [1]:

[mv-rdvmedecins-spring-dao-jpa]: as camadas [DAO] e [JPA] da versão 02 JSF / Spring,
[mv-rdvmedecins-spring-metier]: a camada [métier] da versão 02 JSF / Spring,
[mv-rdvmedecins-pfmobile]: a camada [web] da versão 05 do PrimeFaces Mobile / EJB,
em [2], carregamos no NetBeans,
em [3], as dependências do projeto web não estão mais corretas:
- as dependências nas camadas [DAO], [JPA] e [métier] devem ser alteradas para agora referenciar os projetos Spring;
- o servidor Glassfish fornecia as bibliotecas de JSF. Isso não acontece mais com o servidor Tomcat. Portanto, é necessário adicioná-las às dependências.

O projeto [web] sofreu as seguintes alterações:

O arquivo [pom.xml] da camada [web] agora possui as seguintes dependências:


<dependencies>
    <dependency>
      <groupId>org.primefaces</groupId>
      <artifactId>primefaces</artifactId>
      <version>3.2</version>
      <type>jar</type>
    </dependency>
    <dependency>
      <groupId>org.primefaces</groupId>
      <artifactId>mobile</artifactId>
      <version>0.9.1</version>
      <type>jar</type>
    </dependency>
    <dependency>
      <groupId>com.sun.faces</groupId>
      <artifactId>jsf-api</artifactId>
      <version>2.1.8</version>
    </dependency>
    <dependency>
      <groupId>com.sun.faces</groupId>
      <artifactId>jsf-impl</artifactId>
      <version>2.1.8</version>
    </dependency>
    <dependency>
      <groupId>${project.groupId}</groupId>
      <artifactId>mv-rdvmedecins-spring-dao-jpa</artifactId>
      <version>${project.version}</version>
    </dependency>
    <dependency>
      <groupId>${project.groupId}</groupId>
      <artifactId>mv-rdvmedecins-spring-metier</artifactId>
      <version>${project.version}</version>
    </dependency>
  </dependencies>

Estão ocorrendo erros. Eles são causados pelas referências EJB da camada [web]. Vamos analisar primeiro o bean [Application]:

Removemos todas as linhas com erros causados por pacotes ausentes, renomeamos a interface [IMetierLocal] como [IMetier] (esse é o nome dela na camada [métier] do Spring) e usamos o Spring para instanciá-la:


package beans;

import java.util.ArrayList;
import java.util.List;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import rdvmedecins.metier.service.IMetier;

public class Application {

  // camada de negócios
  private IMetier metier;
  // erros
  private List<Erreur> erreurs = new ArrayList<Erreur>();
  private Boolean erreur = false;

  public Application() {
    try {
      // instanciação da camada [métier]
      ApplicationContext ctx = new ClassPathXmlApplicationContext("spring-config-metier-dao.xml");
      metier = (IMetier) ctx.getBean("metier");
    } catch (Throwable th) {
      // o erro é registrado
      erreur = true;
      erreurs.add(new Erreur(th.getClass().getName(), th.getMessage()));
      while (th.getCause() != null) {
        th = th.getCause();
        erreurs.add(new Erreur(th.getClass().getName(), th.getMessage()));
      }
      return;
    }
  }

  // getters
  public Boolean getErreur() {
    return erreur;
  }

  public List<Erreur> getErreurs() {
    return erreurs;
  }

  public IMetier getMetier() {
    return metier;
  }
}

linhas 20-21: instanciação da camada [métier] a partir do arquivo de configuração do Spring. Esse arquivo é o mesmo utilizado pelas camadas [métier] e [1]. Nós o copiamos para o projeto web [2]:

linhas 22-31: tratamos uma possível exceção e armazenamos sua pilha no campo da linha 14.

Feito isso, o bean [Application] não apresenta mais erros. Vamos agora examinar os beans [Form], [1] e [2]:

3

4

Excluímos todas as linhas com erros (importações e anotações) devido a pacotes ausentes e renomeamos a interface [IMetier] para [ImetierLocal]. Isso é suficiente para eliminar todos os erros [3].

Além disso, é necessário adicionar no código do bean [Form] o getter e o setter do campo


  // bean Application
private Application application;

Algumas das anotações removidas nos beans [Application] e [Form] declaravam as classes como beans com um determinado escopo. Agora, essa configuração é feita no seguinte arquivo [faces-config.xml] [4]:


<?xml version='1.0' encoding='UTF-8'?>

<!-- =========== FULL CONFIGURATION FILE ================================== -->

<faces-config version="2.0"
              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">

  <application>
    <!-- o arquivo de mensagens -->
    <resource-bundle>
      <base-name>
        messages
      </base-name>
      <var>msg</var>
    </resource-bundle>
    <message-bundle>messages</message-bundle>
    <default-render-kit-id>PRIMEFACES_MOBILE</default-render-kit-id>
  </application>
    <!-- o bean applicationBean -->
  <managed-bean>
    <managed-bean-name>applicationBean</managed-bean-name>
    <managed-bean-class>beans.Application</managed-bean-class>
    <managed-bean-scope>application</managed-bean-scope>
  </managed-bean>
    <!-- o bean de formulário -->
  <managed-bean>
    <managed-bean-name>form</managed-bean-name>
    <managed-bean-class>beans.Form</managed-bean-class>
    <managed-bean-scope>session</managed-bean-scope>
    <managed-property>
      <property-name>application</property-name>
      <value>#{applicationBean}</value>
    </managed-property>
  </managed-bean>
</faces-config>

A migração está concluída. Podemos tentar executar o aplicativo web.

Deixamos que o leitor teste essa nova aplicação. Podemos aprimorá-la ligeiramente para lidar com o caso em que a inicialização do bean [Application] falhar. Sabemos que, nesse caso, os seguintes campos foram inicializados:


  // erros
  private List<Erreur> erreurs = new ArrayList<Erreur>();
private Boolean erreur = false;

Esse caso pode ser previsto no método init do bean [Form]:


@PostConstruct
  private void init() {

    // a inicialização ocorreu corretamente?
    if (application.getErreur()) {
      // recuperando a lista de erros
      erreurs = application.getErreurs();
      // a visualização dos erros é exibida
      setForms(false, false, true);
    }

    // armazenando médicos e clientes no cache
    ...
  }

linha 5: se o bean [Application] não foi inicializado corretamente,
linha 7: recuperamos a lista de erros,
linha 9: e exibimos a página de erro.

Assim, se pararmos o SGBD e o MySQL e reiniciarmos o aplicativo, receberemos agora a seguinte página:

10.2. Conclusion

A migração do aplicativo Primefaces Mobile / EJB / Glassfish para um ambiente Primefaces Mobile / Spring / Tomcat revelou-se simples. O problema de vazamento de memória relatado no estudo do aplicativo JSF / Spring / Tomcat (parágrafo 4.3.5) persiste. Ele será resolvido da mesma forma.

10.3. Testes com o Eclipse

Importamos os projetos Maven para o Eclipse [1]:

Executamos o projeto web [2].

Selecionamos o servidor Tomcat [3]. A página inicial do aplicativo é então exibida no navegador interno do Eclipse [4].

10.4. Testes em dispositivos móveis

Para testar o aplicativo em um celular, seguiremos as instruções do parágrafo 8.5.6. Aqui estão algumas fotos do aplicativo: