10. Beispiel-App 06: rdvmedecins-pfm-spring

10.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 Mobile aus der Version 05 PFM / 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-pfm-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-pfmobile]: die Ebene [web] der Version 05 PrimeFaces Mobile / 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>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 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 protokolliert
      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 ihren Stack im Feld in Zeile 14.

Damit weist die Bean [Application] keine Fehler mehr auf. Sehen wir uns nun die Beans [Form], [1] und [2] an:

3

4

Wir entfernen alle fehlerhaften Zeilen (Import und Annotationen) aufgrund fehlender Pakete und benennen die Schnittstelle [ImetierLocal] in [IMetier] um. 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>
    <default-render-kit-id>PRIMEFACES_MOBILE</default-render-kit-id>
  </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>

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 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:

10.2. Fazit

Die Portierung der Anwendung Primefaces Mobile / EJB / Glassfish in eine Primefaces Mobile / 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 lässt sich auf die gleiche Weise beheben.

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

10.4. Tests mit dem Smartphone

Um die Anwendung auf einem Mobilgerät zu testen, gehen wir wie in Abschnitt 8.5.6 beschrieben vor. Hier sind einige Screenshots der Anwendung: