Nous portons maintenant l'application précédente dans un environnement Spring / Tomcat :

Nous allons nous appuyer sur deux applications déjà écrites. Nous allons utiliser :

• les couches [DAO] et [JPA] de la version 02 JSF / Spring,
• la couche [web] / Primefaces de la version 03 PF / EJB,
• les fichiers de configuration de Spring de la version 02

Nous refaisons là un travail analogue à celui qui avait été fait pour porter l'application JSF2 / EJB / Glassfish dans un environnement JSF2 / Spring Tomcat. Aussi donnerons-nous moins d'explications. Le lecteur peut, s'il en est besoin, se reporter à ce portage.

Nous mettons tous les projets nécessaires au portage dans un nouveau dossier [rdvmedecins-pf-spring] [1] :

• [mv-rdvmedecins-spring-dao-jpa] : les couches [DAO] et [JPA] de la version 02 JSF / Spring,
• [mv-rdvmedecins-spring-metier] : la couche [métier] de la version 02 JSF / Spring,
• [mv-rdvmedecins-pf] : la couche [web] de la version 03 Primefaces / EJB,
• en [2], nous les chargeons dans Netbeans,
• en [3], les dépendances du projet web ne sont plus correctes :
• les dépendances sur les couches [DAO], [JPA], [métier] doivent être changées pour cibler désormais les projets Spring ;
• le serveur Glassfish fournissait les bibliothèques de JSF. Ce n'est plus le cas avec le serveur Tomcat. Il faut donc les ajouter aux dépendances.

Le projet [web] évolue comme suit :

Le fichier [pom.xml] de la couche [web] a désormais les dépendances suivantes :

[pom.xml]

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.

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

Des erreurs apparaissent. Elles sont dues aux références EJB de la couche [web]. Etudions d'abord le bean [Application] :

Nous enlevons toutes les lignes erronées à cause de paquetages manquants, nous renommons [IMetier] (c'est son nom dans la couche [métier] Spring) l'interface [IMetierLocal] et nous utilisons Spring pour l'instancier :

Application

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.

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 {

  // couche métier
  private IMetier metier;
  // erreurs
  private List<Erreur> erreurs = new ArrayList<Erreur>();
  private Boolean erreur = false;

  public Application() {
    try {
      // instanciation couche [métier]
      ApplicationContext ctx = new ClassPathXmlApplicationContext("spring-config-metier-dao.xml");
      metier = (IMetier) ctx.getBean("metier");
    } catch (Throwable th) {
      // on note l'erreur
      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;
  }
}

• lignes 20-21 : instanciation de la couche [métier] à partir du fichier de configuration de Spring. Ce fichier est celui utilisé par la couche [métier] [1]. Nous le copions dans le projet web [2] :

  

• lignes 22-31 : nous gérons une éventuelle exception et mémorisons sa pile.

Ceci fait, le bean [Application] n'a plus d'erreurs. Regardons maintenant le bean [Form] [1], [2] :

Nous supprimons toutes les lignes erronées (import et annotations) à cause de paquetages manquants. Cela suffit pour éliminer toutes les erreurs [3].

Par ailleurs, il faut ajouter dans le code du bean [Form], le getter et le setter du champ

  // bean Application
private Application application;

Certaines des annotations supprimées dans les beans [Application] et [Form] déclaraient les classes comme étant des beans avec une certaine portée. Désormais, cette configuration est faite dans le fichier [faces-config.xml] [4] suivant :

[faces-config.xml]

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.

<?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>
    <!-- le fichier des messages -->
    <resource-bundle>
      <base-name>
        messages
      </base-name>
      <var>msg</var>
    </resource-bundle>
    <message-bundle>messages</message-bundle>
  </application>
    <!-- le 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>
    <!-- le 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>

Normalement, le portage est terminé. Il nous restera cependant quelques détails à régler. Nous pouvons tenter d'exécuter l'application web.

Nous laissons le lecteur tester cette nouvelle application. Nous pouvons l'améliorer légèrement pour gérer le cas où l'initialisation du bean [Application] a échoué. On sait que dans ce cas, les champs suivants ont été initialisés :

 

Sélectionnez

1.
2.
3.

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

Ce cas peut être prévu dans la méthode init du bean [Form] :

 

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

@PostConstruct
  private void init() {

    // l'initialisation s'est-elle bien passée ?
    if (application.getErreur()) {
      // on récupère la liste des erreurs
      erreurs = application.getErreurs();
      // la vue des erreurs est affichée
      setForms(false, false, true);
    }

    // on met les médecins et les clients en cache
    ...
  }

• ligne 5 : si le bean [Application] s'est mal initialisé,
• ligne 7 : on récupère la liste des erreurs,
• ligne 9 : et on affiche la page d'erreur.

Ainsi, si on arrête le SGBD MySQL et qu'on relance l'application, on reçoit maintenant la page suivante :

Le portage de l'application Primefaces / EJB / Glassfish vers un environnement Primefaces / Spring / Tomcat s'est révélé simple. Le problème de la fuite mémoire signalée dans l'étude de l'application JSF / Spring / Tomcat (paragraphe , page ) demeure.

On le résoudra de la même façon.

Nous importons les projets Maven dans Eclipse [1] :

Nous exécutons le projet web [2].

Nous choisissons le serveur Tomcat [3]. La page d'accueil de l'application est alors affichée dans le navigateur interne d'Eclipse [4].