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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5 Nazwa EL

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

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

2.6 Alternatywy

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

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

2.7 Stereotypy

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

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

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

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

Stereotyp może mieć przypisane interceptory.

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

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

Stereotyp może mieć stereotypy.

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

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

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

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

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