10. Voorbeeldapplicatie-06: rdvmedecins-pfm-spring
10.1. De porting
We porten nu de vorige applicatie naar een Spring/Tomcat-omgeving:
 |
We zullen gebruikmaken van twee reeds geschreven applicaties. We zullen de volgende lagen gebruiken:
- de lagen [DAO] en [JPA] van versie 02 JSF / Spring,
- de laag [web] / Primefaces mobile uit versie 05 PFM / 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-pfm-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-pfmobile]: de laag [web] van versie 05 Primefaces mobile / EJB,
- in [2], we laden 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>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>
Er treden fouten op. Deze worden veroorzaakt door de verwijzingen naar EJB vanuit de laag [web]. Laten we eerst de bean [Application] bekijken:
 |
We verwijderen alle regels die fouten geven vanwege ontbrekende pakketten, hernoemen de interface [IMetierLocal] naar [IMetier] (dat is de naam ervan in de Spring-laag [métier]) 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 geregistreerd
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 ervan op in het veld op regel 14.
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 en hernoemen [IMetier] naar de interface [ImetierLocal]. 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>
<default-render-kit-id>PRIMEFACES_MOBILE</default-render-kit-id>
</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>
De porting is voltooid. We kunnen nu 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 het initialiseren 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:
10.2. Conclusion
De migratie van de PrimeFaces Mobile-applicatie / EJB / GlassFish naar een PrimeFaces Mobile / Spring / Tomcat-omgeving bleek eenvoudig te zijn. Het probleem van het geheugenlek dat in de analyse van de applicatie JSF / Spring / Tomcat (paragraaf 4.3.5) werd gesignaleerd, blijft bestaan. Dit zal op dezelfde manier worden opgelost.
10.3. Testen 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].
10.4. Testen op een mobiel apparaat
Om de applicatie op een mobiel apparaat te testen, gaan we te werk zoals beschreven in paragraaf 8.5.6. Hieronder staan enkele foto’s van de applicatie:
 |  |
 |  |