7. Beispiel-Anwendung 04: rdvmedecins-pf-spring
7.1. Die Portierung
Wir portieren nun die vorherige Anwendung in eine Spring-/Tomcat-Umgebung:
 |
Wir stützen uns dabei auf zwei bereits geschriebene Anwendungen. Wir verwenden:
- die Schichten [DAO] und [JPA] aus der Version 02 JSF / Spring,
- die Schicht [web] / PrimeFaces aus der Version 03 PF / EJB,
- die Spring-Konfigurationsdateien der Version 02
Wir führen hier eine ähnliche Arbeit durch wie bei der Portierung der Anwendung JSF2 / EJB / Glassfish in eine JSF2 / Spring-Tomcat-Umgebung. Daher werden wir weniger Erläuterungen geben. Der Leser kann bei Bedarf auf diese Portierung zurückgreifen.
Wir legen alle für die Portierung erforderlichen Projekte in einem neuen Ordner „[rdvmedecins-pf-spring] [1]“ ab:
 |
- [mv-rdvmedecins-spring-dao-jpa]: die Schichten [DAO] und [JPA] der Version 02 JSF / Spring,
- [mv-rdvmedecins-spring-metier]: die Schicht [métier] der Version 02 JSF / Spring,
- [mv-rdvmedecins-pf]: die Ebene [web] der Version 03 Primefaces / EJB,
- in [2], laden wir sie in NetBeans,
- in [3] sind die Abhängigkeiten des Webprojekts nicht mehr korrekt:
- Die Abhängigkeiten zu den Schichten [DAO], [JPA] und [métier] müssen geändert werden, damit sie nun auf die Spring-Projekte verweisen;
- Der Glassfish-Server stellte die Bibliotheken von JSF bereit. Beim Tomcat-Server ist dies nicht mehr der Fall. Sie müssen daher zu den Abhängigkeiten hinzugefügt werden.
Das Projekt [web] entwickelt sich wie folgt:
 |
Die Datei [pom.xml] der Schicht [web] weist nun folgende Abhängigkeiten auf:
<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>
Es treten Fehler auf. Diese sind auf die Verweise EJB der Ebene [web] zurückzuführen. Betrachten wir zunächst die Bean [Application]:
 |
Wir entfernen alle fehlerhaften Zeilen, die auf fehlende Pakete zurückzuführen sind, benennen die Schnittstelle [IMetierLocal] in [IMetier] um (so lautet ihr Name in der Spring-Schicht [métier]) 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 {
// Geschäftslogikschicht
private IMetier metier;
// Fehler
private List<Erreur> erreurs = new ArrayList<Erreur>();
private Boolean erreur = false;
public Application() {
try {
// Instanziierung der Schicht [métier]
ApplicationContext ctx = new ClassPathXmlApplicationContext("spring-config-metier-dao.xml");
metier = (IMetier) ctx.getBean("metier");
} catch (Throwable th) {
// Der Fehler wird vermerkt
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;
}
}
- Zeilen 20–21: Instanziierung der Schicht [métier] anhand der Spring-Konfigurationsdatei. Diese Datei wird von den Schichten [métier] und [1] verwendet. Wir kopieren sie in das Webprojekt [2]:
 |
- Zeilen 22–31: Wir behandeln eine mögliche Ausnahme und speichern deren Stack.
Damit weist die Bean [Application] keine Fehler mehr auf. Sehen wir uns nun die Beans [Form], [1] und [2] an:
 |
Wir entfernen alle fehlerhaften Zeilen (Import und Annotationen) aufgrund fehlender Pakete. Das reicht aus, um alle Fehler in [3] zu beseitigen.
 |
Außerdem müssen im Code des Beans [Form] der Getter und der Setter für das Feld
// Anwendungs-Bean
private Application application;
Einige der in den Beans [Application] und [Form] entfernten Annotationen deklarierten die Klassen als Beans mit einem bestimmten Gültigkeitsbereich. Diese Konfiguration erfolgt nun in der folgenden Datei: [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>
<!-- die Meldungsdatei -->
<resource-bundle>
<base-name>
messages
</base-name>
<var>msg</var>
</resource-bundle>
<message-bundle>messages</message-bundle>
</application>
<!-- das 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>
<!-- das Formular-Bean -->
<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>
Normalerweise ist die Portierung damit abgeschlossen. Es sind jedoch noch einige Details zu klären. Wir können 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 Bean [Application] fehlgeschlagen ist. Wir wissen, dass in diesem Fall die folgenden Felder initialisiert wurden:
// Fehler
private List<Erreur> erreurs = new ArrayList<Erreur>();
private Boolean erreur = false;
Dieser Fall kann in der Methode init der Bean [Form] berücksichtigt werden:
@PostConstruct
private void init() {
// Ist die Initialisierung erfolgreich verlaufen?
if (application.getErreur()) {
// Die Fehlerliste wird abgerufen
erreurs = application.getErreurs();
// Die Fehleransicht wird angezeigt
setForms(false, false, true);
}
// Ärzte und Kunden werden zwischengespeichert
...
}
- Zeile 5: Wenn die Bean [Application] nicht korrekt initialisiert wurde,
- Zeile 7: wird die Fehlerliste abgerufen,
- Zeile 9: und die Fehlerseite wird angezeigt.
Wenn man also die Beans SGBD und MySQL beendet und die Anwendung neu startet, erhält man nun die folgende Seite:
7.2. Fazit
Die Portierung der PrimeFaces-Anwendung / EJB / GlassFish in eine PrimeFaces-/Spring-/Tomcat-Umgebung erwies sich als einfach. Das in der Untersuchung der Anwendung JSF / Spring / Tomcat (Abschnitt 4.3.5) gemeldete Problem des Speicherlecks besteht weiterhin.
Es wird auf die gleiche Weise behoben.
7.3. Tests mit Eclipse
 |
Wir importieren die Maven-Projekte in Eclipse [1]:
Wir führen das Webprojekt [2] aus.
 |
Wir wählen den Tomcat-Server [3] aus. Die Startseite der Anwendung wird daraufhin im internen Browser von Eclipse ([4]) angezeigt.