• Łatwiejsze tworzenie, ang. Ease of Development (Eod): W wcześniejszym szkicu zostały zaprezentowane adnotacje jako sposób na stworzenie Servletu – POJO. Jakkolwiek po dyskusji i odpowiedzi społeczności adnotacje @GET i @POST na poziomie metod zostały wycofane. Zostają jednak adnotacje dla typów – deklaracja sevletu @WebServlet oraz deklaracja filtru @ServletFilter, @WebServletContextListener będzie alternatywnym sposobem na zdefiniowanie context listenera. Dodatkowo adnotacje takie jak @Resouorce będą wspierane w aplikacjach webowych będą zachowywać się tak jak w starszej wersji specyfikacji (2.5).
• Rozszerzalność: szkielety webowe zbudowane na bazie servletów są bardzo popularne. Jest ich bardzo wiele, do wyboru w zależności od problemów, które mają rozwiązywać. Specyfikacja będzie umożliwiała łatwiejszą konfigurację tychże szkieletów.
• Przetwarzanie asynchroniczne: największym wyzwaniem i zmianą jaką podjęli autorzy specyfikacji. W poprzedniej wersji zostały zdefiniowane operacje zatrzymania (suspend) oraz wznowienia (resume). Po publikacji grupa ekspertów podjęła dyskusję na temat przypadków użycia takiego rozwiązania.

Na łamach InfoQ są fragmenty dyskusji na temat fragmentów specyfikacji. Ludzie z JBossa krytykują Jetty, inni krytykują grupę która pracuje nad specyfikacją, że kiepsko współpracuje ze społecznością.

Mam osobiście nadzieję, że ta burza mózgów wyjdzie nam na dobre i adnotacje w Servlet API 3.0 nie będą jedyną nowością. :-)

import java.util.concurrent.TimeUnit;
// ...
TimeUnit.MINUTES.toSeconds(55);

Fajna sprawa – jeśli mamy do czynienia z konwersjami. Inny pożyteczny przykład to przekazywanie czasu jako argumentu:

package org.code_house.concurrent;

import java.util.Date;
import java.util.concurrent.TimeUnit;

public class Lock {
    void lock(TimeUnit unit, long value) throws InterruptedException {
        Thread.sleep(unit.toMillis(value));
    }

    public static void main(String[] args) throws Exception {
        System.out.println("before " + new Date());

        new Lock().lock(TimeUnit.SECONDS, 30);

        System.out.println("after " + new Date());
    }

}

Programista, który używa takiej klasy nie musi się więc przejmować konwertowaniem jednostek na milisekundy, które są podstawą do wywołania metody Thread.sleep.

TimeUnit obsługuje następujące wielkości:

• nanosekundy
• mikrosekundy
• milisekundy
• sekundy
• minuty
• godziny
• dni

Posługując się kodem z Javy postanowiłem sobie przypomnieć nieco PHP i napisałem wersję tego typu wyliczeniowego dla PHP:

<?php
// namespace org\code_house\util;
/**
 * A simple class for converting between time units.
 *
 * @author Łukasz Dywicki <luke@code-house.org>
 */
class TimeUnit {

    /**
     * Nanoseconds.
     */
    const NANOS     = 0;

    /**
     * Microseconds.
     */
    const MICROS    = 1;

    /**
     * Milliseconds
     */
    const MILLIS    = 2;

    /**
     * Seconds.
     */
    const SECONDS   = 3;

    /**
     * Minutes.
     */
    const MINUTES   = 4;

    /**
     * Hours.
     */
    const HOURS     = 5;

    /**
     * Days.
     */
    const DAYS      = 6;

    /**
     * Conversion table between time units.
     * @var array
     */
    private static $modifiers = array(
         self::NANOS     => 0.000000001,
         self::MICROS    => 0.000001,
         self::MILLIS    => 0.001,
         self::SECONDS   => 1,
         self::MINUTES   => 60,
         self::HOURS     => 3600,
         self::DAYS      => 86400,
    );

    /**
     * Constructs new time unit.
     *
     * @param $type TimeUnit Time unit base.
     */
    public function __construct($type) {
        if ($type < TimeUnit::NANOS || $type > TimeUnit::DAYS) {
            throw new RuntimeException('Time unit base is out of range');
        }
        $this->type = $type;
    }

    public function toNanos($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::NANOS);
    }

    public function toMicros($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::MICROS);
    }

    public function toMilis($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::MILLIS);
    }

    public function toSeconds($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::SECONDS);
    }

    public function toMinutes($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::MINUTES);
    }

    public function toHours($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::HOURS);
    }

    public function toDays($value) {
        return TimeUnit::convert($this->type, $value, TimeUnit::DAYS);
    }

    /**
     * Convert method.
     *
     * @param $from Time unit
     * @param $value Number of values.
     * @param $to Time unit
     * @return decimal
     */
    private final static function convert($from, $value, $to) {
        if ($from === $to) {
            return $value;
        }

        $value *= self::$modifiers[$from];
        return $value / self::$modifiers[$to];
    }
}

// przykład użycia
$unit = new TimeUnit(TimeUnit::SECONDS);
echo $unit->toMinutes(60) ."\n";

$unit = new TimeUnit(TimeUnit::HOURS);
echo $unit->toMinutes(1) ."\n";

?>

Niestety brak pól z modyfikatorami public static final w PHP uniemożliwił zastosowanie choćby czegoś podobnego do typu wyliczeniowego.. Kod klasy dla PHP jest wolnodostępny. :-)

package org.code_house.test.mock;

interface Populator {
    int fill(String value, String[] arguments);
}

Implementacja interfejsu jest bardzo prosta:

package org.code_house.test.mock;

class FillAnswer implements IAnswer<Integer> {
    public Integer answer() throws Throwable {
        // pobranie argumentow
        Object[] arguments = EasyMock.getCurrentArguments();
        String name = (String) arguments[0];
        Object[] values = (Object[]) arguments[1];

        // logika potrzebna do testu
        int populated = 0;
        for (int i = 0; i < values.length; i++) {
            if (values[i] == null) {
                populated++;
                values[i] = name;
            }
        }
        return populated;
    }
}

Test jest również niezbyt skomplikowany – bazuje on na poprzedniej nocie – “Testowanie tablic argumentów z EasyMock”:

package org.code_house.test.mock;

import static org.easymock.EasyMock.*;
import org.easymock.IAnswer;

import java.util.Arrays;

import junit.framework.TestCase;

public class AnswerTest extends TestCase {

    public void testPopulate() {
        Populator populator = createMock(Populator.class);
        expect(populator.fill(eq("Code House"), aryEq(new String[3])))
            .andAnswer(new FillAnswer());
        expect(populator.fill(eq("Code House"), aryEq(new String[] {"1"})))
            .andAnswer(new FillAnswer());
        replay(populator);

        // tablica do wypełnienia
        String[] populated = new String[3];
        int added = populator.fill("Code House", populated);
        assertEquals(3, added);
        // w odpowiedzi oczekujemy dodania 3 nowych elementów
        assertTrue(Arrays.equals(
            new String[] {"Code House", "Code House", "Code House"},
            populated
        ));

        // w tym przypadku nie oczekujemy nowości
        added = populator.fill("Code House", new String[] {"1"});
        assertEquals(0, added);
    }
}

java.lang.AssertionError:
  Unexpected method call find([Ljava.lang.String;@1ad77a7):
    find([Ljava.lang.String;@b8f82d): expected: 1, actual: 0

package org.code_house.test.mock;

import static org.easymock.EasyMock.aryEq;
import static org.easymock.EasyMock.createMock;
import static org.easymock.EasyMock.expect;
import static org.easymock.EasyMock.replay;

import java.util.Collections;
import java.util.List;

import junit.framework.TestCase;

interface Finder {
    List<String> find(String[] names);
}

public class FinderTest extends TestCase {

    public void testFind() {
        Finder mock = createMock(Finder.class);
        expect(mock.find(aryEq(new String[] {"Amy", "Luke"}))).andReturn(
            Collections.EMPTY_LIST);
        replay(mock);

        List<String> list = mock.find(new String[] {"Amy", "Luke"});
        assertTrue(list.isEmpty());
    }
}

Rozwiązaniem tych problemów jest użycie mechanizmu “matcherów”, które są wbudowane w sam szkielet. Najprostszym sposobem na ich użycie jest odwołanie przy pomocy statycznego wywołania którejś z metod EasyMock. Poniżej znajduje się lista dostępnych matcherów. Wartość “given” to argument przekazany w wywołaniu metody.

• eq(X value)
  Argument pasuje jeśli wyrażenie value.equals(given) zwróci true. Dostępny dla wszystkich typów prostych i obiektów.
• anyBoolean(), anyByte(), anyChar(), anyDouble(), anyFloat(), anyInt(), anyLong(), anyObject(), anyShort()
  Dowolna wartość zostanie przepuszczona niezależnie od tego co będzie przekazane. Dostępny dla wszystkich typów.
• eq(X value, X delta)
  Pasuje jeśli aktualna jeśli wyrażenie given jest równe value z dokładnością do delta. Dostępne dla typów float oraz double.
• aryEq(X value)
  Pasuje jeśli wyrażenie Arrays.equals(value, given) zwraca true. Dostępne dla tablic typów prostych jak i dla obiektów.
• isNull()
  Pasuje jeśli given == null. Dostępne tylko dla obiektów.
• notNull()
  Pasuje jeśli given != null. Dostępne tylko dla obiektów.
• same(X value)
  Pasuje jeśli wyrażenie value == given jest prawdziwe. Dostępne tylko dla obiektów.
• isA(Class clazz)
  Pasuje jeśli given instanceof clazz zwraca true. Given może być instancję clazz jak i pochodną.
• lt(X value), leq(X value), geq(X value), gt(X value)
  Zwraca true jeśli given jest mniejsze, mniejsze równe, większe równe bądź większe niż value. Dostępne dla wszystkich numerycznych typów prostych.
• startsWith(String prefix), contains(String substring), endsWith(String suffix)
  Zwraca true jeśli given zaczyna się, zawiera bądź kończy się daną wartością. Dostępne dla argumentów typu String.
• matches(String regex), find(String regex)
  Pasuje jeśli given pasuje w całości do wyrażenia/fragment pasuje. Dostępne dla argumentów typu String.
• and(X first, X second)
  Zwraca true jeśli matcher first oraz second zwracają prawdę.
• or(X first, X second)
  Zwraca true jeśli matcher first bądź second pasuje.
• not(X value)
  Zwraca true jeśli matcher value zwrócił fałsz.

Uzbrojeni w taki zestaw matcherów możemy poprawić kod testu tak by był on poprawny:

public class FinderTest extends TestCase {

    public void testFind() {
        Finder mock = createMock(Finder.class);
        expect(mock.find(aryEq(new String[] {"Amy", "Luke"}))).andReturn(
            Collections.EMPTY_LIST);
        replay(mock);

        List<String> list = mock.find(new String[] {"Amy", "Luke"});
        assertTrue(list.isEmpty());
    }
}

Inny przykład:

public class FinderTest extends TestCase {

    public void testFind() {
        Finder mock = createMock(Finder.class);
        expect(mock.find("Lucy", aryEq(new String[] {"Amy", "Luke"}))).andReturn(
            Collections.EMPTY_LIST);
        replay(mock);

        List<String> list = mock.find("Lucy", new String[] {"Amy", "Luke"});
        assertTrue(list.isEmpty());
    }
}

Warto zwrócić uwagę na to, że jeśli korzystamy dla matchera aby dopasować argument to musimy zrobić to dla wszystkich, inaczej poleci wyjątek:

java.lang.IllegalStateException: 2 matchers expected, 1 recorded.

Stąd nasz test w końcowej postaci powinien wyglądać następująco:

package org.code_house.test.mock;

import static org.easymock.EasyMock.aryEq;
import static org.easymock.EasyMock.createMock;
import static org.easymock.EasyMock.eq;
import static org.easymock.EasyMock.expect;
import static org.easymock.EasyMock.replay;

import java.util.Collections;
import java.util.List;

import junit.framework.TestCase;

interface Finder {
    List<String> find(String[] names);

    List<String> find(String name, String[] names);
}

public class FinderTest extends TestCase {

    public void testFind() {
        Finder mock = createMock(Finder.class);
        expect(mock.find(eq("Lucy"), aryEq(new String[] {"Amy", "Luke"}))).andReturn(
            Collections.EMPTY_LIST);
        replay(mock);

        List<String> list = mock.find("Lucy", new String[] {"Amy", "Luke"});
        assertTrue(list.isEmpty());
    }
}

package org.code_house.scripting;

import javax.script.ScriptEngine;
import javax.script.ScriptEngineFactory;
import javax.script.ScriptEngineManager;

public class JSMain {

    public static void main(String[] args) throws Exception {
        ScriptEngineManager manager = new ScriptEngineManager();

        System.out.println("Dostępne języki");
        for (ScriptEngineFactory engine : manager.getEngineFactories()) {
            System.out.println(engine.getNames());
        }

        ScriptEngine engine = manager.getEngineByName("js");
        engine.put("y", 12);

        if (engine != null) {
            engine.eval("var x = 1; print(x + y);");
        }
    }

}

W taki oto sposób na naszej konsoli powinno wylądować coś takiego:

[js, rhino, JavaScript, javascript, ECMAScript, ecmascript]
13

Możemy również uruchomić plik js. Wystarczy do metody eval przekazać FileReader. Po uruchomieniu kodu który jest niżej powinno pokazać się okienko podobne do tego, które widzicie przy tym akapicie.

package org.code_house.scripting;

import java.io.*;
import javax.script.*;

public class JavaScriptMain {
    public static void main(String[] args) throws Exception {
        ScriptEngineManager manager = new ScriptEngineManager();
        ScriptEngine engine = manager.getEngineByName("js");
        engine.eval(new FileReader(new File("print.js")));
    }
}

frame = new javax.swing.JFrame;
frame.defaultCloseOperation = javax.swing.JFrame.EXIT_ON_CLOSE;
frame.title = "Test"
frame.setSize(new java.awt.Dimension(180, 80));

button = new javax.swing.JButton("Kliknij mnie")
button.addActionListener(function(event) {
    print(event.source);
});
frame.add(button);

frame.show()

Z dodatkowych języków można podpiąć między innymi PHP, Java FX, Groovy, BeanShell i wiele innych. Aby to zrobić należy ściągnąć ze strony scripting.dev.java.net rozszerzenia (dostępne w sekcji Documents & files) i dodać JAR dla języka którego potrzebujemy do classpath.

package org.code_house.samples.spring;

import java.util.Properties;

import org.springframework.beans.factory.BeanInitializationException;
import org.springframework.beans.factory.InitializingBean;

public class PropertiesConfiguration implements InitializingBean {

    /**
     * Ustawienia konfiguracyjne.
     */
    private Properties properties;

    public void setProperties(Properties props) {
        this.properties = props;
    }

    public void afterPropertiesSet() throws Exception {
        if (properties == null) {
            throw new BeanInitializationException("Nie przekazano ustawień "
                +"konfiguracyjnych. Pole properties jest wymagane.");
        }
    }
}

Spring nie wymusza jednak implementowania interfejsu. Jeśli nasz kod już istnieje i jest metoda która weryfikuje stan obiektu możemy użyć atrybutu init-method dla znacznika bean:

    <bean class="org.code_house.samples.xml.JaxbConfiguration"
        init-method="verify">
        <property name="source" value="classpath:data.xml" />
    </bean>

nazwa.wlasnosci wartosc
inna.nazwa.wlasnosci=costam
# to jest komentarz
jeszcze.cos.nowego

Jeśli chcemy przekazać obiekt klasy Properties do jakiegoś innego obiektu możemy skorzystać z poniższej wstawki w kontekście springa:

<bean class="org.springframework.beans.factory.config.PropertiesFactoryBean">
    <property name="location" value="classpath:corba.properties" />
</bean>

Najważniejsze elementy

Log4j ma kilka składowych:

• Appender
• Layout
• Category

Dzisiaj skupię się tylko na dwóch pierwszych. Appender jest odpowiedzialny za zapis bądź wysyłanie komunikatów do wybranego miejsca podczas gdy Layout konwertuje wpis do określonego formatu.

Z najciekawszych Appenderów wymienię

• RollingFileAppender rotuje logi do określonego rozmiaru, po osiągnięciu np 10mb kopiuje stary plik zgodnie ze schematem i zaczyna zapisywać do nowego.
• DailyRollingFileAppender zachowuje się podobnie jak wyżej wymieniony z tym, że umożliwia zapis z podziałem na lata, miesiące, dni czy nawet minuty.
• SyslogAppender, który wysyła komunikaty do Sysloga
• LF5Appender wyświetlający logi w okienku tworzonym przy pomocy Swinga.
• SMTPAppender wysyłający maile z komunikatami. Jeśli się go źle skonfiguruje gwarantowane zapchanie skrzynki ;-)
• NagiosAppender przesyłający komunikaty do Nagiosa, narzędzia służącego do monitorowania.

Mając już appender, który wie gdzie zapisywać wypada powiedzieć Log4j też co powinien zapisywać.

• HTMLLayout produkujący tabelę HTML
• PatternLayout posiadający możliwość określenia “szablonu” wpisu.

Więcej Layoutów można znaleźć w Javadocu Log4j.

Jako, że zdecydowanie najczęściej używa się PatternLayout dodam parę słów na temat tego co potrafi. We wzorze który będzie później użyty do stworzenia komunikatu możemy używać następujących wyrażeń:

• %c kategoria zdarzenia
• %C nazwa klasy z której zostało wysłane zdarzenie
• %d data zdarzenia (przykład: %d{HH:mm:ss,SSS} )
• %m komunikat wysłany z aplikacji
• %n separator lini
• %p priorytet zdarzenia
• %r ilość milisekund, które zdążyły upłynąć od startu aplikacji
• %t nazwa wątku z którego zostało wysłane zdarzenie
• %x kontekst diagnostyczny powiązany z wątkiem (wie ktokolwiek co to znaczy?)
• %% pojedynczy znak %
• %M nazwa metody z której zostało wysłane zdarzenie (uwaga, bardzo wolne)
• %L numer linii z której zdarzenie pochodzi (uwaga, bardzo wolne)
• %F nazwa pliku z którego pochodzi zdarzenie (uwaga, bardzo wolne)
• %l informacja o wywołującym zdarzenie (uwaga, bardzo wolne, wskazuje na lokalizację z naszego kodu)

Przykłady modyfikatorów:

• %20c dodaje spacje z lewej strony jeśli nazwa kategorii jest krótsza niż 20 znaków
• %-20c dodaje spacje z prawej strony jeśli nazwa kategorii jest krótsza niż 20 znaków
• %.30c przycina kategorię pozostawiając ostatnie 30 znaków
• %20.30c wypełnia z lewej strony nazwę kategorię spacjami do 20 znaków oraz przycina początkowe znaki jeżeli jest dłuższa on 30 znaków
• %-20.30c analogicznie jak wyżej, z tym że znaki zostaną dodane z prawej strony. Ze swojej strony polecam używanie formatu np %-20.20, co zagwarantuje że element będzie miał zawsze 20 znaków. Jeśli pozostawimy -20.30 to element będzie miał 20 znaków jeśli kategoria jest zbyt krótka a 30 gdy będzie za długa

Przykład konfiguracji

Log4j można konfigurować na kilka sposobów. Programowo, przez plik properties oraz konfigurację XML. Zdecydowanie najpopularniejszy jest plik properties. Jego użycie jest banalnie proste. Włączamy log4j.jar do tak by był on dostępny w classpathu, a następnie tworzymy plik log4j.properties, który domyślnie jest poszukiwany przez bibliotekę jeśli nie została przekazana żadna konfiguracja. Aby jednak to się stało nasz kod musi spróbować wysłać jakąś wiadomość do Log4j.

log4j.rootLogger DEBUG, out

# loggery
log4j.logger.org.springframework INFO
log4j.logger.org.apache.activemq INFO
log4j.logger.org.apache.activemq.spring WARN
log4j.logger.org.apache.servicemix DEBUG, stdout

#appendery
log4j.appender.stdout org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern %d{ABSOLUTE} | %-5p | %t | %c | %m%n

log4j.appender.out org.apache.log4j.DailyRollingFileAppender
log4j.appender.out.DatePattern ‘-’yyyy-MM-dd’.log’"/>
log4j.appender.out.layout org.apache.log4j.PatternLayout
log4j.appender.out.layout.ConversionPattern %d{ABSOLUTE} | %-5p | %t | %c | %m%n
log4j.appender.out.file E:/fuse-esb/data/log/servicemix

Założenie powyższej konfiguracji jest następujące. Domyślny poziom logowania jest ustawiony na DEBUG a komunikaty są zapisywane do pliku (rootLogger). Zdefiniowane są dwa appendery stdout oraz out. Pierwszy jest użyty tylko dla paczki org.apache.servicemix. Pozostałe loggery mają określony tylko poziom logowania. Pliki z logami będą dzielone na dni, także w lokalizacji E:/fuse-esb/data/log/ po 3 dniach działania od 13 do 15 października będziemy mieli 3 pliki:

• servicemix – logi z bierzącego dnia
• servicemix-2008.10.14.log – logi z 14 października
• servicemix-2008.10.13.log – logi z 13 października

Mam nadzieję że od dzisiaj Log4j będzie Wam drodzy czytelnicy mówił więcej i prościej. Jeśli są jakieś kwestie które pozostają niewyjaśnione – proszę pytać.

Do dnia 17 września, kiedy to SpringSource ogłosiło zmianę zasad – i poniekąd konieczność wykupywania subskrypcji. Wiadomość ta zaiste zelektryzowała społeczność.

Trudno poniekąd dziwić się zmianom w SpringSource ponieważ w czerwcu tego roku do grona właścicieli dołączyła kolejna spółka typu venture capital. Chyba podobnie tak jak w przypadku przejęcia BEA przez Oracle konieczne było odbicie sobie kosztów podnosząc ceny. Póki co Spring Application Platform nie ma wielkiego przebicia na rynku serwerów, ponieważ jest (chyba?) rozwiązaniem zbyt rewolucyjnym, na wsparcie wielu klientów się nie decydowało, szkolenia organizuje nie tylko SpringSource ale też cała masa innych firm, więc de-facto źródeł dochodów producent Springa nie miał wielu. Po prostu ilość użytkowników tego frameworka nie przekładała się w widoczny sposób na zasobność kiesy. Inwestorzy wykorzystując popularność narzędzia chcą skierować wielki strumień pieniędzy prosto do swojej kieszeni. Oczywiście pieniądze te nie będą przeznaczone tylko na honoraria ale również na dalszą ekspansję na rynku. Już teraz wiadomo, że Spring 3.0 będzie zgodny ze specyfikacją EJB 3.1, co zwiastuje koniec wojny EJB vs Spring. Pod w/w linkiem jest też kilka komentarzy na temat zmian:

To smutne, ale kończę wierzyć marzyć, pora spojrzeć na wszystko trzeźwo, standardy nie są złe, są oparte na idei Springa, dzięki Bogu.

Nie będę płacił myta za korzystanie z kontenera DI. Jeśli będię potrzebował portfolio SpringSource pomyślę czy zapłacić, ale żebym musiał płacić za sam kontener DI? Nie ma mowy, wolę poczekać na “STANDARD” EJB 3.1 albo przesiąść się na Guice czy nawet kontener DI z Tapestry 5

Jak ktoś już powiedział kontener DI Springa nie jest jakimś nadzwyczajnym wynalazkiem, może powinniśmy zacząć używać Guice bądź nadchodzącego EJB 3.1?

Pi** SpringSource!! TO wszystko co powiem. Jesteśmy społecznością i to my pomogliśmy wyrosnąć Spinrgowi a traz oni wbijają nam nóż w plecy. Witam EJB 3.1 jako standard i myślę, że powinienem zacząć poważnie myśleć o Seamie bądź innej alternatywie, może Guice? SpringSource tylko się pogrąża. Panie Rod, miałem Cię za naszego zbawiciela ale okazałeś się takim samym du*** jak wszystko w Open Source

Niestety, sterowany marketingiem szum (“the de facto standard in enterprise Java”) wokół Springa w końcu dobiegł końca. Świetnie!

Więcej opinii znajdziecie jeszcze na The Server Side: New Spring maintenance policy.

Moim skromnym zdaniem

Nie pisał bym o tym wszystkim gdybym nie miał na to własnego zdania. Oczywiście szkoda, że losy Springa teraz idą w kierunku niezbyt sprzyjającym dla większości z nas. Z drugiej jednak strony gwarancja łatania dziur w celu zapewnienia stabilności działania aplikacji produkcyjnych jest kusząca i odciąża developerów. Jakkolwiek nie ma tu już równowagi, ponieważ wg. nowych założeń albo płacisz i masz wszystkie poprawki albo nie płacisz i masz tylko główne wydania (major releases). Czy znajdzie się ktoś kto zacznie rozwijać alternatywę dla Springa?

Nie chodzi mi tu o sam kontener DI bo zdaję sobie doskonale sprawę z tego, że Spring już od bardzo dawna przestał być tylko nośnikiem DI. Masa modułów – wspierających pracę z bazami danych, zarządzanie transakcjami, moduły do JMS, web services, EJB czy nawet integracji. To wszystko miało swoich nabywców. Osobiście zmiana ta średnio mi odpowiada, ponieważ dosłownie zmusza do wykupienia wsparcia (wyobraża sobie ktoś korzystanie ze Springa tylko w wersjach 2.5, 2.0, 1.2, 1.1, 1.0?). W tej chwili nie ma żadnego zastępnika dla Springa i jego inwestorzy doskonale sobie z tego zdają sprawę. Po wejściu EJB 3.1 wszystko się rozmyje, a póki co jest bardzo dobra okazja do łowienia klientów.

Model licencjonowania w przypadku Service Mixa jest jasny – jest za darmo. Ma dokumentację jaką ma, ma dziury, są z nim oczywiście problemy, ale Iona na jego bazie dostarcza produkt i wsparcie do niego. Nikt nie ma obowiązku korzystania z usług Iony, w ogóle nie musi o jej istnieniu wiedzieć. Jeśli ktoś będzie potrzebował wsparcia to je i tak przecież kupi!

Różnicą i to znaczną są wyraźne ambicje SpringSource by walczyć o miano pretendenta na rynku serwerów z IBM i BEA. Problem w tym, że w tym momencie jest on pozbawiony silnego argumentu, jakim był kod Open Source, w obecnej formie jest to po prostu wypaczenie idei otwierania kodu. Społeczność zdaje się, że jest zniesmaczona, ale cóż zrobić.

Za jakość się płaci i nauczka jest taka że w przypadku Springa przychodzi nam płacić po znacznie dłuższym czasie.

Pierwszy z nich odpowiada za wczytanie wymaganych rozszerzeń CXFa oraz definicję bazowej konfiguracji fabryki z interceptorami. W interceptorach możemy skonfigurować logowanie, obsługę załączników czy standardów WS-Security etc. Wszystkie te ustawienia będą dziedziczone, a fabryki docelowych usług będą dodawać tylko adres, do odpytywania. Na koniec bean klienta będzie miał określony autowire by nie przekazywać mu wszystkich własności.

Oto najważniejsze wstawki kodu oraz ich opis:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <parent>
        <groupId>org.code-house.cxf</groupId>
        <artifactId>parent</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <groupId>org.code-house.cxf</groupId>
    <artifactId>client</artifactId>
    <version>1.0-SNAPSHOT</version>

    <name>Code House.Org - CXF - Client</name>

    <dependencies>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>1.2.12</version>
        </dependency>
        <dependency>
            <groupId>org.code-house.cxf</groupId>
            <artifactId>contract</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-frontend-jaxws</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-transports-http</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-transports-http-jetty</artifactId>
            <version>${code-house.cxf.version}</version>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>${code-house.spring.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
            <version>${code-house.spring.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-beans</artifactId>
                <version>${code-house.spring.version}</version>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-core</artifactId>
                <version>${code-house.spring.version}</version>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-context</artifactId>
                <version>${code-house.spring.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

</project>

Deskryptor nie jest zbyt złożony, istotny jest tylko kawałek z kontraktem, który jak wskazuje nazwa jest definicją używanych typów:

<dependency>
    <groupId>org.code-house.cxf</groupId>
    <artifactId>contract</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

Teraz kolej na jedyną wstawkę Javy, która się pojawia w projekcie. Jest to zwykły bean, który będzie miał później wstrzykiwane obiekty pośredniczące w wywoływaniu usług.

package org.code_house.cxf.client;

import org.code_house.services.maven.MavenArtifactType;

/**
 * Klient usług Code-House.
 *
 * @author Łukasz Dywicki <a href="splatch@code-house.org">email</a>
 *
 * $Id$
 */
public class Client {

    /**
     * Usługa do obsługi wyszukiwania artefaktów Mavena.
     */
    private MavenArtifactType maven;

    /**
     * Pobranie wartości pola maven.
     *
     * @return Wartość maven.
     */
    public MavenArtifactType getMaven() {
        return maven;
    }

    /**
     * Ustawienie wartości pola maven.
     *
     * @param maven Nowa wartość pola maven.
     */
    public void setMaven(MavenArtifactType maven) {
        this.maven = maven;
    }
}

Resztę magii załatwia Spring:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context.xsd

http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans.xsd

    ">
    <!--  Konfiguracja placeholderów (znaczy wstawek ${}) -->
    <context:property-placeholder location="classpath:client.properties" />

    <!-- Importy rzeczy koniecznych do pracy CXF -->
    <import resource="classpath:META-INF/cxf/cxf.xml" />
    <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
    <import resource="classpath:META-INF/cxf/cxf-extension-http-jetty.xml" />

    <!-- Konfiguracja poszczególnych usług wstrzykiwanych do klienta -->
    <import resource="classpath:services/*.xml" />

    <!-- Bean zawierający referencje do wygenerowanych klientów usług -->
    <bean id="client" class="org.code_.housecxf.client.Client" autowire="autodetect" />

    <!-- Bazowa konfiguracja fabryk - obiektów tworzących stuby klientów w runtime -->
    <bean id="baseClientFactory" abstract="true"
        class="org.apache.cxf.jaxws.JaxWsProxyFactoryBean">
       <property name="username" value="${org.code_house.cxf.user}" />
        <property name="password" value="${org.code_house.cxf.password}" />
        <property name="inInterceptors">
            <list>
                <ref bean="logIn" />
            </list>
        </property>
        <property name="outInterceptors">
            <list>
                <ref bean="logOut" />
            </list>
        </property>
    </bean>

    <!-- Loggery dla CXF -->
    <bean id="logIn" class="org.apache.cxf.interceptor.LoggingInInterceptor" />
    <bean id="logOut" class="org.apache.cxf.interceptor.LoggingOutInterceptor" />

</beans>

Zgodnie ze wstawką w linii 20 konieczna jest jeszcze konfiguracja usługi. Sztuczka polega na użyciu części konfiguracji zdefiniowanej wcześniej – baseClientFactory.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="

http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans.xsd

    ">

    <!-- Konfiguracja stuba dla usługi wyszukiwania artefaktów -->
    <bean id="mavenService" class="org.code_house.services.maven.MavenArtifactType"
        factory-bean="mavenServiceFactory" factory-method="create" />

    <!-- Fabryka usługi wyszukującej -->
    <bean id="mavenServiceFactory" parent="baseClientFactory">
        <!-- jedyne parametry jakich potrzebujemy -->
        <property name="serviceClass"
            value="org.code_house.services.maven.MavenArtifactType" />
        <property name="address" value="${org.code_house.cxf.service.maven}" />
    </bean>

</beans>

Ustawienia, które mogą ulec zmianie, to znaczy użytkownik, hasło oraz adres usługi są wyodrębnione do pliku client.properties:

# Placeholdery dla kontekstow springa
# Adresy uslug
server.port = 8080
host = localhost
org.code_house.cxf.service.maven http://${host}:${server.port}/webapp/services/maven

# Autoryzacja
org.code_house.cxf.user
org.code_house.cxf.password

No i na koniec opcjonalny test, który odpytuje usługę:

package org.code_house.cxf.client;
import org.code_house.services.maven.definition.ArtifactInfo;
import org.code_house.services.maven.types.FindArtifactRequest;
import org.code_house.services.maven.types.FindArtifactRespose;
import org.springframework.test.AbstractDependencyInjectionSpringContextTests;

/**
 * Proste wywołanie klasy klienta.
 *
 * @author Łukasz Dywicki <a href="ldywicki@pocztowy.pl">email</a>
 *
 * $Id$
 */
public class MainTest extends AbstractDependencyInjectionSpringContextTests {

    /**
     * Wstrzyknięty klient.
     */
    private Client client;

    @Override
    protected String[] getConfigLocations() {
        return new String[] {"classpath:client.xml"};
    }

    public void testOne() {
        FindArtifactRequest request = new FindArtifactRequest();
        ArtifactInfo artifact = new ArtifactInfo();
        artifact.setGroupId("org.code_house.cxf");
        artifact.setArtifactId("contract");
        request.setQuery(artifact);

        FindArtifactRespose respose = client.getMaven().findArtifact(request);
        System.out.println(respose.getDownloadURL());
    }

    /**
     * Ustawienie wartości pola client.
     *
     * @param client Nowa wartość pola client.
     */
    public void setClient(Client client) {
        this.client = client;
    }

}

To by było na tyle. Cały działający kod projektu jest już zamieszczony przy poprzedniej nocie, paczka ze wszystkimi listingami gotowa do pobrania.

Teraz chyba pora zacząć opisywać mechanizmy Springa. :)