Opublikowałem właśnie nowy artykuł Embeddable EJB 3.1 z Apache OpenEJB 4, Apache Maven 3 i IntelliJ IDEA 10.5, który kontynuuje cykl przedstawiania nowych cech specyfikacji Enterprise JavaBeans (EJB) 3.1. Chodził za mną od kilku dni i potrzeba mi było zebrać się w sobie, aby w końcu usiąść i napisać go. W końcu jest!
Zapraszam do lektury i komentarzy. Dla zwrócenia uwagi napiszę, że w samym ziarnie MySession popełniłem kilka błędów architektonicznych, w których zakładam pewne zachowanie ziarna bezstanowego mimo, że takowej nie oferuje (bez świadomej i specyficznej konfiguracji kontenera). Ciekawym komu uda się zauważyć moją pomyłkę, albo kilka? Zachęcam do dyskusji.
Pokazywanie postów oznaczonych etykietą jee6. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą jee6. Pokaż wszystkie posty
03 września 2011
19 lipca 2011
Book review: EJB 3.1 Cookbook
Więcej moich odczuć na temat książki EJB 3.1 Cookbook z Packt Publishing w mojej recenzji Book review: EJB 3.1 Cookbook. Przy okazji, zachęcam do oceny (przydatności) recenzji na Amazonie - Too basic, often repetitive and thus boring - 400 pages yet 100 would make it a better reading. Na chwilę obecną zajmuję "New Reviewer Rank: 13,857" z "Helpful Votes: 110" i chyba dałem się wciągnąć w zabawę w roli recenzenta.
Zainteresowanych lekturą tej książki zapraszam do kontaktu na jacek@japila.pl.
12 lipca 2011
IBM RAD V8.0.3 Installation - part 2: RAD installation
Po ostatnim nagraniu zabrałem się ochoczo za kolejne. Kiedy odkryłem (=dotarło do mnie), że nagrywanie powinno odbywać się w rozdzielczości docelowej i że jej zmiana to wybór odpowiedniego menu na iMac'u, nagrywanie stało się znacznie mniej absorbujące. Niestety, nagranie wciąż nieme, więc trudno znaleźć w nim odpowiedzi, dlaczego instalacja wyglądała tak, jak wygląda. Wersji dźwiękowej można oczekiwać niebawem, bo od tej ciszy aż uszy puchną :)
Zachęcam do obejrzenia 8-minutówki. Uwagi odnośnie nagrania i przyszłym tematów mile widziane. Odpowiedzi pojawią się w kolejnych nagraniach i/lub w komentarzach. Właśnie czytam książkę na temat EJB 3.1, więc to będzie głównym tematem kolejnych nagrań, w których IDE to RAD 8, a serwerem aplikacyjnym będzie WAS 8.
Zastanawiam się jeszcze, czy właściwym miejscem na skrinkasty jest YouTube. Bardziej skłaniałbym się ku vimeo. Jakieś takie bardziej profesjonalne.
Zachęcam do obejrzenia 8-minutówki. Uwagi odnośnie nagrania i przyszłym tematów mile widziane. Odpowiedzi pojawią się w kolejnych nagraniach i/lub w komentarzach. Właśnie czytam książkę na temat EJB 3.1, więc to będzie głównym tematem kolejnych nagrań, w których IDE to RAD 8, a serwerem aplikacyjnym będzie WAS 8.
Zastanawiam się jeszcze, czy właściwym miejscem na skrinkasty jest YouTube. Bardziej skłaniałbym się ku vimeo. Jakieś takie bardziej profesjonalne.
22 maja 2011
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!
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!
19 kwietnia 2011
Wykład na Politechnice Krakowskiej - to już jutro!
Coś co zaczęło się od niewinnego zaproszenia dotyczącego mojego wykładu o Javie na Politechnice Krakowskiej właśnie przybiera formę czegoś namacalnego i wcale nietrywialnego - wykład i seminarium dot. Java EE, OSGi oraz SCA.
Chciałbym, aby miało to format warsztatu niż slajdowiska, ale kto wie komu co przypasuje, więc przygotowuję się i tak, i tak. Zaczynam odczuwać presję wciąż niedoskonałego przygotowania. W końcu, jeśli źle przedstawię dobrą technologię, studenci mogą się do niej zrazić, a tego bym sobie nie wybaczył. Liczę na wiele prac dyplomowych (przynajmniej na inż.) w temacie, najlepiej jeśli głównym graczem było OSGi.
oraz
Wszystkich serdecznie zapraszam.
Planuję również podobną aktywność na Uniwersytecie Zielonogórskim pod koniec maja lub początek czerwca, gdzie zaplanowałem Praktycznie o CDI z Arquillian oraz serwerami aplikacyjnymi WebSphere AS V8 i GlassFish 3.1, a w drugiej części Enterprise OSGi.
Chciałbym, aby miało to format warsztatu niż slajdowiska, ale kto wie komu co przypasuje, więc przygotowuję się i tak, i tak. Zaczynam odczuwać presję wciąż niedoskonałego przygotowania. W końcu, jeśli źle przedstawię dobrą technologię, studenci mogą się do niej zrazić, a tego bym sobie nie wybaczył. Liczę na wiele prac dyplomowych (przynajmniej na inż.) w temacie, najlepiej jeśli głównym graczem było OSGi.
Planuję również podobną aktywność na Uniwersytecie Zielonogórskim pod koniec maja lub początek czerwca, gdzie zaplanowałem Praktycznie o CDI z Arquillian oraz serwerami aplikacyjnymi WebSphere AS V8 i GlassFish 3.1, a w drugiej części Enterprise OSGi.
10 marca 2011
Jedynie beanName albo lookup w @EJB dozwolone, a GlassFish 3.1 akceptuje oba równocześnie
A to dopiero znalezisko! Właśnie natrafiłem na błąd w GlassFish 3.1 przy obsłudze adnotacji @EJB.
Zgodnie z javadoc dla @EJB:
"Either the beanName or the lookup element can be used to resolve the EJB dependency to its target session bean component. It is an error to specify values for both beanName and lookup."
Stąd należałoby oczekiwać, że uruchomienie poniższego komponentu EJB powinno zakończyć się błędem - zwróć uwagę na adnotację @EJB z atrybutami beanName oraz lookup.
Pytanie uzupełniające: Który z atrybutów ma wyższy priorytet - beanName czy lookup, czyli które będzie brane pod uwagę przy rozwiązywaniu @EJB?
Odpowiedź pozostawiam najbardziej dociekliwym i wytrwałym, którzy przykład uruchomili korzystając z artykułu Słabo typizowane DI w EJB 3.x - o beanName w @EJB jeszcze raz.
A jak to jest w innych serwerach? Sprawdzę jeszcze WAS8 i OpenEJB 3.1.4, a ucieszyłbym się, gdybym dowiedział się od kogoś jak to jest obsłużone w JBoss AS 6 czy Oracle WebLogic Server 11g?
Zgodnie z javadoc dla @EJB:
"Either the beanName or the lookup element can be used to resolve the EJB dependency to its target session bean component. It is an error to specify values for both beanName and lookup."
Stąd należałoby oczekiwać, że uruchomienie poniższego komponentu EJB powinno zakończyć się błędem - zwróć uwagę na adnotację @EJB z atrybutami beanName oraz lookup.
package pl.japila.ejb.test;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import pl.japila.ejb.Hello;
@Stateless
public class TestFacadeEJB implements Hello {
@EJB(beanName="HelloInEnglish", lookup="java:global/classes/HelloPoPolsku")
Hello hello;
@Override
public String sayHello(String whom) {
return hello.sayHello(whom);
}
}
Nic bardziej mylnego! Wdrożenie takiego EJB jest całkowicie legalne w GlassFish i nie zakończy się błędem.Pytanie uzupełniające: Który z atrybutów ma wyższy priorytet - beanName czy lookup, czyli które będzie brane pod uwagę przy rozwiązywaniu @EJB?
Odpowiedź pozostawiam najbardziej dociekliwym i wytrwałym, którzy przykład uruchomili korzystając z artykułu Słabo typizowane DI w EJB 3.x - o beanName w @EJB jeszcze raz.
A jak to jest w innych serwerach? Sprawdzę jeszcze WAS8 i OpenEJB 3.1.4, a ucieszyłbym się, gdybym dowiedział się od kogoś jak to jest obsłużone w JBoss AS 6 czy Oracle WebLogic Server 11g?
09 marca 2011
Słabo typizowane DI w EJB 3.x - o beanName w @EJB jeszcze raz
Posiłkując się doświadczeniami z Embeddable EJB 3.1 z GlassFish 3.1 i NetBeans IDE 7.0 oraz Element beanName w @EJB do rozróżnienia deklaracji ziaren EJB stworzyłem przyczułek do dalszych doświadczeń ze specyfikacjami EJB 3.1 oraz CDI 1.0. Tym razem na warsztat wziąłem zbadanie mechanizmu przekazywania zależności (ang. DI, dependency injection) w EJB 3.x.
Potrzebowałem środowiska, w którym będę mógł uruchomić testy automatycznie bez konieczności zestawiania skomplikowanego środowiska uruchomieniowego. Zaletą takiego podejścia może być chociażby uruchomienie testów w dowolnym momencie, na dowolnym komputerze i przez dowolnego (nawet nowego!) członka zespołu. Starałem się utrzymać minimalny nakład pracy, aby łatwiej było przedstawić problem, z którym się zmagam.
Zainteresowany/-a szczegółami? Zapraszam do lektury mojego artykułu Słabo typizowane DI w EJB 3.x - o beanName w @EJB jeszcze raz. Uwagi bardzo mile widziane.
Potrzebowałem środowiska, w którym będę mógł uruchomić testy automatycznie bez konieczności zestawiania skomplikowanego środowiska uruchomieniowego. Zaletą takiego podejścia może być chociażby uruchomienie testów w dowolnym momencie, na dowolnym komputerze i przez dowolnego (nawet nowego!) członka zespołu. Starałem się utrzymać minimalny nakład pracy, aby łatwiej było przedstawić problem, z którym się zmagam.
Zainteresowany/-a szczegółami? Zapraszam do lektury mojego artykułu Słabo typizowane DI w EJB 3.x - o beanName w @EJB jeszcze raz. Uwagi bardzo mile widziane.
08 marca 2011
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?
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?
03 stycznia 2011
NetBeans 7 i Add Embeddable EJB Container, Create JUnit Tests oraz Code Generation in pom.xml
W Java EE 5 udostępniono możliwość uruchamiania Java Persistence (JPA) 1.0 poza środowiskiem serwera aplikacyjnego - można przeczytać o tym w moim artykule Java Persistence API w samodzielnej aplikacji.
W Java EE 6, poza JPA 2.0, można jeszcze uruchomić kontener Enterprise JavaBeans (EJB) 3.1 oraz kontener Contexts and Dependency Injection (CDI) 1.0. O tym pierwszym - EJB 3.1 - pisałem w Embeddable EJB 3.1 z GlassFish 3.1 i NetBeans IDE 7.0, a o drugim - CDI - w Contexts and Dependency Injection (CDI) praktycznie - zestawienie środowiska z JBoss Weld, Arquillian i Apache Maven 2.
Zacząłem drążyć temat EJB 3.1 z NetBeans 7 i całkiem przypadkiem doszukałem się dwóch użytecznych funkcji - Add Embeddable EJB Container oraz Create JUnit Tests. Sprawdźmy je w działaniu zamiast rozwodzić się nad ich użytecznością (albo ich brakiem).
Cmd+Shift+N - Maven > EJB Module, podaj Project Name, np. aaa i Finish. Mamy projekt EJB zarządzany przez Apache Maven.
Cmd+N - Enterprise JavaBeans > Session Bean, wciśnij Next >, wybierz pakiet z listy w Package i Finish. I mamy komponent EJB.
Otworzy się nowa klasa ziarna EJB 3.1. W jej ciele, Ctrl+i i wybierz Add Business Method... i OK. Pojawi się nowa metoda public void businessMethod(). W jej ciele, wpisz sout i wciśnij TAB. Wpisz Witaj! W ten sposób masz gotowe do uruchomienia ziarno EJB z metodą biznesową, której zadaniem jest wyświetlenie Witaj!
Wybierz nowoutworzoną klasę NewSessionBean i z menu pod prawym klawiszem myszki wybierz Tools > Create JUnit Tests.
Pojawi się panel konfiguracyjny klasy testowej.
Zatwierdź przyciskiem ENTER.
Zaraz po tym powinien otworzyć się edytor z właśnie stworzoną klasą testującą z metodą testBusinessMethod(). Usuń linię fail("The test case is a prototype.");, np. przez Cmd+x. Test gotowy.
Uruchomienie testu - Cmd+F6.
Nie wiem, co informuje NetBeans 7 o konieczności pojawienia się pomocy, albo jak długo należy czekać na jej pojawienie się, ale dłuższa chwila, dwie i na projekcie pojawi się ikona z żółtym wykrzyknikiem.
Kiedy najedzie się na katalog projektu pojawi się chmurka z wyjaśnieniem powodu, dla którego pojawił się wykrzyknik - Missing Embeddable EJB Container.
Wtedy, pod prawy przyciskiem myszki znajdziemy menu Show and Resolve Problems...
Pojawi się okienko dialogowe, w którym pojawi się Missing Embeddable EJB Container z przyciskiem Add Embeddable EJB Container.
Kiedy wciśniesz przycisk, do projektu dodana zostanie zależność i repozytorium, gdzie się znajduje. Spróbuj.
A tak całkiem przy okazji mojej nauki uruchamiania wbudowanego kontenera EJB 3.1, wyczytałem w STS 70 Maven :: Test Specification: Maven Support Test Specification, że edytor pom.xml ma specjalizowany system podpowiedzi Code Generation in pom.xml. W pom.xml wciskamy kombinację klawiszy Alt+Insert i możemy wybrać jedną z kilku opcji utworzenia sekcji XMLowej.
Dla początkujących, jak znalazł.
W Java EE 6, poza JPA 2.0, można jeszcze uruchomić kontener Enterprise JavaBeans (EJB) 3.1 oraz kontener Contexts and Dependency Injection (CDI) 1.0. O tym pierwszym - EJB 3.1 - pisałem w Embeddable EJB 3.1 z GlassFish 3.1 i NetBeans IDE 7.0, a o drugim - CDI - w Contexts and Dependency Injection (CDI) praktycznie - zestawienie środowiska z JBoss Weld, Arquillian i Apache Maven 2.
Zacząłem drążyć temat EJB 3.1 z NetBeans 7 i całkiem przypadkiem doszukałem się dwóch użytecznych funkcji - Add Embeddable EJB Container oraz Create JUnit Tests. Sprawdźmy je w działaniu zamiast rozwodzić się nad ich użytecznością (albo ich brakiem).
Cmd+Shift+N - Maven > EJB Module, podaj Project Name, np. aaa i Finish. Mamy projekt EJB zarządzany przez Apache Maven.
Cmd+N - Enterprise JavaBeans > Session Bean, wciśnij Next >, wybierz pakiet z listy w Package i Finish. I mamy komponent EJB.
Otworzy się nowa klasa ziarna EJB 3.1. W jej ciele, Ctrl+i i wybierz Add Business Method... i OK. Pojawi się nowa metoda public void businessMethod(). W jej ciele, wpisz sout i wciśnij TAB. Wpisz Witaj! W ten sposób masz gotowe do uruchomienia ziarno EJB z metodą biznesową, której zadaniem jest wyświetlenie Witaj!
Wybierz nowoutworzoną klasę NewSessionBean i z menu pod prawym klawiszem myszki wybierz Tools > Create JUnit Tests.
Zaraz po tym powinien otworzyć się edytor z właśnie stworzoną klasą testującą z metodą testBusinessMethod(). Usuń linię fail("The test case is a prototype.");, np. przez Cmd+x. Test gotowy.
Uruchomienie testu - Cmd+F6.
------------------------------------------------------- T E S T S ------------------------------------------------------- Running pl.jaceklaskowski.jee6.abc.NewSessionBeanTest businessMethod Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.396 sec <<< FAILURE! Results : Tests in error: testBusinessMethod(pl.jaceklaskowski.jee6.abc.NewSessionBeanTest) Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 ------------------------------------------------------------------------ BUILD FAILURE ------------------------------------------------------------------------Pojawił się błąd? Jak najbardziej oczekiwany (zajrzyj do What's the cause of this exception: java.lang.ClassFormatError: Absent Code? po więcej wyjaśnień).
Nie wiem, co informuje NetBeans 7 o konieczności pojawienia się pomocy, albo jak długo należy czekać na jej pojawienie się, ale dłuższa chwila, dwie i na projekcie pojawi się ikona z żółtym wykrzyknikiem.
Warto dodać, że zapoznanie się z pom.xml dla tego projektu, to wyzwanie same w sobie. Tyle kombinacji, aby uruchomić wbudowany kontener EJB 3.1 z GlassFish 3.0. Warto dla kogoś, kto chciałby poznać Mavena od podszewki (co w tym przypadku lepiej wykonałby Maven podpierając się Apache Ant przez wtyczkę maven-antrun-plugin).org.glassfish.extras glassfish-embedded-all 3.0 test http://download.java.net/maven/glassfish/ http://download.java.net/maven/glassfish/ default
A tak całkiem przy okazji mojej nauki uruchamiania wbudowanego kontenera EJB 3.1, wyczytałem w STS 70 Maven :: Test Specification: Maven Support Test Specification, że edytor pom.xml ma specjalizowany system podpowiedzi Code Generation in pom.xml. W pom.xml wciskamy kombinację klawiszy Alt+Insert i możemy wybrać jedną z kilku opcji utworzenia sekcji XMLowej.
30 grudnia 2010
Embeddable EJB 3.1 z GlassFish 3.1 i NetBeans IDE 7.0
Biorąc pod uwagę liczbę dni do końca roku, ten wpis będzie co najwyżej przedostatnim wpisem na moim blogu, a na pewno ostatnim dotykającym tematu Java EE 6, EJB 3.1 i in.
Korzystając z okazji, chciałbym życzyć Tobie wszystkiego dobrego w nowym roku 2011 i nakłaniam do jeszcze większej aktywności. Nie czekaj, aż powiedzą, ale mów, proponuj, bądź liderem w swojej społeczności. Dla poszukujących natchnienia polecam lekturę wpisu na blogu Damiana Nowaka - Apprenticeship – długa droga ku Software Craftsmanship. Nie wiem, czy to styl pisania Damiana, czy może sama książka, ale tylko takich wpisów życzę nam w nadchodzącym roku. Niech kasa pójdzie w zapomnienie - niech będzie jej tyle, aby nie stanowiła kwestii do rozwiązania - a czas spędzajmy na tworzeniu - nowego i użytecznego oprogramowania, społeczności przez chociażby dzielenie się wiedzą. Nie ważne jaki był (i jeszcze będzie przez kolejne 2 dni) rok 2010, ale ważne, ile możesz zrobić, aby 2011 był jeszcze lepszy. Zalatuje socjotechniką, ale dobre myślenie poprawia mój nastrój, więc może i Twój również, a to może przełożyć się na coś wyjątkowego.
W takim tonie przedkładam Tobie do oceny mój nowy artykuł Embeddable EJB 3.1 z GlassFish 3.1 i NetBeans IDE 7.0, w którym...
Rozdział 22. Embeddable Usage specyfikacji Enterprise JavaBeans (EJB) 3.1 opisuje nową cechę specyfikacji, która pozwala na uruchomienie kontenera EJB i zarządzanych przez niego komponentów EJB poza serwerem aplikacyjnym Java EE 6 - jedynie na poziomie środowiska Java SE. W ten sposób autorzy specyfikacji przewidują (a my programiści im wierzymy) uproszczenie procesu testowania, przetwarzania wsadowego (w którym użycie transakcji jest kluczowe) czy użycie EJB w samodzielnych aplikacjach desktopowych. Innymi słowy, mamy wszystko, co oferuje kontener EJB 3.1 bez konieczności uruchamiania pełnego serwera aplikacyjnego Java EE, którego sama konfiguracja uruchomieniowa mogła przyprawić o ból głowy.
Zainteresowanych lekturą nie zatrzymuję już i jeszcze tylko na odchodne dorzucę nieśmiało, aby komentować, pytać i kwestionować. Wszyscy zostaną *odpowiednio* potraktowani :-)
Korzystając z okazji, chciałbym życzyć Tobie wszystkiego dobrego w nowym roku 2011 i nakłaniam do jeszcze większej aktywności. Nie czekaj, aż powiedzą, ale mów, proponuj, bądź liderem w swojej społeczności. Dla poszukujących natchnienia polecam lekturę wpisu na blogu Damiana Nowaka - Apprenticeship – długa droga ku Software Craftsmanship. Nie wiem, czy to styl pisania Damiana, czy może sama książka, ale tylko takich wpisów życzę nam w nadchodzącym roku. Niech kasa pójdzie w zapomnienie - niech będzie jej tyle, aby nie stanowiła kwestii do rozwiązania - a czas spędzajmy na tworzeniu - nowego i użytecznego oprogramowania, społeczności przez chociażby dzielenie się wiedzą. Nie ważne jaki był (i jeszcze będzie przez kolejne 2 dni) rok 2010, ale ważne, ile możesz zrobić, aby 2011 był jeszcze lepszy. Zalatuje socjotechniką, ale dobre myślenie poprawia mój nastrój, więc może i Twój również, a to może przełożyć się na coś wyjątkowego.
W takim tonie przedkładam Tobie do oceny mój nowy artykuł Embeddable EJB 3.1 z GlassFish 3.1 i NetBeans IDE 7.0, w którym...
Rozdział 22. Embeddable Usage specyfikacji Enterprise JavaBeans (EJB) 3.1 opisuje nową cechę specyfikacji, która pozwala na uruchomienie kontenera EJB i zarządzanych przez niego komponentów EJB poza serwerem aplikacyjnym Java EE 6 - jedynie na poziomie środowiska Java SE. W ten sposób autorzy specyfikacji przewidują (a my programiści im wierzymy) uproszczenie procesu testowania, przetwarzania wsadowego (w którym użycie transakcji jest kluczowe) czy użycie EJB w samodzielnych aplikacjach desktopowych. Innymi słowy, mamy wszystko, co oferuje kontener EJB 3.1 bez konieczności uruchamiania pełnego serwera aplikacyjnego Java EE, którego sama konfiguracja uruchomieniowa mogła przyprawić o ból głowy.
Zainteresowanych lekturą nie zatrzymuję już i jeszcze tylko na odchodne dorzucę nieśmiało, aby komentować, pytać i kwestionować. Wszyscy zostaną *odpowiednio* potraktowani :-)
20 grudnia 2010
EJB 3.1 z OpenEJB 3.1 i NetBeans IDE 7.0
Jest wiele sposobów na naukę nowych technologii i dobór odpowiednich narzędzi może znacząco usprawnić ten proces. W przypadku EJB 3.1 możemy skorzystać z projektu Apache OpenEJB 3.1, podpierając się NetBeans IDE 7.0 jako zintegrowanym środowiskiem programistycznym z asystentami tworzenia ziaren EJB z Apache Maven w tle.
Zastosowanie EJB 3.1 jest zwykle podyktowane względami praktycznymi, kiedy wybór serwera aplikacyjnego Java EE 6 mamy już za sobą i pozostaje wykorzystać jego usługi. Ich kompletność i gotowość do użycia najlepiej doświadczyć, kiedy konieczne jest wykorzystanie transakcji, podłączenia do bazy danych z możliwością przypisania komu i co wolno, udostępnić Web Service z wykorzystaniem REST w ramach aplikacji webowej czy podobne "deklaratywne czynności". Nie ma konieczności zestawiania gotowej konfiguracji usług, a konwencja ponad konfigurację znacznie przyspiesza dostarczanie kompletnych rozwiązań. Przenośność aplikacji jest również istotnym aspektem wyboru stosu technologicznego. Dodając do tego łatwość testowania aplikacji korporacyjnych i Java EE 6 (JEE6) wydaje się być idealną platformą aplikacyjną.
W tym artykule przedstawię uruchomienie bezinterfejsowego, niestanowego ziarna sesyjnego EJB (ang. no-interface stateless session bean) z użyciem projektu Apache OpenEJB 3.1.4, który stworzę w NetBeans IDE 7.0 (wersja rozwojowa z dnia 15.12.2010). Celem jest maksymalne zminimalizowanie czasu koniecznego do uruchomienia środowiska. Kolejną zaletą zastosowania OpenEJB jest możliwość wykonanywania wszystkich operacji projektowych (budowanie i testowanie) poza IDE, dzięki użyciu Apache Maven wspieranym przez NetBeans IDE 7 "z pudełka".
Więcej w artykule EJB 3.1 z OpenEJB 3.1 i NetBeans IDE 7.0.
Zastosowanie EJB 3.1 jest zwykle podyktowane względami praktycznymi, kiedy wybór serwera aplikacyjnego Java EE 6 mamy już za sobą i pozostaje wykorzystać jego usługi. Ich kompletność i gotowość do użycia najlepiej doświadczyć, kiedy konieczne jest wykorzystanie transakcji, podłączenia do bazy danych z możliwością przypisania komu i co wolno, udostępnić Web Service z wykorzystaniem REST w ramach aplikacji webowej czy podobne "deklaratywne czynności". Nie ma konieczności zestawiania gotowej konfiguracji usług, a konwencja ponad konfigurację znacznie przyspiesza dostarczanie kompletnych rozwiązań. Przenośność aplikacji jest również istotnym aspektem wyboru stosu technologicznego. Dodając do tego łatwość testowania aplikacji korporacyjnych i Java EE 6 (JEE6) wydaje się być idealną platformą aplikacyjną.
W tym artykule przedstawię uruchomienie bezinterfejsowego, niestanowego ziarna sesyjnego EJB (ang. no-interface stateless session bean) z użyciem projektu Apache OpenEJB 3.1.4, który stworzę w NetBeans IDE 7.0 (wersja rozwojowa z dnia 15.12.2010). Celem jest maksymalne zminimalizowanie czasu koniecznego do uruchomienia środowiska. Kolejną zaletą zastosowania OpenEJB jest możliwość wykonanywania wszystkich operacji projektowych (budowanie i testowanie) poza IDE, dzięki użyciu Apache Maven wspieranym przez NetBeans IDE 7 "z pudełka".
Więcej w artykule EJB 3.1 z OpenEJB 3.1 i NetBeans IDE 7.0.
14 grudnia 2010
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.
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.
09 grudnia 2010
Temat przewodni na grudzień - Java EE 6
Ankieta określająca temat przewodni na miesiąc grudzień 2010 dobiegła końca z 85 głosami, w których specyfikacja Java EE 6 zdobyła najwięcej głosów, nieznacznie więcej niż EJB 3.1 i JSF 2.0. Bardzo zdumiewające dla mnie było wskazanie na OSGi jako bardziej interesującego niż CDI. A może nie jest to wskazanie na bardziej interesującą technologię, ale na mniej rozpoznaną?!
Tym samym rozpoczynam analizę JEE6, w której głównymi graczami będą - dokument standaryzacyjny JSR 316: Java Platform, Enterprise Edition 6 (Java EE 6), serwery aplikacyjne: GlassFish 3.1, Apache Geronimo 3.0, IBM WebSphere Application Server V8 ze zintegrowanymi środowiskami programistycznymi NetBeans IDE 7.0 i IBM Rational Application Developer V8.
Akurat teraz prowadzę 4-dniowe autorskie warsztaty dla programistów (korzystających z Java EE 5 z RAD8) i administratorów WAS7, w których staram się minimalizować przedstawienie tematu od strony teoretycznej, kładąc nacisk na praktyczną stronę pracy z w/w produktami. Skłamałbym, gdybym powiedział, że udało mi się odpowiedzieć na wszystkie pytania, a było również wiele niezwykle inspirujących. Zebrałem tym samym mnóstwo tematów do przyszłych skrinkastów, więc można spodziewać się ich jeszcze kilka w tym roku i wszystkie (a przynajmniej ich większość) wokół JEE. Końcówka 2010 zapowiada się pracowita nagraniowo. W końcu pojawiła się wena, z którą zamierzam wejść w 2011!
p.s. Uruchomiłem nową ankietę "Preferowany sposób nauki JEE6", w której badam zainteresowanie różnym sposobem prezentacji JEE6. Znajdziesz ją po prawej na moim blogu. Zapraszam.
Akurat teraz prowadzę 4-dniowe autorskie warsztaty dla programistów (korzystających z Java EE 5 z RAD8) i administratorów WAS7, w których staram się minimalizować przedstawienie tematu od strony teoretycznej, kładąc nacisk na praktyczną stronę pracy z w/w produktami. Skłamałbym, gdybym powiedział, że udało mi się odpowiedzieć na wszystkie pytania, a było również wiele niezwykle inspirujących. Zebrałem tym samym mnóstwo tematów do przyszłych skrinkastów, więc można spodziewać się ich jeszcze kilka w tym roku i wszystkie (a przynajmniej ich większość) wokół JEE. Końcówka 2010 zapowiada się pracowita nagraniowo. W końcu pojawiła się wena, z którą zamierzam wejść w 2011!
p.s. Uruchomiłem nową ankietę "Preferowany sposób nauki JEE6", w której badam zainteresowanie różnym sposobem prezentacji JEE6. Znajdziesz ją po prawej na moim blogu. Zapraszam.
06 grudnia 2010
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.
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.
Przyjrzyjmy się kolejnej wersji wcześniejszej klasy BlogPanel, która różni się jedynie adnotacją @Stateless.
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.
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.
19 lipca 2010
Clojure w aplikacji webowej Java EE 6 z Eclipse Helios, Apache Maven i Apache Tomcat
Ufff, udało się! Ależ radości przyniosło mi uruchomienie aplikacji webowej Java EE 6 z logiką napisaną w...Clojure! A później to spisywanie - tego najbardziej nie lubię, kiedy każdy szczegół ma znaczenie i trzeba przerabiać materiał kilkakrotnie. Chciałoby się to po prostu nagrać, zamiast spisywać (ale to po urlopie).
Właśnie ukończyłem prace nad nowym artykułem w moim Wiki - Clojure w aplikacji webowej Java EE 6 z Eclipse Helios, Apache Maven i Apache Tomcat, który przedstawia moje ostatnie doświadczenia z "produkcyjnym" wykorzystaniem Clojure z JEE6. Do całości dorzuciłem jeszcze integrację Eclipse Helios z Apache Maven (przez wtyczkę m2eclipse) i counterclockwise do obsługi Clojure. Powinno się podobać.
Nie przeciągając dłużej (i bez zbytniego zachwalania treści artykułu :-)) wierzę, że każdy znajdzie tam coś dla siebie. Niektórzy poznają Eclipse i jego środowisko (aż dwie wtyczki użyte), niektórzy samo uruchomienie aplikacji JEE6, a inni Clojure z Javą. Zapraszam do lektury i komentowania.
Jeszcze jutro recenzja książki o Springu i w nadchodzący czwartek znikam na długooczekiwany urlop. Jeszcze tylko 2 dni!
Właśnie ukończyłem prace nad nowym artykułem w moim Wiki - Clojure w aplikacji webowej Java EE 6 z Eclipse Helios, Apache Maven i Apache Tomcat, który przedstawia moje ostatnie doświadczenia z "produkcyjnym" wykorzystaniem Clojure z JEE6. Do całości dorzuciłem jeszcze integrację Eclipse Helios z Apache Maven (przez wtyczkę m2eclipse) i counterclockwise do obsługi Clojure. Powinno się podobać.
Nie przeciągając dłużej (i bez zbytniego zachwalania treści artykułu :-)) wierzę, że każdy znajdzie tam coś dla siebie. Niektórzy poznają Eclipse i jego środowisko (aż dwie wtyczki użyte), niektórzy samo uruchomienie aplikacji JEE6, a inni Clojure z Javą. Zapraszam do lektury i komentowania.
Jeszcze jutro recenzja książki o Springu i w nadchodzący czwartek znikam na długooczekiwany urlop. Jeszcze tylko 2 dni!
15 lipca 2010
Google Guice i JSR-330 Dependency Injection for Java
W Recenzja "Dependency Injection, Design patterns using Spring and Guice" z Manning pisałem o moim zachwycie Google Guice. Okazało się, że jest to jedno z tych rozwiązań, którego istnienia nie doceniałem, a gdyby zapytać mnie o cechy wyróżniające go od innych, podobnych jemu, z pewnością nie potrafiłbym wskazać tych, które mogłyby sprawić, że stanie się właściwym rozwiązaniem w projekcie. Obecna moja znajomość Guice sprowadza się do umiejętności wymówienia jego nazwy i opisania jako kontener DI (ang. dependency injection). Niewiele.
Po tej książce, potrzebowałem bliższego, bardziej praktycznego spotkania z Guice. Kiedykolwiek myślę o kontenerze DI, na myśl przychodzi Spring Framework (czasami, ale baaaardzo rzadko, takie egzotyczne rozwiązania jako HiveMind, PicoContainer, może nawet JBoss Seam, Apache XBean czy dawno zapomniany Avalon). Moje ostatnie dokonania na gruncie Spring Framework w postaci warsztatu i po nim następujących artykułów (patrz Tworzenie samodzielnej aplikacji ze Spring Framework i Hibernate w NetBeans IDE 6.9) trochę mnie zmęczyły i kiedykolwiek zabierałem się za kolejną konfigurację w XMLu, wspominałem stare, dobre czasy z serwerem aplikacyjnym Java EE. Ktoś mógłby wspomnieć o możliwości konfiguracji Springa przez adnotacje, ale jakby tego nie ująć, każdorazowe spotkanie ze Springem zawsze u mnie kończy się jednak na XMLu. Brrr...
Kiedy zabrałem się za poznawanie specyfikacji Java EE 6, zacząłem od JSR 299: Contexts and Dependency Injection for the Java EE platform (w skrócie CDI). Tam naczytałem się o wielu innych specyfikacjach i czego mi brakowało, to jego użycia poza serwerem aplikacyjnym JEE6. W końcu jakoś się udało i nawet spisałem moje doświadczenia w artykule Contexts and Dependency Injection (CDI) praktycznie - zestawienie środowiska z JBoss Weld, Arquillian i Apache Maven 2. Należy jednak zwrócić uwagę na słowo "jakoś", bo ono oddaje klimat tego artykułu - CDI w obecnym kształcie jest możliwe do uruchomienia poza serwerem aplikacyjnym, ale jego główne użycie jest właśnie w ramach serwera (chociażby JSF2). Nie pasowało mi tu stworzenie kolejnej specyfikacji JSR-330 Dependency Injection for Java. Możnaby powiedzieć, że DI to CDI, ale coś je jednak musi różnić, skoro obie istnieją pod parasolem JEE6. I różnią się - zespołem pracującym nad nimi :-) Przy CDI pracował Gavin King (JBoss Seam, Hibernate), a przy DI pracowali Bob Lee (Guice) i Rod Johnson (współtwórca Spring Framework). To może tłumaczyć pojawienie się obu, zamiast stworzenia jednej właściw(sz)ej.
Ostatnio zasugerowano mi, aby sprawdzić wsparcie CDI przez Springa i przez myśl przeszło mi, aby się tym zająć, ale zamiast CDI skończyło się na JSR330 DI. Zacząłem od dokumentacji pakietu javax.inject. To właśnie wtedy stwierdziłem, aby zamiast Springa, zbadać Guice.
Po javadoc wzięło mnie na lekturę Dependency injection with Guice, który okazał się bardzo przystępny merytorycznie, wciąż jednak stosunkowo krótki, aby się nie znużyć jedynie czytaniem. Później przyszła pora na Google Guice :: Getting Started i Google Guice :: Spring Comparison. Z nimi i wcześniejszą lekturą książki Dependency Injection - Design patterns using Spring and Guice byłem gotów do wstępnych testów, tym razem z IntelliJ IDEA.
Zacznijmy od końca - od uruchomienia Guice i pobrania kompletnego obiektu z już wstrzelonymi zależnościami.
Ostatnim, aczkolwiek najważniejszym elementem aplikacji korzystającej z Guice, jest wykorzystanie adnotacji @com.google.inject.Inject, która oznacza miejsca podlegające mechanizmowi wstrzeliwania zależności (stąd też nazwa dla specyfikacji JSR 330 DI - atInject). Poniższa klasa prezentuje adnotację @Inject w akcji.
p.s. W ostatniej klasie EnglishPolishDictionaryService popełniłem błąd związany z niepoprawnym użyciem wstrzeliwania zależności (oferowanym przez Guice, ale to nie ma w tym przypadku znaczenia). Sama aplikacja działa, ale właściwe użycie DI powinno odpowiadać zasadzie Inject only direct dependencies. Przykład obrazuje, ile jeszcze przede mną nauki, aby tę całą tajemną wiedzę przyswoić.
Po tej książce, potrzebowałem bliższego, bardziej praktycznego spotkania z Guice. Kiedykolwiek myślę o kontenerze DI, na myśl przychodzi Spring Framework (czasami, ale baaaardzo rzadko, takie egzotyczne rozwiązania jako HiveMind, PicoContainer, może nawet JBoss Seam, Apache XBean czy dawno zapomniany Avalon). Moje ostatnie dokonania na gruncie Spring Framework w postaci warsztatu i po nim następujących artykułów (patrz Tworzenie samodzielnej aplikacji ze Spring Framework i Hibernate w NetBeans IDE 6.9) trochę mnie zmęczyły i kiedykolwiek zabierałem się za kolejną konfigurację w XMLu, wspominałem stare, dobre czasy z serwerem aplikacyjnym Java EE. Ktoś mógłby wspomnieć o możliwości konfiguracji Springa przez adnotacje, ale jakby tego nie ująć, każdorazowe spotkanie ze Springem zawsze u mnie kończy się jednak na XMLu. Brrr...
Kiedy zabrałem się za poznawanie specyfikacji Java EE 6, zacząłem od JSR 299: Contexts and Dependency Injection for the Java EE platform (w skrócie CDI). Tam naczytałem się o wielu innych specyfikacjach i czego mi brakowało, to jego użycia poza serwerem aplikacyjnym JEE6. W końcu jakoś się udało i nawet spisałem moje doświadczenia w artykule Contexts and Dependency Injection (CDI) praktycznie - zestawienie środowiska z JBoss Weld, Arquillian i Apache Maven 2. Należy jednak zwrócić uwagę na słowo "jakoś", bo ono oddaje klimat tego artykułu - CDI w obecnym kształcie jest możliwe do uruchomienia poza serwerem aplikacyjnym, ale jego główne użycie jest właśnie w ramach serwera (chociażby JSF2). Nie pasowało mi tu stworzenie kolejnej specyfikacji JSR-330 Dependency Injection for Java. Możnaby powiedzieć, że DI to CDI, ale coś je jednak musi różnić, skoro obie istnieją pod parasolem JEE6. I różnią się - zespołem pracującym nad nimi :-) Przy CDI pracował Gavin King (JBoss Seam, Hibernate), a przy DI pracowali Bob Lee (Guice) i Rod Johnson (współtwórca Spring Framework). To może tłumaczyć pojawienie się obu, zamiast stworzenia jednej właściw(sz)ej.
Ostatnio zasugerowano mi, aby sprawdzić wsparcie CDI przez Springa i przez myśl przeszło mi, aby się tym zająć, ale zamiast CDI skończyło się na JSR330 DI. Zacząłem od dokumentacji pakietu javax.inject. To właśnie wtedy stwierdziłem, aby zamiast Springa, zbadać Guice.
Po javadoc wzięło mnie na lekturę Dependency injection with Guice, który okazał się bardzo przystępny merytorycznie, wciąż jednak stosunkowo krótki, aby się nie znużyć jedynie czytaniem. Później przyszła pora na Google Guice :: Getting Started i Google Guice :: Spring Comparison. Z nimi i wcześniejszą lekturą książki Dependency Injection - Design patterns using Spring and Guice byłem gotów do wstępnych testów, tym razem z IntelliJ IDEA.
Zacznijmy od końca - od uruchomienia Guice i pobrania kompletnego obiektu z już wstrzelonymi zależnościami.
package pl.jaceklaskowski.javaee.di;
import com.google.inject.Guice;
import com.google.inject.Injector;
public class Main {
public static void main(String[] args) {
Injector injector = Guice.createInjector(new DictionaryModule());
EnglishPolishDictionaryService dictionaryService = injector.getInstance(EnglishPolishDictionaryService.class);
System.out.println(dictionaryService.translate("turn out"));
}
}Konfigurację Guice realizuje się przez moduły - klasy javowe, w których przypisujemy interfejsy do ich implementacji, typów, które będą przedmiotem wstrzeliwania zależności.package pl.jaceklaskowski.javaee.di;
import com.google.inject.AbstractModule;
public class DictionaryModule extends AbstractModule {
@Override
protected void configure() {
bind(VocabularyProvider.class).to(EnglishVocabularyProvider.class);
}
}Każdy moduł rozszerza klasę com.google.inject.AbstractModule. To w module konfigurujemy Guice na potrzeby naszej aplikacji, gdzie następuje przypisanie co będzie przypisane gdzie za pomocą konstrukcji bind([GDZIE]).to([CO]).in([OBSZAR])W powyższym przykładzie, jakiekolwiek wystąpienie zmiennej typu VocabularyProvider zostanie zainicjowane zmienną typu EnglishVocabularyProvider, domyślnie jako singleton.
Ostatnim, aczkolwiek najważniejszym elementem aplikacji korzystającej z Guice, jest wykorzystanie adnotacji @com.google.inject.Inject, która oznacza miejsca podlegające mechanizmowi wstrzeliwania zależności (stąd też nazwa dla specyfikacji JSR 330 DI - atInject). Poniższa klasa prezentuje adnotację @Inject w akcji.
package pl.jaceklaskowski.javaee.di;
import com.google.inject.Inject;
import java.util.Locale;
import java.util.Map;
public class EnglishPolishDictionaryService implements DictionaryService {
private final Map<String, String> vocabulary;
@Inject
EnglishPolishDictionaryService(VocabularyProvider vocabularyProvider) {
this.vocabulary = vocabularyProvider.provideVocabularyFor(Locale.ENGLISH);
}
public String translate(String word) {
return "[PL]" + word;
}
}Każde wystąpienie @Inject jest miejscem, gdzie nastąpi wstrzelenie zależności przez Guice. Czy to konstruktor (którego wszystkie parametry podlegają wstrzeliwaniu przez Guice), czy metoda (o dowolnej nazwie i sygnaturze), czy pole instancji, wszystkie te miejsca są inicjowane przez Guice.p.s. W ostatniej klasie EnglishPolishDictionaryService popełniłem błąd związany z niepoprawnym użyciem wstrzeliwania zależności (oferowanym przez Guice, ale to nie ma w tym przypadku znaczenia). Sama aplikacja działa, ale właściwe użycie DI powinno odpowiadać zasadzie Inject only direct dependencies. Przykład obrazuje, ile jeszcze przede mną nauki, aby tę całą tajemną wiedzę przyswoić.
09 czerwca 2010
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.
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.
01 czerwca 2010
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):
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:
Do tej pory zrelacjonowałem ze specyfikacji CDI (wszystkie w kategorii cdi):
- Nauka Java EE 6 CDI (JSR-299) - relacja z lektury pierwszych dwóch rozdziałów specyfikacji
- Lektura specyfikacji CDI (JSR-299) za mną, NetBeans 6.9 RC1 wydane i JSR-330 Dependency Injection for Java
- Rozdział 2. Koncepcje ze specyfikacji Java EE 6 Contexts and Dependency Injection (CDI)
- i jeden, dwa z przemyśleniami różnymi.
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)
27 maja 2010
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.
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:
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.
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.
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.
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):
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?
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
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.
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
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?
26 maja 2010
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:
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.
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:
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.
Subskrybuj:
Posty (Atom)