Długo nosiłem się z zamiarem napisania czegoś na temat fabryk testów w TestNG. W końcu napisałem…

Zapraszam do pobrania Software Developer’s Journal 3-2011 i przeczytania artykułu ze strony 50.

Okres letni oznacza lepszą pogodę. Zamiast siedzieć przed komputerem, w wolnym czasie można pójść na spacer do parku albo wyjechać gdzieś nad wodę. Niestety oznacza to mniej wpisów na blogu.

Już się poprawiam…

Pod moim ostatnim wpisem bardzo szybko pojawiło się kilka komentarzy. Okazuje się, że zdania na temat tzw. Java Killers są podzielone.

Dla tych, którzy nie mieli jeszcze okazji zetknąć się z omawianym pojęciem – Java Killers to pytania mające na celu udowodnić programiście Java, że właściwie nie zna języka Java.

Dla większości komentujących, pytania takie nie są niczym trudnym. Jednak szczególnie zainteresowała mnie następująca wypowiedź:

No coż, ja wolę pracować z dobrym programistą niż z nawet wybitnym specjalistą od języka :] ale co kto lubi

Od razu napiszę, że ja też. Z doświadczenia wiem, że dobry programista szybko nauczy się nowego języka. Z kolei wybitny specjalista od języka potrafi być fatalnym i niereformowalnym programistą. A jednak…

Jednak są powody, dla których warto być wybitnym specjalistą od języka.

Po pierwsze, specjalista od języka czasem się przydaje w zespole. Wprawdzie wydajność nie jest najważniejszą cechą napisanego kodu, ale przychodzi taki moment, kiedy trzeba przyspieszyć algorytm z kilku minut do jednej sekundy. Wówczas można np. zastąpić proste dodawanie Stringów obiektem klasy StringBuilder.

Ale doraźna optymalizacja nie jest jedynym obszarem do wykorzystania specjalisty od języka. Taki człowiek przydaje się także w sytuacji, gdy trzeba doszkolić niedoświadczonego programistę albo na bieżąco wspomagać zespół w problematycznych sytuacjach. Nauczyciel, konsultant czy też coach musi być wybitnym specjalistą, żeby móc uczyć innych.

Na sam koniec pozostawiłem argument, który może stanowić najlepszą motywację dla sceptyków. Aplikując na stanowisko programisty Java należy się przygotować na testy, które często składają się z pytań, jakie można odnaleźć wśród Java Killers. Może nie są to pytania podchwytliwe, ale dotyczą dobrej znajomości języka.

Co można zrobić, by poszerzyć swoją wiedzę? Na początek dobra może być jakaś książka o SCJP. Jednak wszystkim tym, którzy poważnie myślą o programowaniu w języku Java, polecam stronę BlackBeltFactory. Dlaczego?

• Przeglądając pytania w wersji beta i zdając kolejne egzaminy nauczyłem się kilku rzeczy, na które zapewne nigdy nie natknąłbym się jedynie programując.
• Dzięki BlackBeltFactory dobrze przygotowałem się do testów rekrutacyjnych z języka Java.
• Zdobywszy niebieski pas, mogłem zapisać się do grupy JavaBlackBelt na LinkedIn.
• Podczas nauki, w każdej chwili mogę skorzystać z pomocy któregoś z wielu coachów. Mogę też sam uczyć innych.
• Materiał dostępny na BlackBeltFactory nie ogranicza się jedynie do programowania w języku Java. Są tam też egzaminy z Groovy, Ruby, .NET czy też zagadnień ogólnych, jak programowanie obiektowe.

Każdego, kto chciałby się zarejestrować na BlackBeltFactory, zapraszam na tę stronę.

Chyba dzisiaj wyszedł mi wpis reklamowy, ale trudno. Strona naprawdę jest warta polecenia.

Przeczytałem dzisiaj ciekawy wpis dotyczący egzaminu na technika informatyka. Zawarte w nim informacje zainspirowały mnie do napisania takiego oto fragmentu kodu:

public class Dollars {
    public static void main(String... args) {
        int $100 = 50;
        System.out.println($100);
    }
}

Pytanie brzmi: „Co się stanie?”

1. Wystąpi błąd kompilacji?
2. Program skompiluje się, ale wystąpi błąd podczas uruchamiania?
3. Program wyświetli $100?
4. Program wyświetli 50?

Każdy kto przeczyta wspomniany artykuł z pewnością od razu będzie znał odpowiedź. Jednak wszystkim polecam empiryczne przetestowanie powyższego kodu – to naprawdę ciekawe doświadczenie.

PS. Próbowałem też z $, $$ i $_$.

W programach, z których korzysta wielu różnych użytkowników, moduł ustawień potrafi być bardziej skomplikowany niż sama aplikacja. Większość opcji przyjmuje postać wartości logicznych. W naszym zespole powstał nawet termin Single Checkbox Requirement (albo Single Checkbox Apocalypse), oznaczający funkcję programu, która może być włączona lub wyłączona i wpływa na wiele różnych elementów systemu (np. powiadomienia email).

Wprowadzenie jednego SCR do projektu generuje kilka(naście/dziesiąt) dodatkowych instrukcji warunkowych. Większa ilość takich wymagań powoduje, że kod źródłowy staje się całkowicie nieczytelny (niezależnie od zastosowanych zabiegów poprawiających jego jakość) – zwłaszcza, gdy pojawiają się one po pół roku (sic!) pisania aplikacji.

Programowanie aspektowe pozwoliło mi rozwiązać opisany problem szybko i w elegancki sposób.

W przykładzie wykorzystam plik pom.xml opracowany w jednym z wcześniejszych wpisów. Struktura projektu będzie wyglądać następująco:

• src
  • main
    • java
      • pl.info.czerwinski.conditional
        • Conditional.java
        • ConditioningAspect.java
  • test
    • java
      • pl.info.czerwinski.conditional
        • Calculation.java
        • CalculationTests.java
        • ConditionalCalculation.java
        • FullCalculation.java
    • resources
      • parameters.properties
      • testng.xml
• pom.xml

Adnotacja @Conditional

Aby w prosty sposób włączać i wyłączać wykonywanie określonych metod, oznaczę je adnotacją @Conditional:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@Documented
public @interface Conditional {
    String value();
}

Wartością atrybutu value będzie nazwa parametru warunkującego wykonanie danej metody.

Interfejs Calculation

Aby ułatwić sobie zadanie, do testów wykorzystam dwie implementacje prostego algorytmu:

interface Calculation {
    double calculate();
}

Metoda calculate będzie wykonywać pewne operacje arytmetyczne, po czym zwróci ich wynik.

Pełna implementacja

Najpierw utworzę klasę FullCalculation, której wszystkie metody będą zawsze wykonywane:

class FullCalculation implements Calculation {

    public double calculate() {
        initValue();
        multiply();
        divide();
        add();
        subtract();
        return value;
    }

    private void initValue() {
        value = 1.0;
    }

    private void multiply() {
        value *= 2.0;
    }

    private void divide() {
        value /= 2.0;
    }

    private void add() {
        value += 1.0;
    }

    private void subtract() {
        value -= 1.0;
    }

    private double value;
}

Algorytm składa się z kilku atomowych operacji:

• ustawienie wartości na 1,
• pomnożenie wartości przez 2,
• podzielenie wartości przez 2,
• dodanie 1 do wartości,
• odjęcie 1 od wartości,
• zwrócenie wartości.

Jeżeli żaden etap obliczeń nie zostanie pominięty, wynik powinien wynosić 1.

Implementacja warunkowana

Klasa ConditionalCalculation jest niemalże dokładną kopią pełnej implementacji. Tym razem metody multiply, divide, add i subtract oznaczone są adnotacją @Conditional z odpowiednimi parametrami:

class ConditionalCalculation implements Calculation {

    public double calculate() {
        initValue();
        multiply();
        divide();
        add();
        subtract();
        return value;
    }

    private void initValue() {
        value = 1.0;
    }

    @Conditional("MULTIPLY")
    private void multiply() {
        value *= 2.0;
    }

    @Conditional("DIVIDE")
    private void divide() {
        value /= 2.0;
    }

    @Conditional("ADD")
    private void add() {
        value += 1.0;
    }

    @Conditional("SUBTRACT")
    private void subtract() {
        value -= 1.0;
    }

    private double value;
}

Parametry warunkujące

Działanie przykładowego aspektu oprę na ustawieniach pobieranych z pliku parameters.properties. W typowej aplikacji będą to raczej wielkości pobierane z bazy danych.

Spośród obliczeń warunkowych włączę tylko mnożenie i dodawanie. Teraz rezultat powinien wynieść 3:

# ConditionalCalculation properties:
MULTIPLY=true
DIVIDE=false
ADD=true
SUBTRACT=false

Testy

Metody testowe dla obu algorytmów są raczej oczywiste:

public class CalculationTests {

    @Test
    public void testCalculateFull() {
        Calculation calculation = new FullCalculation();

        assertEquals(calculation.calculate(), 1.0,
                "Full calculation value");
    }

    @Test
    public void testCalculateParameterized() {
        Calculation calculation = new ConditionalCalculation();

        assertEquals(calculation.calculate(), 3.0,
                "Conditional calculation value");
    }
}

Konfiguracja testów

Aby testy się wykonywały, muszę jeszcze utworzyć plik testng.xml, wskazujący właściwy pakiet:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="AspectJ" verbose="2">
  <test name="Conditional">
    <packages>
      <package name="pl.info.czerwinski.conditional"/>
    </packages>
  </test>
</suite>

W tej chwili wywołanie mvn test powinno zakończyć się jedną porażką przy dwóch wykonanych testach. Nieprawidłowy rezultat wystąpi w metodzie testCalculateParameterized, gdzie zamiast oczekiwanej wartości 3.0 pojawi się 1.0.

Aspekt warunkujący

Pora przejść do najważniejszego elementu całego przykładu, czyli do aspektu. Pojawia się tu kilka nowości:

@Aspect
public class ConditioningAspect {

    @Around("call(@Conditional * *.*(..)) && @annotation(conditional)")
    public Object condition(
            ProceedingJoinPoint joinPoint,
            Conditional conditional) throws Throwable {
        String parameterName = conditional.value();
        if (Boolean.parseBoolean(parameters.getString(parameterName))) {
            return joinPoint.proceed();
        }
        return null;
    }

    private ResourceBundle parameters =
        ResourceBundle.getBundle("parameters");
}

Poprzednio omówiłem adnotacje @Before oraz @After, wskazujące rady przed i po. Adnotacja @Around służy to utworzenia rady „otaczającej” punkt przecięcia, czyli takiej, która kontroluje dalsze wykonanie programu. Standardowo metoda taka pobiera parametr klasy ProceedingJoinPoint i zwraca dowolny obiekt. Aby rada pozostała bez wpływu na wykonanie programu, powinna składać się z jednej instrukcji:

return joinPoint.proceed();

Innymi słowy, brak tej instrukcji oznacza, że metoda, której rada dotyczy, nie zostanie w ogóle wykonana.

Definicja punktu przecięcia w przykładzie jest dość złożona:

call(@Conditional * *.*(..)) && @annotation(conditional)

Powyższy zapis oznacza wywołanie dowolnej metody oznaczonej adnotacją @Conditional. Rada przyjmuje tę adnotację jako parametr conditional, dzięki czemu można uzależnić dalsze działanie programu od atrybutu value.

Po dodaniu aspektu, wszystkie testy powinny zakończyć się sukcesem.

Podsumowanie

Opisane rozwiązanie daje możliwość szybkiego i łatwego warunkowania kolejnych metod, z zachowaniem czytelności kodu.

Przypuszczam, że do zaproponowanego przeze mnie aspektu można wprowadzić dalsze poprawki (czekam na konstruktywne komentarze). Mam tylko nadzieję, że duża ilość kodu nie zmniejszy czytelności niniejszego wpisu.

Pracując nad nowym artykułem, po raz kolejny doszedłem do momentu, gdzie powinienem przedstawić strukturę plików i katalogów w projekcie. Do tej pory radziłem sobie przy pomocy znacznika pre oraz odpowiednio umieszczonych spacji. Problem polega na tym, że przy większej liczbie plików lub większym zagnieżdżeniu katalogów, lista staje się nieczytelna.

Uznałem, że najlepszym wyjściem będzie dodanie do bloga arkusza stylów oraz odpowiednich ikonek, z pomocą których utworzę całkiem zgrabne drzewko. Zanim dorobię się własnych obrazków, skorzystam z udostępnionego na licencji GPL zestawu Gnome Crystal Diamond Icons 1.0b.

W pliku CSS dodaję styl całej listy. Chciałbym, aby nazwy plików i katalogów napisane były stałym krojem pisma:

.dir-tree {
  font-family: monospace;
}

Następnie wskazuję ikony użyte przy wypunktowaniu różnych elementów listy. W tej chwili rozróżniam katalogi, pakiety oraz pliki: Java, XML i pozostałe:

.dir {
  list-style: url("dir.png");
}

.package {
  list-style: url("package.png");
}

.file {
  list-style: url("file.png");
}

.file-java {
  list-style: url("file-java.png");
}

.file-xml {
  list-style: url("file-xml.png");
}

Na samym końcu postanowiłem dodać kropkowane linie, w celu zwiększenia czytelności:

.dir-tree ul {
  border-left: 1px dotted #ccc;
}

Przykładowa struktura katalogów w pliku HTML wygląda następująco:

<ul class="dir-tree">
  <li class="dir">src
    <ul>
      <li class="dir">main
        <ul>
          <li class="dir">java
            <ul>
              <li class="package">pl.info.czerwinski
                <ul>
                  <li class="file-java">FooClass.java</li>
                  <li class="file-java">FooEntity.java</li>
                </ul>
              </li>
            </ul>
          </li>
          <li class="dir">resources
            <ul>
              <li class="file">project.properties</li>
            </ul>
          </li>
        </ul>
      </li>
      <li class="dir">test
        <ul>
          <li class="dir">java
            <ul>
              <li class="package">pl.info.czerwinski
                <ul>
                  <li class="file-java">FooTest.java</li>
                </ul>
              </li>
            </ul>
          </li>
          <li class="dir">resources
            <ul>
              <li class="file">testing.properties</li>
              <li class="file-xml">testng.xml</li>
            </ul>
          </li>
        </ul>
      </li>
    </ul>
  </li>
  <li class="file-xml">pom.xml</li>
</ul>

W rezultacie otrzymuję drzewo podobne do poniższego:

• src
  • main
    • java
      • pl.info.czerwinski
        • FooClass.java
        • FooEntity.java
    • resources
      • project.properties
  • test
    • java
      • pl.info.czerwinski
        • FooTest.java
    • resources
      • testing.properties
      • testng.xml
• pom.xml

Od tej pory każdą strukturę plików w projekcie będę przedstawiał za pomocą powyższego rozwiązania. Mam nadzieję, że opisany przykład przysłuży się też komuś poza mną.

Przygotowałem ostatnio plik pom.xml dla projektu korzystającego z AspectJ. Zanim przejdę do omawiania rzeczywistych problemów, przedstawię pokrótce budowę prostego aspektu. Żeby uzyskać jak najwięcej szczegółów, zamiast testów, użyję raczej niezbyt eleganckiego rozwiązania opartego o System.out.

Przygotowania

Na początek utworzę klasę, której dotyczyć będą punkty przecięcia użyte przy tworzeniu aspektu. Wystarczy mi jedna metoda, wyświetlająca komunikat:

public class FooClass {
    public void fooMethod() {
        System.out.println("FooClass.fooMethod() says \"Hello\".");
    }
}

Metodę fooMethod wywoływać będę wewnątrz metody innej klasy. Dla uproszczenia będzie to główna klasa programu:

public class MethodExample {
    public static void main(String... args) {
        new MethodExample();
    }

    public MethodExample() {
        new FooClass().fooMethod();
    }
}

Aspekt

Pora utworzyć pierwszy aspekt. Nie będę tutaj omawiał starego podejścia, gdzie aspekty pisane były w specjalnym języku (przykłady można znaleźć w Wikipedii). Zamiast tego utworzę najzwyklejszą klasę, oznaczoną adnotacją @Aspect:

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.*;

@Aspect
public class MethodLogger {
}

Wykonanie metody

Na początku zajmę się punktem złączenia, odpowiadającym wykonaniu metody fooMethod, nie przyjmującej żadnych parametrów oraz nie zwracającej żadnej wartości. W AspectJ możemy go zapisać:

execution(void fooMethod())

Punkt przecięcia może składać się po prostu z jednego punktu złączenia. Tak też będzie w omawianym przykładzie. Ze względu na prostotę, nie będę definiował osobnego punktu przecięcia (może w kolejnych przykładach), ale przejdę od razu do rad.

Utworzę dwie rady dla omawianego punktu przecięcia – przed oraz po. Będą to metody klasy aspektu, przyjmujące jako parametr konkretny punkt złączenia, przy którym rada została wywołana. Aby wskazać, że metoda jest radą, użyję odpowiednich adnotacji:

@Before("execution(void fooMethod())")
public void beforeExecution(JoinPoint joinPoint) {
    System.out.println("Before execution");
}

@After("execution(void fooMethod())")
public void afterExecution(JoinPoint joinPoint) {
    System.out.println("After execution");
}

Po uruchomieniu programu, otrzymuję chyba oczywisty rezultat:

Before execution
FooClass.fooMethod() says "Hello".
After execution

Wywołanie metody

Nieco innym punktem złączenia jest wywołanie metody. Jego definicja będzie wyglądała następująco:

call(void fooMethod())

Do aspektu dodaję dwie nowe rady   przed wywołaniem metody oraz po wywołaniu metody:

@Before("call(void fooMethod())")
public void beforeCall(JoinPoint joinPoint) {
    System.out.println("Before call");
}

@After("call(void fooMethod())")
public void afterMethodCall(JoinPoint joinPoint) {
    System.out.println("After call");
}

Tym razem rezultat może nie być już tak oczywisty (przynajmniej na pierwszy rzut oka):

Before call
Before execution
FooClass.fooMethod() says "Hello".
After execution
After call

Z powyższego przykładu płynie wniosek, że metoda jest najpierw wywoływana, a dopiero potem wykonywana.

Porównanie punktów złączenia

Aby dokładniej porównać omawiane punkty złączeń, utworzę dodatkową metodę, wywoływaną z poziomu każdej rady:

private void printJoinPointInfo(JoinPoint joinPoint) {
    System.out.println("======== Join point: ========");
    System.out.println("Signature: " +
        joinPoint.getSignature().toShortString());
    System.out.println("Kind: " + joinPoint.getKind());
    System.out.println("This: " +
        joinPoint.getThis().getClass().getSimpleName());
    System.out.println("Target: " +
        joinPoint.getTarget().getClass().getSimpleName());
    System.out.println("=============================");
}

Tym razem na konsoli powinny pojawić się następujące komunikaty:

Before call
======== Join point: ========
Signature: FooClass.fooMethod()
Kind: method-call
This: MethodExample
Target: FooClass
=============================
Before execution
======== Join point: ========
Signature: FooClass.fooMethod()
Kind: method-execution
This: FooClass
Target: FooClass
=============================
FooClass.fooMethod() says "Hello".
After execution
======== Join point: ========
Signature: FooClass.fooMethod()
Kind: method-execution
This: FooClass
Target: FooClass
=============================
After call
======== Join point: ========
Signature: FooClass.fooMethod()
Kind: method-call
This: MethodExample
Target: FooClass
=============================

Jak widać, dla tej samej metody obiekt docelowy (target) jest zawsze ten sam – jest to obiekt, w którym dana metoda się znajduje. Ale wskazanie obiektu bieżącego (this) nie jest już takie proste. W przypadku wykonania metody, jest to ten sam obiekt, co docelowy (zawierający daną metodę). Jednak przy wywołaniu metody, obiekt bieżący jest tym, z poziomu którego metoda jest wywoływana.

Podsumowanie

Omówiony przykład pokazuje, ile potencjalnych błędów może spowodować prosta obsługa wywołania lub wykonania metody. Wewnątrz konstruktora klasy MethodExample została wywołana metoda fooMethod, ale jej wykonanie odbywa się dla obiektu klasy FooClass. Czytelnikom polecam ponowne przeanalizowanie całego kodu.

Następnym razem spróbuję opisać jakieś realne zastosowanie AspectJ. Podam też przykłady innych rad i punktów złączenia.

Programowaniem aspektowym (ang. Aspect-oriented programming) zainteresowałem się ponad rok temu. Niestety od tamtej pory nie znalazłem dość czasu, aby zająć się tym zagadnieniem na poważnie. Nadszedł moment, kiedy nie jestem już całkowicie pochłonięty pracą z Seam Framework. Teraz nareszcie mogę zagłębić się w tajniki biblioteki AspectJ.

Niniejszy wpis nie będzie zawierał żadnych przykładowych aspektów. Na początku postaram się omówić konfigurację projektu w pliku pom.xml.

Ponieważ zamierzam wykorzystać aspekty oparte o adnotacje, potrzebuję kompilacji kodu przynajmniej w wersji Java 1.5:

<project>
  <modelVersion>4.0.0</modelVersion>
  […]

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.3</version>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>
[…]

W następnej kolejności, dodaję wtyczkę aspectj-maven-plugin, która będzie kompilować aspekty razem z kodem oraz testami:

[…]
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>aspectj-maven-plugin</artifactId>
        <version>1.3</version>
        <configuration>
          <complianceLevel>1.5</complianceLevel>
        </configuration>
        <executions>
          <execution>
            <goals>
              <goal>compile</goal>
              <goal>test-compile</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
[…]

Na sam koniec muszę wskazać wtyczce maven-surefire-plugin położenie pliku XML zawierającego konfigurację TestNG:

[…]
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.5</version>
        <configuration>
          <suiteXmlFiles>
            <suiteXmlFile>src/test/resources/testng.xml</suiteXmlFile>
          </suiteXmlFiles>
        </configuration>
      </plugin>
    </plugins>
  </build>
[…]

Aby móc tworzyć aspekty, do zależności muszę dodać bibliotekę aspectjrt:

[…]
  <dependencies>
    <dependency>
      <groupId>org.aspectj</groupId>
      <artifactId>aspectjrt</artifactId>
      <version>1.6.8</version>
    </dependency>
[…]

Na sam koniec, do zależności dodaję bibliotekę TestNG:

[…]
    <dependency>
      <groupId>org.testng</groupId>
      <artifactId>testng</artifactId>
      <version>5.11</version>
      <classifier>jdk15</classifier>
      <scope>test</scope>
    </dependency>
  </dependencies>

  […]
</project>

Oczywiście należałoby ustawić pozostałe parametry projektu, jak groupId, artifactId, version, packaging czy version. Przydadzą się także raporty maven-surefire-report-plugin oraz maven-javadoc-plugin, o których pisałem przy okazji strony wtyczki Maven.

Następnym razem postaram się omówić pierwszy przykład prostego aspektu wraz z testami.

Gdy już udało mi się wysłać wiadomość email z poziomu aplikacji Seam, postanowiłem przenieść konfigurację serwera poczty wychodzącej do bazy danych – tak aby użytkownik (administrator) systemu mógł ją zmieniać w dowolnym momencie.

Realizacja tego zadania wymagała rozszerzenia funkcjonalności komponentu org.jboss.seam.mail.mailSession. Na początek tworzę nową klasę, dziedziczącą po MailSession:

@Name("org.jboss.seam.mail.mailSession")
@Install(
        precedence = Install.APPLICATION,
        classDependencies = "javax.mail.Session")
@Scope(ScopeType.APPLICATION)
public class JpaMailSession extends org.jboss.seam.mail.MailSession {
    @In
    private EntityManager entityManager;
}

Pobieranie danych serwera poczty z bazy wymaga przeciążenia kilku metod. Na początku zajmę się tworzeniem właściwego obiektu sesji:

@Override
@Unwrap
public javax.mail.Session getSession() throws NamingException {
    setSessionJndiName(null);
    create();
    return super.getSession();
}

Ustawienie nazwy sesji na null (linia 4) spowoduje, że metoda create() (linia 5) faktycznie utworzy nową sesję. Domyślnie dane serwera poczty są stałe (pochodzą z pliku components.xml), więc wystarczy jednorazowe utworzenie sesji. W wypadku konfiguracji zapisanej w bazie wszelkie niezbędne dane mogą ulec zmianie w trakcie działania aplikacji, co powoduje konieczność przeładowania sesji.

Powyższe operacje można wykonywać w odpowiednio przygotowanej metodzie obserwatora zdarzenia związanego ze zmianą danych serwera pocztowego… może w następnym artykule.

Kolejną przeciążaną metodą będzie getHost() – odpowiedzialna za pobieranie nazwy serwera pocztowego:

@Override
public String getHost() {
    if (entityManager != null) {
        super.setHost(loadHostFromDB());
    }
    return super.getHost();
}

Implementację prywatnej metody loadHostFromDB() pozostawiam czytelnikom, ponieważ dane serwera pocztowego można przechowywać w bazie na wiele sposobów – wszystko zależy od konkretnej sytuacji i kontekstu.

Przed pobraniem nazwy hosta z bazy sprawdzam, czy istnieje entityManager (linia 3). Nie chodzi o to, że komponent może nie istnieć w kontekście – on mógł nie zostać wstrzyknięty. Powodem takiej sytuacji jest adnotacja @BypassInterceptors przy klasie org.jboss.seam.mail.MailSession – bez interceptorów nie ma wstrzykiwania zależności.

Analogicznie przeciążam metody pobierające pozostałe dane serwera pocztowego:

@Override
public Integer getPort() {
    if (entityManager != null) {
        super.setPort(loadPortFromDB());
    }
    return super.getPort();
}

@Override
public String getUsername() {
    if (entityManager != null) {
        super.setUsername(loadUsernameFromDB());
    }
    return super.getUsername();
}

@Override
public String getPassword() {
    if (entityManager != null) {
        super.setPassword(loadPasswordFromDB());
    }
    return super.getPassword();
}

Teraz już można usunąć znacznik mail:mail-session z pliku components.xml. Wysyłanie wiadomości będzie się odbywać w oparciu o konfigurację zapisaną w bazie danych.

Opisany wyżej mechanizm można poddać wielu dalszym ulepszeniom. Być może opiszę swoje propozycje w przyszłości.

Dzisiejszy artykuł stanowi jedynie wstęp do bardziej zaawansowanych zagadnień dotyczących poczty elektronicznej w Seam Framework. Opiszę tutaj podstawową konfigurację oraz wysyłanie prostej wiadomości email – kwestie kluczowe z punktu widzenia tematyki kolejnych wpisów.

Obsługa poczty w Seam realizowana jest za pośrednictwem biblioteki JavaMail. Dlatego do projektu (albo do bibliotek serwera) należy dodać archiwum mail.jar.

Podstawowa konfiguracja serwera poczty wychodzącej powinna znaleźć się w pliku components.xml:

<mail:mail-session
    host="smtp.foo.com"
    port="25"
    username="fooUser"
    password="fooPassword"/>

Wysłanie wiadomości odbywa się poprzez przetworzenie odpowiedniego widoku zawartego w pliku XHTML. Poniżej przedstawiam przykładowy widok mail.xhtml:

<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<m:message
    charset="UTF-8"
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:m="http://jboss.com/products/seam/mail">

  <m:from name="#{mailBean.fromName}" address="#{mailBean.fromEmail}"/>
  <m:to name="#{mailBean.toName}">#{mailBean.toEmail}</m:to>

  <m:subject>#{mailBean.subject}</m:subject>

  <m:body>
    <p>
      #{mailBean.body}
    </p>
    <p>--</p>
    <p><small>#{mailBean.signature}</small></p>
  </m:body>

</m:message>

Zawarte w przykładzie dane nadawcy i adresata oraz temat i treść wiadomości pobierane są z komponentu mailBean, ale nic nie stoi na przeszkodzie, aby zostały wpisane na stałe do widoku. Tak jak w przypadku zwykłych stron JSF czy dokumentów PDF, także w wiadomościach email można dowolnie łączyć czysty tekst z wyrażeniami Expression Language (#{…}).

Przekierowanie na stronę mail.seam powinno zakończyć się wysłaniem przygotowanej wcześniej wiadomości. Wówczas jednak w przeglądarce pojawi się pusta strona. Aby temu zapobiec, można przetworzyć widok używając komponentu renderer (org.jboss.seam.faces.Renderer):

@In(create=true)
private Renderer renderer;

Wysłanie wiadomości odbywa się poprzez wywołanie metody render():

public void send() {
  // …
  renderer.render("/mail.xhtml");
}

Oczywiście przed dokonaniem wysyłki należy pamiętać, aby ustawić prawidłowe wartości odpowiednich właściwości komponentu mailBean.

Potrzebowałem utworzyć tabelę, zawierającą elementy tabeli źródłowej, lecz w odwrotnej kolejności. Zadanie jest dziecinnie proste, jednak chciałem się upewnić, czy nie ma już specjalnie dla tego celu przygotowanej metody – na przykład w klasie java.util.Arrays. Wówczas natrafiłem na ciekawe rozwiązanie problemu:

public static Object[] reverse(Object[] arr) {
    List<Object> list = Arrays.asList(arr);
    Collections.reverse(list);
    return list.toArray();
}

Oczywiście! Przecież metoda, której szukam, została zaimplementowana dla kolekcji.

Na wszelki wypadek postanowiłem przetestować znaleziony algorytm:

@Test
public void testReverse() {
    Object[] objects = new Object[] {
        1, 2, 3, 4, 5, 6, 7, 8, 9, 10
    };

    Object[] reversed = ArrayHandle.reverse(objects);

    assertEquals(reversed[0], (Object) 10,
            "First element of reversed array");
}

Tak! Działa!

Jeszcze tylko upewnię się, że tabela źródłowa pozostaje niezmieniona:

@Test
public void testReverse() {
    // …
    assertEquals(objects[0], (Object) 1,
            "First element of original array");
}

Uruchamiam testy i… otrzymuję błąd:

java.lang.AssertionError: First element of original array expected:<1> but was:<10>

Co się stało?

Przeanalizujmy metodę reverse.

Na samym początku tworzony jest interfejs java.util.List dla tablicy źródłowej. Zauważmy przy tym, że lista zwrócona przez Arrays.asList() odwołuje się bezpośrednio do wskazanej tablicy – nie kopiuje jej elementów.

Dzięki metodzie Collections.reverse() odwrócona zostaje kolejność elementów listy, czyli de facto elementów tablicy źródłowej.

Na samym końcu, przy użyciu metody List.toArray() tworzona jest nowa tablica, która zostaje następnie zwrócona jako wynik działania metody.

Czyli metoda reverse zmienia kolejność elementów wewnątrz tablicy podanej jako parametr na odwrotną, po czym zwraca kopię tej tablicy? Przypuszczam (albo przynajmniej mam nadzieję), że nie taka była intencja autora. Jeżeli widzę metodę o sygnaturze Object[] reverse(Object[]), to spodziewam się, że parametr pozostanie niezmieniony (już lepiej by było, gdyby ta metoda nie zwracała nic).

Postanowiłem nieco ulepszyć algorytm – tak aby kopia tablicy tworzona była przed zmianą kolejności elementów:

public static <T> T[] reverse(T[] arr) {
    T[] reversed = arr.clone();
    List<T> list = Arrays.asList(reversed);
    Collections.reverse(list);
    return reversed;
}

W ten sposób kolejność elementów tablicy wejściowej pozostaje bez zmian; ponadto unikam tworzenia nadmiarowej kopii.

Istnieje jeszcze jeden atut nowej implementacji – jest to metoda generyczna. Aby odwrócić kolejność elementów tablicy liczb całkowitych, nie muszę już korzystać z rzutowania:

Integer[] reversed = (Integer[]) ArrayHandle.reverse(integers);

Teraz mogę zwyczajnie wywołać tę metodę dla tablicy Integer[], jak w poniższej metodzie testowej:

@Test
public void testReverseForIntegers() {
    Integer[] integers = new Integer[] {
        1, 2, 3, 4, 5, 6, 7, 8, 9, 10
    };

    Integer[] reversed = ArrayHandle.reverse(integers);

    assertEquals(reversed[0], (Integer) 10,
            "First element of reversed array");
    assertEquals(integers[0], (Integer) 1,
            "First element of original array");
}

Oczywiście można ograniczyć odpowiedzialność metody reverse do zmiany kolejności elementów tablicy in situ:

public static <T> void reverse(T[] arr) {
    List<T> list = Arrays.asList(arr);
    Collections.reverse(list);
}