Groovy and Grails releases in the last months appear so often that it is really easy to miss them. Starting with Groovy: it’s current version is 1.7.4, and the maintenance updates from this branch bring little more than bugfixes, so the below list contains mainly the changes introduced in 1.7.0:

• anonymous inner classes – for Java compatibility

• nested static classes – functionality exists, but it is best to use static nested classes if any

• added annotations on imports, packages and variable declarations – this allows for instance to declare dependencies with Grape within your code

• more readable asserts output with Power Asserts

• AST Viewer and AST Builder to facilitate the use of AST transformations

• Groovy Truth expanded – every class now can customize the way it is evaluated to boolean by implementing its asBoolean() method

• batch updates using sql.witchBatch() and sql.withTransaction()

• numerous improvements in testing, collection methods, GroovyScriptEngine, Groovy console and other

More on this, especially the exact behavior and limitation of nested classes in Groovy 1.7.0 Release Notes.

Unlike in Goovy, in each of Grails 1.3.x branch releases new features are implemented. Its current version (1.3.4) uses Spring 3.0.3. With 1.3.0 and the following quite a few changes were made:

• GORM:

  • dirty checking for domain classes with .isDirty() and .isDirty(’fieldName’) methods

  • Hibernate derived properties – domain class property value can be now calculated from a formula; here is a nice post on derived properties themselves.

  • named queries can be combined – nested within another named query, chained one by one or made more specific by supplying additional conditions when invoked

  • .find() and .findAll() query results can now be cached

• GSPs:

  • default layout – if defined, it will be used by all pages that do not explicitly declare to use one

  • <g:join> tag concatenates strings separating them with a specified delimiter

  • <g:unless> tag is a handier version of negated <g:if>

• filters

  • the order in which filters are executed can be specified

• testing:

  • upgraded to JUnit 4

  • TagLib testing allows to test custom tags that use the pageScope property

• plugins

  • classes, views and templates provided by plugins can be overridden

  • inline plugins don’t have to be plugin-packaged before use

• dependency management:

  • you can specify plugin repositories you want to use in BuildConfig.groovy

  • publishing plugins on Maven compatible repositories

  • declaring plugin dependencies with the IvyDSL

• every-day use:

  • script name typo detection in command line

  • when creating artifacts suffixes like *Controller, *Service are now added only when user hasn’t supplied one

  • multiple HTTP proxy configuration

  • grails doc –-pdf exports generated documentation to PDF and –-init generates a documentation template

Grails release notes for more details:

http://www.grails.org/1.3 Release Notes

http://www.grails.org/1.3.1 Release Notes

http://www.grails.org/1.3.2 Release Notes

http://www.grails.org/1.3.4 Release Notes

As for IDEs – having used Netbeans and Spring Tools Suite lately I must say, that the latter is a long awaited improvement in Groovy/Grails free IDE support. There is still a lot to be done, but at the moment syntax highlighting works quite well, code completions gives some hints without making you wait for ages, and even refactoring works sometimes .

• ClusterJPA – narzędzie do obsługi klastra w oparciu o MySQL i JPA
• Spring ROO – dynamicznie się rozwija, wykorzsytywać w projektach springowych
• HPPC – Biblioteka do wydajnych kolekcji typów prymitywnych
• Eclipse RAP webowa wersja Eclipse RCP
• Wykorzystywanie komet do serwisów odświeżanych w czasie rzeczywistym. Wsparcie dla GWT oraz Grails
• Gradle – sprawdzic zamiast Maven’a, wydaje sie być bardziej elastyczny, także dlatego, że oparty jest o Groovy
• Akka lib – przykład wykorzystania aktorów dla współbiezności
• Project Coin – JDK 7 i małe zmiany w języku
• IBM dostarcza zestaw narzędzi dla tuning’u wydajności w javie
• Eclipse memory analyzer jako narzędzie do analizy wydajności aplikacji
• Współbieżność w Groovy z wykorzystaniem biblioteki GPars
• statyczna analiza kodu – zastosowanie JSR-308
• Apache Camel – narzędzie do zastosowania w projektach integracyjnych, implementuje wzorce z książki Enterprise Integration Patterns
• Obserwować rozwój Griffon’a i zastosować do projektów java desktop / swing

Vaadin to framework przeznaczony do budowy graficznego interfejsu użytkownika dla aplikacji internetowych tworzonych z wykorzystaniem języka Java. Całe rozwiązanie oparte jest o Google Web Toolkit (GWT). Paleta gotowych komponentów jest dość szeroka, można w niej znaleźć m.in. kontrolki do obsługi kalendarza, tabel, do budowy menu itp. jeśli jednak okazało by się to niewystarczające można utworzyć własny komponent.

Na stronie projektu dostępny jest plugin dla środowiska Eclipse. Opisany w dalszej części przykład został wykonany właśnie z wykorzystaniem tego pluginu.

Konfiguracja

Struktura projektu wykorzystującego framework Vaadin nie różni się praktycznie niczym od zwykłej aplikacji internetowej wykonywanej za pomocą Javy, nie ma żadnych zbędnych plików i katalogów, które niekiedy potrafi wprowadzić sporo zamieszania.

W pliku web.xml zdefiniowany został m.in. serwlet obsługujący żądania, jego parametr inicjujący zawiera identyfikator klasy, na podstawie której zostanie wygenerowany pierwszy widok (zaraz po uruchomieniu aplikacji). Sama klasa serwletu jest częścią frameworka Vaadin. Domyślnie włączony jest tryb debagowania.

<context-param>
  <description>Vaadin production mode</description>
  <param-name>productionMode</param-name>
  <param-value>false</param-value>
</context-param>

<servlet>
  <servlet-name>Simplevaadinexample Application</servlet-name>
  <servlet-class>
    com.vaadin.terminal.gwt.server.ApplicationServlet
  </servlet-class>
  <init-param>
    <description>Vaadin application class to start</description>
    <param-name>application</param-name>
    <param-value>pl.espeo.example.MainWindow</param-value>
  </init-param>
</servlet>

Przykładowa aplikacja

Każda aplikacja wykorzystująca framework Vaadin musi posiadać klasę, która dziedziczy po klasie Application i implementuje metodę init(). W tworzonej aplikacji tą rolę pełni klasa VaadinApp, dodatkowo został wykorzystany interfejs ClickListener do obsługi zdarzeń obiektu Button.

public class VaadinApp extends Application implements ClickListener {

 private Window mainWindow;
 private Window subWindow;
 private Button closeButton;
 private Label label;

 @Override
 public void init() {
 mainWindow = new Window("Main window");
 createSubWindow();
 mainWindow.addWindow(subWindow);
 setMainWindow(mainWindow);        
 }

//...
}

W metodzie init() stworzone zostało główne okno programu stanowiące kontener dla pozostałych elementów graficznego interfejsu użytkownika.

 private void createSubWindow() {
   VerticalLayout layout = new VerticalLayout();
   layout.setSpacing(true);
   layout.setMargin(true);    

   label = new Label("Window content");
   closeButton = new Button("Close");
   closeButton.addListener(this);

   layout.addComponent(closeButton);

   subWindow = new Window("Window");
   subWindow.addComponent(layout);
   subWindow.center();
   subWindow.setClosable(false);
 }

 @Override
 public void buttonClick(ClickEvent event) {
   mainWindow.removeWindow(subWindow);
 }

Metoda buttonClick pochodzi z interfejsu ClickListener, jej wywołanie powoduje usunięcie okna z okna głównego aplikacji.

Podsumowanie

Vaadin framework stanowi ciekawą alternatywę dla tworzenia tradycyjnego tworzenia widoków – za pomocą jsp, html css itd. W końcu cała aplikacja może być napisana w Javie.

Sposób implementacji poszczególnych elementów jest bardzo podobny do Swinga co moim zdaniem należy uznać za duży plus. Wydaje mi się, że Vaadin świetnie sprawdziłby się w mały i średnich projektach.

Speed Tracer jest dodatkiem do przeglądarki Google Chrome, który umożliwia analizę wydajnościową aplikacji webowych (nie tylko tych tworzonych w GWT). Speed Tracer pozwala na bardzo dokładne przyjrzenie się działającej aplikacji, wliczając w to np. obserwację zdarzeń JavaScript’owych. Zamiast wymieniać następne funkcjonalności narzędzia Speed Tracer, lepiej obejrzeć krótki (1:40) tutorial, gdzie wszystko jest bardzo ładnie pokazane. Warto zwrócić uwagę na naprawdę rewelacyjny interfejs aplikacji (zrobiony oczywiście w GWT ).

Myślą przewodnią nowej wersji GWT są szybsze aplikacje webowe. Szybsze zarówno w sensie szybkości ich działania, jak i szybkości developmentu. Lista zmian i nowości jest naprawdę duża. Zwrócę więc uwagę tylko na te najważniejsze (moim zdaniem).

Wersja 2.0 zdecydowanie poprawia cykl edycja/odświeżenie przez wprowadzenie tzw. development mode, który pozwala uruchomić w trybie debug projekt GWT w dowolnej przeglądarce, a nie jednej, dedykowanej (jak to było wcześniej). Oznacza to, że nareszcie można używać Firefoksa albo Chrome’a przy tworzeniu aplikacji GWT, a wraz z nimi -- pakietu ulubionych rozszerzeń na czele z Firebugiem . Nie obeszło się przy tej okazji bez zmiany Google Plugin for Eclipse, którym teraz można całkowicie kontrolować development mode z poziomu naszego ulubionego IDE . Jeszcze trochę z ciekawostek: development mode działa przez sieć. Można więc “przypiąć się” do zdalnej sesji przeglądarki. Wydaje się to szczególnie przydatne dla Linuksiarzy, którzy mogą tylko zgadywać jak wygląda ich aplikacji w IE pod Windows. (Nawet z GWT pewnych rzeczy się nie przeskoczy…)

Kolejna wielka zmiana, która dla mnie osobiście wydaje się być szalenie interesująca, to wprowadzenie nowego, deklaratywnego sposobu konstruowania interfejsu użytkownika o nazwie UiBinder. Założenie jest takie, by uczynić łatwą (a przy okazji trochę wymusić) separację warstwy widoku od logiki aplikacji. Pomysł polega na tworzeniu dwóch plików dla każdego komponentu warstwy prezentacji. Aspekty widoku zawarte są w pliku .ui.xml, który stanowi “mieszankę” normalnego HTML’a oraz komponentów widoku (ang. widgets). Sama implementacja logiki aplikacji pozostaje natomiast w osobnym pliku .java. Pozwala to na bardzo wyraźną separację tych dwóch zagadnień i np. bardziej efektywną współpracę programistów oraz web designerów. Dodatkowo, w czasie kompilacji sprawdzane są wszystkie referencje między powyższymi plikami, więc nie ma mowy o żadnych literówkach i tego typu błędach. Naturalnie, Google Plugin for Eclipse wspiera to rozwiązanie w 100%, wliczając refactoring, uzupełnianie kodu itd.

Najnowszy Google Web Toolkit wprowadza również tzw. layout panels, pozwalające na dokładne rozmieszczenie elementów w obrębie strony. Nie ma co ukrywać, że używając HTML i CSS jest to duży problem, który najczęściej wymusza użycie pewnych “sztuczek”. Nawet we wcześniejszych wersjach GWT czasami trzeba było pokombinować, żeby coś wyglądało tak jak trzeba we wszystkich przeglądarkach. Nowe rozwiązanie bazuje tylko na standardzie CSS, co ma dać layout nie tylko bardziej stabilny i przewidywalny, ale również szybszy (znane są dość spore problemy wydajnościowe przy zmianie rozmiaru okna przeglądarki we wcześniejszych wersjach GWT). Layout panels, jak łatwo się domyślić, doskonale sprawdzają się w połączeniu z UiBinder.

Kluczową nową funkcjonalnością w GWT 2.0 jest programowe rozdzielanie kodu (ang. code splitting). Polega to na wskazaniu (w kodzie źródłowym), które komponenty muszą być wczytane “z góry” i są konieczne do załadowania aplikacji, a które można doczytać chwilę później. To tak trochę jak oglądanie filmu na YouTube: nie trzeba przecież wczytać całości, żeby rozpocząć oglądanie. Moim zdaniem to świetne rozwiązanie. Mamy do czynienia przecież z aplikacjami webowymi; tutaj nie może być poczucia, że coś jest “instalowane”. Taką aplikację otwieramy i już ma być; każąc użytkownikowi czekać 15 sekund na pojawienie się pierwszego ekranu, możemy go łatwo stracić. Świetne wyniki tutaj uzyskał zespół Google Wave. W chwili obecnej skompilowana, pełna funkcjonalność tej aplikacji to “ważący” prawie 1500 kB JavaScript, który trzeba przecież ściągnąć od razu. Dzięki zastosowaniu rozdzielania kodu, początkowo użytkownik ma do pobrania 200 kB (a po kompresji już tylko 80 kB), a reszta jest “dociągana” w czasie, gdy zastanawia się gdzie by tu kliknąć. Różnica właściwie o rząd wielkości! Częściowo zasługa w tym również nowej wersji kompilatora, który tak czy inaczej “odchudza” kod nawet o ponad 20%. Można bez problemu skompilować starsze aplikacje. W moim ostatnim projekcie w GWT dało to oszczędność 14% (właśnie sprawdziłem ) tak po prostu, bez dotykania kodu źródłowego.

Z mniejszych zmian, nastąpiło ulepszenie mechanizmu paczek (ang. bundles). Teraz zamykać w paczki można nie tylko grafiki, ale pliki dowolnego rodzaju. Jest również specjalny rodzaj paczki dla plików CSS, który automatycznie optymalizuje dołączone arkusze stylów.

Podsumowując, GWT 2.0 wydaje się być znaczną aktualizacją tego produktu. Poprawiono zarówno efektywność pracy z technologią (co w konsekwencji zmniejsza koszt tworzenia oprogramowania), jak i wydajność samych aplikacji. Google Web Toolkit niewątpliwie potwierdza swoją mocną pozycję na rynku nowoczesnych technologii front-end’owych dla aplikacji webowych. Dla mnie osobiście, jest to już od dawna faworyt w tej kategorii, który coraz bardziej rośnie w siłę. Gorąco zachęcam do pobrania nowej wersji biblioteki i przyjrzenia się wprowadzonym zmianom. Zainteresowanych kieruję na stronę produktu.

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