10. Esempio di applicazione-06: rdvmedecins-pfm-spring

10.1. Porting

Ora porteremo l'applicazione precedente su un ambiente Spring/Tomcat:

Ci baseremo su due applicazioni già scritte. Useremo:

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

Qui stiamo eseguendo un'operazione simile a quella effettuata per il porting dell'applicazione JSF2 / EJB / Glassfish in un ambiente JSF2 / Spring Tomcat. Pertanto, forniremo meno spiegazioni. Se necessario, il lettore può fare riferimento a quel porting.

Stiamo inserendo tutti i progetti necessari per il porting in una nuova cartella [rdvmedecins-pfm-spring] [1]:

[mv-rdvmedecins-spring-dao-jpa]: i livelli [DAO] e [JPA] della versione 02 di JSF/Spring,
[mv-rdvmedecins-spring-metier]: il livello [business] della versione 02 di JSF / Spring,
[mv-rdvmedecins-pfmobile]: il livello [web] della versione 05 di PrimeFaces Mobile / EJB,
in [2], li carichiamo in NetBeans,
in [3], le dipendenze del progetto web non sono più corrette:
- le dipendenze dei livelli [DAO], [JPA] e [business] devono essere modificate per puntare ora ai progetti Spring;
- Il server GlassFish forniva le librerie JSF. Questo non è più il caso con il server Tomcat. Devono quindi essere aggiunte alle dipendenze.

Il progetto [web] si evolve come segue:

Il file [pom.xml] per il 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>

Vengono visualizzati degli errori. Sono causati dai riferimenti EJB nel livello [web]. Esaminiamo innanzitutto il bean [Application]:

Rimuoviamo tutte le righe che causano errori dovuti a pacchetti mancanti, rinominiamo l'interfaccia [IMetierLocal] in [IMetier] (questo è il suo nome nel livello [business] di Spring) 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 {
 
  // business layer
  private IMetier metier;
  // errors
  private List<Erreur> erreurs = new ArrayList<Erreur>();
  private Boolean erreur = false;
 
  public Application() {
    try {
      // instantiation layer [business]
      ApplicationContext ctx = new ClassPathXmlApplicationContext("spring-config-metier-dao.xml");
      metier = (IMetier) ctx.getBean("metier");
    } catch (Throwable th) {
      // we note the error
      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;
  }
}

righe 20-21: istanziazione del livello [business] dal file di configurazione Spring. Questo è il file utilizzato dal livello [business] [1]. Lo copiamo nel progetto web [2]:

righe 22-31: gestiamo eventuali eccezioni e memorizziamo la loro traccia dello stack nel campo alla riga 14.

Fatto ciò, il bean [Application] non presenta più alcun errore. Esaminiamo ora il bean [Form] [1], [2]:

3

4

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

Inoltre, dobbiamo aggiungere il getter e il setter per il campo


  // bean Application
private Application application;

Alcune delle annotazioni rimosse dai bean [Application] e [Form] dichiaravano le classi come bean con un ambito specifico. 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>
    <!-- message file -->
    <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>
    <!-- the applicationBean bean -->
  <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>
    <!-- the bean form -->
  <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>

La configurazione è completa. Possiamo provare a eseguire l'applicazione web.

Lasciamo al lettore il compito di testare questa nuova applicazione. Possiamo migliorarla leggermente per gestire il caso in cui l'inizializzazione del bean [Application] abbia dato esito negativo. Sappiamo che in questo caso sono stati inizializzati i seguenti campi:


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

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


@PostConstruct
  private void init() {
 
    // was the initialization successful?
    if (application.getErreur()) {
      // retrieve the list of errors
      erreurs = application.getErreurs();
      // the error view is displayed
      setForms(false, false, true);
    }
 
    // caching doctors and customers
    ...
  }

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

Pertanto, se arrestiamo il DBMS MySQL e riavviamo l'applicazione, ora vediamo la seguente pagina:

10.2. Conclusione

Il porting dell'applicazione PrimeFaces Mobile/EJB/GlassFish in un ambiente PrimeFaces Mobile/Spring/Tomcat si è rivelato semplice. Il problema di perdita di memoria segnalato nello studio dell'applicazione JSF/Spring/Tomcat (Sezione 4.3.5) permane. Verrà risolto allo stesso modo.

10.3. Test con Eclipse

Importiamo i progetti Maven in Eclipse [1]:

Eseguiamo il progetto web [2].

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

10.4. Test su un dispositivo mobile

Per testare l'applicazione su un dispositivo mobile, seguire i passaggi descritti nella sezione 8.5.6. Ecco alcuni screenshot dell'applicazione: