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.
Jacku,
OdpowiedzUsuńpytasz o możliwość zapisania tego samego w Gradle. Pewnie się da, ale chyba w tym przypadku nie ma to większego sensu. W swoim buildzie opierasz się na funkcjonalności Mavenowej której dostarcza jakiś inny projekt (mówię o imporcie pom.xml z weld-core-bom). Jakiż więc sens na siłę przerabiać to na Gradle skoro tu masz bonus w postaci rozszerzania tego co ktoś już zrobił i nie musisz pisać builda od nowa?
Jak mawiają pragmatycznie programiści "use the right tool for the job". W tym przypadku, mimo całego mojego uwielbienia dla Gradle, nie wydaje mi się żeby był on "right tool-em".
--
pozdrawiam
Tomek Kaczanowski
Czy komukolwiek udalo sie przekazac jakas tresc zamiast pustego beans.xml? U mnie plik ten jest parsowany (wychwytuje bledy XML), ale jego zawartosc nie ma wplywu na dzialanie testow...
OdpowiedzUsuńJacek, musze popracowac nad moja umiejetnoscia przekazywania informacji! :)
OdpowiedzUsuńW swoim kodzie, w metodzie @Deployment, tworzysz plik test.jar oraz *pusty* beans.xml. Ja zastanawialem sie, czy mozna tam przekazac istniejacy (w katalogu src/test/resouces na przyklad) istniejacy beans.xml i czy jego zawartosc bedzie uzyta w charakterze CDI.
Zauwaz tez, ze Ty nie dokonujesz wstrzykniecia niczego (zadnej klasy) ze swojego kodu (tylko javax.enterprise.inject.spi.BeanManage). I nie wiem, czy "extends TestCase" jest konieczne?
W kazdym razie, chyba udalo mi sie znalezc odpowiedz - da sie uzyc gotowego beans.xml i jego zawartosc jest wczytywana i uzywana. :)