7. Esempio di applicazione-04: rdvmedecins-pf-spring
7.1. Porting
Ora porteremo l'applicazione precedente su un ambiente Spring/Tomcat:
 |
Ci baseremo su due applicazioni esistenti. Utilizzeremo:
- i livelli [DAO] e [JPA] della versione 02 di JSF / Spring,
- il livello [web] / Primefaces della versione 03 di PF / 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-pf-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 JSF / Spring,
- [mv-rdvmedecins-pf]: il livello [web] della versione 03 di Primefaces / 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>${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>
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 [IMetier] (il suo nome nel livello [business] di Spring) nell'interfaccia [IMetierLocal] e utilizziamo Spring per istanziarlo:
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 salviamo la loro traccia dello stack.
Fatto ciò, il bean [Application] non presenta più alcun errore. Ora esaminiamo il bean [Form] [1], [2]:
 |
Rimuoviamo tutte le righe errate (importazioni e annotazioni) dovute alla mancanza di pacchetti. 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 è impostata 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>
</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>
Normalmente, il porting è completato. Tuttavia, ci sono ancora alcuni dettagli da sistemare. 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 scenario 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:
7.2. Conclusione
Il porting dell'applicazione PrimeFaces/EJB/GlassFish in un ambiente PrimeFaces/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.
7.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].