Wrażenia po seminarium na Uniwersytecie Zielonogórskim = będzie JUG Zielona Góra

To było szybkie, sprawne i niezwykle pouczające doświadczenie. Seminarium na Uniwersytecie Zielonogórskim trwało niespełna pół dnia, ale wierzę, że uczestnicy zdobyli równie dużo wiedzy, co ja, kiedy to przyszło mi ułożyć dotychczasową wiedzę w coś strawnego.

Podróż do Zielonej Góry przebiegła całkiem przyjemnie - stosunko luźno w pociągu i nawet przesiadka na lokalny skład w Zbąszynku nie zepsuła ogólnego wrażenia, całkiem pozytywnego. W trakcie jazdy udało mi się w końcu znaleźć czas na lekturę książki OSGi and Equinox: Creating Highly Modular Java Systems z Addison-Wesley Professional, więc tym bardziej pozytywnie wspominam podróź.

Do Zielonej Góry dotarłem około 20:00 i już na dworcu zostałem przywitany przez mojego podopiecznego z praktyk studenckich ESI w IBM - Marka Szpaka, który współprowadził seminarium oraz dra Andrzeja Marciniaka, który jest promotorem pracy inżynierskiej Marka. Po krótkiej wizycie w hotelu pojawiliśmy się w Winnicy, gdzie spotkaliśmy się z innymi osobami około 21:00. Dzięki temu spotkaniu miałem możliwość zasmakować pysznego łososia w sosie z zielonej herbaty i rizotto, a w części społecznościowej - ludzi z lokalnych firm, którzy poczuli klimat wokół zorganizowania lokalnego, zielonogórskiego JUGa! Brawa i gratulacje za inicjatywę, pod którą podpisuję się obiema rękoma. Na spotkaniu pojawił się również Piotr Kobzda, który, jak sobie później uzmysłowiłem, był pierwszym zielonogórzaninem, którego miałem przyjemność poznać lata temu. Przeszliśmy do pobliskiego pubu na piwo i o 23:00 byłem spowrotem w hotelu.

Trema niemała, więc jeszcze zabrałem się za ponowne przejście z przykładami, bo plan mojego wystąpienia zakładał, aby całkowicie zrezygnować ze slajdów na rzecz programowania na żywo. Dzięki Łukasz ("Smok" Rybka) za inspirację i podtrzymanie pomysłu przy życiu. Jestem zobowiązany i niezwykle wdzięczny za radę!

Co zaplanowałem pokazać praktycznie, na żywo, zostało zrealizowane. Chciałoby się więcej, lepiej, sprawniej, ale mam wrażenie, że ogólnie było nieźle. Zresztą komentarze podczas i po seminarium mówią same za siebie. Tak wyraził się troken:

"Świetna prezentacja. Wielkie dzięki za przyjazd. Takie spotkania po prostu zarażają pasją do szukania coraz to lepszych rozwiązań."

oraz d3ny:

"Chcialbym podziekowac za swietny wystep w Zielonej Gorze. Dla mnie, a jestem osoba mniej doswiadczona w zakresie Javy byl to bardzo profesionalny wyklad. Pomysl "wiecej IDE" byl w pelni trafny, bo krociutki kod + prezentacja dzialania zawsze najlepiej obrazuje, co w trawie piszczy. Warto dodac, iz prezentacje prowadzona bardzo zywo, rzeklbym nawet, ze momentami przebojowo. Bardzo milo sie sluchalo, na 'spanie' nie bylo po prostu czasu:)
Ze strony zwyklego sluchacza-studenta powiem tylko "Serdeczne dzieki!"."

czy opinia Kamila Łuszczki:

"Prezentacja bardzo fajnie przedstawiona, zdecydowanie pokazywanie kodu a nie samych slajdów jest dużo lepszym rozwiązaniem a zarazem bardziej interesującym. Mimo tego że z programowaniem w Javie nie mam zbyt dużego doświadczenia tym bardziej w korporacyjnej Javie, bardzo dobrze się Ciebie słuchało i można było się dowiedzieć dość sporo. Wyczerpałeś i przedstawiłeś temat na tyle że jeżeli ktoś miał styczność z programowaniem to na pewno dużo z tego spotkania wyniósł. Spotkanie jak najbardziej na duży plus."

Wszystkie komentarze można znaleźć pod moją zapowiedzią na Seminarium na Uniwersytecie Zielonogórskim - Java Contexts and Dependency Injection oraz Enterprise OSGi.

Na seminarium naliczyłem ponad 100 osób, które rozkładały się równomiernie na studentów oraz pracowników lokalnych firm. Byli zatem i praktycy programujący w Javie na codzień, ale i tacy, którzy poznali się z OSGi jeszcze na długo przez moim przybyciem. Pozdrowienia dla załogi z Max Elektronik S.A. oraz ADB Poland - Zielona Góra. Spotkałem również osobę, którą spotkałem już podczas naszych warszawskich konferencji (!) Było na prawdę ciekawie i inspirująco. Wyraz twarzy uczestników przybierał wszelkie możliwe formy.

Dzięki zaproszeniu Marka i Andrzeja mój zapał do OSGi ponownie nabrał mocy i zamierzam częściej z nim obcować. Książki są już na półce, więc choćby recenzji pojawi się więcej. Może nawet artykułów i skinkastów? Plany obszerne, ale jak to mówią "dobrymi chęciami, piekło wybrukowane", co mnie nie zraża, bo "nadzieja umiera ostatnia" i raczej zdążę, aby coś, nawet niewielkiego, maluczkiego z tego wyprodukować! :)

Na zakończenie, chciałbym gorąco podziękować Markowi i Andrzejowi za zaproszenie na seminarium oraz jego uczestnikom, którzy spisali się na prawdę wspaniale zadając pytania, wyrażając swoje zainteresowanie (lub brak) różnymi częściami ciała, ale przede wszystkim obecnością. Bardzo, bardzo dziękuję! Jeśli czegokolwiek mógłbym sobie życzyć więcej, to kolejnych tego typu spotkań. Mówi się, że jest plan na więcej w Zielonej Górze. Trzymam za słowo i zgłaszam się na ochotnika-prelegenta czy po prostu pomocnika przy rozkręcaniu lokalnej społeczności javowej.

Seminarium na Uniwersytecie Zielonogórskim - Java Contexts and Dependency Injection oraz Enterprise OSGi

To już w tę środę, 25 maja 2011 w Zielonej Górze na ulicy Podgórnej, gdzie uczestniczę w seminarium nt. Java Contexts and Dependency Injection (CDI) oraz Enterprise OSGi wspólnie z moim podopiecznym z praktyk studenckich w IBM - Markiem Szpakiem.

Temat pojawił się w naszych głowach, kiedy to Marek zastanawiał się nad tematem pracy magisterskiej (patrz: Praca inżynierska z JSF2? Może jednak CDI i OSGi?) i zaproponowałem mu, abyśmy wspólnie zorganizowali małą rozgrzewkę w postaci seminarium. Szczęśliwie, Marek nie potrzebował specjalnych zabiegów mentorskich, aby pomysł przypadł mu do gustu i tak oto, po tygodniach organizacji, wydeptywania ścieżek do odpowiednich organów uczelni, mamy upragnione seminarium.

Zapraszam wszystkich do udziału i zapewniam, że bez Twojej aktywności, moja będzie...jak zwykle. Największym moim problemem jest próba dopasowania się do wszystkich odbiorców, bez wyjątków. Nie można wyobrazić sobie trudniejszej publiki niż uczelniana, w której zasiadają zwykle początkujący, ale nie brakuje również bardziej zaawansowanych graczy. Trudno wtedy zaczynać od początku, aby nie zrazić bardziej zaawansowanych, ale rozpoczęcie od pewnego poziomu zrazi nowicjuszy. I jak tu doradzić? Chciałoby się zacząć wszystko od początku, najlepiej w postaci serii wykładów, ale to w tym momencie niemożliwe. Zaczniemy na przemian, najpierw trochę teorii, później praktyki. I tak dla CDI, i dla Enterprise OSGi. Tym razem zaplanowałem więcej sesji z IDE, a dopiero pod koniec spróbuję podsumować w postaci slajdów. Życz mi powodzenia!

Confitura 2011, 33rd degree, GeeCON i InfoShare oraz "markowy" inż. z OSGi i CDI

Dla tych, którzy spędzają wolne chwile z dala od komputera i mają tą rzadko spotykaną "przypadłość" cieszyć się wolnością umysłu bez wpływu facebooka, twittera, blogów, grup, forów i innych, mniej lub bardziej zajmujących serwisów, donoszę, że długooczekiwana data nie mniej długooczekiwanej konferencji polskiej społeczności javowej Confitura 2011, pod silnym przewodnictwem grupy Warszawa JUG, odbędzie się 11. czerwca 2011. Organizatorzy wierzą, że nie będzie to kolidowało z żadnymi z Twoich planów i stawisz się dzielnie podjąć każde wyzwanie intelektualne podczas konferencji.

Z pewnych rzeczy, to z pewnością miejsce - Warszawa, wspomniany termin - 11.czerwca oraz...cóż, chyba mi się skończyły pewne rzeczy. Agendy jeszcze nie ma, bo plan zakładał jej ustalenie po zebraniu propozycji tematów, o czym niebawem. Więcej na stronie konferencji Confitura 2011.

Jako współorganizator będę robił wszystko^H^H^Hwiele, aby konferencja była największą pod względem możliwości wymiany doświadczeń (jej wielkość niech będzie liczona możliwościami zdobycia praktycznej wiedzy i pomysłami, a nie liczbą uczestników) i chciałbym, aby pojawiło się wiele osób nowych, niekoniecznie z doświadczeniem występowania publicznego. Niech Confitura będzie platformą nauki, a buława prelegenta dana będzie wizjonerom, a nie oratorom (oczywiście osoby łączące te cechy są bardziej niż mile widziane). Zapraszam do udziału w konferencji w roli uczestnika i/lub prelegenta, z naciskiem na tą drugą. Warto! W razie jakichkolwiek wątpliwości zaleca się kontakt ze mną. Sprawdziłem i działa.

Skoro o konferencjach to pojawię się jeszcze na 33rd Degree w Krakowie, w dniach 6-8.04, InfoShare 12-13.05 w Gdańsku oraz GeeCON w Krakowie, w dniach 11-14.05.

Na pierwszej dwóch - 33rd Degree oraz InfoShare - biorę udział jako prelegent z tematami dotyczącymi EJB 3.1, CDI oraz językiem funkcyjnym Clojure. Nie zamierzam wprowadzać w temat, a podzielić się znaleziskami, których część mogłem już przedstawić na tym i moim angielskojęzycznym blogu - http://blog.japila.pl. Znużyło mnie ciągłe wałkowanie tematu od zera, co ani mnie nie bawi (wręcz zaczyna nużyć), a wielu przyprawia o ból głowy musząc słuchać tego samego w nieznacznie zmienionej postaci. I tylko wieje nudą. Szanujmy swój czas, co zamierzam zastosować właśnie podczas wspomnianych konferencji.

Na 33rd Degree będę wyłącznie w piątek, 8.04 (z noclegiem w Krakowie przed i po), a na InfoShare 13.05 (prawdopodobnie z noclegiem do soboty). Piszę o tym, aby pozwolić sobie na przyjemność spotkania się z osobami, z którymi mógłbym przegadać to i owo, a z którymi nie dane mi było spotkać się do tej pory. Zwykle to właśnie dyskusje pozwalają na ugruntowanie wiedzy, a nie bierny udział w prezentacji i możliwość spotkania się wieczorem w pubie czy restauracji uważam za obowiązkowy.

Uważni mogli zauważyć, że terminy InfoShare oraz GeeCON pokrywają się. Dzięki uprzejmości organizatorów GeeCONa otrzymałem wejściówkę, więc łącząc przyjemne z pożytecznym na GeeCONie pojawię się 11-12.05, aby wieczorem udać się do Gdańska, w którym chciałbym spędzić czas do soboty. Nie będzie lekko opanować terminy i chęć zamienienia słowa z uczestnikami, ale nikt nie mówił, że powinno. Na projektach też nie jest lekko, a jednak mają coś magicznego, co nas do nich wciąż ciągnie.

I ostatnia sprawa, nie mniej ważna, o której zaplanowałem napisać - praca inżynierska mojego podopiecznego z praktyk studenckich w IBM - Marka Szpaka dotycząca "analizy połączenia CDI i OSGi (na przykładzie serwera aplikacyjnego GlassFish i IBM WebSphere Application Server) oraz zaprezentowania rozwiązania wolnego od konkretnego serwera aplikacyjnego."

Na temat samych praktyk można przeczytać chociażby na grupie GoldenLine Praktyki w IBM Polska, albo bezpośrednio u "producenta" - IBM Educational Student Internships i gorąco zachęcam do wzięcia w nich udziału. Nie stronię od nawet najbardziej opornych studentów, którym się jednak chce coś zrobić i na brak wrażeń nie można narzekać.

Marek nie tylko próbuje rozpracować możliwość budowania aplikacji korporacyjnych JEE6 z użyciem CDI i OSGi, o czym będzie można przeczytać w jego pracy, ale również organizuje prelekcję na ten temat na swojej uczelni - Uniwersytecie Zielonogórskim. Co mnie bardzo ucieszyło, zaprosił mnie nawet w roli współprelegenta (!) Opiekunem tematu jest pan dr inż. Andrzej Marciniak. Na chwilę obecną wiadomo jedynie co będzie przedstawione - CDI, OSGi i ich połączenie z GlassFishem i WASem, kto - Marek i Ja, a z terminem to jedynie "jeszcze w tym semestrze, to jest najpóźniej pod koniec maja/początek czerwca." Zainteresowanych już informuję, a dalsze informacje niebawem. Wszelkie sugestie mile widziane, czy to związane z terminem, czy też zakresem merytorycznym. Niech to będzie przyczułek do wymiany wiedzy, która mogłaby zaowocować jakimś ciekawym projektem OSS, a może i produktem komercyjnym (?)

Tym samym chciałbym oficjalnie podziękować Markowi i Uniwersytetowi Zielonogórskiemu w osobie p. dra inż. Andrzeja Marciniaka za umożliwienie mi zgłębienia tematu, co powinno przyczynić się do większego rozpoznania tematu po obu stronach, również z korzyścią dla czytelników tego bloga.

Pierwsza połowa 2011 zapowiada się baaardzo interesująco merytorycznie. Już wiem, że druga również, ale o tym jeszcze ciiiii. Czego lepszego mogłem sobie życzyć w 2011. Normalnie bajka!

Mechanizm zdarzeń w CDI z JBoss Weld, Arquillian i Apache Maven 2

Dla zainteresowanych zgłębianiem tajników nowości Java Enterprise Edition (JEE) 6, a dokładniej JSR-299: Contexts and Dependency Injection for the Java EE platform (w skrócie CDI) mam miłą niespodziankę - nowy artykuł Mechanizm zdarzeń w CDI z JBoss Weld, Arquillian i Apache Maven 2.

W artykule znajdziesz wystarczająco wiele, aby poznać mechanizm zdarzeń w CDI, który łudząco przypomina powszechnie (u)znany wzorzec Obserwator (ja jednak wolę nazwę Słuchacz) oraz wzorzec komunikacyjny Publish/subscribe.

Niezwykle mocny mechanizm do użycia w ramach Java EE 6, ale również i na poziomie samego Java SE (tutaj niestety wciąż bez wspólnego interfejsu dostępowego ala JPA, JMS czy JDBC). Mam nieodparte wrażenie, że czas potrzebny do zapoznania się z moim artykułem jest niewspółmierny do dawki wiedzy, jaką nim przekazuję (na korzyść pozyskanej wiedzy oczywiście).

Gorąco zachęcam do lektury Mechanizm zdarzeń w CDI z JBoss Weld, Arquillian i Apache Maven 2 i do kontaktu ze mną celem ustalenia dalszych kroków przy rozpoznaniu specyfikacji CDI i Java EE 6 w ogólności. Skoro mi się chce i znajduję na to czas, a Tobie nie jest to dane, rozważ chociaż przesłanie wskazówek odnośnie formy i treści przyszłych artykułów?

33rd degree i ja z "EJB 3.1 vs Contexts and Dependency Injection (CDI) and Dependency Injection for Java in Java EE 6"

Skoro większość z Was wskazuje na Java EE 6 jako temat przewodni grudnia, to może niech i tak zostanie w nadchodzącym roku 2011. Ot, taka mała zapowiedź dalszych poczynań w blogosferze oraz konferencyjnie.

W mojej skrzynce pocztowej znalazłem wiadomość o nadchodzącej konferencji 33rd degree. Niewiele o niej wiadomo, bo temat bardzo, bardzo świeży. Mógłbym założyć, że na tyle, że jestem pierwszym, który pisze o tym na blogu (poza zapowiedzią u samych organizatorów - Wymarzona konferencja nadchodzi).

Piszę o tym, gdyż jest to kolejna konfencja javowa w Polsce, obok JDD, NYAC, GeeCON, Javarsovia, warsjawa, java4people czy 4Developers. Mimo, że wiele z nich cieszy się renomą, widać, że wciąż jest miejsce dla kolejnej. Do grona "uczestników" sceny konferencyjnej dołącza 33rd degree. Jak na tak niewielki kraj, możemy powiedzieć, że tyle u nas konferencji co partii politycznych (!) Może kiedyś dojdzie do jakiś fuzji konferencyjnych?! Tak czy owak, będzie wiele okazji, aby się spotkać i wymienić doświadczeniami. Będę miał w tym swój wkład!

Należy dodać, że markę 33rd degree chce się zbudować na "Top quality speakers that usually talks at big conferences and were chosen many times as Rock Stars" oraz "All speakers were invited personally and validated in practice. No surprises expected. Only great talks." (za stroną domową konferencji).

I teraz o moim wkładzie, a raczej wykładzie. Tak, tak, będę miał swoje 60 minut na przedstawienie tematu EJB 3.1 vs Contexts and Dependency Injection (CDI) and Dependency Injection for Java in Java EE 6. Na razie mam jedynie szkic, co chciałbym przekazać słuchaczom i w jaki sposób, aby dotrzymać kroku innym wystąpieniom, gdzie slajdy należy potraktować za...relikt przeszłości i eksponat muzealny. Sprawa się będzie klarowała w kolejnych miesiącach.

Pora na rozlosowanie specjalnych kodów promocyjnych. Mam ich 10 (i nie zawaham się ich użyć pro publico bono). Niech jednak będzie to transakcja wiązana (bodaj jedyna legalna forma obdarowywania bezkosztowo w PL), gdzie ja Tobie, a Ty mi i jesteśmy kwita. Proszę o wyrażenie swojej opinii nt. połączenia wystąpienia z wcześniej przygotowanymi nagraniami (coś ala skrinkasty) i lokalnym repozytorium wersji kodów źródłowych, aby zamiast klepania (rękoma i ustami) interakcja między prelegentem a uczestnikami przebiegała znacznie szybciej i bez ryzyka utraty tempa czy toku rozumowania. Rola prelegenta sprowadziłaby się do zaprezentowania nagrań i uzupełniania ich słowno-muzycznie. Czy to ma rację bytu? Wsród osób, które wyrażą swój głos w komentarzu do tego wpisu rozlosuję po jednym specjalnym kodzie promocyjnym na konferencję 33rd degree.

Odkrywcze podobieństwo Java SE i Java EE z CDI na czele

Każdy, kto programuje w Javie "siedzi" na poziomie Java Standard Edition, w skrócie Java SE, czy wręcz JSE. Obecna wersja to 6.0. Mamy do dyspozycji cały zestaw interfejsów i klas - wszystko objęte terminem Java SE API. Dokumentacja do aktualnej wersji znajduje się na stronach Java Platform, Standard Edition 6 API Specification. To powinno być oczywiste i należy do podstawowej wiedzy programisty Java.

Co jednak nie jest już tak oczywiste, to jak niewiele różni obecnie JSE od kolejnego zestawu Java API o nazwie Java Enterprise Edition, w skrócie Java EE, albo po prostu JEE. Zwracam Twoją uwagę na termin "kolejny zestaw Java API". Od lat siedzę przy obu zestawach - JSE i JEE, a jednak dopiero teraz dotarło do mnie, jak niewiele je różni - wszystko za sprawą środowiska uruchomieniowego, które określa zachowanie naszej aplikacji.

Do wersji JSE 5.0 wcale nie było oczywistym, że umiejętność programowania na platformie JSE jest równoznaczna z JEE. Nie grzebiąc za długo w historii JEE postawię tezę, że umiejętność posługiwania się JSE była dalece niewystarczająca od posługiwania się JEE. Wiele się być może nie zmieniło chyba, że nie mówimy o właściwym użyciu API (semantyce), a jedynie umiejętności użycia konstrukcji (składni). Tu widzę duże uproszczenia.

Od wersji JSE5 mamy adnotacje. Możliwość dopisywania metainformacji na różnym poziomie naszych bytów javowych - interfejsów, klas, pól i metod. Szybko zauważono ich zaletę i zaraz wprowadzono na JEE. I jakkolwiek tworzenie aplikacji na poziomie JSE zmieniło się nieznacznie, to w przypadku JEE postęp jest ogromny.

Poniżej klasa do uruchomienia na platformie JSE.

package pl.jaceklaskowski.blog;

public class BlogEntry {
    private String title;

    public BlogEntry(String title) {
        this.title = title;
    }

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }
    
    public BlogEntry create(String title) {
        return new BlogEntry(title);
    }
}

Od wersji JSE5 można dodawać do klasy metadane w postaci adnotacji. Dwoma z adnotacji dostarczanych w ramach zestawu JEE5 są @Entity oraz @Id.

package pl.jaceklaskowski.blog;

import javax.persistence.Entity;
import javax.persistence.Id;

@Entity
public class BlogEntry implements Serializable {

    @Id
    private int id;
    private String title;

    protected BlogEntry() {
    }

    public BlogEntry(String title) {
        this.title = title;
    }

    public int getId() {
        return id;
    }

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

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }

    public BlogEntry create(String title) {
        return new BlogEntry(title);
    }
}

Poza dodaniem tych dwóch adnotacji pojawiły się również zmiany w samym kodzie klasy. I jakkolwiek samo użycie adnotacji nie wymaga ich, to użycie na platformie JEE może uczynić je obowiązkowymi do poprawnego użycia klasy. Aby ujawniła się ich obowiązkowość konieczne jest uruchomienie klasy w ramach platformy JEE, tj. serwera aplikacyjnego JEE (którego zadaniem jest udostępnienie usług respektujących wytyczne specyfikacji JEE) oraz użycie konstrukcji aktywujących daną funkcjonalność. Innymi słowy, samo uruchomienie w ramach serwera aplikacyjnego JEE nie jest równoznaczne z użyciem usługi, która interpretuje adnotacje. Nie zamierzam jednak tym razem wnikać w szczegóły i unikam wyjaśnień wskazując podręcznik The Java EE 6 Tutorial, a szczególnie rozdział Part VI Persistence. Obowiązkowa lektura dla każdego, któremu marzy się tworzenie aplikacji korporacyjnych w JEE, o których w kolejnych wpisach.

I te małe dodatki - metadane w postaci adnotacji - mnie dzisiaj zachwyciły. Podczas lektury artykułu w Sieci na temat tworzenia Web Services, olśniło mnie, że aplikując adnotacje do klasy i uruchamiając ją w ramach serwera aplikacyjnego dostajemy wiele przy tak niewielkim nakładzie pracy.

Przyjrzyj się poniższej klasie.

package pl.jaceklaskowski.blog;

public class BlogPanel {
    public Blog createBlog(String title) {
        return new Blog(title);
    }
}

Niewiele w niej cech aplikacji korporacyjnej, którą cechuje użycie bazy danych (często wielu równocześnie), dostęp do innych zasobów transakcyjnych, różne protokoły dostępowe (wszechobecny HTTP może być uzupełniany przez chociażby FTP czy IMAP) czy bezpieczeństwo. To tylko niektóre z możliwych usług serwera aplikacyjnego JEE.

Przyjrzyjmy się kolejnej wersji wcześniejszej klasy BlogPanel, która różni się jedynie adnotacją @Stateless.

package pl.jaceklaskowski.blog;

import javax.ejb.Stateless;

@Stateless
public class BlogPanel {
    public Blog createBlog(String title) {
        return new Blog(title);
    }
}

Tym razem, poza @Stateless, nic więcej się nie zmieniło. Czyżby?

Jeśli uruchomisz tę klasę na serwerze aplikacyjnym JEE, okaże się, że wykonanie metody createBlog(String title) pociągnie za sobą wzbudzenie monitora transakcji i uruchomienie dedykowanej transakcji, która rozpocznie się i zakończy z rozpoczęciem i zakończeniem wykonania ciała metody. Dodatkowo, każdemu będzie wolno wykonać tę metodę, ale samo sprawdzenie zostanie wykonane. Jak widać, użycie tak niewinnie wyglądającej adnotacji @Stateless może odmienić zachowanie aplikacji, a jej czas wykonania wydłuży się kosztem opakowania jej usługami serwera.

Tak wiele, tak niewielkim kosztem - odkrywcze podobieństwo między JSE a JEE.

W JEE6 pojawiło się rozszerzenie oferowanego API o pakiety javax.enterprise.inject, javax.enterprise.context oraz javax.enterprise.event, które materializują wytyczne specyfikacji JSR 299: Contexts and Dependency Injection for the Java EE platform, w skrócie CDI. Sama specyfikacja jest częścią Java EE 6 i przez to obowiązkowa w ramach serwerów aplikacyjnych JEE6 (tu należy zwrócić uwagę na wersję wspieranego zestawu JEE - musi być 6).

I tutaj było moje największe odkrycie, a w zasadzie faktyczne przetrawienie wszystkiego, co do tej pory usłyszałem na temat JEE6, EJB 3.1, JSF 2.0, JPA 2.0, Servlets 3.0 i kilku innych.

Wszystkie byty na platformie JEE6 są opisywalne przez adnotacje.

Z tego płynie bardzo istotna wiedza pozwalająca zrozumieć sedno działania serwera aplikacyjnego JEE i związywania usług do odpowiednich składowych (komponentów) naszej aplikacji. Wystarczy zaaplikować adnotację i jak za dotknięciem czarodziejskiej różdżki pojawi się automagicznie pożądana funkcjonalność (ortogonalna do funkcjonalności biznesowej, którą oprogramowujemy i tu jest właśnie miejsca dla naszej inwencji twórczej).

Skoro CDI to specyfikacja odnosząca się do definiowania kontekstu funkcjonowania bytu zwanego ziarnem zarządzanym (ang. managed bean) - wcześniej termin zarezerwowany przez specyfikację JSF) i to właśnie kontekst wyznacza jego cykl rozwojowy (ang. lifecycle) - przejścia między stanami, w których wyróżnionymi są utworzenie i zniszczenie obiektu, wtedy można postawić tezę, że wszystko, co mamy do dyspozycji jako programiści JEE6 można oprzeć na CDI.

W ten sposób Resin - kontener webowy - oferuje EJB 3.1 przez CanDI. Pewnie będzie można zauważyć podobny trend w innych serwerach aplikacyjnych.

CDI jest również możliwe do uruchomienia na platformie JSE6, ale w takiej konfiguracji będziemy musieli rolę serwera przejąć na siebie i oprogramować w ramach aplikacji. Nawet, jeśli CDI i JEE6 nie są doskonałe, to są standardem, który zmierza w dobrym kierunku. Po czasach rozterek JEE vs Spring Framework+Hibernate mam wrażenie, że wybór staje się bardziej oczywisty. Mnie to cieszy.

Java EE 6 webapp development with CDI, GlassFish and NetBeans 7

Próbowałem się z NetBeans IDE 7.0 (wersja rozwojowa z dzisiaj) i kiedy sprawdzałem możliwości CDI z przekazywaniem (aka wstrzykiwaniem) zależności do servletu przyszło mi do głowy, aby nagrać moje doświadczenia. Nie są one wyrafinowane, ale chodziło mi raczej o popróbowanie się ze skrinkastami w kwadrans, aby nabrać większej umiejętności w tego typu przekazie niż na samej oprawie czy treści. Chciałem również sprawdzić, czy uda mi się opublikować nagranie na YouTube w formacie 1080p.

Zero podkładu głosowego, zero muzyni, niewiele treści merytorycznej, ale nagranie w Full HD jest. Tym samym 3-minutówka znalazła się na YouTube do oceny publiczności.

Teraz kolej na Ciebie. Zadanie na dziś to obejrzenie filmiku i ocena jego przydatności, a właściwie wskazanie niedoskonałości i tym samym zagwarantowanie sobie bardziej przyzwoitej treści w kolejnych odsłonach.

Zapraszam na swój kanał na YouTube do obejrzenia Java EE 6 webapp development with CDI, GlassFish and NetBeans 7.

p.s. Uruchomiłem ankietę "Temat przewodni na grudzień", której celem jest określenie tematyki, którą chciał(a)byś, abym rozpracowywał w ostatnim miesiącu tego roku - grudniu 2010. Zainteresowanych wyrażeniem swojego zdania zapraszam na blog, gdzie po prawej u góry znajduje się ankieta. Sugestie w postaci odpowiedzi "Inne?!" proszę o rozwinięcie na priv, albo w komentarzu do tego wpisu.

Praca inżynierska z JSF2? Może jednak CDI i OSGi?

Kilkakrotnie pytano mnie o tematy prac inżynierskich i magisterskich, a wtedy zaczyna się główkowanie, który byłby tym jedynym, interesującym. Kiedy wyszła Java EE 5 byłem zachwycony zmianami, podobnie z JEE6. Było też zainteresowanie OSGi i okolicami, teraz programowanie funkcyjne z Clojure, a w odwodzie kilka innych, mniej lub bardziej ciekawych zagadnień. Nawet dzisiaj zostałem poproszony o wyznaczenie tematów do przedstawienia studentom w ramach praktyk studenckich w IBM i w mgnieniu oka miałem 10 sztywno określonych i jeden otwarty, który rozpoczynał się od "Rozpoznanie wybranej funkcji* produktu z rodziny IBM WebSphere BPM". Współpraca ze studentami to niezwykle ciekawy i produktywny sposób na poznawanie nowego (człowieka i jego sposobu myślenia oraz samego tematu). Wszyscy zadowoleni.

Postanowiłem rzucić temat wyszukania czegoś ciekawego na bloga licząc, że ktoś ma pomysł w zakresie JavaServer Faces (JSF) 2.0, a boryka się z problemem braku czasu na jego dogłębne rozpoznanie w postaci pracy licencjackiej (to jakby nie patrzeć rok ślęczenia nad tematem!).

Autor ostatniej prośby napisał:

Czy istnieje możliwość nawiązania współpracy w zakresie mojej pracy inżynierskiej, naturalnie związanej z korporacyjną Javą. Chciałbym zrealizować temat nie tylko wartościowy merytorycznie ale i również interesujący z punktu widzenia programisty, wolałbym uniknąć pracy odtwórczej i skupić się na tym co mógłbym poprzez swoją pracę dyplomową wnieść od siebie. Jestem już po wstępnej rozmowie z moim promotorem, z którym rozważaliśmy możliwość podjęcia tematu związanego mniej lub bardziej z JSF 2.0. Wiem, że jesteś otwarty na różnorodne propozycje, dlatego po cichu liczę na email od Ciebie przesiąknięty entuzjazmem, który mnie nie opuszcza nawet na krok podczas rozważań nad tematem mojej pracy.

Na moją odpowiedź, raczej w tonie ostrożnej aprobaty, otrzymałem taką:

Dzięki za zainteresowanie moją propozycją, tak jak już wcześniej wspomniałem chciałbym poprzez swoją pracę dyplomową wnieść coś od siebie. Wykorzystanie JSF2 do zbudowania przykładowej aplikacji webowej jest ostatecznym rozwiązaniem, którego nawet nie chcę brać pod uwagę. Idealnym rozwiązaniem byłby temat oryginalny oraz interesujący.

W kwestii tematu właśnie liczyłbym na Twoją pomoc, z pewnością są zagadnienia związane z JSF2, którymi zainteresowany jesteś najbardziej. Wiedzę w tej dziedzinie masz nieporównywalnie większą niż moja, stąd zapewne mógłbyś zaproponować kilka interesujących pomysłów. Może istnieje jakieś komercyjne narzędzie (lub jego część), które czeka na swoją ogólnodostępną implementację? A może masz zupełnie inny pomysł na temat pracy?

I tutaj pojawiła się moja odpowiedź, już z wstępnym szkicem zakresu technologicznego pracy:

JSF2 jest ciekawe, ale coś mi mówi, że wiele tu już zrobiono i ciekawym mogłoby być użycie innej technologii tworzenia UI niż facelets czy JSP. Przyjrzałbym się jednak bardziej użyciu CDI w JSF i co do tej pory zrobiono. CDI jako rozwiązanie javowe weszło dopiero w JEE6, więc jest bardzo młode i pewnie wiele tutaj do zrobienia. Gdybym miał szukać ciekawego tematu właśnie koło CDI kręciłbym się, może w połączeniu z OSGi?! Właśnie CDI + OSGi wydaje się być nietrywialnym tematem dotykającym dwa rozwiązania. To byłoby cudo techniczne!

Uważacie, że JSF2, CDI i OSGi mogłoby być "produktywnym" stosem technologicznym? Co mógł(a)byś Ty zaproponować delikwentowi? Mnie zawsze intrygowało, czy dałoby się tak użyć JSF, aby zbudować aplikację desktopową? W końcu JSF dotyka warstwy widoku i aplikacje webowe są jedynie/aż implementacją referencyjną demonstrującą oferowane możliwości (albo ich brak) budowania niebagatelnego interfejsu użytkownika. Gdyby relacjonować JSF2, czy byłoby cokolwiek, co stanowiłoby dla Ciebie szczególnie ciekawe zagadnienie? Wszelkie propozycje będą uważnie rozpatrzone, a upublicznione mają niemałe szanse na realizację. Dla mnie będzie to stanowiło magnes do powrotu do Java EE 6, które zeszło na plan drugi po pojawieniu się Clojure, dla Ciebie zrealizowanie pomysłu cudzymi rękoma, a pytającemu zapewnią ciekawe spędzenie czasu przy pracy inżynierskiej. Wszyscy są do przodu!

[*] Dowiedziałem się dzisiaj, że nie ma liczby mnogiej od "funkcjonalność", a można mówić jedynie o funkcjach produktu (!)

Contexts and Dependency Injection (CDI) praktycznie - zestawienie środowiska z JBoss Weld, Arquillian i Apache Maven 2

Na moim Wiki pojawił się nowy artykuł dotyczący specyfikacji JSR-299: Contexts and Dependency Injection for the Java EE platform (w skrócie CDI).

W artykule Contexts and Dependency Injection (CDI) praktycznie - zestawienie środowiska z JBoss Weld, Arquillian i Apache Maven 2 przedstawiłem możliwość uruchamiania CDI na poziomie Java SE (bez serwera aplikacyjnego JEE6) z użyciem referencyjnej implementacji JBoss Weld z Apache Maven 2 i Arquillian, który znajduje się w ofercie załogi JBoss do testowania aplikacji korzystających ze specyfikacji Java EE 6.

Nie jest to specjalnie zaawansowany artykuł i taki był jego cel - gładko wprowadzić w temat uruchamiania "czystych" aplikacji CDI bez bagażu JEE6. CDI stanowi swego rodzaju alternatywę dla kontenerów IoC/DI jak Google Guice czy Spring Framework z tą zaletą, że jest ustandaryzowanym rozwiązaniem dostępnym w każdym serwerze JEE6, a czerpiącym ze swoich poprzedników całymi garściami. Obecna lektura książki Dependency Injection wydawnictwa Manning uzmysławia mi jak niewiele różni wszystkie z wymienionych - Guice, Spring i CDI (aczkolwiek samo CDI nie jest przedmiotem książki).

UWAGA: Kody źródłowe nie są jeszcze w repo. Do odwołania jest w trybie do odczytu i nie można nic zatwierdzać.

PROŚBA: Gdyby ktoś zechciał mi zaprezentować/opisać, w jaki sposób skorzystać z Gradle zamiast Maven2 byłbym niezmiernie wdzięczny. Wciąż nie czuję zalet jednego nad drugim.

Pomysły na kolejne tematy z CDI mile widziane. Zabieram sie za "przetrawienie" komentarzy dotyczących CDI z poprzednich, moich wpisów, na bazie których powstaną kolejne. Nawet nie wyobrażacie sobie jakie to szczęście móc dotykać tematów, które krążą koło siebie nierozerwanie i kiedyś stanowiły osobne rozwiązania, a obecnie zaczynają stanowić podstawy specyfikacji JEE6 np. facelets (w JSF2, gdzie CDI to główny gracz) czy dawno przeze mnie niewykorzystywany Apache Wicket (jako samodzielne rozwiązanie z CDI czy alternatywna technologia wizualizacji w JBoss Seam 3). Jednak znajomość ich wszystkich nie pomaga bynajmniej w podjęciu decyzji które i gdzie. Sądzę, że to równie trudna decyzja z i bez ich znajomości. A gdzie tu znaleźć się w sytuacji stworzenia czegoś nowego, alternatywnego do istniejącej oferty projektowej? Trzeba mieć na prawdę zawzięcie, aby nie ugiąć się nad wykorzystaniem istniejącego i stworzeniem nowego.

Dokończenie rozdziału 2. Koncepcje ze specyfikacji Java EE 6 Contexts and Dependency Injection (CDI)

Potwierdza się zasada, że jeśli tylko regularnie poświęcić chwilę, np. każdego dnia, na rozpoznawanie nowego, to po jakimś czasie nowe stanie się zwyczajne, aby ostatecznie stać się zrozumiałym. Tak też się dzieje w kontekście mojego poznawania specyfikacji JSR-299: Contexts and Dependency Injection for the Java EE platform (w skrócie CDI). Obłożyłem się specyfikacją, artykułami i przeglądam grupy dyskusyjne, i z każdym dniem wszystko staje się jasne (zgoda, może niekonieczne jasne, ale na pewno jaśniejsze).

Do tej pory zrelacjonowałem ze specyfikacji CDI (wszystkie w kategorii cdi):

1. Nauka Java EE 6 CDI (JSR-299) - relacja z lektury pierwszych dwóch rozdziałów specyfikacji
2. Lektura specyfikacji CDI (JSR-299) za mną, NetBeans 6.9 RC1 wydane i JSR-330 Dependency Injection for Java
3. Rozdział 2. Koncepcje ze specyfikacji Java EE 6 Contexts and Dependency Injection (CDI)
4. i jeden, dwa z przemyśleniami różnymi.

Dzisiaj, od dawna planowane, dokończenie relacji z rozdziału 2. Concepts.

W ostatnim wpisie w temacie CDI - Rozdział 2. Koncepcje ze specyfikacji Java EE 6 Contexts and Dependency Injection (CDI) - padło pytanie, które dla wielu jest banalne, ale dla pozostałych niekoniecznie:

Co różni instancję klasy stworzoną przez new, a tymi, przekazanymi przez kontener?

W Javie do tworzenia nowych obiektów (instancji) służy operator new. Możnaby przyjąć, że to funkcja specjalnego traktowania, gdzie parametrem wejściowym jest typ, którego instancję tworzymy, opcjonalnie z parametrami opisującymi jego stan początkowy. Tutaj żadnej magii nie ma. I nie będzie w CDI, Seam, Spring Framework, Guice, a nawet Aspect-Oriented Programming (AOP), jeśli będziemy pamiętać, że nie ma (znanego mi) sposobu konstruowania obiektów niż właśnie przez new. Tutaj się pojawia moje niezrozumienie dyskusji na temat różnic między CDI a AOP. Oba wymagają środowiska uruchomieniowego, nazywanego powszechnie kontenerem, w którym będą żyły nasze obiekty. Mówi się jednak, że jakaś różnica jest. Podobnie z orędownikami Spring Framework i jego konfiguracji opartej na XML, a CDI, w którym opieramy się głównie na adnotacjach. Aczkolwiek w obu, Spring Framework i CDI, możemy wykorzystywać XML do opisywania zależności i ich miejsc wstrzeliwania, to jednak i tutaj pojawiają się głosy nad wyższością Spring Framework i jego XML (nawet, jeśli nadto obszerny) a CDI z adnotacjami. Tak czy owak, we wszystkich uruchamiany jest kontener, który tworzy środowisko dla grafów obiektów (wyrażających interakcje między nimi), który w pewnym momencie uruchamia obiekt główny - to coś, co możemy nazwać początkiem naszej aplikacji.

A wracając do relacji z lektury specyfikacji CDI...

Sekcja 2.4 Scopes omawia przestrzeń dostępności ziaren (przez to i ich widoczności). Mówimy o ziarnach z określonym zasięgiem (ang. scoped beans), co oznacza, że tak na prawdę, przynależą one do innego obiektu - zasięgu - którego zniszczenie niszczy obiekty w nim żyjące. Każde ziarno jest przypisane do jednego i tylko jednego zasięgu. Jedynie ziarna o danym zasięgu, tj. występujące w danym obszarze, mogą ze sobą "rozmawiać".

Określenie zasięgu dla ziarna następuje przez adnotacje należące do pakietu javax.enterprise.context, np. @SessionScoped, który znamy ze specyfikacji Java Servlets.

Możemy tworzyć własne zasięgi, co sprowadza się do stworzenia nowej adnotacji oznaczonej meta-adnotacjami @javax.inject.Scope lub @javax.enterprise.context.NormalScope.

Określenie zasięgu ziarna to przypisanie do niego adnotacji zasięgu - na poziomie klasy ziarna, metody/pola produkującego.

Dla zwrócenia uwagi: ziarno musi należeć do jednego i tylko jednego zasięgu. Innymi słowy: nie możemy być jednocześnie w domu i w pracy (aczkolwiek takie anomalie coraz częściej zachodzą w naszym życiu).

Domyślny zasięg określony jest przez stereotypy. O tym za moment.

2.5 Nazwa EL

Domyślnie, ziarno nie ma nazwy, jest bezimienne. Nadanie nazwy następuje przez adnotację @javax.inject.Named. Wartość @Named przypisuje nazwę, a bez niego nazwa domyślna to nazwa klasy rozpoczynając od małej litery. Tylko wtedy ziarno jest widoczne dla JSP, JSF czy innych technologii korzystających z Unified EL.

Adnotację @Named przypisujemy do klasy lub metody/pola produkującego.

2.6 Alternatywy

Ziarnem alternatywnym nazywamy ziarno, które jest zdefiniowane w pliku konfiguracyjnym CDI - beans.xml, a które przesłania ziarno, dla którego jest alternatywnym.

Ziarno alternatywne definiujemy przez adnotację @Alternative na poziomie klasy lub metody/pola produkującego. Adnotacja może być przypisana również niewprost przez stereotyp.

2.7 Stereotypy

Stereotyp to adnotacja oznaczona meta-adnotacją @javax.enterprise.inject.Stereotype określająca rolę ziarna w aplikacji. Jest to sposób na nadanie ziarnom pewnych cech wspólnych, które rozumiane są przez aplikację, np. @Action lub @Secure. Jest to nic innego jak meta-adnotacja i jej interpretacja zależy od samej aplikacji.

Przypisanie stereotypu do ziarna jest możliwe przez udekorowanie klasy lub metody/pola produkującego.

Ziarno może mieć zero lub więcej stereotypów.

Stereotyp może mieć przypisany zasięg, który niewprost jest przypisywany ziarnu po zaaplikowaniu stereotypu.

Stereotyp może mieć przypisane interceptory.

Stereotyp może mieć przypisaną pustą (bez wartości dla atrybutu value) adnotację @Named, co spowoduje, że każde ziarno z tym stereotypem będzie miało domyślną nazwę EL.

Stereotyp może być oznaczony przez @Alternative, co automatycznie sprawia, że ziarna z nim są alternatywnymi do innych ziaren (zastępują/przesłaniają je) - przydatne w mockowaniu.

Stereotyp może mieć stereotypy.

Wbudowany stereotyp @javax.enterprise.inject.Model służy do wskazania ziaren będących modelem w aplikacji MVC, np. opartej na JavaServer Faces (JSF).

Tyle. Tym samym zakończyłem relację rozdziału 2. Concepts. Kolejna relacja po długim weekendzie, w poniedziałek. Wypoczywajcie bez komputerów, ale przy specyfikacjach :-)

Gorąco polecam lekturę na nadchodzące dni, która bardzo delikatnie wprowadza w temat CDI:

• Dependency Injection in Java EE 6 - Part 1
• Dependency injection in Java EE, part 2
• Part 3 of dependency injection in Java EE 6
• Dependency Injection in Java EE 6: Conversations (Part 4)

p.s. Z ostatniej chwili - Ruszyła rejestracja na Javarsovia 2010! Jakkolwiek nie będzie podczas konferencji Javarsovia 2010 dedykowanej prezentacji nt. CDI, ale i tak poruszane tematy gwarantują dobrą zabawę. Rejestrujcie się! Konferencja jest całkowicie bezpłatna.

Rozdział 2. Koncepcje ze specyfikacji Java EE 6 Contexts and Dependency Injection (CDI)

Ciekaw jestem, jaki też sposób na poznanie specyfikacji Java EE 6 wybrały osoby zajmujące się nią. W jakiś przedziwny dla mnie sposób, mnie wzięło na poznanie specyfikacji od podstaw, czyli wziąłem się za JSR-299 Context and Dependency Injection for the Java EE platform i z każdym dniem idzie sprawniej, ale nie tak, jakbym sobie tego życzył. Najwyraźniej należało zacząć od początku, czyli zabrać się za samą specyfikację Java EE 6 - JSR 316 Java Platform, Enterprise Edition 6 (Java EE 6) Specification. Pewnie dlatego, że byłoby za prosto, zabrałem się za CDI :)

Tym razem streszczę mądrości z rozdziału 2. Concepts.

Zacznę od pytania: Co różni instancję klasy stworzoną przez new, a tymi, przekazanymi przez kontener? Odpowiedzi nie należy się spodziewać (chyba że na wyraźne życzenie), bo powinna nasunąć się m.in. po lekturze specyfikacji CDI, czy tym streszczeniu.

Ziarna i ich typy

Komponent Java EE jest ziarnem (ang. bean), jeśli cykl rozwojowy jego instancji jest zarządzany przez kontener zgodnie z zasadami specyfikacji CDI.

Ziarno może posiadać dodatkowe metadane opisujące jego zachowanie w systemie.

Instancje ziarna nazywane są kontekstowymi instancjami ziarna.

Możliwe jest przekazywanie kontekstowych instancji ziaren do innych (w ramach tego samego kontekstu). Wspomniane przekazywanie to nic innego jak wstrzeliwanie zależności (ang. dependency injection) - jedna z form Inversion of Control (IoC).

Ziarna kontekstowe mogą być wykorzystywane w wyrażeniach Unified Expression Language (Unified EL).

Ziarno opisywane jest przez:

• niepusty zbiór typów
• niepusty zbiór kwalifikatorów
• zasięg
• (opcjonalnie) nazwy EL
• zbioru związanych interceptorów
• implementacji

Rolą programisty JEE6 jest stworzenie implementacji ziarna w Javie i opatrzenie jej odpowiednimi adnotacjami lub też poleganie na domyślnych właściwościach.

Zwykła klasa javowa - POJO - jest ziarnem, ale może też nim być ziarno zarządzane w JavaServer Faces (JSF) czy ziarno Enterprise JavaBeans (EJB). To jest główna idea tej specyfikacji, jak opisano w specyfikacji Java EE - rozdział EE.6.30 Contexts and Dependency Injection for the Java EE Platform 1.0 Requirements (strona 163):

CDI (JSR-299) definiuje zbiór kontekstowych usług, dostarczanych przez kontenery Java EE, których celem jest uproszczenie aplikacji, które korzystają z technologii warstwy webowej i biznesowej.

Tymi usługami kontekstowymi mogą być wstrzeliwanie zależności, metody zwrotne cykli rozwojowych, interceptory czy dekoratory.

Rolą kontenera jest automagiczne zarządzanie (tworzenie i niszczenie) instancjami, związywanie ich z odpowiednim kontekstem, rozwiązywanie nazw po typie i kwalifikatorach lub samej nazwie EL, obsługa metod zwrotnych (a w zasadzie ich wywoływanie w odpowiednim momencie), przechwytywanie wykonywania metod przez interceptory i dekoratory oraz obsługa zdarzeń.

Typ ziarna to zbiór typów widocznych dla klienta. Typ zawsze zawiera java.lang.Object. Dla EJB typami będą interfejsy biznesowe i Object.

Ograniczenie zbioru typów ziarna możliwe jest przez adnotację @javax.enterprise.inject.Typed, której wartość przyjmuje tablicę typów (i zawsze z dodatkowym Object - bez względu, czy jest wymieniony, czy nie).

Typ wyznacza możliwości ziarna i klient może rzutować instancję ziarna kontekstowego jedynie na typy widoczne dla niego.

Kwalifikatory

Kwalifikator pozwala na przypisanie dodatkowych informacji (metadanych) do typu ziarna. Kwalifikator reprezentowany jest przez adnotację, którą tworzy programista. Typ może posiadać wiele kwalifikatorów, które tym samym specjalizują go (zawężają miejsca, w których może być wstrzeliwany przez konieczność wypisania wszystkich kwalifikatorów).

Punkt/miejsce wstrzeliwania to miejsce w dowolnej klasie, w którym dojdzie do wstrzeliwania zależności. Może być opisane przez wiele kwalifikatorów, co jednocześnie zawęża możliwe ziarna.

Wyznaczenie instancji ziarna, która będzie wstrzelona, następuje przez porównanie typów i kwalifikatorów ziarna. W ten sposób możliwe jest udostępnienie różnych implementacji tego samego interfejsu i przez różne kwalifikatory wskazanie ich różnic (zamiast korzystać z ich typów implementacji). Jedynie zgodność typu i wszystkich kwalifikatorów punktu wstrzeliwania umożliwia przypisanie instancji ziarna.

Kwalifikatory mogą również służyć do filtrowania zdarzeń przez klasy nasłuchujące na zdarzenie.

Wbudowane kwalifikatory należą do pakietu javax.enterprise.inject wraz z @javax.inject.Named.

Każde ziarno ma domyślnie przypisany kwalifikator @Any (poza ziarnami stworzonymi przez @New).

Jeśli ziarno nie ma jawnie przypisanego kwalifikatora, poza @Named, ziarno ma dodatkowy kwalifikator @Default zwany kwalifikatorem domyślnym.

Kwalifikator to adnotacja Javy zdefiniowana jako @Target({METHOD, FIELD, PARAMETER, TYPE}) z @Retention(RUNTIME), ale także zawiera meta-adnotację @javax.inject.Qualifier i zwykle @java.lang.annotation.Documented. Kwalifikator może posiadać atrybuty.

Kwalifikatory ziarna są wyznaczone przez udekorowanie klasy ziarna lub metody/pola producenta typem kwalifikatora.

Kwalifikatory mogą być przypisane do metod, pól, parametrów i typu (zgodnie z deklaracją @Target), a przekładając to na język CDI będą to m.in. parametry metod produkujących (ang. producer methods), inicjujących (ang. initializer methods), rozgłaszających (ang. disposer methods), obserwujących (ang. observer methods) i konstruktorów.

Przestrzenie aktywności

Ziarna CDI istnieją w dobrze określonej przestrzeni, której cykl rozwojowy jest kontrolowany przez kontener. Wszystkie mają przestrzeń aktywności/zasięg działania (ang. scope).

Przestrzeń określona jest przez adnotację, np. @javax.enterprise.context.SessionScoped.

Istnieje 5 standardowych przestrzeni (wszystkie zdefiniowane w javax.enterprise.context):

• @RequestScoped
• @SessionScoped
• @ApplicationScoped
• @ConversationScoped
• @Dependent
  

3 pierwsze reprezentują standardowe przestrzenie ze specyfikacji Java Servlets. Kolejny, @ConversationScoped to nowość w CDI, a ostatni podobnie, ale jest jeszcze dodatkowo specjalnego traktowania.

Można definiować własne przestrzenie. Tworzymy adnotację z @Target({TYPE, METHOD, FIELD}) i @Retention(RUNTIME). Dodatkowo obowiązkowo należy dodać @javax.inject.Scope lub @javax.enterprise.context.NormalScope.

Określenie przestrzeni ziarna to przypisanie adnotacji do jego typu lub metody/pola produkującego.

Brak jawnie określonej przestrzeni ziarna oznacza, że jest ona domyślna i zależy od stereotypów - ich brak to zasięg @Dependent, wspólna przestrzeń stereotypów to przestrzeń ziarna, a w przeciwnym przypadku musi być jawnie podana przestrzeń.

Jawne określenie przestrzeni, to przestrzeń obowiązująca (bez względu na przestrzenie deklarowane przez stereotypy).

Reszta rozdziału w kolejnej relacji, bo zaczyna się robić przydługo (i pewnie nudno).

Gdyby tylko jeszcze znaleźć ciekawe tłumaczenie dla angielskiego bean. Używam ziarno, ale coraz bardziej nie pasuje mi, jak i jego angielski protoplasta. Pomysły?

Lektura specyfikacji CDI (JSR-299) za mną, NetBeans 6.9 RC1 wydane i JSR-330 Dependency Injection for Java

Właśnie ukończyłem lekturę specyfikacji JSR-299: Contexts and Dependency Injection for the Java EE platform. Jeśliby spojrzeć na nią pod kątem liczby stron, to nie należy ona do najbardziej rozległych i jedynie 92 stron można przeczytać w jeden wieczór. Co jednak mnie spowalniało w tym zamiarze, to niezwykle suche podawanie pojęć i zasad działania specyfikacji, której zrozumienie zabrało mi bodajże 2 tygodnie.

Zacząłem od wpisu Nauka Java EE 6 CDI (JSR-299) - relacja z lektury pierwszych dwóch rozdziałów specyfikacji, w którym przedstawiłem pierwszy rozdział z dwóch zakładanych. Miałem wrażenie, że możnaby opisać jednym wpisem całość, a wyszło jak wyszło - przydługi wpis dotyczący jedynie pierwszego rozdziału 1. Architecture.

W tym samym czasie, kiedy ukończyłem czytanie specyfikacji CDI, pojawiła się kolejna wersja NetBeans 6.9 RC1, która udostępnia jej wsparcie. Niewiele jeszcze mogę napisać na ten temat, ale sądzę, że lepiej będzie, jeśli moje próby zrelacjonuję w postaci skrinkastów. W tym tygodniu nie ma co się ich spodziewać, a z kolei w przyszłym jestem na urlopie, więc pewnie dopiero w czwartek, 10 czerwca. Możecie już regulować kalendarze (parafrazując powiedzenie o regulowaniu zegarków).

Sprawę środowiska programistycznego mam więc za sobą i NetBeans IDE 6.9 RC1 będzie moim podstawowym narzędziem, a środowisko uruchomieniowe to GlassFish 3.0.1 (dostarczany z NetBeans IDE), a docelowo IBM WebSphere Application Server V8.0 Alpha.

Co przykuło moją uwagę dzisiaj, to specyfikacja JSR-330 Dependency Injection for Java, która, przynajmniej z nazwy, przypomina CDI. Zaczęło się od wizyty na stronie Apache OpenWebBeans, gdzie w menu po lewej pojawiają się obie specyfikacje JSR299 oraz JSR330. Trochę mnie to zastanowiło, jaka jest różnica między nimi, więc zajrzałem na stronę tej drugiej. Z nazwy wyglądają łudząco podobnie, a prowadzącym specyfikację JSR-330 jest Rod Johnson (z projektu Spring Framework) oraz Bob Lee (z Google Guice), a za JSR-299 odpowiada Gavin King (z JBoss Seam i Hibernate). Mam wrażenie, jakby obie specyfikacje oferowały podobne funkcjonalności?! Poszukując dalej, ciekawe jest zestawienie implementacji JSR-330 na stronie Technology Compatibility Kit (TCK) - atinject:

• Google Guice 2.1
• KouInject
• Apache OpenWebBeans
• Spring Framework 3.0
• JBoss Weld 1.0.0

Jak widać są wszyscy - Guice, OpenWebBeans, Spring Framework i Weld, z nieznanym mi piątym KouInject. Zdaje się, że pora na to, abym zabrał się za lekturę The Java EE 6 Tutorial, Volume I, bo inaczej pogubię się w gąszczu specyfikacji Korporacyjnej 6tki. Coś mi jednak mówi, że do zrozumienia całości, nie ma innego sposobu, jak po prostu zajrzeć do samej specyfikacji JSR 316: Java Platform, Enterprise Edition 6 (Java EE 6), bo inaczej się pogubię. Tak też zrobię, bo w specyfikacji JSR299 pełno wzmianek o specyfikacjach i o wielu nie mam bladego pojęcia (albo określa się je nowymi terminami), np. "The Managed Beans specification" (strona 2) - jakby o JSF, ale później pojawia się oddzielna sekcja 1.2.6. Relationship to JSF, więc to raczej nie JSF - i wspomniana "The Dependency Injection for Java specification" (strona 3). Ach, teraz jasne po co DI for Java! :-) Przecież wyraźnie napisano w sekcji 1.2.4. Relationship to Dependency Injection for Java (w wolnym tłumaczeniu):

"Specyfikacja Dependency Injection for Java określa zbiór adnotacji, którymi oznacza się pola, metody i konstruktory ziaren (ang. bean), które podlegają mechanizmowi DI. Usługa DI [w CDI - mój przypisek] korzysta z tychże."

Na zakończenie chciałbym przywołać opis JSR-299 Contexts and Dependency Injection for the Java EE platform ze strony Apache OpenWebBeans (w wolnym tłumaczeniu):

"Celem specyfikacji CDI [dawniej WebBeans - mój przypisek] jest ujednolicenie modeli komponentowych JSF i EJB, aby znacząco uprościć model programowania aplikacji webowych."

Bardzo trafne podsumowanie specyfikacji CDI, aczkolwiek dotyczy to szerszego spektrum technologicznego i wykracza poza JSF i EJB, gdzie POJO gra również pierwsze skrzypce. Mimo tych niedomówień, wydaje się być bardziej przystępne niż to w samej specyfikacji.

Późno już, ale na przykładzik z servlecikiem z przekazanym ziarnem CDI jeszcze się znajdzie chwilka. Zdecydowanie zbyt wiele teorii, a za mało praktyki. Odmóżdża mnie to.

Tak mnie natchnęło podczas powrotu - CDI, Spring Framework, JBoss Seam i in.

W oczekiwaniu na samolot do Pragi, na lotnisku w Bratysławie, trafiłem do restauracji, która przypominała mi lata 80-te zeszłego wieku. Kiedy wreszcie podano mi kartę (ludzi było sporo i widać było, że kelnerzy biegają jak w ukropie) jeszcze bardziej byłem przerażony - strona graficzna karty przypominała mi moje nieśmiałe próby zabawy z grafiką, a nie mam złudzeń, że nie znam się na temacie. Mimo wszystko dałem się namówić samemu sobie, abym jednak spróbował. Zamówiłem danie, którego wygląd w karcie przypominał lata jak sama restauracja i aż do momentu podania wciąż walczyłem ze swoimi myślami, czy dobrze zrobiłem (co później okazało się bardzo pozytywnym zaskoczeniem!). Czekałem i patrzyłem przez okno na lotnisko, aż zacząłem zastanawiać się nad celem...specyfikacji JSR-299 Contexts and Dependency Injection (CDI) i, jakkolwiek wciąż przede mną część praktyczna, to wydaje mi się, że zrozumiałem jego istotę.

Jak sama nazwa specyfikacji CDI mówi (wręcz narzuca się ze swoim celem przez nią, ale najwyraźniej niezbyt nachalnie, bo dla mnie nie było to jasne, aż do tego momentu) sprawa dotyczy realizacji koncepcji zarządzania kontekstami (znamy przynajmniej 3, które istnieją w Java EE od wieków, ale i tych, które możnaby stworzyć, które pojawiły się w JSF2 conversation i potencjalnie dostępne z rozwiązaniami BPM - businessprocess) oraz obiektami, które podlegają mechanizmowi Dependency Injection (DI) w ramach kontekstu, który tym samym pełni rolę przestrzeni ich widoczności.

Jeśli miałbym szukać odpowiednika CDI w świecie poza JEE6, aby choć nieznacznie nawiązać kontakt myślowy z szerszą częścią czytelników, to byłby to na pewno Spring Framework (i nie mam na myśli jego rozszerzeń tylko sam "czysty" - bez dodatków - kontener DI). Bardziej idealnym odpowiednikiem byłby Guice, albo PicoContainer, albo jeszcze HiveMind, ale ich rozpoznanie nie należy do najszerszych, a to pewnie dlatego, że są bardzo specjalizowanymi rozwiązaniami, które nie doczekały się szerszego wsparcia gotowych rozwiązań "stosowych" (o nich za moment).

Skoro w temat tworzenia CDI zaangażowani byli autorzy JBoss Seam, to możnaby również mniemać, że i w nim coś już było, albo jest dopasowywane. I faktycznie tak jest. Pamiętam moment, kiedy dowiedziałem się o postrzeganiu JBoss Seam jako...kontenera DI, którego porównywano do...Spring Framework (!) Nie mogłem po prostu w to uwierzyć. Dla mnie Seam był i wciąż jest szkieletem webowym opartym na JEE, który był o tyle rewolucyjny, że połączył dwie technologie, które jakkolwiek pod parasolem JEE, to wciąż grały do innej bramki. Mowa o EJB3 i JSF 1.2. Dzięki Seam oba rozwiązania były jakby ukryte pod przykrywką warstwy komponentów i to właśnie stanowiło trzon, aby wprowadzić jako standard do JEE. Teraz to jasne (czasami warto znaleźć się w miejscu, w którym lepiej, aby nas nie było, np. kawiarnia na lotnisku, bo nieoczekiwane prowadzi do ciekawych chwil, których trudno by szukać w znanym i opanowanym mentalnie świecie).

Teraz wiem, dlaczego kiedy przeglądałem materiały do CDI, gdzieś na niskim pułapie wciąż przelatywał JSP i JSF2. Samo CDI to jedynie, albo aż, kontener DI, podobnie jak Spring Framework. Jednak do zbudowania aplikacji korporacyjnej potrzebujemy szkieletu webowego czy Web Services, czy innej obsługi protokołu do komunikacji z użytkownikiem końcowym. Tu jest miejsce dla JavaServer Faces 2.0 jako kompletnego szkieletu webowego, zintegrowanego z CDI. Kiedy dodamy do tego EJB3.1 mamy cały obraz najnowszego wydania Java Enterprise Edition 6.0. Teraz już jest łatwiej zrozumieć ich zmiany i powiązania między nimi.

Tak mnie natchęło, aby pochwalić się swoim znaleziskiem :-) Wracam do lektury specyfikacji. Jeszcze tylko kilka stron i teoretycznie będę "uzbrojony".

Nauka Java EE 6 CDI (JSR-299) - relacja z lektury pierwszych dwóch rozdziałów specyfikacji

Od jakiegoś czasu przymierzam się do Java EE 6 (JEE6), ale ogrom zmian i nowości sprawia mi trochę problemów od czego zacząć. Mam już środowisko programistyczne - NetBeans IDE 6.9 i mam już środowisko uruchomieniowe (wykonawcze) - IBM WebSphere Application Server V8. Możnaby zatem powiedzieć, że mam wszystko, ale baczne oko zauważy, że nie mam najważniejszego - planu rozpoznania zestawu technologicznego, który kryje się pod niewinnie brzmiącym akronimem JEE6. Śmiało można powiedzieć, że nie ma specyfikacji w JEE6, która nie zostałaby zmieniona przez ciało standaryzujące, choćby nieznacznie. A pojawiły się również nowe, chociażby Contexts and Dependency Injection for the Java EE platform (dawniej znanej jako Web Beans, co już po tym kątem może wprowadzać w zakłopotanie). I właśnie od niej postanowiłem zacząć moją naukę, chyba przede wszystkim dlatego, że całkowicie nowa.

Specyfikacja Contexts and Dependency Injection for the Java EE platform (w skrócie CDI) miała swój początek w entuzjastycznym przyjęciu szkieletu webowego JBoss Seam, który stał się jakby domyślnie domem dla implementacji referencyjnej Weld (nota bene doskonale dobrana nazwa związana semantycznie z Seam, bo oba oznaczają mniej więcej "złączanie").

Mam za sobą pierwsze 2 rozdziały specyfikacji - 1. Architecture i 2. Concepts - i raczej, więcej pytań niż odpowiedzi. Mam wrażenie, jakby strona Weld była bardziej składnie pisana niż sama specyfikacja.

Lektura specyfikacji uzmysłowiła mi powód, dla którego warto poznawać nowe specyfikacje bez konieczności ich "odwzorowywania" na zastosowania biznesowe. Przynajmniej nie na etapie jej rozpoznawania. Jeszcze nie tak dawno, pisałem o potrzebie własnego rozwoju technologicznego pod kątem zastosowań biznesowych, w projekcie i dopasowywać rozwiązanie do problemu, a nie odwrotnie. Pamiętam jednak, że ktoś przypominał mi, że jak można dopasowywać coś, czego się jeszcze nie zna?! I tu jest pies pogrzebany. Uczenie się nowych technologii, to nauka technik, których potrzeby moglibyśmy nie być nawet w stanie określić i sprecyzować. Biorąc na warsztat CDI nie mam pojęcia, po co mi alternatives czy stereotypes (pojęcia z CDI), więc jak miałbym przedstawiać je w świetle potencjalnych zastosowań?! W ten sposób znalazłem uzasadnienie dla prezentacji stricte technologicznych, gdzie uczę się samej technologii, po których przyjdzie zastosowanie biznesowe. Pewnie, że możnaby postrzegać listę problem-rozwiązanie jako ułatwienie, ale czy wtedy nasze projekty nie straciłyby na swojej unikalności, gdyby wiadomo było, że skoro mamy projekt X to będzie technologia Y. Nuda. Zresztą mogłoby to wstrzymać postęp, gdyby nie próbować naginać rozwiązań do realizacji swoich wizji. To jest różnica między specyfikacją a książkami, które zwykle prezentują specyfikację przez zastosowania biznesowe, realizując konkretny projekt. Znalazłem tym samym sens istnienia artykułów i prezentacji czysto technicznych jako pierwszy krok wtajemniczenia oraz artykułów i prezentacji będących mieszanką technologii i zastosowania biznesowego jako kolejny etap. Najwyższym etapem wtajemniczenia widzę w świadomym wybraniu tego jednego rozwiązania z wielu dostępnych, często całkowicie niezwiązanych ze sobą. Denerwowało mnie to podczas dotychczasowej lektury specyfikacji CDI, gdzie przedstawiano "jak użyć" bez "po co", ale mając to wyjaśnienie jest mi dużo lżej na duszy :-)

Pierwsze 2 rozdziały specyfikacji CDI, które zajmują niecałe 20 stron, to w zasadzie górnolotne wprowadzenie w temat, które upstrzone jest odnośnikami do kolejnych rozdziałów. Jako podsumowanie rozdziału 1. Architecture możnaby napisać, że nie warto go czytać i od razu można przejść do kolejnego 2. Concepts, który de facto też nie wypada lepiej. Pierwszy rozdział raczej kłopotliwy w zrozumieniu i podpierając się odnośnikami do kolejnych nie zasługuje nawet na miano wprowadzającego. A tyle się mówi o tym, aby nie mieć zbyt dużych oczekiwań, bo można się niemile rozczarować, całkiem niepotrzebnie.

Ważne do zapamiętania jest, aby rozpatrywać CDI jako zbioru uzupełniających się usług, które razem tworzą platformę DI (ang. dependency injection). Brakujące 'C' w nazwie specyfikacji nadaje przestrzeń, w której żyją zarządzane byty - kontekst. Ktoś mógłby powiedzieć, że to Spring Framework i pewnie niewiele by się pomylił (na stan obecnej mojej wiedzy o CDI). Nie potrafię umiejscowić Spring Framework (SF) i Guice w świetle CDI, ale komuś najwyraźniej zamarzyło się posiadanie ich cech na platformie Java EE i skoro znalazł się chętny (zespół JBoss Seam), którego niewielu postrzegało jako konkurent SF, to z CDI zmieni się to zauważalnie.

Mamy więc dobrze określone przestrzenie (ang. context) działania naszych zarządzanych bytów (ang. managed beans) i ot całe CDI. Reszta jest jedynie spisaniem praw i obowiązków programisty oraz środowiska realizującego specyfikację, co biorąc pod uwagę obowiązkowość w Java EE 6, a nawet jej podzbioru Web profile znaczy, że wszyscy muszą realizować tę specyfikację chcąć się mienić zgodnością z JEE6.

Zbiór kontekstów jest rozszerzalny, czyli mamy 3 znane z Java EE obszary - żądanie (ang. request), sesja (ang. session) i aplikacja (ang. application), a z CDI dochodzi kolejny konwersacja (ang. conversation). Chcemy kolejny, np. wspomniany w specyfikacji proces biznesowy, mamy prawo go utworzyć i oczekiwać działania na dowolnym kontenerze CDI.

Zależności są przekazywane (wstrzeliwane) ze względu na tryb uruchomienia aplikacji - rozwojowy czy produkcyjny bez, jak to ujęto, wyrafinowanej konfiguracji.

Integracja z Unified Expression Language (EL) umożliwia użycie CDI z JSF czy JSP, co wyznacza ścieżkę dalszej nauki JEE6 - po CDI warto zajrzeć do zmian w JSF 2.0.

CDI udostępnia również możliwość dekorowania przekazywanych obiektów, definiowania interceptorów i użycia modelu zdarzeń.

Obiekty, które podlegają zarządzaniu przez kontener CDI zawierają ziarna sesyjne EJB3, ziarna zarządzane JSF oraz zasoby JEE. Nazywane są ogólnie ziarnami (ang. beans), a ich instancje związane z kontekstem - instancjami kontekstowymi (ang. contextual instances). Programista określa co i gdzie będzie przekazane przez usługę DI w postaci adnotacji lub deskryptora XML.

Tym samym, dzięki CDI ziarna sesyjne EJB3 mogą być ziarnami zarządzanymi JSF (coś co było możliwe w JBoss Seam, jak i Spring Framework z jego rozszerzeniami).

Aplikacja korzystająca z CDI może działać na platformie Java EE oraz...Java SE. Użycie usług typu transakcje czy utrwalanie (ang. persistence) w CDI na Java SE jest co najwyżej takie, jak dostępne we wbudowanym trybie EJB 3.1. Kolejna specyfikacja na ścieżce poznawania JEE6, po JSF 2.0.

Wszystkie klasy podlegające mechanizmowi wstrzeliwania zależności w JEE6 są możliwe do użycia z ziarnami CDI. W ten sposób, CDI rozszerza dotychczasowe specyfikacje JEE, np. EJB3 o pojęcie kontekstu, spajając specyfikacje prezentacyjne z biznesowymi.

Kontekst wyznacza obszar działania i widoczności. Kontener tworzy instancje obiektów, kiedy są potrzebne, a niszczy, kiedy kontekst kończy swój żywot (pachnie literaturą, więc powinienem był napisać "swoje istnienie").

Adnotacja @Inject określa pole instancji zwane injected field (pole injekcji?), które jest inicjowane przez CDI podczas inicjowania ziarna CDI lub metodę początkową/inicjalną (ang. initializer method) uruchamianą po zainicjowaniu ziarna CDI z wstrzelonymi parametrami (zaraz wysiądę przez te tłumaczenia). Warto zajrzeć do specyfikacji, do sekcji 1.3 Introductory examples, aby przez przykłady poczuć sens specyfikacji. Wyjaśnienia są lakoniczne i raczej technologiczne niż po co i dlaczego.

Rozdział 2. Concepts omawia...następnym razem :-)