10. Приклад додатка-06: rdvmedecins-pfm-spring

10.1. Портування

Тепер ми переносимо попередній додаток у середовище Spring / Tomcat:

Ми будемо спиратися на два вже написані додатки. Ми будемо використовувати:

шари [DAO] та [JPA] з версії 02 JSF / Spring,
модуль [web] / Primefaces mobile з версії 05 PFM / EJB,
конфігураційні файли Spring версії 02

Ми виконуємо тут роботу, аналогічну тій, що була зроблена для перенесення додатка JSF2 / EJB / Glassfish у середовище JSF2 / Spring Tomcat. Тому ми надамо менше пояснень. У разі потреби читач може звернутися до опису цього перенесення.

Ми розміщуємо всі проекти, необхідні для перенесення, у новій папці [rdvmedecins-pfm-spring] [1]:

[mv-rdvmedecins-spring-dao-jpa]: шари [DAO] та [JPA] з версії 02 JSF / Spring,
[mv-rdvmedecins-spring-metier]: шар [métier] версії 02 JSF / Spring,
[mv-rdvmedecins-pfmobile]: шар [web] з версії 05 Primefaces mobile / EJB,
у [2], завантажуємо їх у NetBeans,
у [3] залежності веб-проєкту більше не відповідають дійсності:
- залежності від шарів [DAO], [JPA], [métier] потрібно змінити, щоб вони тепер вказували на проекти Spring;
- сервер Glassfish надавав бібліотеки з JSF. З сервером Tomcat це вже не так. Тому їх потрібно додати до залежностей.

Проєкт [web] розвивається наступним чином:

Файл [pom.xml] з шару [web] тепер має такі залежності:


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

З’являються помилки. Вони пов’язані з посиланнями на EJB у шарі [web]. Спочатку розглянемо bean [Application]:

Видаляємо всі рядки, що містять помилки через відсутні пакети, перейменовуємо [IMetier] (так він називається у шарі [métier] Spring) на інтерфейс [IMetierLocal] і використовуємо 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 {

  // бізнес-шар
  private IMetier metier;
  // помилки
  private List<Erreur> erreurs = new ArrayList<Erreur>();
  private Boolean erreur = false;

  public Application() {
    try {
      // інстанціювання шару [métier]
      ApplicationContext ctx = new ClassPathXmlApplicationContext("spring-config-metier-dao.xml");
      metier = (IMetier) ctx.getBean("metier");
    } catch (Throwable th) {
      // реєструється помилка
      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;
    }
  }

  // гетери
  public Boolean getErreur() {
    return erreur;
  }

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

  public IMetier getMetier() {
    return metier;
  }
}

рядки 20–21: створення екземпляра шару [métier] на основі конфігураційного файлу Spring. Цей файл використовується шарами [métier] та [1]. Ми копіюємо його у веб-проект [2]:

рядки 22–31: обробляємо можливе виключення та зберігаємо його стек у полі рядка 14.

Після цього у біні [Application] більше немає помилок. Тепер розглянемо біни [Form], [1] та [2]:

3

4

Ми видаляємо всі помилкові рядки (імпорт та анотації), пов’язані з відсутніми пакетами, і перейменовуємо інтерфейс [IMetier] на [ImetierLocal]. Цього достатньо, щоб усунути всі помилки [3].

Крім того, у код біна [Form] потрібно додати методи getter і setter для поля


  // об'єкт Application
private Application application;

Деякі з анотацій, видалених у бінах [Application] та [Form], оголошували класи як біни з певною областю дії. Відтепер ця конфігурація здійснюється у наступному файлі [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>
    <!-- файл повідомлень -->
    <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>
    <!-- біан 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>
    <!-- біан форми -->
  <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>

Портування завершено. Можна спробувати запустити веб-додаток.

Залишаємо читачеві можливість самостійно протестувати цей новий додаток. Ми можемо дещо вдосконалити його, щоб врахувати випадок, коли ініціалізація біна [Application] завершилася невдало. Відомо, що в цьому випадку були ініціалізовані такі поля:


  // помилки
  private List<Erreur> erreurs = new ArrayList<Erreur>();
private Boolean erreur = false;

Цей випадок можна передбачити в методі init біна [Form]:


@PostConstruct
  private void init() {

    // Чи пройшла ініціалізація успішно?
    if (application.getErreur()) {
      // отримано список помилок
      erreurs = application.getErreurs();
      // відображається перелік помилок
      setForms(false, false, true);
    }

    // заносимо лікарів та клієнтів у кеш
    ...
  }

рядок 5: якщо бін [Application] ініціалізувався неправильно,
рядок 7: отримуємо список помилок,
рядок 9: і відображаємо сторінку помилки.

Отже, якщо зупинити SGBD та MySQL і перезапустити додаток, тепер відображається така сторінка:

10.2. Conclusion

Перенесення додатка Primefaces mobile/ EJB / Glassfish у середовище Primefaces mobile / Spring / Tomcat виявилося простим. Проблема витоку пам’яті, про яку йшлося в дослідженні додатка JSF / Spring / Tomcat (параграф 4.3.5), залишається. Її вирішують таким самим чином.

10.3. Тестування в Eclipse

Імпортуємо проекти Maven у Eclipse [1]:

Запускаємо веб-проект [2].

Вибираємо сервер Tomcat [3]. Після цього у вбудованому браузері Eclipse відображається головна сторінка додатка [4].

10.4. Тестування на мобільному пристрої

Щоб протестувати додаток на мобільному пристрої, слід діяти так, як зазначено в розділі 8.5.6. Ось фотографії додатка: