10. Applicazione di esempio-06: rdvmedecins-pfm-spring

10.1. Il porting

Ora portiamo l’applicazione precedente in un ambiente Spring / Tomcat:

Ci baseremo su due applicazioni già scritte. Utilizzeremo:

i livelli [DAO] e [JPA] della versione 02 JSF / Spring,
il livello [web] / Primefaces mobile della versione 05 PFM / EJB,
i file di configurazione di Spring della versione 02

Stiamo ripetendo un lavoro analogo a quello svolto in precedenza per il porting dell’applicazione JSF2 / EJB / Glassfish in un ambiente JSF2 / Spring Tomcat. Pertanto forniremo meno spiegazioni. Il lettore può, se necessario, fare riferimento a tale porting.

Abbiamo inserito tutti i progetti necessari al porting in una nuova cartella [rdvmedecins-pfm-spring] [1]:

[mv-rdvmedecins-spring-dao-jpa]: i livelli [DAO] e [JPA] della versione 02 JSF / Spring,
[mv-rdvmedecins-spring-metier]: il livello [métier] della versione 02 JSF / Spring,
[mv-rdvmedecins-pfmobile]: il livello [web] della versione 05 Primefaces mobile / EJB,
in [2], li carichiamo in NetBeans,
in [3], le dipendenze del progetto web non sono più corrette:
- le dipendenze relative ai livelli [DAO], [JPA], [métier] devono essere modificate per puntare ora ai progetti Spring;
- il server Glassfish forniva le librerie di JSF. Con il server Tomcat non è più così. È quindi necessario aggiungerle alle dipendenze.

Il progetto [web] si evolve come segue:

Il file [pom.xml] del livello [web] presenta ora le seguenti dipendenze:


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

Si verificano degli errori. Sono dovuti ai riferimenti EJB del livello [web]. Esaminiamo innanzitutto il bean [Application]:

Rimuoviamo tutte le righe errate a causa dei pacchetti mancanti, rinominiamo l’interfaccia [IMetierLocal] come [IMetier] (questo è il suo nome nel livello Spring [métier]) e utilizziamo Spring per istanziarla:


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 {

  // livello business
  private IMetier metier;
  // errori
  private List<Erreur> erreurs = new ArrayList<Erreur>();
  private Boolean erreur = false;

  public Application() {
    try {
      // istanziazione del livello [métier]
      ApplicationContext ctx = new ClassPathXmlApplicationContext("spring-config-metier-dao.xml");
      metier = (IMetier) ctx.getBean("metier");
    } catch (Throwable th) {
      // si registra l'errore
      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;
    }
  }

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

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

  public IMetier getMetier() {
    return metier;
  }
}

righe 20-21: istanziamento del livello [métier] a partire dal file di configurazione di Spring. Questo file è quello utilizzato dai livelli [métier] e [1]. Lo copiamo nel progetto web [2]:

righe 22-31: gestiamo un'eventuale eccezione e memorizziamo il suo stack nel campo della riga 14.

A questo punto, il bean [Application] non presenta più errori. Esaminiamo ora i bean [Form], [1] e [2]:

3

4

Eliminiamo tutte le righe errate (import e annotazioni) dovute a pacchetti mancanti e rinominiamo l'interfaccia [IMetier] in [ImetierLocal]. Questo è sufficiente per eliminare tutti gli errori [3].

Inoltre, è necessario aggiungere nel codice del bean [Form] il getter e il setter del campo


  // bean Application
private Application application;

Alcune delle annotazioni rimosse nei bean [Application] e [Form] dichiaravano le classi come bean con un determinato ambito. Ora questa configurazione viene effettuata nel seguente file [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>
    <!-- il file dei messaggi -->
    <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>
    <!-- il 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>
    <!-- il bean del modulo -->
  <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>

Il porting è terminato. Possiamo provare a eseguire l’applicazione web.

Lasciamo che sia il lettore a testare questa nuova applicazione. Possiamo migliorarla leggermente per gestire il caso in cui l’inizializzazione del bean [Application] non sia andata a buon fine. Sappiamo che in questo caso sono stati inizializzati i seguenti campi:


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

Questo caso può essere previsto nel metodo init del bean [Form]:


@PostConstruct
  private void init() {

    // L'inizializzazione è andata a buon fine?
    if (application.getErreur()) {
      // si recupera l'elenco degli errori
      erreurs = application.getErreurs();
      // viene visualizzata la schermata degli errori
      setForms(false, false, true);
    }

    // si memorizzano nella cache medici e clienti
    ...
  }

riga 5: se il bean [Application] non è stato inizializzato correttamente,
riga 7: si recupera l'elenco degli errori,
riga 9: e si visualizza la pagina di errore.

Pertanto, se si arrestano i bean SGBD e MySQL e si riavvia l’applicazione, ora viene visualizzata la seguente pagina:

10.2. Conclusion

Il porting dell’applicazione Primefaces mobile / EJB / Glassfish verso un ambiente Primefaces mobile / Spring / Tomcat si è rivelato semplice. Il problema della perdita di memoria segnalato nell’analisi dell’applicazione JSF / Spring / Tomcat (paragrafo 4.3.5) persiste. Lo risolveremo allo stesso modo.

10.3. Test con Eclipse

Importiamo i progetti Maven in Eclipse [1]:

Eseguiamo il progetto web [2].

Scegliamo il server Tomcat [3]. La pagina iniziale dell'applicazione viene quindi visualizzata nel browser interno di Eclipse [4].

10.4. Test su dispositivo mobile

Per testare l’applicazione su un dispositivo mobile, si procederà come indicato nel paragrafo 8.5.6. Ecco alcune immagini dell’applicazione: