http://code.google.com/p/stackov/ JAVA EE SPRING FRAMEWORK 3 + TILES2 + HIBERNATE 3 + SPRING SECURITY 3 TUTORIAL BETA Paweł Tomaszek 30.04.2011 pwl.tomaszek(at)gmail.com
SPIS TREŚCI 1. Wstęp... 1 1.1. Dygresji kilka... 1 1.2. Podział tutorialu na projekty... 2 1.3. Dostęp do projektów... 2 2. Słownikowa szczypta teorii... 3 3. IDE i związane... 4 3.1. Eclipse, JRE, JDK... 4 3.2. Kontener webowy Apache Tomcat... 5 4. Witaj Świecie! Witaj Chaosie! HelloWorld.war... 8 4.1. Nowy projekt... 8 4.2. Spring Framework konfiguracja... 9 4.3. Warstwa kontrolera... 12 4.4. Uruchomienie... 12 5. Koncepcja rozwoju projektów... 16 6. Szablon widoków StackOv-Tiles.war... 17 6.1. Tiles konfiguracja I warstwa prezentacji... 18 7. Baza danych StackOv-Hibernate.war... 20 7.1. Baza danych... 20 7.2. Hibernate konfiguracja... 20 7.3. Warstwa kontrolera... 22 7.4. Warstwa dostępu do danych... 23 7.5. Warstwa prezentacji... 25 7.6. Podsumowanie... 25 8. Autoryzacja StackOv-SpringSecurity.war... 26 8.1. SpringSecurity konfiguracja... 26 8.2. Warstwa prezentacji... 27 8.3. Podsumowanie... 28 9. All-In-One StackOv.war... 29 10. Bibliografia... 30
1. Wstęp 1.1. Dygresji kilka Dokument ma na celu przedstawienie kolejnych kroków prowadzących do stworzenia prostego serwisu internetowego. Nie ukazuje jednak, jak klik po kliku tego dokonać, ani dokładnie co, jak i dlaczego jest w danej chwili robione. Z tego powodu pogłębianie wiedzy przez korzystanie z wyszukiwarek internetowych, forów i literatury specjalistycznej jest wskazane. W Sieci znaleźć można wiele polsko- i angielskojęzycznych samouczków ukazujących różne podejścia i narzędzia związane z tematem aplikacji internetowych oraz technologii Java Enterprise Edition. Polecam korzystać z nich, samemu testować i wybierać, co jest subiektywnie lepsze. Niektóre kwestie, takie jak konfiguracja JDK z IDE, nie będą tu poruszane, ponieważ tak daleko idące powielanie wiedzy Internetu, nawet dla ateisty wydaje się być grzechem. Także niniejszy tekst dla niektórych może wydawać się swoistą kalką i w pewnym stopniu tak właśnie jest. Tutorial nie ma na calu dogłębnego wyjaśniania, czym jest JVM, JRE, JDK, IDE i inne trzyliterowe skróty. Informację o wspominanych należy czerpać z Internetu, tudzież literatury książkowej. Charakterystyka używanych bibliotek jest bardzo ogólna. Oczywistym jest, gdzie można odnaleźć odpowiednią dokumentację na ich temat. Wszystkie operacje przedstawione w dokumencie zostały wykonane w systemie Windows XP 64-bit SP3. Nie ma jednak problemu z programowaniem pod Linuksem czy innymi wersjami systemów MS (wymagania co do platformy OS znaleźć można na oficjalnych stronach deweloperów narzędzi). Frameworkowi czy frejmłorkowi? Konwencja jaką przyjąłem dla niektórych może wydawać się poprawna, a dla innych już nie. Zasady j. polskiego jasno nie precyzują jak postępować z żargonem technicznym będącym jednym z LSP (language for specific purposes). Wyznacznikiem przy pisaniu tekstu, było to, byś po prostu mogła/mógł zrozumieć o co chodzi. Styl nazewnictwa klas i plików został przyjęty z ogólnie panujących konwencji, z którymi miałem styczność (dowiedz się sama/sam, dlaczego część początkowa pakietów Java nosi nazwę odwróconego adresu internetowego). Nie wszystko będzie jasne na samym początku to normalne. Nie będzie też tłumaczone korzystanie m.in. z oficjalnej dokumentacji to chleb powszedni programisty. Z każdą kolejną stroną powinno być lepiej. Możliwe, że w tutorialu występują błędy natury językowej i technicznej daj znać, to poprawię. 1
1.2. Podział tutorialu na projekty Tutorial składa się z 5 projektów, z których każdy kolejny zawiera w sobie to co poprzedni + modyfikacje i nowe frameworki. Kolejne rozdziały opisują tworzenie bądź budowę każdej z aplikacji: HelloWorld.war podstawowa konfiguracja nowego projektu jedynie ze Spring Framework i stroną JSP na kontenerze Tomcat; warstwa kontrolerów; podstawowy obieg danych w szablonie MVC (w zasadzie same warstwy VC) StackOv-Tiles.war szablon widoków Tiles StackOv-Hibernate.war CRUD (zapisywanie/odczytywanie/edytowanie/usuwanie) obiektów z baz danych; konfiguracja serwera MySQL i aplikacji webowej; mapowanie obiektów Java na obiekty w bazie i vice versa za pomocą Hibernate; używanie podstawowych funkcji działania na obiektach StackOv-SpringSecurity.war autoryzacja za pomocą Spring Security; podstawowa konfiguracja i implementacja StackOv.war najbardziej rozbudowany projekt. Integruje wcześniej użyte frameworki na nieco większym poziomie; współtworzony z Grzegorzem Ilachem, odpowiedzialnym głównie za front-end oraz AJAX/JSON; tutorial Grześka oraz poruszone przez niego kwestie znajdować się będą w innym pliku, tak więc przy przeczesywaniu projektu przydadzą Ci się oba dokumenty każdy będzie poruszał inne aspekty jednej aplikacji 1.3. Dostęp do projektów Najnowsze wersje aplikacji znajdują się w repozytorium SVN w drzewie branches (dla 4 pierwszych projektów; archiwa w dziale Download mogą być przestarzałe) oraz w katalogu trunk (dla StackOv.war). Adres: http://code.google.com/p/stackov/ 2
2. Słownikowa szczypta teorii Serwlet obiekt klasy Java, który potrafi odpowiadać na zgłoszenia HTTP. Kontener/serwer aplikacji pudełko, w którym egzystują serwety. Jego zadaniem jest zarządzanie przekierowaniami, transakcjami, cyklem życia serwletów, bezpieczeństwem i kilkoma innymi kwestiami. Servlet API interfejs umożliwiający interakcję pomiędzy serwletem a kontenerem webowym. MVC model, widok, kontroler. Model obiekt używany w aplikacji, jak również warstwa DAO. Kontroler klasa przyjmująca żądania i działająca na ich podstawie. Często wymusza zmiany w modelu i zwraca widok. Widok strona będąca interfejsem użytkownika, czyli po prostu wygenerowana w przeglądarce treść; widok to także określenie źródła, czyli plik HTML, JSP, JSF, itp. DAO Data Access Object. BO Business Object. 3
3. IDE i związane 3.1. Eclipse, JRE, JDK Pracę należy zacząć od pobrania zintegrowanego środowiska programistycznego ze wsparciem dla Java EE, np. Eclipse Helios [1] lub NetBeans. Przy pisaniu poradnika wykorzystano pierwszy z wymienionych programów. Uwaga! Mimo posiadania 64-bitowego OS, lepiej nie pobierać 64-bitowych wersji środowisk. U mnie pojawiały się problemy z IDE oraz JDK/JRE, co jest dosyć znaną przypadłością, lecz nie regułą. Jednak bezpieczniej będzie pobrać 32-bitową wersję Eclipse i Javy. Proces instalacji ogranicza się do wypakowania archiwum zip do miejsca, w którym trzymane są programy. Przy pierwszym uruchomieniu najprawdopodobniej wyskoczy taki komunikat: Rys. 3.1. Informacja o braku Javy Do uruchomienia Eclipse wystarczy JRE, jednak do tworzenia aplikacji niezbędne jest JDK (które notabene zawiera w sobie niezależne JRE). Dlatego, jeśli nie masz JDK, pobierz je ze strony Oracle [8]. Jeśli jest już w systemie, wystarczy, że wykonasz jedną z rzeczy: ustalisz zmienną systemową PATH na ścieżkę do javaw.exe ustawisz odpowiednią ścieżkę w pliku eclipse.ini z parametrem -vm skopiujesz JRE w folder wskazany w komunikacie, tak by plik javaw.exe był widziany przez IDE we własnym podkatalogu jre Uruchomienie aplikacji oznacza, że JRE jest poprawnie dowiązane. Kolejnym sprawą, o którą upomni się IDE, jest wskazanie katalogu workspace, w którym to będą przechowywane nowotworzone projekty. Rys. 3.2. Wskazanie katalogu roboczego 4
W razie problemów posiłkuj się stroną producenta [2]. Na sam koniec upewnij się, że w Eclipse ustawiony jest widok Java EE. Zmiana perspektywy: Window > Open Perspective > Other > Java EE Jeśli dopiero zaczynasz przygodę z Eclipse lub w ogóle z programowaniem z użyciem IDE, polecam pobawić się w klikanego: najeżdżać myszą nad przyciski, czytać opisy i wciskać je, jeśli przyjdzie na to ochota. Eclipse jest bardzo stabilne i dopóki przed klawiaturą nie posadzi się kilku małp, nic nie powinno się stać. Drobne zepsucie czegoś (przestawienie widoku, usunięcie pasków narzędzi czy paneli) i późniejsze naprawienie, sprawi, że poczujesz się pewniej z platformą. 3.2. Kontener webowy Apache Tomcat Aplikacje stworzone w technologii Java EE uruchamia się w specjalnym środowisku kontenerze webowym (serwerze Java EE). Jednym z nich jest Tomcat. Inne to m.in. GlassFish i JBoss. Na poziomie zabawy z technologią Java EE wybór kontenera nie ma większego znaczenia. Warto jednak zaznaczyć, że Tomcat pracuje w miarę stabilnie (czasem są problemy z publikowaniem zmian) i szybko się uruchamia, co dla środowiska developerskiego jest dużym plusem. Dywagacje na temat wyższości jednych rozwiązań nad innymi, znaleźć można m.in. w publikacjach internetowych. Instalacja serwera obejmie 7. wersję Tomcata: Pobierz Tomcat 7.0 ze strony Tomcat Apache [5]. Ściągnij odpowiednią paczkę (np. 32-bit Windows zip) i rozpakuj ją do folderu programów. W Eclipse kliknij PPM (Prawy Przycisk Myszy) w panelu Servers > New > Server. Rys. 3.3. Panel serwerów Z listy wybierz Apache/Tomcat v7.0 Server i kliknij Next. Podaj lokalizację serwera i zakończ kreator. 5
Rys. 3.4. Powiązanie projektu z kontenerem Na liście serwerów pojawiła się nowa pozycja. Zaznacz ją i kliknij w ikonę strzałki na zielonym tle, oznaczoną jako Start the server. Wpisz w oknie przeglądarki (zewnętrznej lub wewnętrznej) adres http://localhost:8080/ Jeśli pojawi się okienko powitalne Tomcat, jest dobrze. W innym przypadku należy zdiagnozować, co jest nie tak. Zastopuj serwer, wejdź w katalog Tomcata, a dalej w podfolder bin. Wciśnij na klawiaturze Win+r, wpisz cmd. Na otwartą konsolę przeciągnij i upuść plik startup.bat. Jeśli wyskoczył błąd dotyczący: JAVA_JRE, ustaw zmienną systemową o tej nazwie na katalog zainstalowanego JDK. CATALINA_HOME, ustaw zmienną systemową o tej nazwie na katalog wypakowanego Tomcata. 6
Poprawny start powinien prezentować się mniej-więcej tak: Rys. 3.5. Start serwera z poziomu konsoli Komunikat o APR można zignorować. Chodzi o to, że dodatkowe biblioteki mogą zoptymalizować działanie Tomcata. Jeśli chcesz, możesz z nich skorzystać. By zatrzymać serwer, wciśnij Ctrl+C lub uruchom shutdown.exe z podkatalogi bin. Przetestuj działanie kontenera z poziomu Eclipse. Jeśli pojawia się Error 404, zastopuj serwer, wejdź w jego ustawienia i zaznacz opcję Use Tomcat Installation. Zapisz zmiany i uruchom serwer. Jeśli po jego włączeniu pojawia się strona powitalna, pozostaw taką konfigurację. Jednak w takim przypadku dobrze jest usunąć przykładowe projekty z folderu webapps katalogu Tomcata, by uniknąć ich deployowania przy każdym starcie serwera (zwróć uwagę na logi konsoli). 7
4. Witaj Świecie! Witaj Chaosie! HelloWorld.war Nie wyłamując się z konwencji, czas na Przywitanie! Jeśli nie masz ochoty na wykonywanie poniższych kroków, skorzystaj z przygotowanego projektu HelloWorld.war, który zawiera w sobie prawie dokładnie to samo (zewnętrzne biblioteki nie są dodawane do archiwów oszczędność miejsca. Musisz je dodawać indywidualnie do każdego projektu.), co otrzymałabyś/otrzymałbyś po przebrnięciu przez paragrafy. Dojdź samodzielnie, jak go zaimportować. Przedstawione w rozdziale (i kolejnych) informacje z pewnością nie będą od razu jasne. Nie jest moją intencją tłumaczenie wszystkiego. Od tego jest odpowiednia literatura i inne tutoriale, a także niezbędne godziny spędzone przed monitorem. Powodzenia! 4.1. Nowy projekt By utworzyć nowy projekt, wyklikaj: File > New > Dynamic Web Project Okno powinno zostać wypełnione, jak na poniższym obrazku. Rys. 4.1. Okno tworzenia nowego projektu 8
Wersja modułu odpowiada wersji serweta, który ma dostęp do API (także w odpowiedniej wersji). Wybór 3.0 API Servlet pociąga za sobą pewne wymogi: wersja JDK >=1.6 kontener webowy Tomcat >=7.0 Jeśli nie stać programisty na luksus 3.0, może zmienić wersję na np. 2.5, która znacznie obniża wymagania, lecz nie ma większego wpływu na docelowe działanie aplikacji, która i tak będzie jedynie zabawką, niekorzystającą z najnowszych usług Java EE. Jeszcze dwa kliknięcia w Next i okno dialogowe przeniesie Cię do ostatniego punktu dialogowego. Upewnij się, że zostało zaznaczone pole Generate web.xml deployment descriptor, a następnie wciśnij Finish. Deskryptor web.xml jest sercem aplikacji; definiuje serwety oraz ich parametry, np. mapowanie adresu czy kodowanie znaków w kontekście całej aplikacji. Więcej o jego zadaniach przeczytasz w kolejnych rozdziałach. W lewym panelu pojawi się drzewo projektu z szeregiem odnóg. Interesujące są: Java Resources miejsce, w którym znajdować się będą pisane klasy Java WebContent zasoby aplikacji: widoki jsp, konfiguracja serwletów i bibliotek, ale także obrazki, js, style css, itp. 4.2. Spring Framework konfiguracja Z pewnością wiesz (przynajmniej ogólnikowo), czym jest Spring Framework. Czas na jego implementację w projekcie. Odpowiednie biblioteki (rys. 4.4.) pobrane ze strony Spring Source [7] umieść w katalogu WebContent/WEB- INF/lib. To będzie standardowe miejsce dla wszystkich dodawanych jarów. Konfiguracja web.xml: <?xml version="1.0" encoding="utf-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemalocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="webapp_id" version="3.0"> <!-- Ustawienie kodowania w obrębie aplikacji Standardem jest UTF-8 --> <filter> <filter-name>characterencodingfilter</filter-name> <filter-class>org.springframework.web.filter.characterencodingfilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>utf-8</param-value> </init-param> <init-param> <param-name>forceencoding</param-name> <param-value>true</param-value> </init-param> </filter> <!-- UrlRewriteFilter FILTER Odpowiednio modyfikuje adresy URI. O co chodzi widać w pliku konfiguracyjnym urlrewrite.xml --> <filter> <filter-name>urlrewritefilter</filter-name> <filter-class>org.tuckey.web.filters.urlrewrite.urlrewritefilter</filter-class> </filter> <!-- Konfiguracja servleta. 9
Najechanie myszką na kolejne bloki powinno wyświelić stosowną pomoc. Ważnym elementem jest blok <param-value> określający miejsce, w którym znajduja się pliki konfiguracyjne dla serwleta. Dane umieszczane w bloku, są inicjalizowane przez VJM i umieszczane w wirtualnej pamięci w obiekcie ServletContext, do którego można w razie potrzeby odwołać się w kodzie Java. --> <display-name>helloworld</display-name> <servlet> <servlet-name>helloworld</servlet-name> <servlet-class> org.springframework.web.servlet.dispatcherservlet </servlet-class> <init-param> <param-name>contextconfiglocation</param-name> <param-value> /WEB-INF/config/*-config.xml </param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <!-- Określenie, jakie żądania będzie odbierał serwlet. Może być to np. <url-pattern>*.hw</url-pattern>. W tym przypadku, jeśli zostałoby wywołane żądanie inne niż z zakończeniem.hw, servlet nie obsłużyłby go. --> <servlet-mapping> <servlet-name>helloworld</servlet-name> <url-pattern>/app/*</url-pattern> </servlet-mapping> <!-- Klasa obsługująca pliki konfiguracyjne --> <listener> <listener-class>org.springframework.web.context.contextloaderlistener</listener-class> </listener> <context-param> <param-name>contextconfiglocation</param-name> <param-value> /WEB-INF/config/*-config.xml </param-value> </context-param> <!-- Mapowanie wszyskich żądań przez CharacterEncodingFilter --> <filter-mapping> <filter-name>characterencodingfilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <!-- Mapowanie wszyskich żądań przez UrlRewriteFilter --> <filter-mapping> <filter-name>urlrewritefilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> </web-app> Korzystanie z urlrewrite nie jest niezbędne, lecz warto znać to narzędzie, gdyż przy rozbudowanej aplikacji może okazać się bardzo pomocne. O bibliotece przeczytasz w oficjalnej dokumentacji [9], a ogólnikowo, narzędzie pozwala na zmianę wywoływanych adresów na inne, zdefiniowane w pliku konfiguracyjnym. Konfiguracja urlrewrite.xml: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//dtd UrlRewrite 3.0//EN" "http://tuckey.org/res/dtds/urlrewrite3.0.dtd"> <urlrewrite default-match-type="wildcard"> <rule> <from>/images/**</from> <to>/images/$1</to> </rule> <rule> <from>/js/**</from> <to>/js/$1</to> </rule> <rule> <from>/css/**</from> <to>/css/$1</to> </rule> <rule> <from>/**</from> <to>/app/$1</to> </rule> 10
<outbound-rule> <from>/app/**</from> <to>/$1</to> </outbound-rule> </urlrewrite> Zgodnie z kodem web.xml, w odpowiednim miejscu należy utworzyć folder config. Będą w nim przechowywane konfiguracje obejmujące różne części aplikacji, a więc konfiguracje dla dołączanych bibliotek. Na początek ustawienia dla Springa. Należy dodać plik app-config.xml, a w jego wnętrzu umieścić: <?xml version="1.0" encoding="utf-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:p="http://www.springframework.org/schema/p" xmlns:context="http://www.springframework.org/schema/context" xmlns:mvc="http://www.springframework.org/schema/mvc" xsi:schemalocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/springmvc-3.0.xsd" > <!-- W podanej ścieżce powinny znajdować się pliki kontrolerów. Kontroler znajdujący się w innej ścieżce (np. pl.com.maslo) nie zostanie przeskanowany podczas wywołania żądania. Kontroler znajdujący się głębiej (np. pl.com.helloworld.maslo.cukierek) zostanie sprawdzony pod kątem pasowania do żądania. --> <context:component-scan base-package="pl.com.helloworld" /> <!-- Włączenie obsługi adnotacji Springa. --> <mvc:annotation-driven /> <!-- Lokalizacja dla pliku startowego po wywołaniu 'gołęgo' żądania serwletu. Po wpisaniu http://localhost:8080/helloworld/ przekierowanie trafi do pliku redirect --> <mvc:view-controller path="/" view-name="redirect" /> <!-- Obsługa tylko pewnego typu plików dla widoków. Wg poniższego zapisu wszystkie widoki brane pod uwagę przez kontrolery muszą się znajdować w katalogu /WEB-INF/jsp/ i muszą mieć rozszerzenie.jsp --> <bean class="org.springframework.web.servlet.view.internalresourceviewresolver"> <property name="prefix" value="/web-inf/jsp/"/> <property name="suffix" value=".jsp"/> </bean> </beans> Idąc dalej, oto kod dla pliku redirect.jsp, który ma się znaleźć w folderze jsp: <%@page contenttype="text/html" pageencoding="utf-8"%> <!-- Bezpośrednie przekierowanie do welcome. Zostanie wygenerowany URL o adresie HelloWorld/welcome --> <% response.sendredirect("welcome"); %> W poszukiwaniu kontrolera obsługującego żądanie welcome, zostaną zbadane klasy w ścieżce pl.com.helloworld zdefiniowanej uprzednio w pliku app-config. 11
4.3. Warstwa kontrolera By serwlet odnalazł pakiet oraz kontroler, należy je utworzyć. W tym celu rozwiń drzewo Java Resources, kliknij PPM na src > New > Package. Wprowadź nazwę pl.com.helloworld i zatwierdź. Analogicznie dodaj do pakietu klasę Java (Class) o nazwie WelcomeController. Jego zawartość wypełnij tak: package pl.com.helloworld; import java.io.ioexception; import org.springframework.stereotype.controller; import org.springframework.web.bind.annotation.requestmapping; import org.springframework.web.bind.annotation.requestmethod; @Controller public class WelcomeController { } @RequestMapping(value = "welcome", method = RequestMethod.GET) public String start() throws IOException { System.out.println("hello z kontrolera! "); return new String("/welcome"); } Adnotacja @Controller definiuje klasę jako kontroler. Wszystkie pliki oznaczone w ten sposób są przeszukiwane w celu znalezienia pasującej maski dla żądania (definiowanej za pomocą @RequestMapping). Każdy kontroler może obsługiwać wiele żądań zdefiniowanych w kolejnych metodach. W adnotacji @RequestMapping pierwszy parametr odpowiada żądaniu, które obsłuży metoda kontrolera. Drugi to typ żądania (którego nie trzeba definiować na tym etapie projektu, lecz w trakcie rozrostu aplikacji, podział na obsłużenie żądania typu GET, POST i innych, będzie wymagany). Klasa zwraca obiekt klasy String, który w kontekście kontrolera Spring uznawany jest za nazwę pliku widoku. Przypomnij sobie linijki <property name="prefix" value="/web-inf/jsp/"/> <property name="suffix" value=".jsp"/> z pliku app-config.xml i zwróć uwagę, dlaczego mimo podania tylko części nazwy widoku i zupełnym braku ścieżki, kontroler zapewne zwróci poprawny widok. Oczywiście zwróci go, jeśli plik welcome.jsp będzie istniał. Utwórz go w odpowiedniej ścieżce i wstaw kod: <%@ page language="java" contenttype="text/html; charset=utf-8" pageencoding="utf-8"%> <h2> Hello World! </h2> 4.4. Uruchomienie Projekt wydaje się być skonfigurowany. Pozostaje go odpalić na kontenerze webowym. Wykonaj wybraną czynność: PPM na projekcie > Run As > Run on Server. Wybierz skonfigurowany uprzednio serwer; kliknij Next. kliknij PPM na serwerze > Add and Remove. 12
Rys.. 4.2. Uruchamianie aplikacji na serwerze Każde z działań doprowadzi Cię do punktu, w którym definiuje się powiązanie aplikacji z kontenerem. Lewa strona zawiera indeks otwartych niepowiązanych projektów, które nie będą publikowane; natomiast prawa listę projektów, które będą instalowane przy starcie/restarcie serwera. Upewnij się, że HelloWorld znajduje się po prawej stronie panelu i kliknij Finish. 13
Twym oczom w automagicznie powstałym oknie (o ile wybrałeś pierwszą czynność z początku podrozdziału. Jeśli nie, musisz sam uruchomić serwer i uruchomić wewnętrzną przeglądarkę webową) powinien ukazać się mniej-więcej taki widok: Rys.. 4.3. Działająca aplikacja Zwróć uwagę na wiadomość z konsoli (zerknij na kod kontrolera). Oczywiście stronę można oglądać także pod zewnętrznymi przeglądarkami wpisując odpowiedni adres. W ustawieniach Eclipse można dokonać wyboru wewnętrznej przeglądarki. Wartym zauważenia jest, że po modyfikacji jakiegokolwiek pliku i zapisaniu go, w panelu Servers widać poruszenie (zmianę statusu), a w Console nowe logi. Otóż nowoutworzona instancja Tomcata posiada domyślne ustawienie ponownego publikowania (ang. redeploy, republish) danych po każdej aktualizacji tychże. Oczywiście można to zostawić w spokoju, jednak przy większym projekcie taka funkcja jest wielce niepożądana. Aby ją wyłączyć należy kliknąć dwukrotnie na serwer Tomcata w panelu Servers, odnaleźć pole 14
Publishing, rozwinąć je, zaznaczyć Never publish automatically, zamknąć zakładkę potwierdzając dokonane zmiany. Od tej chwili deploy będzie odbywał się tylko na żądanie. A oto dotychczasowa struktura projektu: Rys.. 4.4. Struktura projektu 15
5. Koncepcja rozwoju projektów Znasz podstawy, więc teraz zacznie się ciekawsza zabawa. Załóżmy, że na potrzeby kursu stworzymy prostą stronę a la Stack Overflow [12]. Projekt będzie zawierał: kompozycyjny podział widoku strony (Tiles) dostęp do bazy danych (Hibernate Framework) logowanie (Spring Framework) dodawanie postów (asynchronicznie AJAX/JSON) ocenianie postów (asynchronicznie AJAX/JSON) Jeśli chcesz, zmień nazwę projektu oraz pakietów na coś bardziej odpowiedniego. U mnie będzie to mało oryginalne StackOv. Poza zmianą nazwy projektu, można też zmienić nazwę serwletu w pliku web.xml; w przypadku zmiany nazwy pakietu w folderze src, wymagana jest aktualizacja ścieżki dla kontrolerów w pliku app-config.xml. Aby odnaleźć wzorce tekstowe w projekcie, można pomóc sobie narzędziem wyszukiwania i zamiany (Ctrl+H). By nie rozciągać tutoriala, zmienię nieco kwestię przybliżania kodu źródłowego. Od teraz będę się powoływał do plików i interesujących jego części zamiast listować źródła. Cały kod oraz obszerniejszy komentarz będzie natomiast do zobaczenia po zaimportowaniu kolejnych archiwów projektu i przeczesywaniu jego struktury. 16
6. Szablon widoków StackOv-Tiles.war Rozdział ten jest poświęcony frameworkowi Apache Tiles. Umożliwia on kompozycyjny podział layoutu i wygenerowanie widoku. Każdy z elementów strony, jak stopka, menu czy treść główna, muszą znajdować się w oddzielnych plikach. Rys. 6.1. Model kompozycyjny [10] Nieco inne podejście stosuje się w podziale dekoracyjnym, którego używa m.in. Sitemesh, będący jedną z kilku alternatyw dla Tiles. Różnice w obu technologiach dokładniej opisane są na stronie Apache Tiles [10]. 17
6.1. Tiles konfiguracja I warstwa prezentacji Po imporcie StackOv-Tiles.war dodaj do projektu odpowiednie biblioteki (rys. 6.2.) z dostarczonego zbioru lub ze strony producenta [11]. Rys. 6.2. Biblioteki Wejdź w folder jsp. Zauważysz tam plik include.jsp oraz folder tiles-templates, w którym znajduje się kilka plików. include.jsp zawiera w sobie importowane ścieżki do wykorzystywanych bibliotek tagów, styli css czy skryptów js. Sam plik jest z kolei importowany w widokach jsp korzystających z wcześniej wymienionych usług. Oczywiście pozycje z include.jsp można samodzielnie importować w widokach, ale zasada stosowana w projekcie wydaje się nieco lepsza. Konfiguracja Tiles opiera się na dwóch plikach xml: tiles-config.xml, w którym zawarta jest ścieżka do biblioteki dla wywołań oraz adres konfiguracyjny dla definicji widoków; tiles-defs.xml, w którym znajdują się definicje widoków. Same nazwy plików w folderze tiles-templates niosą sobą informacje o ich przeznaczeniu. Najciekawiej z nich prezentuje się plik layout.jsp, w którym zawarte są importy odpowiednich części całego widoku użytkownika. <tiles:insertattribute name="menu" /> <tiles:insertattribute name="content" /> <tiles:insertattribute name="footer" /> Plik ten tworzy strukturę portalu, którą tak jak w normalnym pliku jsp, można wspomagać np. blokami div w celu tworzenia odpowiedniego położenia części strony. W naszym przypadku całość będzie wyglądała jak wielopoziomowy tort, więc zwykły import bez używania bloków powinien załatwić sprawę. Czas na przyporządkowanie importowanych atrybutów. W jaki sposób menu, content i footer mapują odpowiednie strony jsp? Spójrz na tiles-defs.xml: <definition name="base.definition" template="/web-inf/jsp/tiles-templates/layout.jsp"> <put-attribute name="menu" value="/web-inf/jsp/tiles-templates/menu.jsp" /> <put-attribute name="content" value="" /> <put-attribute name="footer" value="/web-inf/jsp/tiles-templates/footer.jsp" /> 18
</definition> Element definicji nazwany base.definition określa główny szablon strony, którym jest layout.jsp. Kolejne atrybuty definiowane po nazwie wskazują na pliki, które mogą być wstrzykiwane w odpowiednich miejscach w layout.jsp. menu oraz footer są określone od razu. content będzie trzeba przesłaniać. <definition name="/*" extends="base.definition"> <put-attribute name="content" value="/web-inf/jsp/{1}.jsp"/> </definition> <definition name="*/*" extends="base.definition"> <put-attribute name="content" value="/web-inf/jsp/{1}/{2}.jsp"/> </definition> <definition name="*/*/*" extends="base.definition"> <put-attribute name="content" value="/web-inf/jsp/{1}/{2}/{3}.jsp"/> </definition> Każde pasujące żądanie zostanie przepuszczone przez którąś z definicji dziedziczących po base.definition. Definicje potomne domyślnie zawierają to samo co element po którym dziedziczą. Przesłaniają jedynie to, co potrzeba, a są wywoływane jedynie, jeśli pasują do żądania określonego w parametrze name. W aplikacji zależnie od zagnieżdżenia linku widoku zwracanego z kontrolera, odpowiednio pasujący plik będzie ustawiany jako wartość dla atrybutu content. Najlepiej będzie sprawdzić to na przykładzie. W zasadzie wszystko już zostało skonfigurowane i po odpaleniu serwera, tak jak w poprzednim przykładzie, powinieneś zobaczyć treść powitalną, a prócz tego także menu i stopkę. Jak możesz sprawdzić, w kontrolerze zwracany jest napis /welcome. Przez skonfigurowanie Tiles, owy tekst przechodzi przez definicje, wpasowuje się w wyrażenie /* i zostaje uznany jako część ścieżki do pliku stanowiącego obszar content całej wyświetlanej strony. menu i footer są już domyślnie określone w definicji nadrzędnej. Poszczególne części są składane w całość w layout.jsp, a następnie właśnie ten dynamicznie skonstruowany plik jest renderowany i zwracany w przeglądarce jako widok. Dotychczas opisywany projekt znajduje się w archiwum StackOv-Tiles.war. Dodatkowo dodany został pakiet oraz widok dla podstrony O stronie, a także styl css. 19
7. Baza danych StackOv-Hibernate.war Hibernate Framework udostępnia funkcje realizujące mapowanie relacyjnych baz danych na obiekty Java i na odwrót. Innymi słowy pozwala na przyjemne wykorzystanie bazy danych w projekcie opartym na aplikacji Java EE. 7.1. Baza danych W projekcie używany będzie serwer MySQL, a dostęp do bazy odbywał się będzie przez aplikację phpmyadmin. Oba komponenty znaleźć można w pakiecie XAMPP [14]. Do uruchomienia phpmyadmin należy włączyć serwer Apache oraz MySQL, a następnie kliknąć przycisk Admin przy drugim. Korzystanie z aplikacji raczej nie powinno stanowić problemu, szczególnie jeśli masz dostęp do Internetu. Jeśli Apache nie startuje, to zapewnie pracuje na zajętym porcie, wykorzystywanym np. przez aktualnie używanego klienta komunikatora. Zlokalizuj aplikację korzystającą z portu i zamknij ją. Po uruchomieniu Apache ponownie włącz aplikację, która być może znajdzie sobie inny port wilk syty i owca cała. Działanie Apache jest wymagane jedynie do phpmyadmin, natomiast do samego projektu Java EE nie jest potrzebne. Na początek utwórz użytkownika sodb (z hasłem) na hoście lokalnym, mającego nadane wszystkie uprawnienia do bazy o tej samej nazwie. 7.2. Hibernate konfiguracja Do zaimportowanego projektu StackOv-Hibernate.war powinieneś dołączyć odpowiednie biblioteki pobrane ze strony producenta [13]. U mnie najnowsza wersja (3.6.3) powoduje problemy. By nie szukać zależności (a nie używam Mavena) zdecydowałem się na skorzystanie ze starszej wersji Hibernate i zależności, z których korzystałem w dawnych projektach. Zbiór bibliotek dla aktualnego projektu widać na rysunku 7.1. 20
Rys. 7.1. Biblioteki Zajrzyj do katalogu konfiguracyjnego aplikacji i zerknij na plik hibernate-config.xml. W tym jednym pliku zostały ustawione obiekty umożliwiające dostęp do bazy. W komentarzach zostało wyjaśnione co i jak. Istotną rzeczą jest, że wszystkie klasy będące odzwierciedleniami encji w bazie danych muszą być umieszone w pakiecie zdefiniowanych w pliku hibernate-config.xml jako packagestoscan pl.stackov.classes. Z kolei jdbc.properties opisuje parametry połączenia z bazą i konfiguracją Hibernate. Znaczenia konkretnych pól są wyjaśnione w dokumentacji. Zanim przejdziemy dalej, uruchom aplikację. Zauważysz nowy link Lista tematów. Kliknij w niego. Powinna wyświetlić się lista pusta tematów. W kolejnych podrozdziałach znajdziesz wytłumaczenie jak to działa. 21
7.3. Warstwa kontrolera Wszystkie obiekty z adnotacją @Controller znajdujące się w pakiecie pl.stackov.modules są przeszukiwane przez Spring przy każdym żądaniu. Jeśli żądanie pasuje do kontrolera, tudzież jego funkcji, to ta funkcja jest wywoływana. W ciele każdej metody można robić wiele, np. pracować na obiektach dostarczonych w żądaniu czy wysyłać dane do zwracanych widoków. Najlepiej prześledzić to na przykładzie: Dodawanie nowych tematów. Jest to możliwe dzięki funkcji add() klasy TopicController, która przenosi użytkownika do formularza w katalogu jsp/edit.jsp. Tam po uzupełnieniu tytułu i zatwierdzeniu, obiekt klasy Temat jest przechwytywany przez żądanie w funkcji add2(), która pociąga do pracy funkcje serwisowe obiektu TopicService, a na końcu przekierowuje do listy tematów. Całość działa wg schematu MVC. Kliknięcie linku w interfejsie użytkownika (View) powoduje wywołanie reakcji w kontrolerze (Controller). W nim mogą nastąpić operacje na bazie danych (Model), po czym zwracany jest kolejny widok użytkownika (View), będący najbardziej zewnętrzną formą odpowiedzi na wcześniej wywołane żądanie. I tak w kółko. Spójrz na obrazki pomocnicze. Rys. 7.2. Poziom zagnieżdżenia warstw architektury trójwarstwowej. Na podstawie [15] Warstwa biznesowa z rysunku 7.2. odpowiada warstwie serwletu, który odbiera wszystkie żądania; kontrolerom, do których trafiają przekierowane z serwlet żądania; oraz klasom pomocniczym, do których odwołują się kontrolery, a które wykonują operacje biznesowe (jednak nie na danych. Dopiero te funkcje wywołują kolejne stanowiące interfejs warstwy danych). Rys.. 7.3. Związek pomiędzy modelem, kontrolerem i widokiem. Na podstawie [16] Jak widać z rysunku 7.3. kontroler jest pośrednikiem pomiędzy warstwą widoku i dostępu do danych. Jak zauważyłaś/zauważyłeś w kontrolerze znajduje się obszerny komentarz, dlatego w tym paragrafie opuszczę tłumaczenie co z czym. 22
7.4. Warstwa dostępu do danych Zwróć uwagę, że w bazie danych została utworzona nowa tabela temat, a przecież nie było wzmianki o jakimkolwiek kodzie SQL. Hibernate i jego adnotacje pozwalają na automatyczne tworzenie tabel w bazie danych po zdefiniowaniu jedynie klas Java (odpowiada za to parametr hibernate.hbm2ddl.auto=update w hibernate-config.xml)! Zerknij na nowy pakiet.classes, a w nim na klasę Temat.java będąca odpowiednikiem automatycznie wygenerowanej encji temat w bazie danych. Opisywanie wykorzystanych adnotacji mija się z celem, gdyż dokumentacja na ten temat jest naprawdę obfita, a sama struktura niezwykle prosta. Wystarczy wiedzieć, że tak zdefiniowana klasa samoistnie zdefiniuje się w bazie, jeśli oczywiście tabela o tej nazwie nie będzie jeszcze istniała. OK, tabela już jest, lecz brak w niej rekordów. Dodawanie rekordu z poziomu warstwy modelu jest dosyć proste i przedstawia się jak na schemacie: Rys.. 7.4. Rozgraniczenie warstwy biznesowej od warstwy dostępu do danych Jesteśmy w widoku formularza dodawania tematu. Po podaniu nazwy tematu kontroler (opisany w poprzednim paragrafie) wywołuje funkcje addtopic(form) z klasy serwisowej BO TopicService (oznaczonej adnotacją @Service). Ta z kolei wywołuje metodę addtopic(temat) z klasy DAO TopicDAO (oznaczonej adnotacją @Repository). Owa klasa korzysta z pomocniczej wstrzykniętej (@Autowired) klasy hibernatetemplate i wywołuje funkcję add(object) dodawania rekordu do bazy danych. Prześledź cały mechanizm na spokojnie i porównaj z metodami realizującymi inne funkcjonalności. Być może zastanawiasz się dlaczego nie wykorzystałem takiego schematu: Rys.. 7.5. Wymieszane w jednej płaszczyźnie funkcjonalności warstwy biznesowej i warstwy dostępu do danych 23
Byłoby o dwie klasy mniej (interfejs i implementacja BO), a tak następują po sobie niepotrzebne wywołania kolejnych metod kolejnych interfejsów. Otóż tak też można by zrobić, jednak w trakcie rozrostu projektu wspólny obszar warstwy czysto biznesowej i dostępu do danych niemal na pewno przysporzyłby wielu problemów. Odseparowanie warstw skutkuje lepszą czytelnością, a także ewentualną refaktoryzacją. Zasada jaką powinieneś/powinnaś się kierować jest taka w klasach oznaczonych jako @Repository mają znajdować się metody bezpośrednio działające na bazie danych; @Service tu dobrze umieścić jest logikę biznesową (notabene możliwą do wykonania w kontrolerze, ale z racji, że kontroler powinien być czysty na ile to możliwe, lepiej przenieść ją w te klasy). Dodatkowo, wymienione wyżej adnotacje istnieją nie ot tak sobie. Spring robi z nich użytek, i tak np. w klasie oznaczonej jako DAO (@Repository), można określić role klasy w kontekście całej aplikacji, przyznając dodatkowe możliwości czy ograniczenia (np. nazewnictwo instancji klas w aplikacji, rodzaj transakcyjności), poprzez definiowanie atrybutów danej adnotacji. Nie będzie to wykorzystywane w tym projekcie, ale warto o tym pamiętać. Wartym zauważenia jest fakt, że dodanie nowej warstwy interfejsu, w pewnym stopniu powoduje zwiększenie zapotrzebowania systemu, a także doprowadza do nieco dłuższego wywołania ostatecznego kodu. Jest to cena za zastosowanie zwiększonej modularności, która jednak nie ma dużego znaczenia przy niniejszym projekcie, dla którego prędkość działania nie jest krytycznie ważnym atrybutem. TopicDAOImpl.java najciekawiej prezentująca się klasa warstwy biznesowej ma bezpośredni dostęp do bazy danych. Po wstrzyknięciu obiektu HibernateTemplate (zerknij na hibernate-config.xml i ostatnie linijki) można łatwo korzystać z funkcji operujących na rekordach bazy. Przyjrzyjmy się jednej z metod: @SuppressWarnings("unchecked") @Override public List<Temat> getlistoftopics() { DetachedCriteria criteria = DetachedCriteria.forClass(Temat.class); List<Temat> list = hibernatetemplate.findbycriteria(criteria); } return list; Pierwsza adnotacja informuje Spring, by nie sygnalizował ostrzeżeń związanych z rzutowaniem obiektów (wyciągane rekordy umieszczane w liście tematów). Kolejna oznacza, że metoda jest przesłaniana i definiowana z implementowanego interfejsu. DetachedCriteria to klasa pomocnicza służąca do tworzenia zapytań. Nie używany jest jednak SQL, a po prostu metody pozwalające na określenie o co nam chodzi. Stworzone zapytanie może zostać użyte jako parametr do funkcji findbycriteria(detachedcriteria) wyciągającej dane z bazy. Możliwe jest również używanie czystego SQL i użycie funkcjo find(string). Funkcja zwraca listę obiektów Temat, która po drabinie zagnieżdżenia wędruje do warstwy serwisowej, gdzie funkcja getlistoftopics() została wywołana (a dalej do kontrolera, gdzie z kolei została wywołana funkcja serwisowa getlistoftopics() i ostatecznie do zwracanego przez kontroler widoku). 24
7.5. Warstwa prezentacji <h2>lista tematów</h2> <a href="add">dodaj temat</a> <table> <c:foreach items="${topics}" var="item"> <tr> <td><c:out value="${item.id}" /></td> <td><c:out value="${item.tytul}" /></td> <td><a href="edit?id=<c:out value="${item.id}"/>">edytuj</a></td> <td><a href="delete?id=<c:out value="${item.id}"/>">usuń</a></td> </tr> </c:foreach> </table> Powyższy kod nie wymaga wielu wyjaśnień. Ot korzystając ze znaczników HTML i JSTL następuje iteracja po otrzymanej z kontrolera liście i wyświetlenie wyników. 7.6. Podsumowanie W pliku JSP zauważ dodatkowo wygenerowane linki do edycji i usuwania pozycji. Żądania po ich kliknięciu trafiają do tego samego kontrolera i dalej do odpowiednich metod. Ich działania nie będę opisywał. Spróbuj samodzielnie do tego dojść bazując na opisanych wyżej informacjach. Rozdział jest dosyć trudny, gdyż w stosunku do rozdziału HelloWorld, doszła kolejna warstwa dostępu do danych; a sama warstwa kontrolera także się skomplikowała. Przy testowaniu aplikacji zwracaj uwagę na logi konsoli. Znajdziesz tam informacje tym co się w danej chwili dzieje co zostało wywołane, co robi Hibernate, itp. W razie problemów właśnie tam można znaleźć pomocne dane. 25
8. Autoryzacja StackOv-SpringSecurity.war Zabezpieczmy aplikację tak, by: dostęp do listy tematów miał każdy (zarówno zalogowany jak i niezalogowany użytkownik) każdy widział linki dodawania/edycji/usuwania tematów tylko zalogowany zwykły użytkownik lub administrator mógł dodawać i edytować tematy wyłącznie administrator mógł usuwać pozycje każdy zalogowany użytkownik miał swój dodatkowy panel administrator miał dodatkowo swój super tajny panel 8.1. SpringSecurity konfiguracja Na początek odpowiednie biblioteki ze strony Spring Security [17] wrzuć do katalogu lib (rys. 8.1.). Rys. 8.1. Biblioteki 26