10. Aplikacja przykładowa-06: rdvmedecins-pfm-spring

10.1. Portowanie

Teraz przenosimy poprzednią aplikację do środowiska Spring / Tomcat:

Będziemy opierać się na dwóch już napisanych aplikacjach. Wykorzystamy:

warstwy [DAO] i [JPA] z wersji 02 JSF / Spring,
warstwę [web] / Primefaces mobile z wersji 05 PFM / EJB,
pliki konfiguracyjne Springa z wersji 02

Wykonujemy tutaj pracę podobną do tej, którą przeprowadzono w celu przeniesienia aplikacji JSF2 / EJB / Glassfish do środowiska JSF2 / Spring Tomcat. Dlatego też nie będziemy się zbytnio rozpisywać. W razie potrzeby czytelnik może zapoznać się z tym przeniesieniem.

Wszystkie projekty niezbędne do przeniesienia umieszczamy w nowym folderze [rdvmedecins-pfm-spring] [1]:

[mv-rdvmedecins-spring-dao-jpa]: warstwy [DAO] i [JPA] z wersji 02 JSF / Spring,
[mv-rdvmedecins-spring-metier]: warstwa [métier] z wersji 02 JSF / Spring,
[mv-rdvmedecins-pfmobile]: warstwa [web] z wersji 05 Primefaces mobile / EJB,
w [2], ładujemy je do NetBeans,
w [3] zależności projektu internetowego nie są już poprawne:
- zależności dotyczące warstw [DAO], [JPA], [métier] należy zmienić tak, aby odnosiły się teraz do projektów Spring;
- serwer Glassfish dostarczał biblioteki z projektu JSF. W przypadku serwera Tomcat tak już nie jest. Należy zatem dodać je do zależności.

Projekt [web] zmienia się w następujący sposób:

Plik [pom.xml] z warstwy [web] ma teraz następujące zależności:


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

Pojawiają się błędy. Wynikają one z odwołań do pliku EJB w warstwie [web]. Przyjrzyjmy się najpierw beanowi [Application]:

Usuwamy wszystkie wiersze zawierające błędy spowodowane brakującymi pakietami, zmieniamy nazwę interfejsu [IMetierLocal] na [IMetier] (tak nazywa się on w warstwie Spring [métier]) i używamy Springa do utworzenia jego instancji:


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 {

  // warstwa biznesowa
  private IMetier metier;
  // błędy
  private List<Erreur> erreurs = new ArrayList<Erreur>();
  private Boolean erreur = false;

  public Application() {
    try {
      // instancjonowanie warstwy [métier]
      ApplicationContext ctx = new ClassPathXmlApplicationContext("spring-config-metier-dao.xml");
      metier = (IMetier) ctx.getBean("metier");
    } catch (Throwable th) {
      // odnotowuje się błąd
      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;
    }
  }

  // metody pobierające
  public Boolean getErreur() {
    return erreur;
  }

  public List<Erreur> getErreurs() {
    return erreurs;
  }

  public IMetier getMetier() {
    return metier;
  }
}

wiersze 20–21: instancjonowanie warstwy [métier] na podstawie pliku konfiguracyjnego Springa. Jest to ten sam plik, z którego korzystają warstwy [métier] i [1]. Kopiujemy go do projektu internetowego [2]:

wiersze 22–31: obsługujemy ewentualny wyjątek i zapisujemy jego stos w polu z wiersza 14.

Po wykonaniu tej czynności bean [Application] nie zawiera już żadnych błędów. Przyjrzyjmy się teraz beanom [Form], [1] oraz [2]:

3

4

Usuwamy wszystkie błędne wiersze (importy i adnotacje) spowodowane brakującymi pakietami i zmieniamy nazwę interfejsu [IMetier] na [ImetierLocal]. To wystarczy, aby wyeliminować wszystkie błędy [3].

Ponadto należy dodać w kodzie bean’a [Form] metody getter i setter dla pola


  // bean aplikacji
private Application application;

Niektóre z usuniętych adnotacji w beanach [Application] i [Form] deklarowały klasy jako beany o określonym zakresie. Obecnie konfiguracja ta jest dokonywana w następującym pliku: [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>
    <!-- plik komunikatów -->
    <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>
    <!-- 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>
    <!-- bean formularza -->
  <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>

Portowanie zostało zakończone. Możemy spróbować uruchomić aplikację internetową.

Pozostawiamy czytelnikowi przetestowanie tej nowej aplikacji. Możemy ją nieco ulepszyć, aby obsłużyć sytuację, w której inicjalizacja komponentu [Application] zakończyła się niepowodzeniem. Wiemy, że w takim przypadku zainicjowano następujące pola:


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

Sytuację tę można przewidzieć w metodzie init fasoli [Form]:


@PostConstruct
  private void init() {

    // czy inicjalizacja przebiegła pomyślnie?
    if (application.getErreur()) {
      // pobieramy listę błędów
      erreurs = application.getErreurs();
      // wyświetlany jest widok błędów
      setForms(false, false, true);
    }

    // lekarze i klienci są zapisywani w pamięci podręcznej
    ...
  }

wiersz 5: jeśli inicjalizacja komponentu [Application] przebiegła nieprawidłowo,
wiersz 7: pobieramy listę błędów,
wiersz 9: i wyświetla się strona błędu.

W ten sposób, jeśli zatrzymamy SGBD i MySQL, a następnie ponownie uruchomimy aplikację, otrzymamy teraz następującą stronę:

10.2. Conclusion

Przeniesienie aplikacji Primefaces mobile / EJB / Glassfish do środowiska Primefaces mobile / Spring / Tomcat okazało się proste. Problem z wyciekiem pamięci zgłoszony w analizie aplikacji JSF / Spring / Tomcat (punkt 4.3.5) nadal występuje. Rozwiążemy go w ten sam sposób.

10.3. Testy w środowisku Eclipse

Importujemy projekty Maven do środowiska Eclipse [1]:

Uruchamiamy projekt internetowy [2].

Wybieramy serwer Tomcat [3]. Strona główna aplikacji jest następnie wyświetlana w wewnętrznej przeglądarce Eclipse [4].

10.4. Testy na urządzeniach mobilnych

Aby przetestować aplikację na urządzeniu mobilnym, należy postępować zgodnie z instrukcjami zawartymi w punkcie 8.5.6. Oto zdjęcia aplikacji: