Google GIN (GWT INjection) to stosunkowo młody projekt Google, wprowadzający do Google Web Toolkit możliwość wstrzykiwania zależności (ang. dependency injection). Oparty jest na Google Guice (o którym pisałem kilka tygodni temu) i zapewnia pewien podzbiór funkcjonalności tej biblioteki.  Po co więc GIN? Potrzeba wynika wprost ze specyfiki aplikacji tworzonych w GWT, która uniemożliwia zastosowanie „typowego” frameworka do wstrzykiwania zależności. Rozwinę ten temat za chwilę.

Póki co, nie ma możliwości pobrania skompilowanej biblioteki ze strony projektu (tak jak pisałem, jest to jeszcze wczesna faza rozwoju), więc pozostaje check out z publicznego repozytorium i własnoręczna kompilacja:

svn checkout http://google-gin.googlecode.com/svn/trunk/ google-gin-read-only
cd google-gin-read-only
ant dist

Zbudowanego JARa (./out/dist/gin.jar) oczywiście należy dołączyć do swojego projektu.

Zaczynamy!

Mamy już dostępne klasy GIN, więc można zaczynać. W regularnym Guice, po skonfigurowaniu zależności w klasie modułu i utworzeniu Injectora, obiekty pobiera się mniej więcej tak:

RegistrationService registrationService = injector.getInstance(RegistrationService.class);

W GWT jednak powyższy kod nie zadziała. Żeby być ścisłym: nie zadziała w komponentach po stronie klienta (ang. client-side). Jak wiadomo, aplikacja GWT dzieli się na stronę klienta i stronę serwera. Po stronie serwera nie ma żadnego problemu ze wstrzykiwaniem zależności. Obiekty są instancjonowane w rzeczywistym JRE (najczęściej w kontenerze serwletów) i żyją „normalnym” Javowym życiem. Można używać Guice, Spring albo dowolnego innego rozwiązania do wstrzykiwania zależności i będzie działać. Po stronie klienta wygląda to jednak zupełnie inaczej, ponieważ kod Java jest kompilowany do JavaScript, więc JRE nie istnieje (jest jedynie w niewielkim zakresie emulowane przez bibliotekę GWT). Standardowe użycie Guice nie zadziała więc z dwóch powodów:

• Na poziomie JavaScript nie istnieją klasy.
• Guice (podobnie jak większość tego typu rozwiązań) często korzysta z mechanizmu reflection Javy, który nie jest w ogóle emulowany w GWT.

GIN stosuje więc inny sposób na zapewnienie wstrzykiwania zależności. Na początek należy zaimportować moduł GIN we własnym module GWT.

<module>
  ...
  <inherits name="com.google.gwt.inject.Inject" />
  ...
</module>

Teraz funkcjonalność oferowana przez GIN jest dostępna w obrębie strony klienta aplikacji GWT. Dochodzimy jednak ponownie do momentu, gdy „jakoś” trzeba w końcu te zależności pobrać. W GIN używa się do tego specjalnej wersji Injectora — Ginjectora (który jednak de facto nie jest związany relacją dziedziczenia z tym pierwszym).

public interface ApplicationGinjector extends Ginjector {
    ApplicationPresenter getApplicationPresenter();
}

Ginjector powinien oferować tylko komponenty potrzebne na etapie inicjalizacji aplikacji. Przy ich pobieraniu zostaną zainicjowane ich zależności, a więc również zależności tych zależności itd. W ten sposób zostanie zbudowany cały graf obiektów, a zależności automatycznie powstrzykiwane. W tym przypadku, komponentem potrzebnym na samym początku działania aplikacji jest ApplicationPresenter, który wyświetla ekran startowy. Zależności definiuje się dokładnie tak jak w Guice, czyli za pomocą adnotacji @Inject.

Jak wiadomo, Injector potrzebuje również modułu, w którym zawarte są informacje na temat komponentów.

public class ApplicationClientModule extends AbstractGinModule {
    @Override
    protected void configure() {
        bind(ApplicationPresenter.class);
        // other bindings...
    }
}

Jak widać, moduł po stronie klienta w GWT dziedziczy z AbstractGinModule. Poza tym wszystko wygląda dokładnie jak w Guice. Istotnym niuansem związanym z modułami GIN jest fakt, że w przypadku nie odnalezienia powiązania dla klasy, automatycznie wywoływana jest dla niej metoda GWT.create(), przez co niektóre rzeczy (np. asynchroniczne interfejsy usług) będą działać nawet bez odpowiedniej deklaracji w klasie modułu.

Zdefiniowany moduł należy jeszcze skojarzyć z właściwym interfejsem Ginjector za pomocą adnotacji @GinModules.

@GinModules(ApplicationClientModule.class)
public interface ApplicationGinjector extends Ginjector {
    ApplicationPresenter getApplicationPresenter();
}

W ten sposób, Ginjector jest w stanie skonfigurować całą aplikację na podstawie danych zawartych w określonym module. Aby to zrobić, należy go utworzyć za pomocą wywołania GWT.create() oraz pobrać początkowe obiekty.

public final class Application implements EntryPoint {
    public void onModuleLoad() {
        ApplicationGinjector injector = GWT.create(ApplicationGinjector.class);
        ApplicationPresenter applicationPresenter = injector.getApplicationPresenter();
        applicationPresenter.go(RootPanel.get());
    }
}

W ten sposób, cała procedura wstrzykiwania zależności ma miejsce już w czasie kompilacji. Użycie GIN nie jest więc związane z żadnym dodatkowym narzutem przetwarzania. (Wyszłoby na to samo, gdybyśmy konfigurowali komponenty ręcznie.)

Prawie jak Guice

Z użyciem GIN jest związanych kilka niuansów, o czym wspomniałem już na samym początku. GIN to nie jest mimo wszystko to samo co Guice, tylko dla GWT. Najbardziej istotne różnice w stosunku do Guice to:

• Zamiast typów Module i AbstractModule są GinModule i AbstractGinModule.
• Zamiast typu Injector jest Ginjector z adnotacją @GinModules.
• Niemożliwe jest użycie powiązania toInstance() i prawdopodobnie nigdy nie będzie możliwe (ze względu na to, że GIN działa w czasie kompilacji, a nie wykonania).
• Na chwilę obecną nie jest możliwe definiowanie własnych zasięgów.
• Nie ma adnotacji @ImplementedBy oraz @ProvidedBy.
• Brak obsługi zależności cyklicznych.
• Brak wsparcia dla AOP.

Warto jeszcze dodać, że istnieje sposób na współpracę z regularnym Guice za pomocą klasy GinModuleAdapter, dzięki której GinModule staje się dostępny jako zwykły Module. Można więc rozważyć utworzenie wspólnej części zależności w postaci GinModule. Ponadto, zrozumienie jak działa strona klienta w GWT na pewno pomoże uniknąć wielu potencjalnych problemów z GIN.

Podsumowanie

Jak widać, w GWT również można wygodnie wstrzykiwać zależności i to korzystając z bardzo przyjaznego API znanego z Guice. Mimo, że biblioteka ta jest jeszcze nieco niedojrzała i nie doczekała się nawet wersji 1.0, moim zdaniem warto się nią zainteresować i zastosować we własnych projektach w Google Web Toolkit. Używając jej przez ostatnie kilka miesięcy nie napotkałem żadnych problemów (w szczególności ze stabilnością), a znacząco ułatwiłem sobie pracę, rezygnując z ręcznego wstrzykiwania zależności. Myślę, że Google jeszcze nie raz zaskoczy nas różnymi ciekawymi dodatkami do GWT. Póki co, zapraszam na stronę domową projektu oraz zachęcam do własnych eksperymentów z Google GIN.

Google Guice to framework wspierający wstrzykiwanie zależności (ang. dependency injection) w aplikacjach Java. Można by powiedzieć: kolejny framework wspierający wstrzykiwanie zależności. Faktycznie, trzeba przyznać, że rynek Javowych rozwiązań tego typu jest dość mocno nasycony już od dłuższego czasu i oferuje pełen przekrój złożoności bibliotek, zaczynając od bardzo lekkich, takich jak choćby PicoContainer, a kończąc na pełnych stosach rozwiązań Java Enterprise ze Springiem na czele. Czy warto więc zawracać sobie głowę Guice’m? Moim zdaniem warto, bo zaproponowane przez Google’a rozwiązanie pokazuje nową jakość w implementacji wstrzykiwania zależności w aplikacjach Java, czyniąc ogromny użytek z typów generycznych oraz adnotacji. Guice jest przy tym lekki, ma proste API i bardzo szybko można się go nauczyć. Dlaczego warto to zrobić? Bo jest dobry. Kolesie z Google’a go używają. Musi być dobry. Poza tym, wygrał 18th Jolt Award w kategorii Libraries, Frameworks and Components. Musi być dobry.

Podstawy

W Guice występują dwie podstawowe konstrukcje opisujące wstrzykiwanie zależności. Pierwszą są moduły, które mówią co należy wstrzyknąć, a drugą jest adnotacja @Inject, która mówi gdzie należy wstrzyknąć. Proste. Zobaczmy jak to działa na przykładzie usługi rejestracji użytkowników.

public class RegistrationServiceImpl implements RegistrationService {
    private final PersistanceManager persistanceManager;
    private final MailService mailService;

    @Inject
    public RegistrationServiceImpl(PersistanceManager persistanceManager, MailService mailService) {
        this.persistanceManager = persistanceManager;
        this.mailService = mailService;
    }

    public void register(User user) {
        ...
    }
}

Jak widać naszą usługę specyfikuje kontrakt RegistrationService. Mamy jego implementację w postaci klasy RegistrationServiceImpl, która wymaga do działania usługi trwałości danych (PersistanceManager) oraz usługi do wysyłania maili (MailService). Chcielibyśmy, aby odpowiednie implementacje tych usług zostały automatycznie wstrzyknięte za pomocą parametrów konstruktora (adnotacja @Inject) już na etapie tworzenia usługi rejestracji. Spróbujmy opisać zależności między interfejsami a ich konkretnymi realizacjami za pomocą modułu.

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(RegistrationService.class).to(RegistrationServiceImpl.class);
        bind(PersistanceManager.class).to(HibernatePersistanceManager.class);
        bind(MailService.class).to(JavaMailService.class);
    }
}

Mamy nasz moduł. Jak widać, metoda configure() zawiera definicje kolejnych powiązań. Mamy więc usługę rejestracji określoną kontraktem RegistrationService z przypisaną naszą implementacją RegistrationServiceImpl. Mamy również usługę trwałości danych PersistanceManager zaimplementowaną w klasie HibernatePersistanceManager, która używa Hibernate’a do zapewnienia trwałości encji, oraz usługę MailService wraz z implementacją JavaMailService korzystającą z JavaMail do wysyłania poczty.

OK. Wystarczy już tylko użyć zdefiniowanego zespołu obiektów i przeprowadzić rejestrację użytkownika.

public class UserRegistrationExample {
    public static void main(String[] args) {
        Injector injector = Guice.createInjector(new MyModule());
        RegistrationService registrationService = injector.getInstance(RegistrationService.class);
        User user = new User("Michal", "Kalinowski");
        registrationService.register(user);
    }
}

To wszystko. Działa. „Prawie” jak w Springu, tylko zamiast trochę przydługawego pliku XML mamy elegancką implementację interfejsu Module w Javie, a zamiast identyfikowania obiektów za pomocą jakichś napisów mamy referencje do rzeczywistych klas. Myślę, że nie muszę wspominać jak ułatwia to refactoring. Jedyne do czego można się „przyczepić” to inwazyjność framework’a (odniesienia do API we własnych klasach), ale coś za coś. Wygoda jest niesamowita. Swoją drogą, pomysł na tyle przypadł do gustu kolesiom od Springa, że sami piszą już coś podobnego; nazywa się to Spring JavaConfig i powinno niedługo zostać oficjalnie wydane.

Oczywiście, proste powiązania interfejs <=> klasa i wstrzykiwanie zależności przez konstruktor to nie koniec możliwości Guice.

Powiązania

Oprócz prostych powiązań klasy z interfejsem, jest również kilka bardziej zaawansowanych konstrukcji.

Jedną z nich jest powiązanie adnotacją. Wyobraźmy sobie, że JavaMailService ma zostać użyty przez 2 różne usługi. Jedna z nich, nasz RegistrationService, do rozsyłania poczty powinna używać konta na Gmail’u, a inna – konta na Yahoo. Nic prostszego. Potrzebna nam dodatkowa adnotacja.

@BindingAnnotation
@Target( { FIELD, PARAMETER, METHOD })
@Retention(RUNTIME)
public @interface Gmail {
}

Modyfikujemy nieznacznie konstruktor naszej usługi rejestracji.

public class RegistrationServiceImpl implements RegistrationService {
    @Inject
    public RegistrationServiceImpl(PersistanceManager persistanceManager, @Gmail MailService mailService) {
        this.persistanceManager = persistanceManager;
        this.mailService = mailService;
    }
    ...
}

Oczywiście potrzebne jest również dodatkowe powiązanie w module.

bind(MailService.class).annotatedWith(Gmail.class).to(GmailJavaMailService.class);

Widać więc, że w Guice powiązanie jednoznacznie definiuje dopiero para adnotacji oraz typu.

Idźmy dalej. Jest możliwość stworzenia powiązania z konkretną instancją danego typu.

bind(String.class).annotatedWith(JdbcUri.class).toInstance("jdbc:mysql://localhost/application");

public class HibernatePersistanceManager implements PersistanceManager {
    public HibernatePersistanceManager(@JdbcUri String jdbcConnectionString) {
         ...
    }
    ...
}

Cool, huh? Można również zdefiniować w module własną metodę tworzenia obiektu. Używa się do tego adnotacji @Provides.

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        ...
    }

    @Provides
    PersistanceManager providePersistanceManager() {
        HibernatePersistanceManager persistanceManager = new HibernatePersistanceManager("jdbc:mysql://localhost/application");
        persistanceManager.initConnectionPool();
        return persistanceManager;
    }
}

Robi się bałagan w klasie modułu? Napiszmy zewnętrzne providery dla naszych komponentów.

public class DatabasePersistanceManagerProvider implements Provider<PersistanceManager> {
    private final Connection connection;

    @Inject
    public DatabasePersistanceManagerProvider(Connection connection) {
        this.connection = connection;
    }

    public PersistanceManager get() {
        DatabasePersistanceManager persistanceManager = new DatabasePersistanceManager();
        persistanceManager.setConnection(connection);
        return persistanceManager;
    }
}

I jeszcze odpowiednie powiązanie.

bind(PersistanceManager.class).toProvider(DatabasePersistanceManagerProvider.class);

Można nawet zdefiniować providera bezpośrednio w interfejsie.

@ProvidedBy(DatabasePersistanceManagerProvider.class)
public interface PersistanceManager {
    ...
}

Warto zwrócić uwagę, że definicje powiązań w Guice „czytają się same”. Jest to ogromna zaleta tej biblioteki. Nie ma tu nawet co tłumaczyć.

Zasięgi

Domyślnie Guice dostarcza nową instancję klasy przy każdym zapytaniu do kontenera. Można jednak zażyczyć sobie za pomocą adnotacji @Singleton, by istniała dokładnie jedna instancja danego komponentu w obrębie całej aplikacji. W aplikacjach webowych, po dołączeniu odpowiedniego dodatku do deskryptora web.xml, można używać również zasięgu sesyjnego (@SessionScoped) oraz zasięgu pojedynczego żądania HTTP (@RequestScoped). Zasięgi można ustawiać na kilka sposobów. Można np. zrobić to na samej klasie.

@Singleton
public class JavaMailService implements MailService {
    ...
}

Nic nie stoi na przeszkodzie, by ustawić zasięg na metodzie tworzącej obiekt w obrębie modułu.

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        ...
    }

    @Provides @Singleton
    MailService provideMailService() {
        ...
    }
}

Oczywiście, zawsze można zrobić to po prostu w definicji powiązania.

bind(MailService.class).to(JavaMailService.class).in(Singleton.class);

Wstrzykiwanie

W Guice dostępne są 3 standardowe metody wstrzykiwania zależności. Widzieliśmy już wstrzykiwanie przez konstruktor. Można również użyć do tego regularnej metody (niekoniecznie klasycznego settera).

public class RegistrationServiceImpl implements RegistrationService {
    @Inject
    public void provideLogger(Logger logger) {
        ...
    }
    ...
}

Można również wstrzykiwać bezpośrednio do pola klasy, ale jest to zdecydowanie niezalecane.

public class RegistrationServiceImpl implements RegistrationService {
    @Inject Logger logger;
    ...
}

Można w Guice również wstrzykiwać same providery.

public interface Provider<T> {
  T get();
}

Zapewniają one dodatkową elastyczność polegającą na tym, że kontener zwraca instancję komponentu-zależności wraz z każdym wywołaniem metody get(), a nie tylko jednorazowo na etapie tworzenia grafu obiektów.

public class DatabasePersistanceManager implements PersistanceManager {
    private final Provider<Connection> connectionProvider;

    @Inject
    public DatabasePersistanceManager(Provider<Connection> connectionProvider) {
        this.connectionProvider = connectionProvider;
    }

    public void persist(Object entity) {
        Connection connection = connectionProvider.get();
        ... // do something with provided connection
    }
}

Jakie to może mieć zastosowanie? Różne, przeróżne. Możemy potrzebować wielu instancji tego samego komponentu. Możemy zechcieć pomieszać komponenty różnych zasięgów (np. wstrzykiwanie danych użytkownika utrzymywanych w sesji HTTP do komponentu z zasięgiem Singleton). Możemy wreszcie użyć późnego ładowania (ang. lazy loading), jeśli konstruowanie komponentu-zależności jest kosztowne, a nie musi być wykonywane za każdym razem.

Czy to wszystko?

Oczywiście, omówiono tylko część możliwości Guice, aczkolwiek prawdopodobnie wystarczy to w 90% zastosowań. Widać więc, jak szybko można tę technologię przyswoić. Więcej informacji można odnaleźć w dokumentacji biblioteki. Znajduje się tam m.in. omówienie wsparcia dla programowania aspektowego oraz opis integracji Guice z rozwiązaniami webowymi. Warto tam zajrzeć.

Podsumowanie

Google Guice wydaje się stanowić bardzo ciekawą ofertę jako framework do wstrzykiwania zależności. Jeśli nie potrzebujemy bardzo kompleksowego rozwiązania takiego jak np. Spring, Guice powinien być w zupełności wystarczający. Jest bardzo lekki, prosty i ma niezwykle szybką krzywą uczenia. Dokładne przeczytanie tego posta powinno pozwolić na rozpoczęcie pracy, a w razie problemów zawsze pozostaje dokumentacja. Guice znacznie uprzyjemnia pracę programisty, pozwalając opisywać zależności i szczegóły ich wstrzykiwania za pomocą kodu Java „ozdobionego” adnotacjami i typami generycznymi, z zachowaniem jednocześnie deklaratywnego charakteru tego opisu. Jest to niewątpliwie znaczny krok do przodu. Uważam, że w dobrym kierunku.

.classpath
.project
.settings
.wtpmodules

do atrybutu svn:ignore katalogu każdego projektu w ramach przestrzeni roboczej (ang. workspace) i było po problemie. Aktualnie mamy w zespole jednego NetBeans’owca i do powyższej listy trzeba było dopisać jeszcze:

nbproject

Postanowiłem jednak przy okazji skonstruować kompletną listę wpisów do svn:ignore, która zawiera metadane 3 głównych IDE (Eclipse, NetBeans, IntelliJ IDEA). Dodatkowo dodałem target, jako standardowy katalog wyjściowy Maven’a oraz maskę *.log, bo takie pliki czasem również pojawiają się w repo. Mam nadzieję, że ta lista okaże się dla kogoś przydatna. Wygląda na to, że wystarczy ją „z góry” zaaplikować do wszystkich katalogów projektowych i mieć problem z głowy .

Ostateczna wartości atrybutu svn:ignore:

target
*.log
.classpath
.project
.settings
.wtpmodules
nbproject
*.ipr
*.iws
*.iml

W przypadku standardowych (lokalnych) programów ich uruchomienie, a tym samym debugging  nie rodzi większych trudności. W przypadku aplikacji webowych, dla których wymagana jest obecność środowiska takiego jak serwer aplikacji, sprawa ulega komplikacji. Ponieważ sam temat może być bardzo rozległy, przyjmijmy zatem pewne założenia:

• środowisko programistyczne (IDE) – Eclipse
• uruchomienie aplikacji w środowisku serwerowym (serwer aplikacji, kontener) – ograniczymy się do: Apache Tomcat, Glassfish, Jboss

Ze względu na różne możliwe podejścia, dalsza część materiału pogrupowana została na 3 części, co oczywiście jest wyłącznie subiektywną decyzją autora.

1. Wykorzystanie wtyczek (plugins)
Jeśli posiadasz środowisko Eclipse dla Java EE (pierwsza pozycja na liście) lub co najmniej wtyczkę Web Standard Tools, to sprawa jest stosunkowo banalna.

• Otwórz widok Servers (Window -> Show View -> Other -> Servers)
• Zdefiniuj nowy serwer wybierając opcję New-> Server. Jeśli na liście nie ma takiego serwera jakiego oczekujesz możesz spróbować Download additional server adapters



• Kolejne kroki są bardzo intuicyjne: specyfikujesz środowisko uruchomienia serwera podając ścieżkę do katalogu z serwerem, podajesz parametry dla danego typu serwera (np. adres, porty, itp.)
• Jeśli wszystko będzie w porządku to na liście serwerów pojawi się nowy wpis. Warto zauważyć, że pojawia się również nowa konfiguracja uruchomienia w menu Run i Debug zatytułowana tak samo jak serwerowy wpis.



• Istnieje również możliwość dostosowania stworzonej konfiguracji serwera, wystarczy wybrać wpis i wykonać dwuklik.
  W przypadku serwera Glassfish opcje konfiguracyjne wyglądają następująco:



• Jeśli szukasz szczegółowych informacji jako przykład może posłużyć
  tutorial dla Glassfisha. Analogicznie przebiega sposób konfiguracji dla innych serwerów.
• W przypadku posługiwania się wtyczkami możemy też skorzystać z innych dostępnych rozwiązań.
  Bardzo popularnym pluginem dla serwera Apache Tomcat jest Sysdeo
  Posiada wiele opcji konfiguracyjnych, jest przyjazny dla użytkownika i dodaje kolorowe Kociaki.
  Na pewno warto wypróbować.

2. Uruchomienie serwera jak zwykłej aplikacji Java.
Ta propozycja skierowana jest główniej dla tej części Społeczności Programistów, która sceptycznie i z dużą dozą nieufności patrzy na gotowe rozwiązania.
Jeśli programowanie aplikacji zaczynasz np. od zastanawiania się nad pisaniem własnego kompilatora, to bardzo prawdopodobne, że wykorzystanie pluginów,
będzie dla Ciebie zbyt ograniczające i niesatysfakcjonujące. Powodem może też być frustracja wynikająca z problemów z ich obsługą.

Tak czy inaczej w zaistniałej sytuacji rozwiązaniem wydaję się być utworzenie własnej konfiguracji uruchomienia serwera. Jako przykład przedstawię sposób tworzenia konfiguracji uruchomienia dla serwera Apache Tomcat. (Podpowiedź, pluginy zazwyczaj udostępniają możliwość wygenerowania takiej konfiguracji lub po prostu ją tworzą)

• W menu Run wybierz opcję Run Configurations. Utwórz nową konfigurację typu Java Application. Jako klasę startową (posiadającą metodę main) wybierz:
  org.apache.catalina.startup.Bootstrap
  
• Na kolejnej zakładce możesz podać argumenty z jakimi ma zostać uruchomiony serwer. Podstawowe jakie najczęściej się używa to:
  Wymagane:
  • -Dcatalina.home=”D:\apache-tomcat-5.5.26″
  • -Dcatalina.base=”D:\apache-tomcat-5.5.26″
  Dodatkowe:
  • -Djava.endorsed.dirs=”D:\apache-tomcat-5.5.26\common\endorsed”
  • -Djava.io.tmpdir=”D:\apache-tomcat-5.5.26\temp”
  • -Xms256m -Xmx512m
  • -XX:MaxPermSize=128m

  

• Na zakładce Classpath należy skonfigurować ścieżkę klas, poprzez dołączenie biblioteki bootstrap.jar, która znajduje się podkatalogu bin zainstalowanego serwera (np. D:\apache-tomcat-5.5.26\bin)
• Kolejna zakładka Source służy wskazaniu jakie źródła mają być rozpoznawane przez debuggera. Czyli po prostu dodajesz te projekty, które Cię interesują. I to praktycznie tyle. Pamiętaj o zachowaniu wprowadzonych zmian (przycisk Apply)

3. Debug zdalny (remote debug)
Ciekawą możliwością jest śledzenie działania serwera w sposób zdalny. Aby Eclipse był w stanie obsługiwać debug serwera potrzebne są 2 konfiguracje.
Po pierwsze serwer musi być skonfigurowany tak, aby pozwalał na debug. Po drugie konieczne jest utworzenie w Eclipsie konfiguracji dla Remote Java Application

• Konfiguracja serwera może sprowadzić się do odnalezienia pliku konfiguracyjnego i aktywacji trybu debug. Na przykład dla serwera JBoss wystarczy w pliku skryptowym run odkomenotwać odpowiedni wiersz:
  set JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y %JAVA_OPTS%
• W środowisku Eclipse tworzymy konfigurację Remote Java Application której parametry (adres, port) muszą pokrywać się z ustawieniami serwera. Na zakładace Source podobnie jak to omawialiśmy wyżej dołączamy projekty, których źródła chcemy prześledzić



• Oczywiście zdalne debugowanie działa również w przypadku, gdy serwer mamy na tej samej maszynie na której pracujemy
• Przydatne informacje można znaleźć tutaj:
  • Eclipse Special: Remote Debugging Tomcat & JBoss Apps with Eclipse
  • Debugging a servlet with tomcat and Eclipse tutorial
  • Debugging Glassfish with Eclipse

I to by było na tyle Moi Drodzy. Obfitego Debugowania!!!

Celem Mate jest zaproponowanie prostego i skutecznego mechanizmu zorganizowania przepływu sterowania (ang. control flow) w stylu MVC, z wykorzystaniem eventów Fleksa. Jest to jedna z głównych zalet Mate: zostaje wykorzystany już istniejący, sprawdzony i naturalny dla Fleksa mechanizm komunikacji między warstwami aplikacji. Framework nie wprowadza własnych rozwiązań, jeśli nie ma takiej potrzeby, co wspiera niezależność tworzonych modułów programowych.

Mate jest całkowicie przezroczysty z punktu widzenia aplikacji. Nie ma żadnych odniesień do klas frameworka zarówno w komponentach widoku, jak również biznesowych. Naturalnie, warstwa kontrolerów (w sensie MVC), musi być już powiązana z konkretną biblioteką i tak też jest w tym przypadku. Zastosowano jednak dość ciekawe rozwiązanie, polegające na zapisywaniu logiki sterowania w postaci tzw. map zdarzeń (ang. event map) definiowanych za pomocą XML. Określają one sekwencje poleceń do wykonania w odpowiedzi na wystąpienie konkretnych eventów. Przykładowo, nasza klasa zdarzenia mogłaby wyglądać tak:

package pl.espeo
{
    import flash.events.Event;

    public class AuthEvent extends Event
    {
        public static const LOGIN:String = "loginAuthEvent";

        public var username:String;
        public var password:String;

        public function AuthEvent(type:String, bubbles:Boolean = true, cancelable:Boolean = false)
        {
            super(type, bubbles, cancelable);
        }
    }
}

Blok przetwarzania dla tego zdarzenia mógłby wyglądać tak:

<EventMap ...>

    <EventHandlers type="{AuthEvent.LOGIN}">

        <RemoteObjectInvoker instance="{authService}"
            method="loginRemoteMethod" arguments="{[event.username, event.password]}">

            <resultHandlers>

                <MethodInvoker generator="{AuthManager}"
                    method="loginLocalMethod" arguments="{resultObject}"/>

            </resultHandlers>

        </RemoteObjectInvoker>

    </EventHandlers>

</EventMap>

Jeśli gdziekolwiek w naszej aplikacji zostanie „wyrzucony” event o typie AuthEvent.LOGIN, zostanie wykonany odpowiedni kod z mapy zdarzeń, który w tym przypadku wywołuje metodę loginRemoteMethod zdalnego obiektu authService, przekazując 2 argumenty: username oraz password. Po otrzymaniu wyniku tego wywołania, zostanie on następnie przekazany jako argument metody loginLocalMethod obiektu klasy AuthManager, która zrealizuje jakąś logikę związaną z obsługą wyniku logowania. Takie podejście często określa się mianem MVCS, gdzie to dodatkowe S oznacza Service. Mate promuje taką architekturę, oferując znaczniki obsługujące nie tylko zdalne obiekty, ale również WebService’y oraz dowolne inne usługi HTTP (np. w konwencji REST). Diagram przepływu sterowania w opisanym scenariuszu wygląda tak:

Jest to przypadek stosunkowo prosty. Możliwości Mate w zakresie kontroli przepływu sterowania są znacznie bardziej rozbudowane; jest np. możliwość zdefiniowania metody obsługi błędów zdalnych usług albo wywołanie odpowiednich metod logiki widoku w zależności od wyniku wykonania metod logiki biznesowej. Jeśli konieczne jest zaimplementowanie czegoś naprawdę skomplikowanego, na co tagi Mate mogą nie pozwolić, zawsze można napisać własną metodę w ActionScript i wydelegować przetwarzanie do niej. Możliwości są tutaj w zasadzie nieograniczone. Kolejny wielki plus Mate: bardzo duża elastyczność.

Oprócz realizacji architektury MVC(S), Mate zapewnia również implementację mechanizmu wstrzykiwania zależności (ang. dependency injection). Ponownie, nie ma tutaj ingerencji we właściwy kod logiki biznesowej czy widoku; zależności do wstrzyknięcia definiuje się w mapach zdarzeń. Mate oferuje tutaj jedynie sposób deklaratywnego opisu powiązań między obiektami. Właściwe wstrzykiwanie jest po stronie Fleksa i jego atrybutu [Bindable]. To kolejny przykład nieinwazyjności tego frameworka. Jeśli platforma programowa realizuje jakąś funkcjonalność dobrze, po co to powielać? Spójrzmy, jak łatwo w Mate wstrzykuje się obiekt bieżącej sesji (pole currentSession obiektu klasy SessionManager) do menedżera autoryzacji (pole session obiektu klasy AuthManager):

<EventMap ...>

    <Injectors target="{AuthManager}">

        <PropertyInjector source="{SessionManager}"
            sourceKey="currentSession" targetKey="session" />

    </Injectors>

</EventMap>

Podsumowując, Mate to naprawdę świetny pomysł na wprowadzenie do własnego projektu dobrej, spójnej architektury MVC. Promuje najlepsze praktyki rozwiązywania typowych problemów, występujących w każdej aplikacji, np. problemu zależności między komponentami z rozwiązaniem w postaci wstrzykiwania zależności. Zapewnia ogromną elastyczność, pozwalając w elegancki sposób wspomóc framework własnym kodem w ActionScript, jeżeli dostarczone tagi okażą się niewystarczające. Jest przy tym całkowicie nieinwazyjny, przez co komponenty widoku i logiki biznesowej mogą być ponownie wykorzystane.

Mimo młodego wieku, Mate oferuje naprawdę dużą funkcjonalność, która jest cały czas rozszerzana. Śledząc stronę projektu i jego forum, można przekonać się, że projekt żyje, jest rozwijany, a społeczność zadowolonych programistów-użytkowników Mate nieustannie się powiększa. Myślę, że warto się nim zainteresować. Już teraz jest bardzo poważnym konkurentem takich rozwiązań jak Cairngorm czy PureMVC. Jeśli projekt nie wytraci impetu to może już niedługo być najchętniej wybieranym frameworkiem dla nowopowstających projektów Fleksowych.

Gorąco zachęcam do odwiedzenia strony domowej projektu:
http://mate.asfusion.com/

Do łączenia aplikacji klienckiej napisanej we Fleksie z aplikacją serwerową napisaną w Javie zazwyczaj używa się darmowego BlazeDS lub komercyjnego LiveCycle ES, oba te narzędzia są autorstwa firmy Adobe i udostępniają wiele ciekawych możliwości. Chyba najszybszym i najlepszym sposobem połączenia Fleksa z Javą jest wykorzystanie tzw. remote objects. Jest to po prostu zdalne wywoływanie metod obiektów napisanych w Javie z poziomu Fleksa, cała komunikacja odbywa się przy użyciu bardzo wydajnego, binarnego protokołu AMF (Action Message Format).

Dotychczas, aby z poziomu Fleksa skorzystać z beanów tworzonych przez Springa z użyciem wstrzykiwania zależności, należało wykonać wiele niekoniecznie prostych i oczywistych operacji. Domyślnie sam BlazeDS tworzy skonfigurowane w jego plikach obiekty, co w tym przypadku było działaniem niepożądanym. Trzeba było skonfigurować odpowiednią fabrykę dla BlazeDS, tak aby pozwolił on zająć się tworzeniem odpowiednich obiektów kontenerowi Springa. Były to dość złożone operacje i potrafiły spowodować pojawienie się wielu siwych włosów nawet u doświadczonych developerów.

Sytuacja diametralnie zmieniła się pod koniec zeszłego roku, gdy SpringSource wypuściło na światło dzienne nowy projekt – Spring BlazeDS Integration. Na razie jest to jeszcze dość świeży projekt, jednak pozwala już na użycie beanów tworzonych przez Springa w aplikacjach napisanych we Fleksie przy stosunkowo niewielkim wysiłku. W najbliższych planach jest m.in. implementacja mechanizmu Spring Security, bardzo pożądanego przez developerów tworzących aplikacje Fleksowe.

Aktualnie, przy użyciu Spring BlazeDS Integration, udostępnienie obiektów tworzonych przez Springa sprowadza się do kilku prostych kroków:

1.Po stronie Javy:

a) ustawienie odpowiedniego listenera w pliku web.xml:

<listener>
	<listener-class>flex.messaging.HttpFlexSession</listener-class>
</listener>

b) praktycznie standardowa konfiguracja springowego servletu w pliku web.xml:

<!-- The front controller of this Spring Web application -->
<servlet>
	<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
	<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
	<init-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/config/web-application-config.xml</param-value>
	</init-param>
	<load-on-startup>1</load-on-startup>
</servlet>  

<!-- Map all /spring requests to the DispatcherServlet for handling -->
<servlet-mapping>
	<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
	<url-pattern>/spring/*</url-pattern>
</servlet-mapping>

c) dodanie odpowiedniego MessageBrokera w pliku konfiguracyjnym podanym powyżej jako parametr (web-application-config.xml):

<!-- Bootstraps and exposes the BlazeDS MessageBroker -->
<bean id="mySpringManagedMessageBroker"
	class="org.springframework.flex.messaging.MessageBrokerFactoryBean" />

Będzie on używał pliku konfiguracyjnego BlazeDS z domyślnego miejsca (WEB-INF/flex/services-config.xml). Aby zmienić to miejsce, należy dodać do powyższego beana następujący parametr:

<property name="servicesConfigPath" value="classpath*:services-config.xml" />

d) dodanie mapowania do MessageBrokera z BlazeDS (również w web-application-config.xml):

<!-- Maps request paths at /messagebroker to the BlazeDS MessageBroker -->
<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
	<property name="mappings">
        	<value>
                	/messagebroker/*=mySpringManagedMessageBroker
            	</value>
	</property>
</bean>

e) dodanie kanału odpowiadającego powyższej konfiguracji w pliku services-config.xml:

<channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel">
	<endpoint url="http://{server.name}:{server.port}/{context.root}/spring/messagebroker/amf"
		class="flex.messaging.endpoints.AMFEndpoint"/>
	<properties>
		<polling-enabled>false</polling-enabled>
	</properties>
</channel-definition>

f) przykładowa definicja obiektu, który ma zostać wystawiony Fleksowi (znowu web-application-config.xml):

<!-- Implementation of HelloService -->
<bean id="blazeHelloService" class="pl.espeo.blog.HelloServiceImpl" >
</bean>

<!-- Expose the blazeHelloService bean for BlazeDS remoting -->
<bean id="helloService"
	class="org.springframework.flex.messaging.remoting.FlexRemotingServiceExporter">
	<property name="messageBroker" ref="mySpringManagedMessageBroker"/>
	<property name="service" ref="blazeHelloService"/>
</bean>

Po takim skonfigurowaniu z poziomu Fleksa powinien być dostępny obiekt o nazwie „helloService” jako remote object.

2.Po stronie Fleksa:

a) odpowiednia konfiguracja do współpracy z BlazeDS – ustawienie projektu do korzystania ze standardowego pliku services-config.xml

b) obiekt „helloService” użyty we Fleksie:

<mx:RemoteObject id="helloSrv" destination="helloService"/>

Po prawidłowym ustawieniu plików konfiguracyjnych w obu aplikacjach można bezproblemowo cieszyć się springowymi beanami dostępnymi z poziomu Fleksa. Dokumentację dotyczącą projektu Spring BlazeDS Integration można przeczytać na stronie projektu:

http://www.springsource.org/spring-flex

W naszej aplikacji nie chcemy znać definicji tych obiektów, chcemy załadować kontener swf zawierający taki obiekt do głównej aplikacji i uzyskać dostęp do zasobów. Do dzieła!

Nasza prosta aplikacja będzie miała za zadanie wzywanie bohaterów którzy uratują świat przed nieuniknioną zagładą. Przygotujmy interface dla takiego bohatera:

package pl.espeo.hero
{
    import flash.display.Bitmap;

    public interface IHero
    {
         function getName():String;

         function getImage():Bitmap;
    }
}

Jak widać jedyne co nasz bohater będzie potrafił to powiedzieć jak się nazywa i dać nam swoją pamiątkową fotografię. Dodajmy klasę po której nasi poszczególni bohaterowie będą dziedziczyć:

package pl.espeo.hero
{
	import flash.display.Bitmap;
	import flash.display.Sprite;

	public class SuperHero extends implements IHero
	{
		protected var heroName:String;

		protected var heroImage:Bitmap;

		public function SuperHero(heroName:String, heroImage:Bitmap)
		{
			super();
			this.heroName = heroName;
			this.heroImage = heroImage;

		}

		public function getName():String
		{
			return heroName;
		} 

		public function getImage():Bitmap
		{
			return heroImage;
		}
	}
}

Czas przedstawić naszych zbawców. Pierwszy z nich to nikt inny jak Rambo:

package
{

	import pl.espeo.hero.SuperHero;

	public class Hero extends SuperHero
	{
		[Embed(source="assets/rambo.jpg")]
		private var EmbedImage:Class;

		public function Hero()
		{
			super('Rambo', new EmbedImage());
		}
	}
}

Tak przygotowanego bohatera kompilujemy do pliku swf. To samo robimy z naszym następnym bohaterem, Kapitanem Planetą:

package
{

	import pl.espeo.hero.SuperHero;

	public class Hero extends SuperHero
	{
		[Embed(source="assets/captain_planet.jpg")]
		private var EmbedImage:Class;

		public function Hero()
		{
			super('Captain Planet', new EmbedImage());
		}
	}
}

Mamy więc naszych bohaterów, czas przygotować dla nich podium oraz opracować sposób komunikacji z nimi. Aby nasza komunikacja przebiegała poprawnie, oraz aby nie przywołać zwykłego śmiertelnika w naszej aplikacji będziemy potrzebowali interfacu pl.espeo.hero.IHero. Czas przygotować formę komunikacji z naszym bohaterem:

package pl.espeo.hero
{
	import flash.display.Loader;
	import flash.events.Event;
	import flash.events.EventDispatcher;
	import flash.net.URLRequest;

	public class HeroSummoner extends EventDispatcher
	{
		public static const CAPTAIN_PLANET:String = 'CaptainPlanet';

		public static const RAMBO:String = 'Rambo';

		private var loader:Loader = new Loader();

		public function HeroSummoner()
		{
			loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loaderCompleteEventHandler);
		}

		public function callHero(heroName:String):void
		{
			loader.load(new URLRequest('assets/' + heroName + '.swf'));
		}

		private function loaderCompleteEventHandler(event:Event):void
		{
			var Hero:Class = event.target.applicationDomain.getDefinition('Hero') as Class;
                        var heroEvent:HeroEvent = new HeroEvent(HeroEvent.SUMMONED);
                        heroEvent.hero = new Hero();
                        dispatchEvent(heroEvent);
		}
	}
}

dzięki tak przygotowanej klasie, zostaniemy poinformowani eventem HeroEvent że nasz bohater jest już na miejscu.

package pl.espeo.hero
{
	import flash.events.Event;

	public class HeroEvent extends Event
	{
		public static const SUMMONED:String = 'pl.espeo.hero.HeroEventSummoned';

		public var hero:IHero;

		public function HeroEvent(type:String, bubbles:Boolean=false, cancelable:Boolean=false)
		{
			super(type, bubbles, cancelable);
		}

	}
}

Tak może to wyglądać w aplikacji flex:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" initialize="init()">
  <mx:Script>
    <![CDATA[
       import pl.espeo.hero.HeroEvent;
       import pl.espeo.hero.HeroSummoner;
       import mx.collections.ArrayCollection;
       import pl.espeo.hero.IHero;

       public static const NO_HERO:uint = 0;

       [Bindable]
       private var heroes:ArrayCollection = new ArrayCollection([{label:'There is no hero!', data:NO_HERO},
								 {label:'First hero', data:HeroSummoner.CAPTAIN_PLANET},
     								 {label:'Second hero', data:HeroSummoner.RAMBO}]); 

       private var heroSummoner:HeroSummoner = new HeroSummoner();                   													 

       private function init():void
       {
          heroSummoner.addEventListener(HeroEvent.SUMMONED, welcomeMyHero);
       }

       private function summonHero(event:Event):void
       {
            var hero:* = ComboBox(event.target).selectedItem.data;

            if (hero == NO_HERO)
            {
            	return;
            }

            heroSummoner.callHero(hero);
	}

        private function welcomeMyHero(event:HeroEvent):void
	{
  	   heroPanel.status = event.hero.getName();
	   heroImage.source = event.hero.getImage();
	}
      ]]>
    </mx:Script>
  <mx:HBox>
    <mx: Panel id="heroPanel" x="10" y="10" width="400" height="400" layout="absolute">
      <mx:Image id="heroImage" x="0" y="0"></mx:Image>
    </mx: Panel>
    <mx:ComboBox id="heroesList" dataProvider="{heroes}" change="{summonHero(event)}"/>
  </mx:HBox>
</mx:Application>

Dzięki tak przygotowanym obiektom możemy zbudować elastyczny system z zasobami zamkniętymi w łatwych do podmiany plikach. Dodając do tego prosty program narzędziowy wykorzystujący kompilator mxmlc możemy stworzyć furtkę, dzięki której przygotowanie kolejnych elementów nie będzie wymagało ingerencji programisty.

Zasadnicza koncepcja jest prosta: użyć Flex jako front-end, Grails jako back-end i zintegrować jedno z drugim. Brzmi łatwo, ale bardziej doświadczeni developerzy (szczególni Ci, zajmujący się systemami rozproszonymi) zapewne dostali właśnie dreszczy, widząc magiczne słowo: „zintegrować”. Mam dobrą wiadomość: w tym przypadku integracja obu technologii jest łatwa, szybka i przyjemna. Wydaje mi się, że jest to jedna z głównych przyczyn rosnącej popularności omawianego rozwiązania.

Na początek warto zastanowić się po co właściwie nam Grails + Flex. Można przecież zbudować aplikację internetową w Grails od początku do końca, podobnie zresztą jak we Flex. Użycie kombinacji obu technologii ma sens w przypadku, gdy robimy RIA, ale implementację logiki biznesowej chcielibyśmy pozostawić na serwerze, a także, dodatkowo, chcemy to wszystko wykonać w możliwie dobrych technologiach, które całą sprawę nam ułatwią, a nie utrudnią i zapewnią, przy okazji, realizację kilku wymagań niefunkcjonalnych (jak choćby duża przenośność), na których na pewno nam zależy. Grails + Flex = dokładnie to. Flex jest świetną technologią, która oferuje nam pełną potęgę graficzną Flash’a, ale w formie przyjaznej programiście (a nie grafikowi). Grails natomiast pozwala wykorzystać w całości moc platformy Java EE (czyli również jej bogactwo bibliotek, framework’ów oraz innych narzędzi), czyniąc jednak programowanie łatwiejszym i szybszym dzięki takim cechom jak choćby zasady DRY (Don’t Repeat Yourself – Nie powtarzaj się) i Convention Over Configuration (Konwencja ponad konfigurację), język programowania Groovy czy technologie Spring i Hibernate podane „na tacy”, bez żadnego dodatkowego wkładu pracy w konfigurację itp. Więcej na ten temat przeczytać można we wcześniejszym wpisie Pawła.

Teraz czas na właściwą integrację. Po stronie Grails nie musimy właściwie nic robić, bo wszystko załatwia jeden plug-in. Wystarczy go zainstalować, wydając z konsoli (w katalogu głównym projektu Grails) polecenie:

grails install-plugin flex

oraz dodać w klasie usługowej (ang. service), która implementuje logikę biznesową, którą chcemy udostępnić aplikacji Flex, jedno pole statyczne:

static expose = ['flex-remoting']

i to wszystko! Usługa będzie od teraz udostępniona. Powiedzmy, że wygląda ona tak:

class HelloService {
    static expose = ['flex-remoting']
    def hello() {
        return "Hello World!"
    }
}

W aplikacji Flex wystarczy powołać obiekt RemoteObject:

<mx:RemoteObject id="myService" destination="helloService"/>

by móc korzystać z naszej usługi. Przykładowa aplikacja może wyglądać tak:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:RemoteObject id="myService" destination="helloService"/>
    <mx:Button label="Hello" click="myService.hello()"/>
    <mx:TextInput text="{myService.hello.lastResult}"/>
</mx:Application>

Nic dodać, nic ująć. Zero konfiguracji. To po prostu działa… i już!

Ale właściwie… jak to działa? Otóż nie ma tu żadnej „magii”, wbrew temu co widać na pierwszy rzut oka. „Pod maską” siedzi magiczny komponent BlazeDS i odrobina Convention Over Configuration. BlazeDS jest technologią serwerową, która obsługuje styk Grails <=> Flex (a tak naprawdę to Java <=> ActionScript) poprzez implementację mechanizmu RPC, tak jak to pokazano wyżej. Przez „obsługuje” rozumiem wszystko, co jest potrzebne do zdalnego wywołania metody logiki biznesowej: udostępnienie usługi w sieci (pod konkretnym URL), ustalenie protokołu komunikacyjnego ponad warstwą HTTP oraz zapewnienie konwersji typów między światem Java, a światem ActionScript. Część „magii”, jak sądzę, została już wyjaśniona. Idźmy dalej. Przenieśmy naszą aplikację Flex do osobnego projektu, czyli rozdzielmy całość na projekt Grails i projekt Flex. Okaże się, że nagle wszystko przestało działać, co zresztą nie dziwi, bo niby skąd aplikacja Flex ma mieć pojęcie co zrobić z:

<mx:RemoteObject id="myService" destination="helloService"/>

skoro nie wie gdzie jest helloService (przypominam, że aplikacja Grails jest już osobnym projektem). Oto rozwiązanie: uruchamiamy naszą aplikację Grails poleceniem:

grails run-app

i (zakładając, że aplikacja jest dostępna pod adresem http://localhost:8080/hello) modyfikujemy powyższą definicję obiektu RemoteObject:

<mx:RemoteObject id="myService" destination="helloService"
    endpoint="http://localhost:8080/hello/messagebroker/amf"/>

Mamy URL, pod którym udostępnione są nasze obiekty usługowe, i mamy „magika” łączącego świat typów Java ze światem typów ActionScript, którym są biblioteki BlazeDS. Dodam tylko (żeby nie pozostawić żadnych wątpliwości), że protokołem komunikacyjnym nad warstwą HTTP jest AMF (ang. ActionScript Message Format), którym „rozmawiają” aplikacja Flex (wykonująca zdalne wywołanie metody) i BlazeDS (uruchamiający na żądanie metody logiki biznesowej i zwracający ich rezultat).

Jak wspomniałem wcześniej Grails jest framework’iem wzorowanym na Ruby on Rails, jako bazę wykorzystującym język Groovy. Po swoim poprzedniku przejął podstawowe zasady:

• DRY (Don’t Repeat Yourself – Nie powtarzaj się)
• Convention Over Configuration (Konwencja ponad konfigurację)

Co stanowi o dodatkowej sile Grails’a to wykorzystanie dla popularnych i mających bardzo dobrą opinię bibliotek Javovych: Spring Framework, Hibernate, Sitemesh. Dla użytkownika końcowego mogą byc one niewidoczne, ukryte za interjefsami napisanymi w Groovy, ułatwiającymi ich używanie i redukującymi ilośc potrzebnej kofiguracji (to jest właśnie siła wspomnianej wcześniej zasady!). W każdym momencie możliwe jest jednak pełne ich wykorzystanie oraz samodzielna konfiguracja.

W skrócie więc Grails = elastycznośc Groovy + moc bibliotek Javy

Jak to wygląda w praktyce? Prosty przykład, wydajemy polecenia:

grails create-app
grails create-domain-class [nazwaKlasy] , edytujemy stworzony plik .groovy dodając odpowiednie pola
grails generate-all
grails run-app


… i możemy już w przeglądarce uruchomic aplikację, ze stronkami do dodawania nowych instancji dla stworzonej klasy, edycji i usuwania. Stworzone mamy kontrolery wykorzystujące Spring’a, mapowania Hibernate’owe, strony GSP (podobne do JSP), dane zapisywane są też już do bazy i parę jeszcze użytecznych plików. Ciekawe ile zajęłoby zrobiebienie takiej funkcjonalności w Javie…

Co dodatkowo stanowi o sile Grails jest system plugin’ów. Sprawnie działająca społecznośc skupiona wokół projektu tworzy coraz to nowe pluginy (aktualnie około 40) pozwalające na współpracę m.in. z Flex’em, JSF, GWT, Acegi, OpenLaszlo, Yahoo UI, i wieloma innymi technologiami.

Z punktu widzenia programisty szybkośc tworzenie aplikacji wzrasta więc niesamowicie a dodatkowo to wciąż jest Java (no i troche Groovy). Kolejna rewolucja? Znowu tak, o tym projekcie jest już teraz głośno, będzie jeszcze bardziej.

W następnej części cyklu postaram się przedstawic jakie plusy może miec stosowanie Groovy / Grails w tzw. prawdziwym świecie czyli dlaczego klienci biznesowi mogą byc tym wszystkim zainteresowani.

W pierwszym cyklu wpisów na blogu chciałem poświęcic kilka słów dwóm technologiom o którym od jakiegoś już czasu głośno na blogach poświęconych Javie, mianowicie językowi Groovy oraz opartemu na nim framework’owi Grails. W skrócie dla tych co ostatnie pół roku (przynajmniej) przespali: Groovy jest to dynamiczny język programowania, działający na JVM i bardzo dobrze integrujący się z Java (dzięki temu, że jest kompilowany do postaci bytecode), natomiast Grails to framework zworowany na Ruby on Rails, służący do budowy aplikacji webowych opartych na modelu MVC (model-widok-sterownik), wykorzystujący m.in. Groovy, Spring Framework, Hibernate. Tyle tytułem wstępu, przejdźmy do detali.

Groovy jako język programowania jest obecny od kilku lat, jednak dopiero teraz nastąpił drastyczny wzrost jego popularności. Można to przypisywac kilku przyczynom, jednak moim zdaniem największy wpływ miały na to Ruby i RoR, które pokazały, że język skryptowy może w niektórych zastosowaniach przewyższac język kompilowany. Przynajmniej tak wyglądała moja historia, po pierwsze usłyszałem o Ruby, zacząłem czytac na ten temat i w ten sposób znalazłem Groovy, który ma dużo podobieństw jednak przewyższa Ruby w jednej zasadniczej sprawie – współpracy z Javą, która jest jednak wciąż najpowszechniej stosowanym językiem programowania. Co Groovy daje więc programiście? Jest językiem skryptowym, zawiera domknięcia (ang. closures), właściwości (ang. properties), możliwośc stosowanie niezdefiniowanych typów, ułatwia zasadniczo tworzenie i parsowanie XML, tworzenie komponentów Swinga, pisanie testów jednostkowych (ang. unit tests). Można takich udogodnień wymienic jeszcze dużo, jednak najlepsze w w tym wszystkim jest to, że możemy w dowolnym momencie przełączac sie pomiędzy kodem napisanym w Groovy i w Javie i wywoływac jeden z drugiego. Przynajmniej dla mnie wygląda to rewelacyjnie. Nie przyłączyłbym sie może jeszcze do stwierdzenia ,że w przeciągu 2-3 lat Groovy całkowicie zastąpi Javę ale na pewno jego udział będzie coraz większy i w niektórych zastosowaniach dominujący. Rewolucja? Dla mnie tak, dla innych śledzących rozwój Groovy od dłuższego czasu zapewne naturalny krok w ewolucji Javy. Czy z punku widzenia programisty Javy warto się uczyc Groovy? Moim zdaniem zdecydowanie i wręcz trzeba.

Jeśli chce ktoś przetestowac Groovy i dowiedziec się więcej polecam oficjalną stronę projektu oraz swietną książke Groovy in Action, dostępną na razie jedynie po angielsku.

c.d.n. W następnej cześci opiszę zapowiadany framework Grails.