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.

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.

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

Często można spotkać opinie, że JavaFX nie ma przyszłości, bo nie posiada żadnego wsparcia dla komunikacji z elementami biznesowymi. Kiedyś być może było to prawdą, dziś naprzeciw takim oczekiwaniom wychodzi Flamingo. Jest to framework, który może stać się czymś w rodzaju „kleju” łączącego teoretycznie różne technologie, m.in. JavyFX i Seama.

Aby nie pozostawiać słów bez pokrycia, przygotuję projekt, który zaprezentuje możliwości Flamingo. Pokaże on jak łączyć JavaFX z Seamem. Na koniec wszystko wrzucimy na serwer aplikacji i uruchomimy z poziomu przeglądarki.

Zacznijmy od klasycznego projektu Seama. Wykorzystam tu Eclipse 3.5.2, Seama 2.2, JBossa 5.1 oraz JBoss Tools dla Eclipse, żeby szybko wygenerować działającą aplikację. Jeżeli jeszcze ich nie masz, czas się zaopatrzyć w te niezbędne narzędzia.

W Eclipse wybieramy New – > Other -> Seam -> Seam Web Project

Wypełniamy pola formularza:

• nazwa projektu: SeamApp
• Target runtime: JBoss 5.1 Runtime
• Dynamic Web Module Vesion: 2.5
• Target Server: JBoss 5.1 Runtime Server
• Configuration: Dynamic web project with JBoss Seam 2.2.0

Najprawdopodobniej nazwy docelowego runtime’u i serwera będą inne – w zależności od tego co sobie skonfigurujemy. Najważniejsze, by wybrać JBoss 5.1 (Seam 2.2. teoretycznie działa też na wcześniejszych wersjach).

Przez kilka kolejnych ekranów konfiguratora możemy przeskoczyć z domyślnymi ustawieniami. Dotrzemy ostatecznie do ekranu z wyborem bazy danych i sposobu deploymentu aplikacji. Ponieważ przykłady mają być proste, wybieramy pakowanie do war i bazę HSQLową – lub dowolną inną, nie będziemy korzystać tutaj z tego elementu.

Możemy zmienić jeszcze domyślne pakiety, ale nie jest to konieczne.

Wygenerowana aplikacja jest gotowa do użycia i deploymentu – zawiera wszystkie niezbędne elementy do uruchomienia, przykładowe strony oraz klasę Authenticator służącą do autentykacji użytkownika w systemie. Dla pewności możemy uruchomić aplikację by upewnić się, że wszystko poszło ok.

Aby móc podpiąć się do aplikacji za pomocą JavaFX, musimy dodać do niej kilka niezbędnych elementów. Są to biblioteki Flamingo (linki do wszystkich materiałów znajdują się na końcu artykułu):

• amf-serializer.jar
• flamingo-service.jar
• flamingo-services-common.jar
• hessian.jar
• scannotation.jar

Umieszczamy je bezpośrednio w katalogu lib aplikacji. W skład Flamingo wchodzi jeszcze parę bibliotek, ale do podstawowego przykładu wystarczą te. Aby móc wywoływać komponenty Seam musimy jeszcze dodać do pliku web.xml wpis definiujący servlet, który będzie odpowiadał za komunikację JavaFX z Seamem

Teraz już możemy dostać się do dowolnego komponentu Seam w naszej aplikacji za pomocą Flamingo. Przykładowa aplikacja posiada tylko jeden komponent (autentykator), więc wykorzystajmy go, aby nie komplikować całości. Do klasy Authenticator.java dodajmy metodę

Pozostanie ona naszą metodą, którą będziemy wywoływać z poziomu aplikacji FX-owej.

Czas na stworzenie klienta tej jakże wyrafinowanej metody.

W Eclipse tworzymy nowy projekt, w którym znajdą się zarówno klasy Java jak i JavaFX. Polecam by zainstalować sobie wytczkę  Exadel JavaFX Eclipse plugin. Ułatwia ona nieco tworzenie projektów FX-owych w Eclipse. Do tej części wymagane jest też posiadanie JavaFX 1.3 SDK. Jeżeli jeszcze go nie masz – czas zainstalować.

Wybieramy New -> Other -> JavaFX -> JavaFX Project

Na kolejnych ekranach wizarda wybieramy nazwę projektu (FxClient), wersję SDK JavyFX, oraz JDK do wykorzystania w projekcie. Po „doklikaniu” do końca wizarda zostanie utworzony projekt ze wszystkimi niezbędnymi bibliotekami do pisania uruchamiania aplikacji FXowej.

Aby móc skorzystać z mechanizmów Seamowych, musimy dodać jeszcze trzy biblioteki. Tworzymy katalog lib i wrzucamy do niego:

• jboss-seam.jar (z instalacji seama)
• jboss-seam-remoting.jar (jw.)
• hessian.jar (ta sama wersja co w aplikacji Seamowej)

Teraz musimy dodać interfejs, który będzie bramką do naszej usługi seamowej. W idealnym świecie pewnie byłby on zawarty w dostarczonym z zewnątrz jarze z API, ale upraszczamy wszystko jak możemy.

Potrzebna będzie też fabryka tej usługi, dodajmy więc i ją:

Krótki komentarz do powyższego:

(1)   – Tworzymy nową instancję fabryki połączeń. Komunikacja za pomocą JavaFX i Seam odbywa się po protokole Hessian.

(2)   – Pobieramy instancję usługi HelloWorld na podstawie adresu URL zasobu. Parametr ten ustawimy już bezpośrednio w skrypcie FX i tam opiszę jego wygląd.

Pozostał nam jeszcze skrypt FX który skorzysta z usługi Seamowej. Utwórzmy go zatem:

(1)    – Tworzymy miniklasę, w której będziemy trzymać imię do powitania, oraz odpowiedź z komponentu Seam.
(2)    – Ustawiamy adres do komponentu Seam do którego chcemy się odwołać. Generalnie powinien mieć on postać http://adres_serwera/kontekst_aplikacji/flamingo/hessian/nazwa_komponentu_seam, przy czym /flamingo/hessian to ścieżka dla servletu Flamingo którą wpisaliśmy w web.xml aplikacji seamowej.
(3)    – Wiążemy zawartość pola tekstowego z jedną ze zmiennych naszej miniklasy.
(4)    – Podpinamy wywołanie usługi pod kliknięcie na przycisk.
(5)    – Tworzymy scenę, na której umieszczone zostaną nasze elementy graficzne.

W tym momencie (jeżeli mamy uruchomioną aplikację seamową oczywiście) możemy już uruchomić aplikację FXową i sprawdzić czy wszystko się udało.

Jak widać, udało nam się wywołać komponent Seam z aplikacji desktopowej.

Czas podnieść sobie nieco poprzeczkę, i zrobić to samo z aplikacji webowej.

Tu też przydatny jest plugin do eclipse, gdyż może on za nas załatwić mozolną walkę z kompilacją do pliku jar wraz z wymaganymi bibliotekami (javafxpackager z linii poleceń też może to zrobić, ale wówczas trzeba się trochę napisać…).

Aby przygotować plik jar odpowiedni do wykorzystania na serwerze aplikacji wystarczy kliknąć na naszym skrypcie prawym przyciskiem myszy i wybierać Run as -> JavaFX Application (applet)

W folderze dist projektu zostaną utworzone następujące elementy

• plik jar ze skompilowanym skryptem FX
• pliki jnlp, umożliwiające uruchamianie aplikacji przez Java Web Start
• strona html, w treści której umieszczony został aplet ze skryptem FX

Wszystko to przenosimy do katalogu WebContent naszej aplikacji Seamowej, zmieniamy nazwę wygenerowanego przez kompilator pliku html na index.html i robimy redeploy całej aplikacji. Teraz pod domyślnym adresem aplikacji seamowej powinniśmy otrzymać działający skrypt JavyFX

Prawda, że to proste?

Na koniec jeszcze jedna ciekawostka. Jeżeli zmodyfikujemy plik index.html i dodamy do definicji apletu parametr draggable, będziemy mogli dosłownie wyciągnąć aplet na pulpit (trzymając klawisz alt oraz lewy przycisk myszy) i korzystać z niego nawet po zamknięciu przeglądarki.

Podsumowując, Flamingo pozwala nam łatwo zintegrować aplikację FXową z aplikacją Seamową. Dzięki niemu możemy korzystać z komponentów Seama zarówno w aplikacji desktopowej, jak i wykorzystać JavaFX do stworzenia interfejsu użytkownika bezpośrednio w aplikacji seamowej. Aplikację przygotowaną w ten sposób bez problemu można umieścić na serwerze, a także udostępnić wersję desktopową przez jnlp. JavaFX nie zabrania wykorzystania innych elementów na stronie, może współistnieć z innymi elementami i bibliotekami. Czas więc zakasać rękawy i stworzyć prawdziwe RIA.

Zasoby i bibliografia

• Framework Flamingo
• Exadel JavaFX Eclipse Plugin
• Maxa Blog (wiele pomocnych artykułów na temat łączenia Seama z JavaFX, również bardziej zaawansowanych – polecam!)
• wymagane pliki jar frameworku flamingo
• FxClient
• Seam App wersja final (z dodanym apletem klienta)
• JavaFX SDK jeżeli mamy już JDK 1.6.20
• JDK + JavaFX SDK jeżeli nie mamy jeszcze JDK w wersji 1.6.20

Na początek słowo wstępu o tym, czym jest OSGi.  Open Services Gateway Initiative -  bo tak należy rozwinąć ten skrót – to nic innego jak system dynamicznych modułów dla Java. Definiuje architekturę modułowych aplikacji, które mogą być uruchamiane w kontenerach wspierających OSGi. Do tychże zaliczyć możemy

• Equinox
• Apache Felix
• knopflerfish

Po co dodatkowy kontener? Co daje modularność? Pytania są jak najbardziej słuszne. Jeżeli idzie o kontenery, to są one tworzone specjalnie po to, by umożliwić zarządzanie aplikacjami modularnymi w sposób najwygodniejszy z możliwych – podmienianie modułów, ich dołączanie i odłączanie bez konieczności restartu całego serwera.  Umożliwiają zarządzanie zależnościami między modułami i pozwalają budować aplikacje najróżniejszych typów – od mobilnych do RIA.

Coraz większa popularność OSGi z pewnością ma też coś wspólnego ze wsparciem tego modelu przez Eclipse IDE. Środowisko to posiada wbudowane wizardy do tworzenia modułów OSGi, jak i własny kontener do ich testowania i debugowania.

Utwórzmy prosty moduł OSGi  (zwany Bundle) właśnie w środowisku Eclipse (Europa). Aby to zrobić, wybieramy New->Project->Plug-in Development -> Plug-in Project. Dostaniemy do wypełnienia wizard, który utworzy dla nas przykładowy projekt.

Nazwa: TestBundle

Target Platform: OSGi framework -> standard

Klikamy Next, Next. Jako szablon wybieramy Hello OSGi Bundle i klikamy next do końca kreatora.

Po zakończeniu powinniśmy dostać projekt z klasą Activator, plikiem MANIFEST.FM oraz build.properties.

Przyjrzyjmy się wszystkim tym plikom.

Activator

public class Activator implements BundleActivator {

 /*
 * (non-Javadoc)
 * @see org.osgi.framework.BundleActivator#start(org.osgi.framework.BundleContext)
 */
 public void start(BundleContext context) throws Exception {
 System.out.println("Hello World!!");
 }

 /*
 * (non-Javadoc)
 * @see org.osgi.framework.BundleActivator#stop(org.osgi.framework.BundleContext)
 */
 public void stop(BundleContext context) throws Exception {
 System.out.println("Goodbye World!!");
 }

}

Activator to klasa implementująca BundleActivator – interfejs, który wskazuje, jak nasz moduł ma być startowany i zatrzymywany. W metodach start/stop wykonywane są operacje dostarczające danych do dalszej pracy i sprzątające przy zamknięciu (nawiązanie połączenia z bazą, zakończenie połączenia)

MANIFEST.FM

Na pierwszy rzut oka, plik MANIFEST to nic nadzwyczajnego, jest on zaszyty w niemal każdej bibliotece JAR. Dla mnie miał on jednak szczególne znaczenie, gdyż był przyczyną owych nieszczęsnych komunikatów o nieprawidłowych pakietach. Wygenerowany plik ma następującą treść

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: TestBundle Plug-in
Bundle-SymbolicName: TestBundle
Bundle-Version: 1.0.0
Bundle-Activator: testbundle.Activator
Import-Package: org.osgi.framework;version="1.3.0"

Pierwsze, co powinno rzucić się nam w oczy, to dyrektywa Bundle-Activator. Wymieniona jest tam nasza klasa Activator.  Sugeruje to,  że plik MANIFEST, może odgrywać dużo większą rolę niż się wydaje. Prześledźmy więc kolejno wszystkie dyrektywy

• Bundle-ManifestVersion: 2 – informuje o tym, z jakiej wersji specyfikacji OSGi korzysta ten bundle. 2 oznacza kompatybilność z release 4 specyfikacji, 1 z wcześniejszymi wersjami
• Bundle-Name: – nazwa bundle w formie czytelnej dla człowieka
• Bundle-SymbolicName – nazwa bundle, pod którą będzie widziany z innych modułów
• Bundle-Version: wersja tego bundle (w kontenerach może jednocześnie działać kilka wersji tego samego bundle’a).
• Bundle-Activator: klasa aktywatora bundle’a, czyli z jakiej klasy należy skorzystać przy uruchamianiu i zatrzymywaniu modułu
• Import-Package:  tu definiujemy jakie pakiety chcemy zaimportować do naszego bundle’a. Możliwe jest importowanie pakietów z innych modułów, a więc ich wzajemne wiązanie i wykorzystywanie funkcjonalności

W powyższym zestawieniu brak jednak dyrektywy najbardziej istotnej z punktu widzenia mojego problemu. A mianowicie:

• Export-Package: tu określamy jakie pakiety z naszego bundle’a chcemy wyeksportować. Tylko wyeksportowane pakiety mogą być importowane przez inne moduły.

Plik manifestu może posiadać jeszcze parę innych ważnych dyrektyw. Są to

• Private-Package: tu wymienione są pakiety, których nie chcemy udostępnić. Początkowo wydaje się to nie potrzebne, ale przecież może zaistnieć sytuacja, w której będziemy chcieli wyeksportować klasy pakietu pl.atena.* ale nie pakietu pl.atena.secret.*.  Header ten nie mieści się jednak w oficjalnej specyfikacji, wykorzystywany jest przez narzędzie BND do budowania bundle’a. Może to być różnie interpretowane w różnych kontenerach
• Bundle-Classpath: tu możemy określić, gdzie w naszej bibliotece znajdują się inne wykorzystywane biblioteki. Domyślnie specyfikacja zakłada, że wszelkie dodatkowe pliki jar są w korzeniu bundle’a.
• Ignore-Package: tu wymienione są pakiety ignorowane w trakcie budowania za pomocą narzędzia BND. Podobnie jak Private-Package nie jest to oficjalny nagłówek.

build.properties

Plik ten określa tylko ścieżki do wykorzystania w trakcie budowania modułu.

Aplikacje modularne robią coraz większą furorę, więc przyszłość OSGi wydaje się jasna i pewna. Niewykluczone, że jeszcze nie raz przyjdzie mi spotkać się z nimi. Z pewnością podzielę się wtedy swoimi doświadczeniami w ich tworzeniu.

Źródła:

• Creating OSGi Bundles
• OSGi Alliance

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

Kiedyś pracowaliśmy z Krzyśkiem przy tym samym projekcie, który intensywnie wykorzystywał JPA w implementacji Hibernate 3 oraz bazę danych Oracle.
Kolega zwrócił właśnie uwagę na mało wydajny sposób w jaki Hibernate wstawia rekordy do bazy danych:

• wykonuje polecenie select, które pobiera identyfikator z sekwencji,
• wstawia właściwy rekord z pobranym wcześniej identyfikatorem.

Krzysiek był na tyle szybki, że zaraz po tym przedstawił propozycję rozwiązania problemu: zastosowanie strategii generowania identyfikatorów org.hibernate.id.SequenceIdentityGenerator.

Co to jest i jak wpływa na wydajność?

Jest to specyficzna dla Hibernate implementacja obsługi sekwencji bazodanowych, która wykorzystuje funkcjonalność sterowników JDBC zgodnych ze specyfikacja 3.0 (charakterystyczna funkcja getGeneratedKeys). Dzięki jej zastosowaniu Hibernate jest w stanie wstawić rekord do bazy danych w połączeniu z wygenerowaniem identyfikatora i tym samym wykonać 50% operacji mniej
Ograniczeniem zastosowania tego typu sekwencji jest wsparcie wspomnianej już specyfikacji JDBC 3.0 ze strony używanego sterownika.

Aby cieszyć się w pełni wydajnym wstawianiem danych, należy zadeklarować generator używając adnotacji @GenericGenerator. Stanowi ona rozszerzenie Hibernate i nie wchodzi w skład specyfikacji JPA. Adnotację możemy zastosować na pakiecie (w package-info.java), klasie lub atrybucie klasy.

Przykładowa deklaracja generatora może wyglądać następująco:

package pl.atena;

import javax.persistence.Entity;
import javax.persistence.Table;
import javax.persistence.Id;
import javax.persistence.Column;
import javax.persistence.GeneratedValue;

@Entity
@Table(name="TBL_TEST")
public class Test {

    @Id
    @GeneratedValue(generator="jdbc3_generator")
    @org.hibernate.annotations.GenericGenerator(
        name="jdbc3_generator",
        strategy="org.hibernate.id.SequenceIdentityGenerator"
    )
    @Column(name="ID")
    protected Long id;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }
}

Jeżeli zależy nam na kodzie, który ma być przenośny miedzy kilkoma bazami danych, generator zoptymalizowaną pod kątem JDBC 3.0 należy umieścić w kodzie klasy (nie na poziomie pakietu). Tak skonstruowany kod w łatwy sposób nadpiszemy za pomocą pliku orm.xml np. przywracając domyślny mechanizm generowania sekwencji .

Przykład:

<?xml version="1.0" encoding="UTF-8"?>
<entity class="pl.atena.Test" metadata-complete="false">
    <attributes>
        <id name="id">
	    <generated-value strategy="AUTO" />
	</id>
    </attributes>
</entity>

Przedstawione informację są kwintesencją całego rozwiązania. Zachęcam osoby ciekawskie do zrobienia testów wydajności, ja tymczasem życząc wszystkim Wesołych Świąt oddaję się tropieniu tematów do kolejnych publikacji.

Gdy już ochłonąłem, zacząłem zastanawiać się, jak można modyfikować takie zasoby. Przy użyciu konsoli zarządzania serwerem sprawa jest prosta.
Inaczej rzecz się ma w przypadku modyfikowania właściwości z poziomu skryptów wykonywanych przez wsadmin (Jacl lub Jython).
Większość przykładów tworzenia zasobów pokazuje, jak tworzyć nowe właściwości lub je „nadpisywać” przez dodanie nowej z taką samą nazwą, jak istniejąca. Nie jest to dobrym rozwiązaniem, ponieważ konsola administracyjna Websphere gubi się, odczytując właściwości zasobu, w którym istnieje kilka wpisów definiujących ten sam element.

Przykład nieprawidłowego modyfikowania zasobów (dodawane są nowe wpisy o identycznych nazwach):

Poniższy przykład pokazuje, jak prawidłowo modyfikować wartość właściwości URL

Czy pomogło ?

Daniel Ramotowski

PS

Mam nadzieję, że nie zaszkodziło.

DR

Nie wdając się w dalsze dyskusje, poniżej charakteryzuję ustawianie właściwości kontekstu JNDI na różnych serwerach aplikacji.
Zakładam przy tym, że każdy z serwerów jest zainstalowany pod dobrze znanym adresem „localhost” oraz, że usługi są  skonfigurowane na portach domyślnych.

Właściwości te możemy przekazać jako mapę podczas tworzenia kontekstu JNDI.
Możemy je również zdefiniować w pliku o nazwie jndi.properties:

Postać pliku dla SAP NetWeaver 7.1

java.naming.factory.initial=com.sap.engine.services.jndi.InitialContextFactoryImpl
java.naming.provider.url=p4://localhost:50004
java.naming.factory.url.pkgs=com.sap.engine.services

Postać pliku dla IBM Websphere Application Server 7

java.naming.factory.initial=com.ibm.websphere.naming.WsnInitialContextFactory
java.naming.provider.url=corbaloc:iiop:localhost:2809
java.naming.factory.url.pkgs=com.ibm.ws.naming

Postać pliku dla JBoss

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=jnp://localhost:1099
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

Aby w pełni cieszyć się możliwościami wywołań zdalnych komponentów, przydadzą się nam jeszcze biblioteki z implementacją JNDI.

• Jeżeli używamy SAP NetWeaver Develiper Studio, na ścieżce klas potrzebna nam będzie biblioteka com.sap.engine.clientapis_2.0.0.090709123112.jar, którą znajdziemy w katalogu plugins.
• W przypadku IBM Websphere Application Server 7 będziemy potrzebowali bibliotek com.ibm.ws.ejb.thinclient_7.0.0.jar oraz com.ibm.ws.orb_7.0.0.jar, które znajdziemy w katalogu AppServer\runtimes.
• W przypadku serwera JBoss 4.2.X będzie potrzebna biblioteka jbossall-client.jar,którą znajdziemy w katalogu client.
• W przypadku serwera JBoss 5.X będą potrzebne właściwie wszystkie biblioteki z katalogu client.

Miłej zabawy!!!

PS. Jako ciekawostkę dodam, że wywołując zdalne metody komponentów EJB zainstalowanych na IBM Websphere warto zapoznać się z narzędziem createEJBStubs.
Jest ono dostarczane razem z serwerem aplikacji Websphere.

Często programiści zostawiają w tworzonych aplikacjach różnego rodzaju furtki, by w razie awarii, jakiegoś nietypowego zachowania, mogli dojść do przyczyn. Czasem też dane w programie ewoluują, i okazuje się, że brakuje nam informacji by wykonać daną operację, np. stworzyć zaległy raport czy fakturę.

Java dostarcza środków do sprawnej realizacji tego typu zadań – silnik skryptowy. Dzięki niemu, możemy bez ingerencji w kod aplikacji czy magicznych sztuczek na poziomie interfejsu dostać się do interesujących nas danych i zmodyfikować je. I to wszystko bez potrzeby restartowania serwera czy przebudowywania kodu zależnie od problemu. Wystarczy umieścić w aplikacji Script Engine i interfejs do jego obsługi. Istnieje cały projekt zajmujący się dostarczaniem bibliotek do obsługi języków skryptowych w Javie – zainteresowanym polecam stronę https://scripting.dev.java.net/

Java dostarcza dwa rodzaje API do obsługi skryptów. Są to:

• JSR 223 Scripting API
• Bean Scripting Framework (BSF) API

Java 1.6 standardowo dostarcza engine do obsługi javaskryptu, jeżeli chcemy wykorzystywać JSR 223 do JRubiego, musimy dodać odpowiednie biblioteki do naszej aplikacji:

• jruby-bin-1.0.tar.gz – do pobrania z jruby.codehouse.org
• jsr223-engines.tar.gz – do pobrania z scripting.dev.java.net

Przyjrzyjmy się jak działa Script Engine na przykładzie*

import javax.script.*;

public class EvalScript {

    public static void main(String[] args) throws Exception {

ScriptEngineManager factory = new ScriptEngineManager()

// Create a JRuby engine.
ScriptEngine engine = factory.getEngineByName("jruby");

    // Evaluate JRuby code from string.
    try {
        engine.eval("puts('Hello')");
    } catch (ScriptException exception) {
        exception.printStackTrace();
    }

    }
}

Powyższa klasa tworzy engine JRuby i próbuje wykonać skrypt napisany w tym języku. Ten prosty przykład wypisuje tylko powitanie, jednak poprzez jego parametryzację możemy w łatwy sposób uzyskać obsługę skomplikowanych skryptów.

Poza ewaluacją skryptu Script Engine pozwala nam na wywoływanie konkretnych metod zdefiniowanych w skrypcie, w zależności od potrzeb.

//klasa Javy **

public class RunMethods {

public static void main(String[] args) throws ScriptException, FileNotFoundException {

     ScriptEngineManager factory = new ScriptEngineManager();

         // Create a JRuby engine.

         ScriptEngine engine = factory.getEngineByName("jruby");

         //process a ruby file

         engine.eval(new BufferedReader(new FileReader("myruby.rb")));

         //call a method defined in the ruby source

         engine.put("number", 6); //[1]

         long fact = (Long) engine.eval("fact($number)"); //[2]

         System.out.println("fact: " + fact);

engine.eval("$myglobalvar = fact($number)"); //[3]

long myglob = (Long) engine.getBindings(ScriptContext.ENGINE_SCOPE).get("myglobalvar");//[4]

         System.out.println("myglob: " + myglob);

    }
}

// myruby.rb **

def fact(n)

 if n==0

    return 1

 else

    return n*fact(n-1)

 end

end

Klasa wczytuje plik myruby.rb, który definiuje metodę fact obliczającą silnię dla podanego parametru. Po ewaluacji, engine pozwala nam ustawić lokalne zmienne [1] i wykorzystać je do wywołania metody zdefiniowanej w pliku [2]. Dodatkowo zmienne możemy ustawiać wywołując kolejne ewaluacje [3]. Engine.getBindings pozwala nam odczytać ustawione w skrypcie zmienne [4].

Wszystko fajnie, ale co z modyfikowaniem danych i obiektów Javy? Tu wkraczamy bardziej w samą składnię JRubiego niż istotę Script Engine jednak pozwolę sobie na prosty przykład

//example1.rb***

   require 'java'      #[1]

   import java.lang.System #[2]

   frame = javax.swing.JFrame.new("Window") #[3]

   label = javax.swing.JLabel.new("The Time" + System::currentTimeMillis) #[4]

   frame.getContentPane.add(label) #[5]

   frame.setDefaultCloseOperation(javax.swing.JFrame::EXIT_ON_CLOSE)

   frame.pack

   frame.setVisible(true)

Wczytując i wykonując powyższy skrypt powinniśmy dostać okienko pokazujące nam informację o aktualnym czasie. Linia [1] jest najistotniejsza w powyższym pliku. To ona pozwala nam na dostęp do standardowych klas Javy. Od tego momentu możemy używać klas Javy poprzez podanie pełnych ścieżek i nazw klas. Aby nie podawać ciągle pakietu klasy możemy użyć słowa import [2]. Linia [3] tworzy nam nowego JFrame’a, [4] JLabel z informacją o czasie. Operator :: używany jest do dostępu do statycznych metod i pól klasy. Do niestatecznych metod dostęp uzyskujemy przez standardową kropkę [5]. Aby uniknąć wielu importów klas, można importować całe pakiety dyrektywą include_package a klasy z poza projektu dostępne są po dodaniu pliku jar do skryptu (dyrektywa require). Tym sposobem, możemy w skrypcie dodać brakujące dane, stworzyć potrzebny obiekt i usunąć zbędne dane (np generowanie zaległej faktury po zmianie oferowanych produktów).

Załóżmy, że mamy działającą aplikację na serwerze, z zaimplementowanym Script Engine w postaci formularza z polem tekstowym, który służy do wpisania skryptu. Submit formularza wywołuje metodę ewaluującą wpisany tekst.

Naszą nietypową sytuacją jest konieczność wykonania operacji na fakturze, jej wydrukowanie i usunięcie

// skrypt wpisany do pola tekstowego

require 'java'

    import pl.atena.MyInvoice

    import pl.atena.InvoiceRepository

    root =  InvoiceRepository.instance

    invoice = MyInvoice.new

    # manipulate invoice data

    root.getInvoices.add(invoice)

    root.printInvoice(invoice)

    root.removeInvoice(invoice)

//funkcja obsługująca submit formularza

public void doSubmit(String script) {

      try {

        ScriptEngine engine = factory.getEngineByName("jruby");

        engine.eval(script);

      } catch (ScriptException exception) {

        exception.printStackTrace();

      }

}

// klasa obsługi faktur

class InvoiceRepository {

InvoiceRepository getInstance() {…}

List<Invoice> getInvoices() {….}

void printInvoice(Invoice invoice) {….}

boolean removeInvoice(Invoice invoice {…}

}

Sytuacji wyjątkowych może być całe mnóstwo, a wszystkie je możemy obsłużyć w analogiczny sposób – bez konieczności modyfikacji nawet kawałka kodu naszej aplikacji. Jeżeli dodamy do tego, że aplikacja nie dostarcza bezpośrednio GUI do obsługi funkcji removeInvoice, ujawnia się nam prawdziwa potęga Script Engine.

JRuby pozwala na dużo więcej, wszystkich zainteresowanych odsyłam na stronę projektu http://jruby.codehouse.org

Materiały źródłowe:

* http://java.sun.com/developer/technicalArticles/scripting/jruby/

** http://www.ics.muni.cz/~makub/ruby/

*** http://wiki.jruby.org/wiki/Calling_Java_from_JRuby