Instalacja JavaFX 2.0

1. Pobieramy i instalujemy JavaFx SDK 2.0 wraz z JavaFx 2.0 Runtime
   http://www.oracle.com/technetwork/java/javafx/downloads/index.html
2. Pobieramy i instalujemy narzędzie Netbeans. Wersja Netbeans 7.1 Beta zawiera w sobie plugin do obsługi JavaFx 2.0. Jeśli chcemy używać starszej wersji Nebeans, musimy go sami zainstalować.
   http://dlc.sun.com.edgesuite.net/netbeans/7.1/beta/

Przykładowy program w JavaFX 2.0

Aby porównać JavaFx 2.0 z jej poprzednimi wersjami, stworzymy prosty kalkulator, który w JavaFx 1.3 został już opublikowany w naszym blogu.
Procedura zakładania nowego projektu nie zmieniła się.

1. Tworzymy nowy projekt JavaFX Application:
   
2. Uzupełniamy dane o projekcie i wybieramy Finish:
   

Deklaracja nowego okna w JavaFX 2.0 oraz JavaFX 1.3

• W JavaFX 1.3 deklaracja nowej sceny wyglądała następująco:

  1 2 3 4 5 6 7 8 9

  Stage {     title: "JavaFX quick calculator!"     scene: Scene {         width: 130         height: 150         content: [         ] //Zawartość Sceny     } }

• W nowej JavaFX 2.0 deklaracja ta wygląda zupełnie inaczej:

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

  public class Calculator extends Application {         public static void main(String[] args) {         Application.launch(args);     }         @Override     public void start(Stage primaryStage) {         primaryStage.setTitle("Calculator");         Scene scene = new Scene(?zawartość?, 130, 150);         primaryStage.setScene(scene);         primaryStage.show();     } }

A oto deklaracja przykładowych elementów projektu „Kalkulator”:

• JavaFX 1.3:

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

  TextBox{                 layoutX:2;                 layoutY:2;                 height:20;                 width:120;                 text: bind currResult.toString();                 editable:false;             } Button{                 layoutX:2;                 layoutY:25;                 text:"1";                 width:20;                 height:20;                 onMouseClicked:function (e:MouseEvent){                         if(not funcDefined){                            firstElem=firstElem*10+1;                            currResult=firstElem;                         }else{                            secondElem=secondElem*10+1;                         }                 }             }

• JavaFX 2.0:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

  TextField ekran = new TextField();  ekran.setEditable(false);  ekran.setPrefSize(120, 20); Button przycisk = new Button("0"); przycisk.setPrefSize(30,30); przycisk.setOnAction(new EventHandler() {                 @Override public void handle(ActionEvent e) {                                         if(functionset){                         secondnumber=secondnumber*10;                         ekran.setText(secondnumber.toString());                     }                     else{                         firstnumber=firstnumber*10;                         ekran.setText(firstnumber.toString());                     }                 }             });

Kalkulator

Projekt Kalkulatora możemy pobrać tutaj.

Podsumowanie

• JavaFX 2.0 nie wymaga od programistów zagłębiania wiedzy o nowym języku skryptowym, jak miało to miejsce w JavaFX 1.3. Programiści języka Java z powodzeniem mogą wykorzystać swoje umiejętności oraz narzędzia do tworzenia aplikacji w JavaFX 2.0.
• Wszystkie aplikacje stworzone w JavaFX 2.0 zachowują się tak samo w różnych środowiskach.
• Możliwość wykorzystania wszystkich istniejących bibliotek JAVA.
• Istniejące aplikacje SWING mogą być w prosty sposób aktualizowane z użyciem JavaFX 2.0.
• JavaFX jest instalowana wraz z Java Runtime Environment, co umożliwia uruchomienie aplikacji na prawie wszystkich komputerach.
• JavaFX dostarcza wszystkie najważniejsze kontrolki UI oraz umożliwia dostosowanie ich wyglądu z wykorzystaniem CSS.

Źródła

• http://blog.atena.pl/wprawki-w-javafx JavaFX 1.3
• http://download.oracle.com/javafx/index.html Dokumentacja JavaFX 2.0

Na początek przykładowa aplikacja

Na potrzeby testów stwórzmy sobie prościutką aplikację i umieśćmy ją na JBossie.

Najprościej będzie użyć do tego celu mechanizmu archetypów Mavena:

mvn archetype:generate
wybierzmy webapp-jee5
wybierzmy wersję 1.0
wskażmy groupId – np. pl.atena
wskażmy artifactId – np. ldap-integration
wskażmy version – np. 1.0-SNAPSHOT
wskażmy pakiet – np. pl.atena.ldap

Po zatwierdzeniu powinniśmy mieć gotowy do deployu projekt.

Wystarczy go zbudować

mvn clean package

i skopiować do katalogu JBOSS/server/default/deploy

Po uruchomieniu serwera i wejściu na stronę http://localhost:8080/ldap-integration powinniśmy zobaczyć „Hello World”.

Konfiguracja modułu uwierzytelniania w JBossie

Kolejnym krokiem będzie konfiguracja uwierzytelniania w JBossie. W tym celu edytujemy plik JBOSS/Server/default/login-config.xml i dodajemy w nim nową politykę bezpieczeństwa, którą nazwiemy ldap:

<application-policy name="ldap">
  <authentication>
    <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required" >
      <module-option>ldap://serwerLdap:389</module-option>
      <module-option>ATENA\ldapUser</module-option>
      <module-option>password</module-option>

      <module-option name="baseCtxDN">CN=Users,DC=companyName,DC=com</module-option>
      <module-option name="baseFilter">(sAMAccountName={0})</module-option>

      <module-option>OU=Groups,DC=companyName,DC=com</module-option>
      <module-option name="matchOnUserDN">true</module-option>
      <module-option name="uidAttributeID">member</module-option>
      <module-option name="roleFilter">(member={1})</module-option>
      <module-option name="roleAttributeID">CN</module-option>

      <module-option name="roleRecursion">2</module-option>
      <module-option name="searchScope">SUBTREE_SCOPE</module-option>

      <module-option name="allowEmptyPasswords">false</module-option>
    </login-module>
  </authentication>
</application-policy>

Wyjaśnienie najważniejszych parametrów:

• login-module – wskazanie modułu uwierzytelniania – dla samego uwierzytelniania możemy użyć LdapLoginModule; jeśli chcemy użyć również autoryzacji opartej o LDAP musimy użyć LdapExtLoginModule
• java.naming.provider.url – namiary na kontroler domeny
• bindDN – nazwa użytkownika z uprawnieniami do wykonywania zapytań w LDAPie
• bindCredential – hasło użytkownika
• baseCtxDN – ścieżka do wyszukiwania użytkownika
• baseFilter – filtr służący do wyszukania uwierzytelnianego użytkownika
• rolesCtxDN – ścieżka do wyszukiwania roli
• roleFilter – filtr służący do wyszukania roli użytkownika
• roleAttributeID – wskazanie na miejsce w ścieżce gdzie będzie nazwa roli
• roleRecursion – głębokość wyszukiwania roli
• searchScope – zasięg wyszukiwania (OBJECT_SCOPE, ONELEVEL_SCOPE, SUBTREE_SCOPE)
• allowEmptyPasswords – flaga wskazująca, czy puste hasła powinny być przekazywane do serwera LDAPa (niektóre serwery LDAP traktują puste hasło jako zalogowanie anonimowe)

Pełna lista parametrów dla modułu LdapExtLoginModeule dostępna jest pod adresem:

http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/4.2/html/Server_Configuration_Guide/Using_JBoss_Login_Modules-LdapExtLoginModule.html

Podpięcie uwierzytelniania do aplikacji

Ostatnim krokiem jest podpięcie dodanej polityki do naszej aplikacji i zabezpieczenie dostępu do pewnych zasobów w aplikacji. W tym celu dodajemy w katalogu src/main/webapp/WEB-INF/ plik jboss-web.xml o następującej treści:

<jboss-web>
  <security-domain>java:/jaas/ldap</security-domain>
</jboss-web>

Następnie zabezpieczamy dostęp do aplikacji w pliku web.xml:

<web-app>
  <display-name>Archetype Created Web Application</display-name>
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>LDAP Restricted Zone</web-resource-name>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>administrator</role-name>
    </auth-constraint>
    </security-constraint>
    <login-config>
      <auth-method>BASIC</auth-method>
      <realm-name>LDAP Restricted Zone</realm-name>
    </login-config>
    <security-role>
      <role-name>administrator</role-name>
    </security-role>
</web-app>

Gdy ponownie wejdziemy na stronę naszej aplikacji (http://localhost:8080/ldap-integration) powinniśmy zostać zapytani o login i hasło użytkownika. Po podaniu domenowego loginu i hasła powinniśmy ponownie zobaczyć nasze ‘Hello World’ – pod warunkiem, że jesteśmy w LDAPie przypisani do grupy administrator.

Rozproszona kontrola wersji jest zorganizowana w zupełnie inny sposób. Repozytoriów jest tyle ilu członków zespołu. Każdy z nich lokalnie posiada pełne źródła projektu wraz z historią zmian. Wszystkie repozytoria są równe – żadne z nich nie jest w żaden sposób wyróżnione. To, z którego repozytorium na przykład zbudujemy wersję jest sprawą czysto umowną.

Rozpoczęcie pracy z projektem wiąże się ze stworzeniem nowej kopii projektu przez sklonowanie wybranego istniejącego repozytorium. Dalsza praca może odbywać się lokalnie. W wybranych momentach następuje scalanie zmian dokonywanych przez różnych członków zespołu.

Co zyskujemy dzięki rozproszeniu?

Przede wszystkim pracujemy lokalnie – tworzymy branche wtedy kiedy my ich potrzebujemy, nazywamy je tak jak chcemy (nie ma konfliktów nazw często spotykanych w repozytoriach centralnych), commitujemy zmiany kiedy uznamy jakąś część pracy za wykonaną. Pomimo pracy lokalnej jesteśmy cały czas pod kontrolą wersji – możemy zarządzać nawet małymi lokalnymi zmianami, które potencjalnie mogą zawierać błędy.

Zarządzamy zmianami a nie wersjami. Wbrew pozorom to bardzo duża zmiana w podejściu do zarządzania kodem – zamiast zastanawiać się jak uaktualnić jedną wersję tak, żeby była taka sama jak inna – zarządzamy zmianami – mówimy więc ‘daj mi swój zestaw zmian’. Przy takim podejściu mergowanie zmian staje się codziennością w związku z czym musi być wydajne i bezproblemowe i takie właśnie jest. Dzięki temu pośrednio zyskujemy też silne wsparcie dla nieliniowego rozwoju projektu.

Kompletny projekt wraz z historią zmian istnieje w wielu miejscach. Podczas zakładania (klonowania) projektu dostajemy pełną kopię repozytorium (wraz z historią zmian). Dzięki temu nie mamy jednego newralgicznego punktu, ale te same źródła w wielu miejscach.

Systemy rozproszonego zarządzania wersjami

Na rynku istnieje kilka systemów DVCS (Distributed Version Control System). Do głównych należą darmowe Mercurial, Bazaar, Git oraz komercyjny BitKeeper. Nie ma dużych różnic projektowych pomiędzy nimi (być może poza sposobem synchronizacji), są za to znaczące różnice w implementacji, które wpływają na wydajność i komfort pracy. Ciekawostką jest to, ze Bazaar może pracować zarówno jako repozytorium rozproszone jak i w modelu z centralnym repozytorium.

Ze względu na rosnącą popularność Git’a proponuję pouczyć się co to jest DVCS na jego przykładzie.

Git

Git jest szybkim rozproszonym systemem kontroli wersji dostępnym na licencji open source. Został zaprojektowany i pierwotnie stworzony przez Linusa Torvaldsa na potrzeby zarządzania źródłami jądra Linuxa.

Wśród głównych cech Git’a autorzy wymieniają to, że jest systemem rozproszonym, wspiera nieliniowy development, jest wydajny w dużych projektach oraz zapewnia spójność repozytorium przez zastosowanie algorytmów szyfrujących (SHA1).

Instalacja

Większość systemów linuxowych ma już gita w swoich repozytoriach pakietów (git-core). Wersję zbudowaną lub źródła można pobrać ze strony projektu (http://git-scm.com/download). Instalacja jest prosta i nie powinna przysporzyć problemów.

Po zainstalowaniu Git jest gotowy do zarządzania naszym kodem.

Jedyne co powinniśmy ustawić, to swoją nazwę użytkownika i e-mail:

git config --global user.name Michal Laguna
git config --global user.email michal.laguna@atena.pl

Utworzenie repozytorium

Po założeniu katalogu z projektem wykonujemy polecenie git init. Spowoduje to utworzenie repozytorium – w katalogu z projektem powinien powstać katalog .git.

$git init
Initialized empty Git repository in /home/atena/repo1/.git

Za pomocą polecenia git status możemy sprawdzić aktualny stan naszego repozytorium. Powinniśmy dostać odpowiedź podobną do tej:

$git status
# On branch master
nothing to commit (working directory clean)

Dodanie/zmiana plików

Pliki dodajemy i zmieniamy w repozytorium za pomocą polecenia add:

$git add.
$git status
# On branch master
# Changes to be commited:
…
# new file: test1.txt

Zatwierdzenie zmian

Wprowadzone zmiany zatwierdzamy za pomocą polecenia commit (uwaga: commit zatwierdza zmiany tylko w lokalnym repozytorium):

$git commit –m ‘Poprawa bledu Abcd1234’
1 files changed, 1 insertion(+), 0 deletion(-)
create mode 100644 test1.txt

Historia zmian

W dowolnej chwili można podejrzeć historię zmian za pomocą polecenia log:

$git log

Możemy podejrzeć również listę różnic:

$git log –p

Branchowanie i mergowanie

Stworzenie brancha jest tak proste jak wykonanie instrukcji git branch [nazwa brancha]. Żeby przełączyć się na brancha wykonujemy polecenie git checkout [nazwa brancha].

$git branch xyz123
$git checkout xyz123
Switched to branch ‘xyz123’

W dowolnej chwili możemy sprawdzić w jakim branchu aktualnie się znajdujemy (ten oznaczony gwiazdką):

$git branch
master
* xyz123

Dokonajmy teraz zmiany w naszym branchu xyz123 i dodajmy zmianę do brancha:

$git add –m ‘Zmiana w branchu’
$git commit

Powyższe dwie instrukcje możemy też zastąpić pojedynczą:

$git commit –a –m ‘Zmiana w branchu’

Po przejściu z powrotem do brancha głównego widzimy, że nie ma w nim wprowadzonych zmian:

$git checkout master
$git log

Możemy teraz dociągnąć zmiany za pomocą polecenia merge:

$git merge xyz123

Na koniec możemy podejrzeć drzewko zmian w narzędziu gitk

$gitk

I usunąć gałąź xyz123

$git branch –d xyz123

Tagowanie

Założenie taga to wykonanie polecenia Tag:

$git tag 0.1.15

Lista tagów:

$git tag -l

Następnie możemy stworzyć brancha z dowolnego taga:

$git branch stable 0.1.15

Praca w zespole

Jak już wiemy w pracy z rozproszonym systemem kontroli wersji wszystkie repozytoria są równe, a wskazanie repozytorium, z którego na przykład budujemy wersję lub uruchamiany testy jest tylko kwestią umowy.

Załóżmy, że pracujemy w dwuosobowym zespole (user1, user2). User2 tworzy swoje lokalne repozytorium przez sklonowanie repozytorium należącego do user1:

$git clone git-repo-user1 git-repo-user2
Cloning into git-repo-user2…
done.

Następnie user2 edytuje lokalnie jakieś pliki umieszcza je w swoim repozytorium:

cd git-repo-user2
git commit –a –m ‘Zmiany user2’

Gdy skończy może powiadomić usera1 o możliwości zaciągnięcia zmian – wtedy user1 może dociągnąć zmiany z repozytorium usera2 za pomocą polecenia pull:

$git pull /home/atena/git-repo-user2 master

Polecenie pull powoduje pobranie zmian ze wskazanego repozytorium i zmergowanie ich z naszym kodem (fetch + merge). Wskazane jest zacommitowanie wszystkich lokalnych zmian przed wykonaniem operacji pull – pozwoli to na bezproblemowe przeprowadzenie merge’a.

Istnieje możliwość ściągnięcia zmian z innego repozytorium bez ich mergowania – służy do tego polecenie fetch:

$git fetch /home/atena/git-repo-user2 master
$git log –p HEAD..FETCH_HEAD
$git merge FETCH_HEAD

Dla ułatwienia pracy można nadać alias zdalnemu repozytorium, z którym pracujemy:

$git remote add user2 /home/atena/git-repo-user2

Z poziomu swojego repozytorium możemy też ‘wepchać’ zmiany do repozytorium zdalnego – praca z Gitem przypomina wtedy pracę z repozytorium centralnym. Służy do tego polecenie push:

$git push user2 master

Co ważne – Git domyślnie nie pozwoli na wepchnięcie zmian do zdalnego repozytorium jeśli wskazany branch został w nim zacheckoutowany. Dostaniemy wtedy taki komunikat:

error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.

Możemy wtedy zrobić dwie rzeczy – albo w zdalnym repozytorium przejść (checkout) na inny branch lub przekształcić zdalne repozytorium w repozytorium centralne (bare), czyli takie, które zawiera jedynie katalog .git i nie zawiera żadnych zacheckoutowanych plików

git config --bool core.bare true

Rebase

Niniejszy artykuł jest jedynie wprowadzeniem do zagadnienia rozproszonego kontrolowania źródeł, ale ponieważ za przykład wzięliśmy Git’a nie sposób nie wspomnieć o jeszcze jednej bardzo wartościowej i silnej funkcjonalności którą dostarcza – rebase.

Rebase to w uproszczeniu przesunięcie miejsca utworzenia brancha. Załóżmy, że mamy w projekcie branch główny oraz jakiś dodatkowy z funkcjonalnością przygotowywaną dla konkretnego klienta. Jeśli chcemy aby branch dedykowany dla klienta zawierał wszystkie zmiany wrzucane do brancha głównego musimy dokonywać merge’y.

Git daje nam możliwość wykonania operacji rebase, która spowoduje przesunięcie miejsca utworzenia brancha:

$git checkout clientX_branch
$git rebase origin

Po takiej operacji Git zapisze wszystkie commity od momentu utworzenia brancha jako patche w katalogu .git/rebase, zaktualizuje brancha tak, żeby wskazywał aktualną wersję w branchu głównym i na koniec zaaplikuje odłożone patche. Dzięki temu historia zmian będzie serią commitów bez merge’y.

Podsumowanie

Rozproszone systemy zarządzania wersjami moim zdaniem w pewnym sensie definiują na nowo podejście do zarządzania kodem źródłowym. Skupienie się na zmianach zamiast na wersjach rozwiązało bardzo wiele problemów spotykanych w pracy z SVN’em czy CVS’em – branchowanie i mergowanie staje się standardowym elementem prowadzenia developmentu, a dzięki rozproszeniu repozytorium towarzyszy nam od pierwszej linijki kodu.

Z drugiej strony rozproszone systemy repozytorium kodu nie są żadną nowością, a moim zdaniem wciąż nie zyskały bardzo dużej popularności w projektach komercyjnych. Wydaje mi się, że z punktu widzenia firmy rozproszenie repozytorium nie jest czymś niezbędnym – najczęściej przecież i tak potrzebujemy repozytorium centralnego, z którego automatycznie budujemy aktualną wersję i na przykład puszczamy testy jednostkowe. Tworzenie oprogramowania w firmie jest zazwyczaj prowadzone w sposób bardziej usystematyzowany niż w projektach tworzonych przez otwartą społeczność. Zakłada się, że wszyscy deweloperzy wykonują przydzielone zadania i wyniki ich pracy będą musiały się znaleźć w wersji. Czasem może nawet nie chcemy, żeby szeregowy developer mógł pobrać projekt wraz z kilkuletnią historią jego rozwoju.
Pewnym problemem może być też wsparcie systemu kontroli wersji przez IDE. SVN czy CVS jest wszechobecny – większość narzędzi do projektowania i wytwarzania aplikacji bez względu na język programowania czy modelowania ma albo natywną obsługę albo przynajmniej wtyczki do obsługi najpopularniejszych systemów kontroli wersji. Niestety żaden z rozproszonych systemów kontroli wersji nie należy jeszcze do tych najpopularniejszych.

Jeśli chodzi o Git’a to jest bez wątpienia bardzo silnym narzędziem. Na dzień dzisiejszy wydaje się być dopracowanym projektem gotowym do użycia w komercyjnym projekcie. Nie jest jednak jedynym DVCS’em – moim zdaniem przed rozpoczęciem projektu warto rozpoznać konkurencję pod kątem naszych konkretnych potrzeb (np. chociażby pluginów do wybranych IDE).

Gdzie ja mam wrzucić te pliki?

Ta wielka zaleta potrafi jednak obrócić się przeciwko nam. Ponieważ to projektanci i programiści definiują strukturę projektu i sposób budowania aplikacji trudno jest znaleźć dwa takie same projekty. Każdy, kto pracował w kilku projektach javowych, szczególnie wytwarzanych w ramach różnych zespołów prawdopodobnie spotkał się z opisywaną sytuacją. Wydaje mi się, że taki brak „szablonu projektu” może być problematyczny szczególnie dla młodszych programistów, którzy – przechodząc z projektu do projektu – mogą czuć się zagubieni.

Wsparcie – Maven

Z pomocą przychodzi Maven, czyli narzędzie do zarządzania projektem Javowym. Osobiście uważam Mavena za jeden z najbardziej przełomowych ‘wynalazków’ świata Javowego.

Maven zrodził się z potrzeby zdefiniowania standardowej struktury projektu, standardowego sposobu budowania aplikacji oraz sposobu definiowania zależności pomiędzy modułami projektu. Dzięki tej standaryzacji przejście pomiędzy projektami opartymi o Mavena jest wręcz przezroczyste – możemy skupić się na biznesowych problemach zamiast zastanawiać się nad tym jak to wszystko zbudować i skąd wziąć oraz gdzie wrzucić kolejnego JARka.

Budowanie oprogramowania przy użyciu Mavena oparte jest o cele. Każde wołanie powinno zakończyć osiągnięciem konkretnego celu. Może być nim np. kompilacja (compile), zbudowanie paczki (package) czy przeprowadzenie testów jednostkowych (test). Dostępne cele są określane przez wtyczki rozszerzające funkcjonalność Mavena. Konkretne cele mogą wymagać wykonania wcześniej jakiegoś innego celu (np. package musi być poprzedzony compile).

Projekt mavenowy definiuje się poprzez stworzenie i utrzymywanie pliku pom.xml (POM – ang. Project Object Model). Pom.xml jest głównym miejscem pracy z projektem i zawiera wszystkie istotne elementy definiujące projekt, jego strukturę, sposób budowania i przede wszystkim zależności.

Mavena można pobrać ze strony projektu http://maven.apache.org/download.html – nie wymaga on tak naprawdę żadnej instalacji – po rozpakowaniu należy jedynie ustawić zmienne środowiskowe: M2_HOME (wskazanie na katalog, do którego rozpakowaliśmy mavena), M2 (wskazanie na katalog [M2_HOME]/bin) i dodać katalog bin do zmiennej PATH (wskazanie na [M2_HOME]/bin).

Struktura projektu

Typowy projekt mavenowy ma strukturę taką, jak na poniższym diagramie:

atena-app
|-- pom.xml
`-- src
    |-- main
    |   `-- java
    |       `-- pl
    |           `-- atena
    |               `-- app
    |                   `-- AtenaApp.java
    |   `-- resources
    |       `--META-INF
    |          `--application.properties
    `-- test
        `-- java
            `-- pl
                `-- atena
                    `-- app
                        `-- AtenaAppTest.java

Sam plik pom.xml może wyglądać tak jak w poniższym fragmencie kodu:

<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/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>pl.atena</groupId>
  <artifactId>atena-app</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>Maven Quick Start Archetype</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Jest to bardzo prosty podstawowy plik pom.xml. Poniżej krótki opis poszczególnych sekcji pom’a:

• groupId - twórcę (pl.atena),
• artifactId - nazwę aplikacji (atena-app),
• packaging - sposób pakowania (jar, war, ear),
• version - wersję,
• name - nazwę wyświetlaną
• url - link do strony projektu
• dependecies – zależności od innych modułów

Zakładanie i definiowanie projektu

Projekt możemy zdefiniować ręcznie poprzez utworzenie wymaganej struktury katalogów oraz stworzenie pliku pom.xml. Nie ma tutaj żadnej magii – tak przygotowany projekt jest w pełni poprawnym projektem mavenowym. Takie tworzenie nie jest jednak zbyt przyjemne.

Z pomocą przychodzi mechanizm archetypów (a ściślej mówiąc plugin archetype), czyli tzw. szablony projektów. Poprzez wywołanie poniższej linii stworzymy kompletną strukturę prostego projektu wraz z podstawowym plikiem pom.xml:

mvn archetype:generate -DgroupId=pl.atena -DartifactId=atena-app
-DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

Powyższa linia oznacza: wywołaj cel ‘generate’ z pluginu ‘archetype’ i stwórz projekt pl.atena.atena-app na podstawie szablonu maven-archetype-quickstart. W wyniku pracy mavena powinniśmy otrzymać katalog z projektem i prosty pom.xml.

Istnieje bardzo dużo gotowych szablonów, dzięki czemu możemy na przykład przez wywołanie takiego prostego polecenia stworzyć kompilujący się i gotowy do deployu projekt aplikacji webowej zgodny z JEE6.

Budowanie projektu

Jak już wcześniej wspominałem budowanie projektu to wykonywanie określonych celi. Jeśli chcemy np. skompilować projekt wykonujemy polecenie mvn compile z poziomu katalogu głównego projektu (czyli tam gdzie jest umieszczony plik pom.xml).

Możemy wykonać kilka celi po kolei – np.: mvn clean package spowoduje wyczyszczenie wyników wcześniejszych buildów i spakowanie od nowa projektu (poprzedzone kompilacją, gdyż package wywołuje najpierw compile).

Cykl życia projektu

Maven definiuje coś co nazywa się cykle życia projektu. Jest to zestaw standardowych najważniejszych z punktu widzenia aplikacji, bardzo precyzyjnie zdefiniowanych i wykonywanych w określonej kolejności faz. Błąd na dowolnym etapie zatrzymuje wykonywanie kolejnych faz w cyklu. Maven definiuje trzy cykle życia: default, clean i site.

Fazy domyślnego (default) cyklu życia:

• validate - sprawdza poprawność projektu;
• compile - kompiluje kod źródłowy;
• test - wykonuje testy jednostkowe;
• package - pakuje skompilowany kod w paczki dystrybucyjne (np. Jar, war);
• integration-test – deployuje paczkę w środowisku testów integracyjnych;
• verify - sprawdza poprawność paczki;
• install - umieszcza paczkę w lokalnym repozytorium aby mogła być używana przez inne moduły;
• deploy - umieszcza (publikuje) paczkę w zdalnym repozytorium.

Cykl życia clean czyści wynik działania wcześniejszych buildów.

Cykl życia site generuje dokumentację projektu.

Powyżej opisane fazy są tak naprawdę mapowane na konkretne cele. Na przykład package w przypadku projektu typu jar wywoła jar:jar, a w przypadku projektu typu war war:war.

Pluginy

Funkcjonalność Mavena może być rozszerzana przez pluginy. Wywoływanie celów zdefiniowanych w pluginach odbywa się poprzez wywołanie polecenia mvn [plugin]:[goal], gdzie plugin to nazwa wtyczki, a goal to wywoływany cel.

Użyliśmy tej konstrukcji tworząc projekt z szablonu (mvn archetype:generate).

Samo dodanie plugina do projektu odbywa się poprzez dodanie odpowiedniej definicji w pliku pom.xml. Taka zależność może wyglądać jak poniżej:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>2.0.2</version>
      <configuration>
        <source>1.5</source>
        <target>1.5</target>
      </configuration>
    </plugin>
  </plugins>
</build>

Zależności

Zarządzanie zależnościami bywa trudne nawet w małym projekcie, a w projekcie dużym i złożonym bywa zadaniem bardzo wyczerpującym.

Prawdopodobnie każdy z nas niejednokrotnie wyszukiwał w google’u jakichś JARków i próbował je ściągać z przypadkowych stron. Ponadto pracując w projekcie złożonym z kilku modułów bardzo często napotykamy problem dostarczania coraz to nowszej wersji modułu do innego obszaru projektu. W tych problemach z pomocą ponownie przychodzi Maven. Zarządzanie zależnościami jest chyba tym z czego Maven tak naprawdę słynie najbardziej.

Dodanie zależności sprowadza się do dodanie elementu dependency w pliku pom.xml. W elemencie dependency wkazujemy dostawcę (groupId), nazwę modułu (artifactId), wersję (version) i zasięg (scope). Maven podczas budowania automatycznie pobierze z repozytorium moduł od którego zależność zdefiniowaliśmy (wcześniej może być konieczne zdefiniowanie dodatkowych repozytorium).

Przykładowa definicja zależności:

<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    ……
  </dependencies>

Zależności przechodnie

Zależności przechodnie oszczędzają nam pracy związanej z odkrywaniem od czego jeszcze musimy zależeć w związku ze zdefiniowaniem zależności od jakiegoś modułu. Jeśli nasz moduł A zależy od modułu B, a moduł B zależy od kolejnych modułów to te końcowe zależności zostaną automatycznie dołączone do naszego projektu.

Istotnym elementem definiowania zależności jest określenie zasięgu (scope). Może mieć on jedną z poniższych wartości:

• compile - domyślny zasięg – zależności o zasięgu kompilacji są dostępne we wszystkich fazach (kompilacji, uruchomienia) projektu i są propagowane do projektów zależących od mojego projektu.
• provided - zasięg zbliżony do compile z tą różnicą, że zakładamy dostępność tych bibliotek w runtime. Przykładem dla użycia provided może być Servlet API – potrzebujemy go do kompilacji, ale w runtime będzie udostępniony przez kontener.
• runtime - zasięg zakłada, że biblioteka nie jest potrzebna do kompilacji, ale tylko do uruchomienia (runtime i test).
• test - zasięg wskazuje, że biblioteka nie jest wymagana do normalnej pracy aplikacji i jest potrzebna jedynie w fazie testów.
• system - zasięg zbliżony do provided z tą różnicą, że jawnie wskazujemy jara zawierającego bibliotekę.
• import (dostęny od Mavena 2.0.9) – zasięg dostępny jedynie dla zależności typu pom – wskazuje Mavenowi, że chcemy dołożyć do naszego projektu zależności zdefiniowane w innym projekcie.

Integracja z IDE

Korzystanie z Mavena tylko z linii poleceń może być uciążliwe, ale oczywiście nie jest to konieczne. Istnieją oficjalne pluginy do Eclipse’a i Netbeans’a. Szczególnie polecanym pluginem do Eclipse’a jest m2eclipse – jest to najstarszy i najdojrzalszy plugin i działa bardzo poprawnie.

Więcej o pluginach do Eclipse’a można znaleźć na stronie http://maven.apache.org/eclipse-plugin.html, a o pluginach o Netbeans’a na http://maven.apache.org/netbeans-module.html. InteliJ wspiera mavena natywnie.

Podsumowanie

Powyższy artykuł jest tak naprawdę tylko wstępem, który mam nadzieję choć trochę przybliży Mavena i zachęci do zagłębienia się w temat. Maven daje wiele więcej – udostępnia mechanizmy dziedziczenia i agregacji pom’ów, pozwala na tworzenie własnych artefaktów, może być rozszerzany o wtyczki wspierające deployment komponentów na różnych serwerach aplikacyjnych … i wciąż się rozwija.

Opis prezentacji

Podczas prezentacji Łukasz Korzeniowski skupił się na porównaniu czasu pisania aplikacji na różne platformy telefonów komórkowych oraz podsumowaniu co zaskoczyło twórców i z czym mieli największe problemy. Przedstawił także obecne trendy i przyszłe prognozy popularności telefonów. Nie zostały poruszone szczegółowe różnice platform w oferowanych możliwościach. Wszystkie wnioski, jakie zostały przekazane przez prowadzącego, pochodzą z realnego projektu Pakk wykonanego na zlecenie węgierskiego klienta Vodafone. Ważne jest też, że do każdego typu telefonu został przydzielony programista z doświadczeniem w pracy z daną platformą.

Obecne dane

Oto, jak przedstawia się procentowy udział platformy na rynku urządzeń mobilnych za pierwszy kwartał 2011 roku:

Według danych od Vodafhone wśród czołowych czterdziestu modeli telefonów występują:

• Java: 42%

• Symbian: 26%

• Android: 32%

Podsumowanie platform

Java

Zalety

• Stosunkowo krótki czas wytworzenia

• Powszechny język programowania

Problemy:

• API nie działające zgodnie ze specyfikacją
• rozmiar aplikacji
• zróżnicowanie wielkości ekranu
• zróżnicowanie możliwości przeglądarki
• różna reprezentacja obiektów (np. kontakt)
• wysoki koszt testów
• problem z konfiguracją APN (Nokia) oraz uprawnień aplikacji – negatywny wpływ na wrażenia użytkownika!!!

Android

Zalety:

• wielozadaniowy system operacyjny – można więcej
• duża swoboda aplikacji (szeroki dostęp do systemu)
• popularny język programowania
• szybkość tworzenia aplikacji
• automatyczna dostępność aplikacji na tablety

Problemy:

• różnice w zachowaniu API na różnych modelach telefonów (raczej incydentalne)
• pewne nienaruszalne założenia (np. sposób instalacji aplikacji) – ograniczenie możliwości
• nie najlepsza dokumentacja

Symbian

Zalety:

• API pozwalające na dostęp do każdego elementu systemu
• w nowych telefonach możliwość tworzenia aplikacji w Qt

Problemy:

• dużo wyższa pracochłonność niż na innych platformach (bez użycia Qt)
• archaiczny język i środowisko programistyczne
• ukryte API
• skomplikowany system podpisów
• „sztuczki i kruczki” zarówno w systemie jak i w środowisku
• zróżnicowanie między wersjami Symbiana
• zróżnicowanie między urządzeniami

iPhone

Zalety:

• niewielka liczba urządzeń i wersji systemu
• szybki development
• „błyszczący” interfejs użytkownika
• automatyczna dostępność aplikacji dla iPad

Wady:

• nietypowy język programowania
• konieczność posiadania sprzętu Apple
• ograniczone API do dostępu do elementów systemu (np. skrzynka SMS)

Czas napisania aplikacji

Wnioski

Ważne jest, aby podczas podpisywania umowy ograniczyć ilość telefonów docelowych na których zapewniamy poprawność naszej aplikacji. Mnogość modeli na rynku może znacząco wpłynąć na ryzyko przekroczenia budżetu i czasu naszego projektu. Należy testować aplikację na konkretnych telefonach, a nie tylko symulatorach, co również pozwoli skrócić czas wykrycia nieprawidłowości w działaniu aplikacji.
W związku z popularyzacją smartphonów i osłabianiem się pozycji Symbiana na rynku, powinno się w miarę możliwości zrezygnować z supportu dla tej drugiej platformy. Po za tym sprawił on najwięcej problemów w projekcie i zajął najwięcej czasu. W przypadku iPhona powinno się zastanowić, na ile nasza aplikacja może być popularna na iStore, gdyż w przypadku napisania pierwszej koszty wejścia na ten rynek, są dość wysoki. Niestety niezbędny jest zakup: iPhone, iMac i licencji developerskiej pozwalającej na publikowanie aplikacji w iStore. Kolejną rzeczą, która wymaga zastanowienia , jest fakt, że w powyższym przedsięwzięciu nie używano praktycznie żadnego współdzielenia kodu między platformami. Rozwiązaniem tego problemu może być użycie jednego z frameworków:

• LWUIT -  http://lwuit.java.net/

• OpenGL – http://www.khronos.org/opengles/

• PhoneGap (HTML5) – http://www.phonegap.com/home/

Z powyższej listy do prostego interfejsu bez „fajerwerków” wybrałbym zdecydowanie PhoneGap. Dzięki użyciu HTML5 i javascript (powszechnie znanych technologi) jest on bardzo prosty w użyciu dla programisty. Zarazem zapewnia API pozwalające na tworzenie dowolnych aplikacji, można odwoływać się również do native API. Gdyby pojawiły się problemy, możemy liczyć na wsparcie rozwijającej się społeczności wokół tego projektu. Natomiast jeśli miałaby to być gra lub inna aplikacja wymagająca więcej od telefonu, warto rozważyć użycie OpenGL. Projekt ten jest wiodącym pod względem renderingu 3D. Więcej informacji o frameworkach można znaleźć na stronach podanych powyżej. Dodatkowe wiadomości można również zaczerpnąć z prezentacji Łukasz Korzeniowskiego dostępnej tutaj.



Metodologia testu

Interfejs WebDAV oferuje szeroki zakres funkcjonalności. Na potrzeby testu wybrałem tylko kilku podstawowych metod: PUT (wysłanie pliku), GET (pobranie pliku), LIST (lista wszystkich plików w węźle) oraz DELETE (usunięcie pliku). Niestety, interfejs WebDAV jest rozszerzeniem standardu dlatego standardowe komponenty JMetera nie są w stanie wygenerować prawidłowych żądań. Dlatego utworzymy bibliotekę dostępu do wybranych metod WebDAV, a następnie będziemy wywoływać metody przy pomocy komponentu JMetera „Java Request”.

Uruchomienie JackRabbit

Zacznijmy od uruchomienia repozytorium. JackRabbit można uruchomić w różnych środowiskach i konfiguracjach. Wszystkie możliwości zaprezentowane są tutaj. Na potrzeby naszego testu uruchomimy JackRabbit jako moduł WAR na serwerze JBoss 5.1.  W tym celu ściągamy stabilną wersję aplikacji jackrabbit-webapp-X.X.X.war ze strony  http://jackrabbit.apache.org/downloads.html. Następnie za radą FAQ Jackrabbita musimy usunąć z niej biblioteki: WEB-INF\lib\xercesImpl-2.9.0.jar oraz WEB-INF\lib\xml-apis-1.3.04.jar. Wynika to z tego, że te biblioteki istnieją już w dystrybucji Jboss-a. Umieszczenie ich dodatkowo w aplikacji WAR prowadzi do konfliktu. Innym rozwiązaniem jest zmiana konfiguracji classloaderów w JBoss.

Po uruchomieniu jboss-a aplikacja JackRabbit jest dostępna na przykład pod adresem http:\\localhost:8080\jackrabbit. Domyślnie pod tym adresem dostępna jest strona z dokumentacją, opisem standardów, FAQ, tutorialami itp. Z innych ciekawych rzeczy mamy do dyspozycji browser, wyszukiwarkę treści oraz tzw: „Zasilacz treści” (ang. Populate).  Zasilenie polega na losowym wygenerowaniu i zapisaniu do repozytorium różnego rodzaju plików. Opcja przydatna przy przeprowadzaniu testów. My nie będziemy leniwi i sami zasilimy repozytorium własnymi danymi.

Projekt biblioteki dostępu do JackRabbit za pomocą WebDav

Api JackRabbita zawiera cały zestaw metod służących do wykonywania wszystkich dostępnych metod interfejsu WebDAV. Metody te są zawarte w pakiecie: “org.apache.jackrabbit.webdav.client.methods”. Przykładowy kod uruchomienia metody PUT może wyglądać następująco:

Warto zwrócić uwagę na pętlę do{… }while. Służy ona do zmniejszenia ryzyka wystąpienia błędu jednoczesnej modyfikacji węzła. Sytuacja taka wystąpi, gdy równolegle dwóch lub więcej klientów wykonuje operację dodawania/usuwanie/modyfikacji pliku w tym samym węźle. Jest to spowodowane tym, że podczas tych operacji wykonywane są również modyfikacje na węźle, co przy równoległej pracy prowadzi do błędu HTTP 409 (Konflikt). W celu rozwiązania tego problemu operację wykonuję w pętli. Jeśli za pierwszym razem wystąpił błąd, próbuję wykonać ją ponownie. Liczba prób nie może przekroczyć dziesięciu, po tym metoda kończy działanie i zwraca kod błędu.
Kod metody List:

W podobny sposób zaimplementowane są pozostałe metody Get i Delete.

Projekt biblioteki JMeter

Aby wykonywać żądania WebDAV, wykorzystamy komponent Java Request. Pozwala on na wykonywanie metod napisanych w języku Java. Będziemy wykonywać metody powyższego Api. Aby było to możliwe, należy utworzyć dodatkowe klasy testu JMeter, które rozszerzają interfejs „org.apache.jmeter.protocol.java.sampler.JavaSamplerClient”. Dla każdej z metod tworzymy klasę JMetera. Zawiera ona następujące metody:

• getDefaultParameters – lista parametrów metody
• runTest – ciało metody testującej
• setupTest – przygotowanie testu (metoda wykonywana jako pierwsza)
• teardownTest – zakończenie testu (metoda wykonywana jako ostatnia)

W metodzie runTest implementujemy uruchomienie akcji WebDAV.

Przykładowy kod klasy testującej metodę PUT w JMeter:

W metodzie getDefaultParameters umieszczamy listę parametrów, jakie mają być dostępne do ustawienia z poziomu JMetera. Widok na listę parametrów zdefiniowanych w powyższym teście:

Analogicznie tworzymy klasy testowe dla pozostałych metody WebDAV.
Po skompilowaniu należy umieścić klasy java w pliku jar i skopiować go to katalogu JMetera: “<jmeter.home>/lib/ext”. Po zrestartowaniu JMetera oraz wybraniu komponentu “Java Request” pojawią się nowe opcje:

Skrypt testowy

Widok na hierarchie skryptu testowego:

Opis konfiguracji:
Zmienne globalne – zmienne wykorzystywane w różnych komponentach:

VAR_LICZBA_UZYTKOWNIKOW – liczba symulowanych równolegle pracujących użytkowników
VAR_LICZBA_POWTORZEN – liczba powtórzeń testu
VAR_LICZBA_KATALOGOW – liczba węzłów na których pracują użytkownicy
VAR_WEB_DAV_URL – adres WebDav

Java Request Put

sourceFileName – lokalizacja pliku źródłowego (w tym przypadku plik tekstowy o wielkości 256Kb)
destName – nazwa docelowa pliku w JackRabbit, funkcja ${__counter(false)} zwraca kolejną wartość, zaczynając od 1, parametr false oznacza, że licznik jest wspólny dla wszystkich użytkowników
webDavURL – adres serwera WebDav
Jako dziecko do tego komponentu dodany jest komponent „Regular Expression Extractor”. Wykorzystujemy go do odczytania nazwy, pod którą został zapisanego pliku w JackRabbit. Nazwę tę umieszczamy w odpowiedzi żądania w tagach <fileName>…</fileName> (kod do obejrzenia w klasie PutWebDavJMeter).

Java Request – List
Wylistowanie wszystkich plików z węzła podanego w parametrze webDavURL. Plik testowy został tak napisany, że zwraca nazwy plików w znacznikach <name>…</name>. Wyrażenie regularne wyciąga listę nazw plików z odpowiedzi Java Request i umieszcza w zmiennej VAR_CONTENT_NAME_IN.

ForEach Controller – Get
Odczytuje listę nazw plików ze zmiennej VAR_CONTENT_NAME_IN i iteruje po niej umieszczając konkretne nazwy plików w zmiennej VAR_CONTENT_NAME_OUT.

Java Request Get
Wywołuję metodę GET na pliku podanym w zmiennej destName:

Wykonanie testu JMeter

Tak przygotowany test umożliwia nam manipulowanie liczbą użytkowników, liczbą węzłów, do których zapisujemy pliki oraz rozmiarem pliku.

Skrypt uruchamiamy, wybierając opcję z menu Uruchom->Start, a następnie pozostaje nam już tylko cieszyć się napływającymi wynikami:

Załóżmy, że mamy w naszej aplikacji jakieś zdarzenia które chcemy obsługiwać i wysyłać powiadomienia. Mamy więc abstrakcyjny byt Event, przydałby się manager zarządzania powiadomieniami i oczywiście mechanizmy obsługi zdarzeń – EventHandler.

Do czego w takim razie jest nam tu potrzebne Guice? Przecież w czasie działania aplikacji jeżeli nasz kontener wspiera w jakiś wstrzykiwanie instancji, mógłby więc też wrzucić nam odpowiednie elementy i niczym nie musielibyśmy się martwić. No tak, ale co w sytuacji, kiedy nasz kontener tak po prostu tego nie potrafi? A jeżeli w ogóle nie mamy kontenera? Co z testami jednostkowymi, które chcemy uruchamiać bez niego? Do tego właśnie nadaje się Guice. Zamiast w aplikacji wykonywać rzeczy takie jak

a potem jeszcze „kombinować” przy testach

możemy posłużyć się Guice, by to on zadbał o wszystkie konieczne elementy dla naszej aplikacji i testów. Czy nie lepiej zrobić coś takiego:

Takie podejście upraszcza nam logikę testów i odcina je od faktycznej implementacji. Czy ktoś jest w stanie sobie wyobrazić sytuację w której handler będzie miał dziesięć różnych elementów? Wszystkie chcemy testować, a po jakimś czasie okazuje się, że dwa z nich sa niepotrzebne, a trzy nowe musimy dodać. Doprowadziłoby to do zmian wielu testów, nie mówiąc o zmianach w logice biznesowej. Utrzymywanie tego bytu stałoby się mozolne. A w większych aplikacjach takich bytów bywa przecież więcej. Guice pozwala uniknąć tych problemów, musimy zadbać tylko o parę rzeczy. Po pierwsze – obiekty powinny posiadać konstruktory bezargumentowe lub adnotowane przez @Inject.

Po drugie – musimy dla każdej interesującej nas kombinacji parametrów obiektu stworzyć moduł, który będzie wiedział jak utworzyć naszą instancję. Czyli dla kawałka kodu

potrzebujemy TestNotificationManagerModule. Każdy moduł powinien rozszerzać klasę AbstractModule oraz implementować metodę configure(), w której określamy jakie klasy chcemy posiadać w czasie runtime’u ukryte pod interfejsami

W przypadku klas które posiadają konstruktory z parametrami możemy wykorzystać nieco inne podejście – metody @Provides

Metody takie zastępują wywołanie bind() – gdy moduł będzie potrzebował implementacji Event odszuka odpowiednią metodę z adnotacją @Provides i wywoła ją w celu pozyskania elementu.

W ten sposób możemy utworzyć dowolne kombinacje elementów podstawiając wymagane implementacje, zależnie od naszych potrzeb w danej chwili. Co więcej zmiana mechanizmów tworzenia wstrzykiwanego komponentu sprowadza się do zmiany modułów, które są zazwyczaj prostymi klasami, i nie musimy dokonywać dodatkowych modyfikacji w kodzie z logiką biznesową.

Cały projekt można pobrać z załączników żeby zobaczyć jak moduły załatwiają sprawę przydzielania odpowiednich implementacji do interfejsów zależnie od potrzeb.

Guice posiada kilka mechanizmów wstrzykiwań

• linked bindings – tak jak w podanym przykładzie
• instance bindings – możliwość przywiązania klasy do jej konkretnej instancji. Przydatne w łączeniu z adnotowaniem parametrów (o tym niżej)

1	bind(String.class).annotatedWith(Names.named("JDBC URL")).toInstance("jdbc:mysql://localhost/pizza");

• @Provides methods – jak w przykładzie, wykorzystanie metod oznaczonych @Provides zamiast bind(). Przydatne przy większych obiektach które posiadają proste elementy w konstruktorach, oraz w sytuacji, kiedy chcemy je przed użyciem skonfigurować

1 2 3 4 5

@Provides Event provideEvent(){     CreationEvent event = new CreationEvent("Creation Event Caller");     return event; }

• klasy Provider – mechanizm podobny do metod @Provides, jednak dla zdecydowanie większych i bardziej złożonych konstrukcji. Klasa taka powinna rozszerzać interfejs Provider<T> i posiadać metodę get() która zwraca wymagany element T. Klasy takie mogą jak najbardziej być adnotowane przez @Inject by uprościć sobie ich tworzenie, np

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

public class DatabaseTransactionLogProvider implements Provider<TransactionLog> {   private final Connection connection;   @Inject   public DatabaseTransactionLogProvider(Connection connection) {     this.connection = connection;   }   public TransactionLog get() {     DatabaseTransactionLog transactionLog = new DatabaseTransactionLog();     transactionLog.setConnection(connection);     return transactionLog;   } }

i w module przywiązujemy interfejs nie do konkretnej klasy, ale do klasy Providera

1 2 3 4

@Override   protected void configure() {     bind(TransactionLog.class).toProvider(DatabaseTransactionLogProvider.class);   }

• untargeted bindings – wiązania, które nie określają implementacji.

1	bind(CreditCardProcessor.class)

Przydatne, jeżeli posiadamy interfejsy adnotowane @ImplementedBy i @ProvidedBy

1 2 3 4 5 6 7 8 9 10 11

@ImplementedBy(PayPalCreditCardProcessor.class) public interface CreditCardProcessor {   ChargeResult charge(String amount, CreditCard creditCard)       throws UnreachableException; } //... @ProvidedBy(DatabaseTransactionLogProvider.class) public interface TransactionLog {   void logConnectException(UnreachableException e);   void logChargeResult(ChargeResult result); }

Adnotowanie parametrów służy rozróżnieniu wiązań – możemy przecież chcieć posiadać w ramach modułu różne implementacje zależnie od sytuacji.
Więcej o adnotowaniu parametrów w dokumentacji

Zasoby i bibliografia:

• strona projektu
• przykład GuiceDemo

Konfiguracja

W ramach podstawowej niezbędnej konfiguracji należy dodać następujące właściwości do pliku persistence.xml lub hibernate.cfg.xml:

<property name=”hibernate.ejb.event.post-insert” value=”org.hibernate.ejb.event.EJB3PostInsertEventListener,org.hibernate.envers.event.AuditEventListener” />
<property name=”hibernate.ejb.event.post-update” value=”org.hibernate.ejb.event.EJB3PostUpdateEventListener,org.hibernate.envers.event.AuditEventListener” />
<property name=”hibernate.ejb.event.post-delete” value=”org.hibernate.ejb.event.EJB3PostDeleteEventListener,org.hibernate.envers.event.AuditEventListener” />
<property name=”hibernate.ejb.event.pre-collection-update” value=”org.hibernate.envers.event.AuditEventListener” />
<property name=”hibernate.ejb.event.pre-collection-remove” value=”org.hibernate.envers.event.AuditEventListener” />
<property name=”hibernate.ejb.event.post-collection-recreate” value=”org.hibernate.envers.event.AuditEventListener” />

Konfigurujemy w ten sposób listenery , które sprawdzają, czy zmieniły się jakieś audytowalne encje i czy należy zachować historię zmian tych encji.

Kolejnym krokiem jest już oznaczenie encji adnotacją @Audited. Jeśli adnotację umieścimy na poziomie klasy, wszystkie pola będą wersjonowane. Możemy również adnotację umieścić na poziomie pól klasy, aby wersjonować tylko wybrane.

Przykład użycia

Po umieszczeniu konfiguracji opisanej w kroku wyżej użycie Envers’a sprowadza się do dodania odpowiednich adnotacji.

I to tak naprawdę wszystko z rzeczy specyficznych dla Envers. Użycie encji w innym zakresie jest tak standardowe, jak w przypadku JPA lub Hibernate i w zasadzie niczym się od nich nie różni.

Przechowywanie rewizji

Dla każdej adnotowanej encji zostanie utworzona dodatkowa tabela przechowująca audyt. Dla naszej encji z podanego przykładu powstanie podstawowa tabela:

Oraz dodatkowa tabela do przechowywania audytu:

Dodatkowo doszły nam następujące pola:

• REV – oznacza numer rewizji;
• REVTYPE – typ zmiany; możliwe wartości: 0 – wstawienie rekordu, 1 – modyfikacja rekordu, 2 – usunięcie rekordu.

Najnowszy rekord w tabeli audytu będzie miał wartości o jedną wersję wstecz względem wartości w aktualnej tabeli. Jeśli natomiast rekord zostanie usunięty, nie znajdziemy go już w tabeli podstawowej, a najświeższy wpis będzie miał wartości ustawione na <null> i typ rewizji 2.

Numery rewizji są wspólne dla wszystkich encji. Oznacza to, że jeśli najpierw zmienimy encję A, otrzyma ona rewizję 1, dopiero potem zmienimy encję B, która otrzyma rewizję 2 (oczywiście obie będą posiadały oddzielne tabele audytu).

Encja rewizji i zapis dodatkowych danych

Oprócz zapisywania historii zmian danej encji możemy dla każdej rewizji zapisać dodatkowe informacje. Służy do tego encja rewizji – jest to standardowa encja z dodatkową adnotacją oraz dodatkowymi polami, jakie chcemy zapisać. Przykładowo:

Klasa DefaultRevisionEntity jest dostarczana wraz z Envers i deklaruje dwa podstawowe pola: id oraz timestamp. Do tego możemy dołożyć dodatkowe informacje, które chcemy zapisać, np. nazwę użytkownika. Wykonuje się to w listenerze wskazanym przez adnotację @RevisionEntity:

Dla przykładowej encji rewizji zostanie utworzona następująca tabela:

Teraz przy utworzeniu nowej rewizji dowolnej audytowanej encji zostanie utworzony nowy wpis w tej tabeli z danymi uzupełnionymi według naszego listenera.

Odpytywanie o rewizje

Envers dostarcza klasy użytkowe pozwalające na odpytywanie o stan rewizji poszczególnych encji. Klasa AuditReaderFactory pozwala nam na pobranie instancji AuditReader w zależności od tego, czy operujemy na EntityManager z JPA czy też na Session z Hibernate.

AuditReader pozwala na budowanie zapytań implementujących interfejs AuditReader. Służy on do budowania zapytań w sposób podobny jak w przypadku Hibernate Criteria. Pytać możemy na dwa sposoby:

• o encję w konkretnej rewizji,
• o rewizje, w których encje się zmieniły.

Przykład zapytania o konkretną rewizję:

Przykład zapytania o rewizje, w których zmieniała się encja:

Wnioski

Jak widać, Envers pozwala na łatwe wdrożenie historii zmian bez specjalnego nakładu pracy i praktycznie transparentnie dla istniejącego modelu. Warto też wspomnieć, że Envers stał się już częścią dystrybucji Hibernate’a (od wersji 3.5), co dodatkowo świadczy o jego użyteczności i jakości.

Źródła

Strona główna projektu: http://jboss.org/envers
Dokumentacja: http://docs.jboss.org/envers/docs/index.html

Sonar to opensource’owy projekt, który wykorzystuje najpopularniejsze zewnętrzne narzędzia do sprawdzania jakości kodu – pmd, findbugs czy checkstyle. Wyniki prezentowane są na stronie WWW. Ponieważ najlepiej temat poznawać na przykładzie, zainstalujmy Sonara i sprawdźmy jak to wygląda w praktyce.

Przede wszystkim potrzebujemy Sonara – można pobrać go z http://sonar.codehaus.org/downloads/ . Na potrzeby tego artykułu pobrałem wersję 2.1.2.

Dostarczany jest jako paczka zip/tar,  po rozpakowaniu aplikacja jest gotowa do pracy. Żadne wyrafinowane mechanizmy instalacji czy konfiguracji nie są wymagane – wystarczy wejść do folderu Sonara i uruchomić

bin\windows-x86-32\StartSonar.bat

w przypadku systemu operacyjnego Windows lub wybrać odpowiedni skrypt dla swojej wersji OS (dostępna jest spora ilość skryptów na systemy Linux, UNIX czy Mac OS). Po bardziej zaawansowaną konfigurację odsyłam do dokumentacji

W wyniku działania powinniśmy dostać nowe okienko powłoki. Nie należy się martwić, jeżeli jest puste – zależnie od wersji Sonara którą pobraliśmy, czasami będziemy widzieć w nim log aplikacji, a w innych wersjach log domyślnie zapisywany jest do pliku. Aplikacja Sonar dostępna jest pod adresem http://localhost:9000/

Jeżeli wszystko poszło dobrze, powinniśmy otrzymać stronę główną Sonara

Po kliknięciu odnośnika ‘Configuration’ zostaniemy przeniesieni na stronę z listą profili jakościowych domyślnie zdefiniowanych w Sonarze. Oczywiście nic nie stoi na przeszkodzie, aby zdefiniować własny styl – każda reguła posiada dokładny opis, czego dotyczy. A reguł jest aż 706. Jest więc z czego wybierać, tworząc własne profile jakości. Ja pozostanę przy domyślnym „Sonar way” – zbiera najczęstsze błędy i naruszenia.

Jeżeli zechcecie zmienić domyślny profil dla testów, najpierw należy się zalogować jako ‘admin’, domyślne hasło to również ‘admin’.

Aby wykonać analizę projektu, należy wykonać z linii komend polecenie

mvn sonar:sonar

Jeżeli nie masz zainstalowanego Mavena to najwyższa pora, by to zrobić – http://maven.apache.org/download.html Ponieważ nie jest to artykuł o Mavenie, pomijam opis instalacji i konfiguracji. Na stronie projektu są dostępne materiały dobrze opisujące te zagadnienia.

Prawdopodobnie po przeczytaniu powyższego akapitu pomyślałeś, że Sonar nie nadaje się do twoich projektów, bo nie korzystasz z Mavena. Nic bardziej mylnego. Sonar może przeanalizować każdy projekt w Javie. Wystarczy, że dodasz do niego plik pom.xml z następującą treścią

W pliku definiujemy nazwę projektu, którego dotyczy analiza oraz ścieżkę do katalogu z plikami źródłowymi projektu. W katalogu, w którym jest nasz plik wywołujemy z listy poleceń

mvn sonar:sonar

W efekcie powinnien pojawić się taki trace:

C:\Documents and Settings\adama\workspace\SonarTest\src>mvn sonar:sonar
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'sonar'.
[INFO] ------------------------------------------------------------------------
[INFO] Building SonarTest
[INFO]    task-segment: [sonar:sonar] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [sonar:sonar]
[INFO] Sonar host: http://localhost:9000
[INFO] Sonar version: 2.1.2
[INFO] [sonar-core:internal]
[INFO]  Database dialect class org.sonar.api.database.dialect.Derby
[INFO]  -------------  Analyzing SonarTest
[INFO]  Selected quality profile : Sonar way, language=java
[INFO]  Configure maven plugins...
[INFO]  Sensor SquidSensor...
[INFO]  Java AST scan...
[INFO]  Java AST scan done: 265 ms
[INFO]  Squid extraction...
[INFO]  Squid extraction done: 906 ms
[INFO]  Sensor SquidSensor done: 1250 ms
[INFO]  Sensor JavaSourceImporter...
[INFO]  Sensor JavaSourceImporter done: 3188 ms
[INFO]  Sensor AsynchronousMeasuresSensor...
[INFO]  Sensor AsynchronousMeasuresSensor done: 625 ms
[INFO]  Execute maven plugin maven-pmd-plugin...
[INFO] ------------------------------------------------------------------------
[INFO] Building SonarTest
[INFO]    task-segment: [org.apache.maven.plugins:maven-pmd-plugin:2.4:pmd]
[INFO] ------------------------------------------------------------------------
[INFO] [pmd:pmd]
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] File encoding has not been set, using platform encoding Cp1250, i.e. b
uild is platform dependent!
[INFO]  Execute maven plugin maven-pmd-plugin done: 5265 ms
[INFO]  Sensor PmdSensor...
[INFO]  Sensor PmdSensor done: 3375 ms
[INFO]  Sensor ProfileSensor...
[INFO]  Sensor ProfileSensor done: 16 ms
[INFO]  Sensor ProjectLinksSensor...
[INFO]  Sensor ProjectLinksSensor done: 94 ms
[INFO]  Sensor VersionEventsSensor...
[INFO]  Sensor VersionEventsSensor done: 156 ms
[INFO]  Execute maven plugin maven-checkstyle-plugin...
[INFO] ------------------------------------------------------------------------
[INFO] Building SonarTest
[INFO]    task-segment: [org.apache.maven.plugins:maven-checkstyle-plugin:2.4:ch
eckstyle]
[INFO] ------------------------------------------------------------------------
[INFO] [checkstyle:checkstyle]
[WARNING] File encoding has not been set, using platform encoding Cp1250, i.e. b
uild is platform dependent!
[WARNING] Unable to locate Source XRef to link to - DISABLED
[INFO]  Execute maven plugin maven-checkstyle-plugin done: 8984 ms
[INFO]  Sensor CheckstyleSensor...
[INFO]  Sensor CheckstyleSensor done: 172 ms
[INFO]  Sensor CpdSensor...
[INFO]  Sensor CpdSensor done: 94 ms
[INFO]  Sensor Maven dependencies...
[INFO]  Sensor Maven dependencies done: 15 ms
[INFO]  Execute decorators...
[INFO]  ANALYSIS SUCCESSFUL, you can browse http://localhost:9000
[INFO]  Database optimization...
[INFO]  Database optimization done: 453 ms
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 5 seconds
[INFO] Finished at: Thu Jun 17 09:22:21 CEST 2010
[INFO] Final Memory: 22M/40M
[INFO] ------------------------------------------------------------------------

Po odświeżeniu strony głównej Sonara powinny pojawić się informacje o przeanalizowanym projekcie

Klikając w nazwę projektu zagłębiamy się w szczegóły:

Z tego miejsca możemy jeszcze głębiej zajrzeć, np. w konkretny typ błędów:

Wybierając konkretny błąd, możemy podejrzeć, w którym miejscu w kodzie wystąpiło naruszenie.

Po takiej analizie jak na dłoni widać gdzie i jakie naruszenia popełniliśmy.

Dodatkową istotną funkcjonalnością jest możliwość integracji bezpośrednio z IDE.
W tej chwili Sonar posiada wtyczki do Eclipse i IntelliJ IDEA. W fazie budowy jest też wtyczka do NetBeans. W tym przykładzie skupię się na Eclipse.

Wtyczkę do Eclipse pobieramy z update site http://dist.sonar-ide.codehaus.org/eclipse/
Po instalacji przechodzimy do Window -> Preferences -> Sonar. Możemy zdefiniować nową instancję Sonara, ale domyślnie powinniśmy mieć dodaną już lokalną wersję. Po kliknięciu przycisku  ‘Edit’ możemy sprawdzić czy połączenie z Sonarem działa.

Następnie klikamy prawym na naszym projekcie, wybieramy ‘Properties i w zakładce Sonar upewniamy się, że jesteśmy podpięci do poprawnej instancji Sonara

Jeżeli wszystko się zgadza, ponownie klikamy prawym na projekt, wybieramy Sonar -> Associate Project with Sonar, a potem jeszcze prawy -> Sonar -> Refresh Violations.

Po tych zabiegach nasz kod zostanie zbadany przez Sonara i wszelkie naruszenia zostaną podświetlone oraz dodany stosowny komentarz:

Niestety Eclipse pobiera tylko listę naruszeń z serwera Sonara, więc istnieje możliwość że otrzymamy zgłoszenia dotyczące linii kodu, które nie są błędne, a nawet nie istnieją lub są puste. Jeżeli chcemy otrzymać świeżą listę naruszeń, dokładnie odpowiadającą naszej wersji kodu musimy z linii poleceń wywołać

mvn sonar:sonar

w katalogu z plikiem pom.xml naszego projektu.

A to jeszcze nie wszystko – przecież rozwój prawdziwych aplikacji to nie tylko development i budowa projektów w IDE. Często większe projekty wykorzystują środowiska Continues Integration do budowy i weryfikacji poprawności kodu. Jednym z takich narzędzi jest Hudson. Sonar wpasowuje się w trend CI dostarczając wtyczkę do Hudsona umożliwiającą weryfikację jakości kodu po każdej budowie projektu. Wtyczka do pobrania jest na stronie http://wiki.hudson-ci.org/display/HUDSON/Sonar+plugin. Dokładne informacje o mechanizmach Hudsona dostępne są na stronie projektu, ja skupię się tylko na konfiguracji połączenia z Sonarem.

Po uruchomieniu Hudsona przechodzimy do „Manage Hudson” -> „Manage Plugins” -> „Advanced”. Tam ładujemy pobrany plik z wtyczką Sonara i restartujemy Hudsona.
Następnie przechodzimy do „Manage Hudson”->”Configure System” i na samym dole dokonujemy konfiguracji instancji Sonara – jeżeli wszystko instalowaliśmy z domyślnymi wartościami nasza konfiguracja ogranicza się jedynie do podania nazwy identyfikacyjnej daną instancję Sonara

Po dokonaniu konfiguracji przechodzimy do utworzenia zadania kompilującego i wykonującego weryfikację jakościową. Wybieramy „New Job” -> „Build a free-style software Project”. Dokonujemy standardowej konfiguracji zadania podając namiary na SCM i metody budowania (maven, ant itp.) – po szczegóły odsyłam do dokumentacji.
Dla nas najistotniejsza jest sekcja „Post-build Actions”. Zaznaczamy opcję „Sonar” i wypełniamy interesujące nas pola. Co ciekawe, z poziomu Hudsona nie potrzebujemy pliku pom.xml, możemy dodać odpowiednie parametry w definicji akcji

Po zapisaniu i wykonaniu builda powinien pojawić się taki trace

…
[SonarTest] $ D:\apache-maven-2.1.0\bin\mvn.bat -e -B -f sonar-pom.xml sonar:sonar
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'sonar'.
[INFO] ------------------------------------------------------------------------
[INFO] Building SonarTest
[INFO]    task-segment: [sonar:sonar] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [sonar:sonar]
[INFO] Sonar host: http://localhost:9000
[INFO] Sonar version: 2.1.2
[INFO] [sonar-core:internal]
[INFO]  Database dialect class org.sonar.api.database.dialect.Derby
[INFO]  -------------  Analyzing SonarTest
[INFO]  Selected quality profile : Sonar way, language=java
[INFO]  Configure maven plugins...
[INFO]  Sensor SquidSensor...
[INFO]  Java AST scan...
[INFO]  Java AST scan done: 312 ms
[INFO]  Squid extraction...
[INFO]  Squid extraction done: 344 ms
[INFO]  Sensor SquidSensor done: 719 ms
[INFO]  Sensor JavaSourceImporter...
[INFO]  Sensor JavaSourceImporter done: 78 ms
[INFO]  Sensor AsynchronousMeasuresSensor...
[INFO]  Sensor AsynchronousMeasuresSensor done: 47 ms
[INFO]  Execute maven plugin maven-pmd-plugin...
[INFO] ------------------------------------------------------------------------
[INFO] Building SonarTest
[INFO]    task-segment: [org.apache.maven.plugins:maven-pmd-plugin:2.4:pmd]
[INFO] ------------------------------------------------------------------------
[INFO] [pmd:pmd]
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] File encoding has not been set, using platform encoding Cp1250, i.e. build is platform dependent!
[INFO]  Execute maven plugin maven-pmd-plugin done: 5265 ms
[INFO]  Sensor PmdSensor...
[INFO]  Sensor PmdSensor done: 859 ms
[INFO]  Sensor ProfileSensor...
[INFO]  Sensor ProfileSensor done: 0 ms
[INFO]  Sensor ProjectLinksSensor...
[INFO]  Sensor ProjectLinksSensor done: 16 ms
[INFO]  Sensor VersionEventsSensor...
[INFO]  Sensor VersionEventsSensor done: 31 ms
[INFO]  Execute maven plugin maven-checkstyle-plugin...
[INFO] ------------------------------------------------------------------------
[INFO] Building SonarTest
[INFO]    task-segment: [org.apache.maven.plugins:maven-checkstyle-plugin:2.4:checkstyle]
[INFO] ------------------------------------------------------------------------
[INFO] [checkstyle:checkstyle]
[WARNING] File encoding has not been set, using platform encoding Cp1250, i.e. build is platform dependent!
[WARNING] Unable to locate Source XRef to link to - DISABLED
[INFO]  Execute maven plugin maven-checkstyle-plugin done: 9219 ms
[INFO]  Sensor CheckstyleSensor...
[INFO]  Sensor CheckstyleSensor done: 187 ms
[INFO]  Sensor CpdSensor...
[INFO]  Sensor CpdSensor done: 157 ms
[INFO]  Sensor Maven dependencies...
[INFO]  Sensor Maven dependencies done: 15 ms
[INFO]  Execute decorators...
[INFO]  ANALYSIS SUCCESSFUL, you can browse http://localhost:9000
[INFO]  Database optimization...
[INFO]  Database optimization done: 219 ms
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 27 seconds
[INFO] Finished at: Thu Jun 17 11:12:20 CEST 2010
[INFO] Final Memory: 22M/40M
[INFO] ------------------------------------------------------------------------
Finished: SUCCESS

W tym momencie możemy przejść na stronę główną aplikacji Sonara żeby sprawdzić wyniki weryfikacji.

Łącząc razem te trzy narzędzia otrzymujemy prawdziwy kombajn do weryfikacji poprawności i jakości tworzonych aplikacji. Korzyści są ogromne:
1. developerzy tworząc kod danych modułów na bieżąco widzą naruszenia jakościowe
2. kod oddany do SCM jest pobierany przed Hudsona i regularnie raz na dobę uruchamiana jest procedura budowy całej aplikacji, która sprawdza, czy całość aplikacji się kompiluje i buduje, a następnie jest poddawana weryfikacji przez Sonara
3. weryfikacje jakości wywoływane przez Hudsona są zapisywane w bazie danych Sonara, a zatem możemy obserwować trendy w jakości kodu oraz korzystać ze wszystkich dobrodziejstw Sonara nie obciążając go nadmierną ilością weryfikacji wywoływanych przez developerów.

Podsumowując – Sonar jest kompleksowym narzędziem do weryfikacji jakości kodu. Może być wykorzystywany zarówno do szybkiej lokalnej weryfikacji jak i przy budowie bardziej złożonych aplikacji w systemach CI. Jest to narzędzie, które zdecydowanie warto posiadać i wykorzystywać by budować dobrej jakości aplikacje.

Źródła:
- http://docs.codehaus.org/display/SONAR/Documentation
- http://wiki.hudson-ci.org/display/HUDSON/
- http://maven.apache.org

1. Jest to nowy standard w ramach Javy.
2. Będzie wchodził w skład JEE 6.
3. Bardzo łatwo się go używa – również na platformie SAP NetWeaver.
4. Posiada nowe rozbudowane API oraz nowe możliwości rozszerzeń (np. tzw. „composite constraints”).
5. W sposób przezroczysty integruje się z już posiadanym kodem.

Ponieważ jest to artykuł subiektywny, nie zamierzam w nim wymieniać wszystkich właściwości oraz różnic w specyfikacji JSR 303 w stosunku do starego hibernate-validator’a. Ze szczegółami można zawsze zapoznać się pobierając specyfikację ze stron Java Community Process.

Moim zdaniem bardzo istotna jest rozbudowa specyfikacji o możliwość definiowania mechanizmów walidacji za pomocą deskryptorów XML. Być może niektórzy czytelnicy posądzą mnie tutaj o herezję, ponieważ dziesiątki deskryptorów dostępnych w JEE to swoiste „małe piekiełko”. W przypadku walidatora jest to bardzo dobry pomysł o czym świadczą silne argumenty:

1. Deskryptory pozwalają na zastosowanie walidacji w beanach dostarczanych w postaci bibliotek,
2. Definicje w deskryptorach uniezależniają walidowane komponenty od API walidatora oraz własnych walidatorów w formie rozszerzeń.

Poniżej przedstawiam przykład kodu z zastosowaniem adnotacji oraz odpowiednika z zastosowaniem deskryptora xml.

Stan analogiczny do powyższego kodu możemy uzyskać za pomocą następujących definicji w deskryptorze xml:

Nie jest trudno wywnioskować, że wszystkie ograniczenia zdefiniowane w kodzie źródłowym mają swoje odpowiedniki w deskryptorze. Aby powyższe przykłady uruchomić, konieczne jest jeszcze skonfigurowanie całego „silnika” walidacji.
Konfigurację realizuje się przez zamieszczenie w katalogu META-INF pliku o nazwie validation.xml, który jest deskryptorem konfiguracji JSR-303.
Oto przykład pliku:

W powyższym pliku określono następujące właściwości silnika:

1. Default-provider wskazuje dostawcę implementacji JSR-303, którym jest oczywiście hibernate validator
2. Constraint-mapping wskazuje na dodatkowy deskryptor xml z definicją ograniczeń, można zdefiniować wiele plików z definicją ograniczeń

Na deser pozostał mi jeszcze prościutki przykład uruchomienia walidacji w kodzie z zastosowaniem poprzednich przykładów.
Oto on:

Smacznej walidacji