Skip to content

7. Applicazione esempio-04: rdvmedecins-pf-spring

7.1. Il porting

Ora trasferiamo 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 della versione 03 PF / 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 denominata [rdvmedecins-pf-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-pf]: il livello [web] della versione 03 Primefaces / 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>${project.groupId}</groupId>
      <artifactId>mv-rdvmedecins-spring-metier</artifactId>
      <version>${project.version}</version>
    </dependency>
    <dependency>
      <groupId>com.sun.faces</groupId>
      <artifactId>jsf-api</artifactId>
      <version>2.1.7</version>
    </dependency>
    <dependency>
      <groupId>com.sun.faces</groupId>
      <artifactId>jsf-impl</artifactId>
      <version>2.1.7</version>
    </dependency>
    <dependency>  
      <groupId>org.primefaces</groupId>  
      <artifactId>primefaces</artifactId>  
      <version>3.3</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 [IMetier] (questo è il suo nome nel livello Spring [métier]) l’interfaccia [IMetierLocal] 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 rileva 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 ne memorizziamo lo stack.

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

Eliminiamo tutte le righe errate (import e annotazioni) dovute a pacchetti mancanti. Questo è sufficiente per eliminare tutti gli errori relativi a [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>
  </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>

Normalmente, il porting è completato. Rimangono tuttavia alcuni dettagli da sistemare. 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 si è 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:

Image

7.2. Conclusion

Il porting dell’applicazione Primefaces / EJB / Glassfish verso un ambiente Primefaces / Spring / Tomcat si è rivelato semplice. Il problema della perdita di memoria segnalato nello studio dell’applicazione JSF / Spring / Tomcat (paragrafo 4.3.5) permane.

Lo risolveremo allo stesso modo.

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

https://stahe.github.io
Questo tutorial scritto da Serge Tahé è reso disponibile al pubblico secondo i termini della Creative Commons Attribuzione – Non commerciale – Condividi allo stesso modo 3.0 Unported.