10. Beispielanwendung-06: rdvmedecins-pfm-spring
10.1. Portierung
Wir werden nun die vorherige Anwendung in eine Spring/Tomcat-Umgebung portieren:
 |
Wir werden auf zwei bereits vorhandene Anwendungen zurückgreifen. Wir verwenden:
- die [DAO]- und [JPA]-Schichten aus Version 02 JSF / Spring,
- die [Web]-/PrimeFaces-Mobile-Schicht aus Version 05 PFM/EJB,
- die Spring-Konfigurationsdateien aus Version 02
Hier führen wir eine Aufgabe durch, die der Portierung der JSF2 / EJB / Glassfish-Anwendung auf eine JSF2 / Spring Tomcat-Umgebung ähnelt. Daher werden wir weniger Erläuterungen geben. Bei Bedarf kann der Leser auf diese Portierung zurückgreifen.
Wir legen alle für die Portierung erforderlichen Projekte in einem neuen Ordner [rdvmedecins-pfm-spring] [1] ab:
 |
- [mv-rdvmedecins-spring-dao-jpa]: die [DAO]- und [JPA]-Schichten der JSF/Spring-Version 02,
- [mv-rdvmedecins-spring-metier]: die [Business]-Schicht der Version 02 von JSF/Spring,
- [mv-rdvmedecins-pfmobile]: die [Web]-Schicht der PrimeFaces Mobile/EJB-Version 05,
- in [2] laden wir sie in NetBeans,
- in [3] sind die Abhängigkeiten des Webprojekts nicht mehr korrekt:
- die Abhängigkeiten der [DAO]-, [JPA]- und [Business]-Schichten müssen geändert werden, damit sie nun auf die Spring-Projekte verweisen;
- Der GlassFish-Server stellte die JSF-Bibliotheken bereit. Dies ist beim Tomcat-Server nicht mehr der Fall. Sie müssen daher zu den Abhängigkeiten hinzugefügt werden.
Das [Web]-Projekt entwickelt sich wie folgt:
 |
Die [pom.xml]-Datei für die [Web]-Schicht enthält nun die folgenden Abhängigkeiten:
<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>
Es treten Fehler auf. Diese werden durch die EJB-Referenzen in der [web]-Schicht verursacht. Sehen wir uns zunächst die [Application]-Bean an:
 |
Wir entfernen alle Zeilen, die aufgrund fehlender Pakete Fehler verursachen, benennen die Schnittstelle [IMetierLocal] in [IMetier] um (so lautet ihr Name in der Spring-[Business]-Schicht) und instanziieren sie mit Spring:
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;
}
}
- Zeilen 20–21: Instanziierung der [business]-Schicht aus der Spring-Konfigurationsdatei. Dies ist die Datei, die von der [business]-Schicht verwendet wird [1]. Wir kopieren sie in das Webprojekt [2]:
 |
- Zeilen 22–31: Wir behandeln alle Ausnahmen und speichern deren Stacktrace im Feld in Zeile 14.
Damit weist die [Application]-Bean keine Fehler mehr auf. Sehen wir uns nun die [Form]-Bean an [1], [2]:
 |
|
Wir entfernen alle fehlerhaften Zeilen (Importe und Annotationen), die auf fehlende Pakete zurückzuführen sind, und benennen die Schnittstelle [ImetierLocal] in [IMetier] um. Dies reicht aus, um alle Fehler zu beheben [3].
Zusätzlich müssen wir den Getter und den Setter für das Feld hinzufügen
// bean Application
private Application application;
Einige der Annotationen, die aus den [Application]- und [Form]-Beans entfernt wurden, deklarierten die Klassen als Beans mit einem bestimmten Gültigkeitsbereich. Diese Konfiguration erfolgt nun in der folgenden [faces-config.xml]-Datei [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>
Die Portierung ist abgeschlossen. Wir können nun versuchen, die Webanwendung auszuführen.
 |
Wir überlassen es dem Leser, diese neue Anwendung zu testen. Wir können sie leicht verbessern, um den Fall zu behandeln, in dem die Initialisierung der [Application]-Bean fehlgeschlagen ist. Wir wissen, dass in diesem Fall die folgenden Felder initialisiert wurden:
// erreurs
private List<Erreur> erreurs = new ArrayList<Erreur>();
private Boolean erreur = false;
Dieser Fall kann in der init-Methode des [Form]-Beans behandelt werden:
@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
...
}
- Zeile 5: Wenn die Initialisierung der [Application]-Bean fehlgeschlagen ist,
- Zeile 7: die Fehlerliste abrufen,
- Zeile 9: und die Fehlerseite anzeigen.
Wenn wir also das MySQL-DBMS anhalten und die Anwendung neu starten, sehen wir nun die folgende Seite:
10.2. Fazit
Die Portierung der PrimeFaces Mobile/EJB/GlassFish-Anwendung auf eine PrimeFaces Mobile/Spring/Tomcat-Umgebung erwies sich als unkompliziert. Das in der Untersuchung der JSF/Spring/Tomcat-Anwendung (Abschnitt 4.3.5) gemeldete Problem mit dem Speicherleck besteht weiterhin. Es wird auf die gleiche Weise behoben werden.
10.3. Tests mit Eclipse
Wir importieren die Maven-Projekte in Eclipse [1]:
 |
Wir führen das Webprojekt aus [2].
 |
Wir wählen den Tomcat-Server aus [3]. Die Startseite der Anwendung wird daraufhin im internen Browser von Eclipse angezeigt [4].
10.4. Testen auf einem mobilen Gerät
Um die Anwendung auf einem mobilen Gerät zu testen, befolgen Sie die in Abschnitt 8.5.6 beschriebenen Schritte. Hier sind einige Screenshots der Anwendung:
 |  |
 |  |