Do tej pory dużo rozpisywałem się o Korporacyjnej Javie 5 (Java EE 5) i tym razem...nie będzie inaczej (bo jak nie skorzystać z czegoś, co jest do wzięcia na wyciągnięcie ręki?!). Różnicą będzie wykorzystanie możliwości usług serwera aplikacji i rozszerzenie ich o możliwości Spring Framework. A skąd pomysł na skorzystanie ze Springa? Tym, co skłania do użycia Spring Framework jest jego zaawansowany mechanizm wstrzeliwania zależności (ang. DI - dependency injection), który w korporacyjnej javie jest stosunkowo mocno okrojony, powiedziałbym zawężony do niezbędnego minimum. Skoro siłą Springa jest mechanizm wstrzeliwania zależności, a serwera aplikacji Java EE 5 usługi, jak transakcyjność, utrwalanie danych, bezpieczeństwo, współbieżność, czy możliwość ich rozproszenia, to dlaczegóżby nie połączyć obu, aby mieć doskonalsze środowisko do tworzenia aplikacji korporacyjnych? Zawsze mnie korciło, aby bliżej przyjrzeć się Springowi, więc nadeszła pora upiec dwie pieczenie na jednym ogniu - rozpoznawać Springa w kontekście rozpoznawania kolejnej technologii Java EE 5 - JavaServer Faces (JSF) 1.2. W JSF istnieje pewien wycinek wsparcia dla DI, który oferuje Spring, więc mając zintegrowane oba rozwiązania spodziewam się, że wszelkie braki w JSF zostaną uzupełnione. Pozostaje pytanie o dalsze elementy środowiska, które pomogą w realizacji celu. Do programowania w Javie wykorzystam Eclipse IDE 3.3.1.1 z wtyczką Geronimo Eclipse Plugin, podczas gdy zarządzanie zależnościami aplikacyjnymi pozostawię projektowi, który spisuje się w tej roli bezsprzecznie najlepiej Apache Maven 2. Nie, nie chciałbym tym razem uskuteczniać akrobacji z linii poleceń, więc integrację między Eclipse IDE i Maven oprę na wtyczce M2Eclipse (Tycho). Środowiskiem uruchomieniowym tworzonej aplikacji internetowej będzie Apache Geronimo 2.0.2.
Całe środowisko będzie przyczółkiem do dalszych integracji w celu wykorzystania najlepszych cech poszczególnych projektów i technologii upraszczając proces tworzenia aplikacji korporacyjnych Java EE 5, gdzie głównym rozgrywającym będzie JSF 1.2.
Zapraszam do lektury artykułu JavaServer Faces i Spring Framework w parze z Apache Maven i Apache Geronimo. Co mnie bardziej interesuje to komentarze dotyczące sposobu przedstawienia tematu i dalsze ścieżki jego rozwoju. Generalnie doskwiera mi brak krytycznych komentarzy ;-)
Subskrybuj:
Komentarze do posta (Atom)
Jacek,
OdpowiedzUsuńprzede wszystkim cieszy mnie że piszesz o JSF 1.2 oraz że przerzucasz się z linii poceceń na Eclipse - prosiłeś o komentarze o twoich artykułach więc masz :)
Ale mam też pytanko - tworząc projekt definiujesz biblioteki JSF, czemu nie wybrałeś opcji 'Server Supplied JSF Implementation'? Wydawało mi się, że ta opcja jest tam właśnie po to, by użyć jej gdy aplikację uruchamiamy na serwerze Java EE 5 (np. Geronimo). Ręczne wskazywanie bibliotek dla odmiany powinno być używane jak mamy np. Tomcat'a. Próbowałeś użyć tej opcji?
Jacek,
OdpowiedzUsuńprzejrzałem literaturę którą podałeś pod swoim artykułem, tzn. 'WTP Tutorials - JavaServer Faces Tools Tutorial' i znalazłem tam zdanie:
"If you deploy the JSF web application to a server runtime that includes the JSF 1.2 reference implementation, then you should select the Server Supplied JSF implementation option."
Nawiasem mówiąc, to co tam widać, tzn. możliwości 'JavaServer Faces Tools' całkiem mi się podoba - przypomina mi to w dużej mierze Exadel Studio czyli RH Developer Studio.
Mi za to brakuje wytłumaczenia dlaczego uzyles el-resolver zamiast variable-resolver, napisałes ładnie co zrobic ale nie piszesz dlaczego tak a nie inaczej i co Ci to daje.
OdpowiedzUsuńDodatkwo wymusza to wykorzystanie geronimo-el_1.0_spec-1.0.jar, zdefiniowanie biblioteki JSF recznie.
Nie bardzo wiem dlaczego a chetnie sie dowiem :)
Pozdro.
Metyl,
OdpowiedzUsuńnie mam super odpowiedzi na pytanie dlaczego el-resolver zamiast variable-resolver ale fakt faktem, że jak próbowałem połączyć Facelets + JSF 1.2 ze Spring'iem i użyłem początkowo variable-resolver to zapluło mi jakimś wyjątkiem (niestety nie pamiętam już co to było) i musiałem zmienić na el-resolver. Natomiast zdecydowanie nie jest prawdą, że "wymusza to wykorzystanie geronimo-el_1.0_spec-1.0.jar".
Integrację JSF 1.2 i Spring opisałem na swoim blogu w artykule "Integracja JSF 1.2 i Spring z pomocą Red Hat Developer Studio" i mimo że użyłem el-resolver to obyło się bez tej biblioteki. Nie jest też jak mi się wydaje (nie sprawdzałem więc nie jestem pewien) prawdą, że bibliotekę JSF w przypadku użycia Geronimo trzeba definiować ręcznie. Patrz mój drugi komentarz do tego artykułu.
Hmm myslałem ze autor rzuci troche swiatała na sprawe ...
OdpowiedzUsuńRzuci, rzuci, ale musi się zebrać w sobie i przygotować odpowiedź. Ostatnio zagrzebałem się w Seama i Geronimo i po prostu "odjechałem" ;-) Jeszcze moment, a cierpliwość zostanie wynagrodzona.
OdpowiedzUsuń