7. Voorbeeldapplicatie-04: rdvmedecins-pf-spring

7.1. De porting

We porten nu de vorige applicatie naar een Spring/Tomcat-omgeving:

We gaan uitgaan van twee reeds geschreven applicaties. We gaan gebruikmaken van:

de lagen [DAO] en [JPA] van versie 02 JSF / Spring,
de laag [web] / Primefaces van versie 03 PF / EJB,
de Spring-configuratiebestanden van versie 02

We voeren hier een soortgelijk werk uit als dat wat eerder is gedaan om de applicatie JSF2 / EJB / Glassfish te porten naar een JSF2 / Spring Tomcat-omgeving. Daarom zullen we minder uitleg geven. De lezer kan, indien nodig, deze portatie raadplegen.

We plaatsen alle projecten die nodig zijn voor de porting in een nieuwe map [rdvmedecins-pf-spring] [1]:

[mv-rdvmedecins-spring-dao-jpa]: de lagen [DAO] en [JPA] van versie 02 JSF / Spring,
[mv-rdvmedecins-spring-metier]: de laag [métier] van versie 02 JSF / Spring,
[mv-rdvmedecins-pf]: de laag [web] van versie 03 Primefaces / EJB,
in [2], laden we ze in NetBeans,
in [3] kloppen de afhankelijkheden van het webproject niet meer:
- de afhankelijkheden van de lagen [DAO], [JPA] en [métier] moeten worden aangepast zodat ze nu verwijzen naar de Spring-projecten;
- de Glassfish-server leverde de bibliotheken van JSF. Dit is niet langer het geval met de Tomcat-server. Ze moeten dus aan de afhankelijkheden worden toegevoegd.

Het project [web] ontwikkelt zich als volgt:

Het bestand [pom.xml] van de laag [web] heeft nu de volgende afhankelijkheden:


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

Er treden fouten op. Deze worden veroorzaakt door de verwijzingen EJB vanuit de laag [web]. Laten we eerst de bean [Application] bekijken:

We verwijderen alle regels die fouten opleveren vanwege ontbrekende pakketten, hernoemen [IMetier] (dat is de naam in de Spring-laag [métier]) naar de interface [IMetierLocal] en gebruiken Spring om er een instantie van te maken:


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 {

  // bedrijfslaag
  private IMetier metier;
  // fouten
  private List<Erreur> erreurs = new ArrayList<Erreur>();
  private Boolean erreur = false;

  public Application() {
    try {
      // instantiëring van de laag [métier]
      ApplicationContext ctx = new ClassPathXmlApplicationContext("spring-config-metier-dao.xml");
      metier = (IMetier) ctx.getBean("metier");
    } catch (Throwable th) {
      // de fout wordt genoteerd
      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;
  }
}

regels 20-21: het aanmaken van een instantie van de laag [métier] op basis van het Spring-configuratiebestand. Dit is hetzelfde bestand dat wordt gebruikt door de lagen [métier] en [1]. We kopiëren het naar het webproject [2]:

regels 22-31: we vangen een eventuele uitzondering op en slaan de stack op.

Nu dit is gebeurd, bevat de bean [Application] geen fouten meer. Laten we nu eens kijken naar de beans [Form], [1] en [2]:

We verwijderen alle foutieve regels (import en annotaties) vanwege ontbrekende pakketten. Dit is voldoende om alle fouten in [3] te verhelpen.

Bovendien moeten in de code van de bean [Form] de getter en de setter van het veld


  // Application-bean
private Application application;

Sommige van de verwijderde annotaties in de beans [Application] en [Form] declareerden de klassen als beans met een bepaald bereik. Voortaan wordt deze configuratie uitgevoerd in het volgende bestand: [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>
    <!-- het berichtenbestand -->
    <resource-bundle>
      <base-name>
        messages
      </base-name>
      <var>msg</var>
    </resource-bundle>
    <message-bundle>messages</message-bundle>
  </application>
    <!-- de 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>
    <!-- de form-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>

Normaal gesproken is de porting nu voltooid. Er moeten echter nog enkele details worden afgehandeld. We kunnen proberen de webapplicatie uit te voeren.

We laten het aan de lezer over om deze nieuwe applicatie te testen. We kunnen deze enigszins verbeteren om het geval af te handelen waarin de initialisatie van de bean [Application] is mislukt. We weten dat in dat geval de volgende velden zijn geïnitialiseerd:


  // fouten
  private List<Erreur> erreurs = new ArrayList<Erreur>();
private Boolean erreur = false;

Dit geval kan worden voorzien in de methode init van de bean [Form]:


@PostConstruct
  private void init() {

    // is de initialisatie gelukt?
    if (application.getErreur()) {
      // de lijst met fouten wordt opgehaald
      erreurs = application.getErreurs();
      // het overzicht van de fouten wordt weergegeven
      setForms(false, false, true);
    }

    // artsen en klanten worden in de cache opgeslagen
    ...
  }

regel 5: als de bean [Application] niet correct is geïnitialiseerd,
regel 7: wordt de lijst met fouten opgehaald,
regel 9: en wordt de foutpagina weergegeven.

Als we dus de SGBD en MySQL stoppen en de applicatie opnieuw starten, krijgen we nu de volgende pagina te zien:

7.2. Conclusion

De migratie van de Primefaces / EJB / Glassfish-toepassing naar een Primefaces / Spring / Tomcat-omgeving bleek eenvoudig te zijn. Het in de analyse van de JSF / Spring / Tomcat-toepassing (paragraaf 4.3.5) gemelde geheugenlek blijft bestaan.

Dit zal op dezelfde manier worden opgelost.

7.3. Tests met Eclipse

We importeren de Maven-projecten in Eclipse [1]:

We voeren het webproject [2] uit.

We kiezen de Tomcat-server [3]. De startpagina van de applicatie wordt vervolgens weergegeven in de interne browser van Eclipse [4].