Krzysztof Rychlicki-Kicior Java EE 6 Programowanie aplikacji WWW Szybko i bez k opotów poznaj Java Enterprise Edition Naucz si praktycznie tworzy ciekawe aplikacje WWW Do cz do elity programistów nowoczesnych rozwi za webowych Ju dzi si gn po jedyne kompendium wiedzy na temat Java EE!
Java EE 6. Programowanie aplikacji WWW Autor: Krzysztof Rychlicki-Kicior ISBN: 978-83-246-2659-5 Format: 158 235, stron: 232 Szybko i bez k³opotów poznaj Java Enterprise Edition Naucz siê praktycznie tworzyæ ciekawe aplikacje WWW Do³¹cz do elity programistów nowoczesnych rozwi¹zañ webowych Ju dziœ siêgnij po jedyne kompendium wiedzy na temat Java EE! Java Enterprise Edition to standard tworzenia aplikacji biznesowych wykorzystuj¹cych jêzyk Java. Opracowany przez firmê Sun Microsystems, dzia³a w oparciu o wielowarstwow¹ architekturê komponentow¹, oferuj¹c programistom bardzo rozbudowane mo liwoœci tworzenia oprogramowania funkcjonuj¹cego na niemal dowolnym sprzêcie, w ka dym systemie operacyjnym, z wykorzystaniem licznych serwerów aplikacji. Du a popularnoœæ rozwi¹zañ Java EE i coraz powszechniejszy dostêp do technologii WWW sprawiaj¹, e programiœci sprawnie pos³uguj¹cy siê tego rodzaju narzêdziami rzadko figuruj¹ na listach osób poszukuj¹cych pracy, a jeœli ju jakimœ cudem siê na nich znajd¹, bardzo szybko otrzymuj¹ atrakcyjne propozycje zatrudnienia. Nauka swobodnego poruszania siê w tym œrodowisku mo e te byæ wspania³¹, poszerzaj¹c¹ horyzonty przygod¹, a gdy poznasz platformê Java EE, bêdziesz dysponowa³ potê nym narzêdziem, u³atwiaj¹cym tworzenie nawet najbardziej skomplikowanych aplikacji internetowych w bardzo efektywny i szybki sposób. Studenci, programiœci i hobbyœci pragn¹cy poznaæ œrodowisko Java Enterprise Edition czêsto napotykaj¹ problem ze znalezieniem solidnych Ÿróde³ wiedzy, które pozwoli³yby im szybko i ³atwo wejœæ w œwiat tej coraz bardziej popularnej technologii. Lukê tê z powodzeniem wype³nia ksi¹ ka Java EE 6. Programowanie aplikacji WWW. Dziêki niej wszyscy zainteresowani tematem zyskaj¹ mo liwoœæ poznania Java EE od podstaw i zdobycia praktycznej wiedzy, na podstawie której bêd¹ mogli rozwijaæ swoje umiejêtnoœci programistyczne w przysz³oœci. Ten podrêcznik pozwala na szybkie rozpoczêcie przygody z tworzeniem aplikacji webowych, skutecznie wprowadzaj¹c w zagadnienia wykorzystywanych przy tym platform i mechanizmów, lecz nie pomijaj¹c te informacji o charakterze ogólnym. Jeœli niewiele mówi¹ Ci skróty JSP, JPA, JSF czy JPQL, a chcia³byœ zmieniæ ten stan rzeczy, bez w¹tpienia powinieneœ siêgn¹æ po tê ksi¹ kê, podobnie jak wszystkie osoby zainteresowane bezproblemowym u ywaniem ca³ego spektrum nowoczesnych narzêdzi oferowanych przez œrodowisko Java EE. Tworzenie serwletów Zastosowanie szablonów JSP Integracja danych z aplikacjami za pomoc¹ mechanizmu JPA U ywanie interfejsów i komponentów Korzystanie z technologii JSF Uniwersalny i wygodny dostêp do danych, czyli jêzyk JPQL Praktyczne przyk³ady realizacji Spraw, aby tworzenie aplikacji WWW z wykorzystaniem Java EE nie mia³o przed Tob¹ tajemnic
Spis tre ci Cz I Podstawy... 7 Rozdzia 1. Java EE naprawd krótkie wprowadzenie... 9 Web vs Enterprise... 10 Serwery aplikacji... 11 Streszczenie, czyli krótki przewodnik po niniejszej publikacji... 11 Serwlety na dobry pocz tek... 11 Deskryptor wdro enia... 12 JSP HTML + Java... 13 JPA czas na dane!... 13 JSF wy szy poziom prezentacji... 13 Facelets... 14 Rozdzia 2. Pierwsza aplikacja webowa... 15 Integrowanie Tomcata z Netbeansem... 16 Pierwsza aplikacja... 17 Dodawanie nowych elementów... 18 Pierwszy serwlet?... 20 Rozdzia 3. Serwlet na dobry pocz tek... 25 ycie serwletu... 25 Serwlet pod lup... 26 danie odpowied... 27 Przesy anie odpowiedzi... 29 Om nom nom, czyli ciasteczka w pe nej krasie... 31 Sesje nie tylko dla studentów... 31 Konfiguracja w kodzie Javy mo na tego unikn... 33 Parametry serwletów... 34 Kontekst serwletów... 35 Trzech muszkieterów?... 36 Atrybuty a mnogo da... 36 S uchowisko... 39 ServletContextListener... 39 ServletContextAttributeListener... 39 ServletRequestAttributeListener i ServletRequestListener... 39 HttpSessionAtributteListener i HttpSessionListener... 40
4 Java EE 6. Programowanie aplikacji WWW HttpSessionBindingListener... 40 Sesja + wiele JVM = HttpSessionActivationListener... 40 Filtry... 41 Techniczny aspekt filtrów... 41 Konfiguracja filtrów w pliku web.xml... 42 Rozdzia 4. JSP gdy out.println() nie wystarcza... 45 Zacznijmy od pocz tku, czyli JSP w wiecie serwletów... 46 Pliki JSP dost pne bezpo rednio... 46 Pliki JSP wywo ywane z poziomu serwletów... 46 Pochodzenie JSP dziedzictwo serwletów... 47 Pierwsze kroki w JSP... 47 Doceni wygod, czyli jak to lat temu kilka bywa o... 50 Expression Language elegancja i wygoda... 54 Remedium warto by o czeka!... 55 Dost p do obiektów w j zyku EL... 56 Beany, czyli ziarna kult kawy wiecznie ywy... 57 Ziarna + EL = kolejne u atwienie... 58 Ziarna, mapy i co dalej?... 59 EL nie tylko atrybuty... 59 Akcje JSP... 61 Include vs Forward ods ona druga... 62 Akcje + ziarna = kolejne pot ne narz dzie... 63 Dynamiczne generowanie elementów... 66 Rozdzia 5. JSTL wisienka na torcie JSP... 69 Skrzynka z narz dziami... 69 Rdze... 70 c:out... 70 Ale to ju by o, czyli c:set... 72 Czwarty muszkieter... 73 Kontrola sterowania... 73 P telka do kompletu... 75 Wyj tki + JSP =... 76 Adresy URL same k opoty... 77 Adresy URL bez tajemnic... 77 Tajemnica sesji... 78 Trzech tenorów... 79 Na deser funkcje!... 80 Przez kolekcje do serca... 80 Funkcje a cuchowe... 81 Podsumowanie... 82 Cz II Frameworki webowe... 83 Rozdzia 6. JavaServer Faces... 85 Frameworki kolejny dowód na lenistwo cz owieka... 85 JSF kanonu ci g dalszy... 86 JSF, czyli MVC w praktyce... 87 Kontroler uniwersalny spawacz... 88 Ma e zanurzenie... 88 Pierwsze przyk ady... 89 Aplikacja Notowania gie dowe... 90 Tajemniczy zapis # vs $... 95 Notowania historyczne, czyli kolekcja w kolekcji... 97
Spis tre ci 5 Najpierw szablon, pó niej tre... 98 Klient szablonu... 99 Przygotowania... 100 Czas na obliczenia!... 103 Ma y zastrzyk... 105 JSF komponenty, komponenty, komponenty!... 106 Output (prawie) wszystko, czego do szcz cia potrzeba... 107 UIInput teraz do szcz cia nie brakuje ju nic... 108 Powrót do szarej rzeczywisto ci... 112 Zasady dzia ania JSF... 115 Przyk adowa aplikacja maszyna licz ca... 115 Przywrócenie widoku (1)... 118 Pobranie danych z dania (2)... 119 Walidacja (3)... 119 Aktualizacja warto ci w modelu (ziarnach 4)... 120 Wywo anie zadeklarowanych uprzednio metod (5)... 120 Renderowanie odpowiedzi (6)... 120 Cykl ycia w praktyce... 120 Podsumowanie... 121 Rozdzia 7. Konwertowanie i walidacja... 123 Uroki transformacji... 123 Konwertery standardowe... 124 Piszemy konwerter!... 126 Walidator nieod czny partner konwertera... 130 Walidatory prawie jak konwertery... 131 Walidacja niestandardowa jak zawsze wi cej pracy... 132 Cz III Obs uga danych... 135 Rozdzia 8. JPA, czyli ORM + Java... 137 Dost p do danych w Javie... 137 O wiecenie... 138 Pierwszy przyk ad... 139 Za o enia... 139 Realizacja... 139 Tworzenie projektu... 140 Hibernate a JPA co i jak w ORM-owym wiecie... 141 Pierwsza klasa encji... 141 Jednostka utrwalania... 145 Graficzna strona aplikacji... 146 Dodawanie przychodni... 150 EntityManager i spó ka... 152 Mened er encji elegancki dost p!= atwa sprawa... 153 Nudni s uchacze nareszcie przydatni!... 156 C ju jest, czas na RUD... 158 Niewiele Ci mog da (póki nie pozwolisz mi zaprezentowa danych)... 158 S uchacz akcji vs akcja starcie numer 2... 160 Istotny drobiazg nasza aplikacja to niemowa!... 162 Rozdzia 9. Zwi zki mi dzy encjami jedna tabela to za ma o!... 165 Przychodnia i co dalej?... 165 Zwi zki mi dzy tabelami krótkie przypomnienie... 165 Zwi zki SQL w praktyce... 166 Jeden do wielu, wiele do jednego... 167
6 Java EE 6. Programowanie aplikacji WWW Wiele do wielu najwy szy stopie wtajemniczenia... 167 Dodajemy tabele do bazy... 168 Encje klas Javy czas na zwi zki!... 170 Encja Przychodnia zmiana na lepszy model... 171 Czas na nowo ci!... 172 Wizyta encja JPA w pe nej krasie... 178 CRUD dla lekarza to ju by o, ale nie do ko ca... 183 Nowy lekarz nowe pole, du a zmiana... 184 Magikonwersja... 185 Ziarnko do ziarnka i zbierze si aplikacja... 186 Kolejne metody ziarna LekarzBean... 188 Na zako czenie edycja... 189 Pacjenci suplement... 191 Danie g ówne: all in one, czyli wizyty!... 192 Od czego trzeba zacz, czyli zmiany... 193 Dodawanie wizyty... 196 Ostatnie ziarno... 197 Edycja i usuwanie powrót... 200 Koniec coraz bli ej, czyli edycja w pe nej krasie... 201 Podsumowanie... 202 Rozdzia 10. JPQL i jego mo liwo ci... 203 Prawie jak SQL prawie robi ró nic... 203 Podstawy... 204 Pobieranie z wariantami... 204 JPQL a atrybuty z o one i null... 206 Nieco wi cej o SELECT... 207 Funkcje obliczeniowe... 208 Operacje niezwi zane z pobieraniem... 209 Mechanizmy zaawansowane... 209 JOIN na lewo, JOIN na prawo... 210 Grupowanie i sortowanie... 211 Podzapytania prawdziwa moc... 212 Podsumowanie... 213 Dodatki... 215 Dodatek A Instalacja serwera Apache Tomcat... 217 Pobranie... 217 Konfiguracja... 217 Dodatek B Bibliografia... 219 Skorowidz... 221
Rozdzia 3. Serwlet na dobry pocz tek Aplikacja z poprzedniego rozdzia u wprowadzi a kilka istotnych elementów, których omawianiem zajmiemy si w przeci gu najbli szych trzech rozdzia ów. Rozpoczniemy od podstawy podstaw, czyli elementu, który jest wykorzystywany po rednio lub bezpo rednio we wszystkich aplikacjach webowych mowa o serwlecie. Serwlet, czyli klasa rozszerzaj ca mo liwo ci serwera aplikacji, mo e by traktowany jako poj cie nies ychanie ogólne. Praktycznie jedynym istotnym wymaganiem stawianym serwletom jest dzia anie w trybie danie odpowied serwlet powinien generowa tre odpowiedzi w oparciu o to, co otrzyma w daniu. W poprzednim rozdziale spotka e si z jednym z typowych zastosowa serwletów generowaniem kodu HTML. Nie jest to jednak w adnym razie kres ich mo liwo ci nic nie stoi na przeszkodzie, aby za pomoc serwletów generowa zarówno dane tekstowe (np. w formacie XML), jak i dane binarne (np. pliki wykonywalne, obrazy, etc.). Zanim jednak zabierzemy si za praktyczne przyk ady (pierwszy z nich mog e przeanalizowa w poprzednim rozdziale), konieczne jest krótkie wprowadzenie teoretyczne, w którym dowiesz si, jak serwlet wspó pracuje z serwerem aplikacji, a tak e jakie podstawowe opcje zwi zane z serwletami mo na ustawi w pliku web.xml. ycie serwletu Gdy uruchamiasz zwyk aplikacj, graficzn lub konsolow, w swoim systemie operacyjnym, mo esz w wi kszo ci przypadków okre li precyzyjnie, kiedy rozpoczyna si, a kiedy ko czy jej dzia anie. W przypadku popularnych technologii dynamicznych stron internetowych (np. PHP) pliki s interpretowane na bie co (aczkolwiek istnieje mo liwo ich po redniej kompilacji). Jak mo na opisa cykl ycia serwletu? Zacznijmy od klasy w takiej postaci, jak ju znamy nieskompilowanego kodu ród owego. Zanim serwer zostanie uruchomiony, wszystkie pliki klas musz zosta poddane kompilacji. Powsta e pliki (o rozszerzeniu.class) s kopiowane do odpowiednich
26 Cz I Podstawy katalogów. Dopiero wtedy serwer mo e by uruchomiony, na nowo lub ponownie. Na szcz cie w nowszych wersjach serwerów aplikacji (np. Apache Tomcat 6) istnieje mo liwo automatycznego wykrywania i aktualizacji klas w trakcie dzia ania serwera. Gdy uruchamiasz serwer aplikacji, z punktu widzenia naszego serwletu nie dzieje si nic istotnego. Nast puje wtedy, rzecz jasna, inicjalizacja samego serwera, a tak e niektórych ustawie ca ej aplikacji webowej. Sam serwlet pozostaje jednak nienaruszony. Ca a zabawa zaczyna si, gdy dowolny u ytkownik Twojej aplikacji po raz pierwszy spróbuje z niego skorzysta. Serwer wykonuje wtedy nast puj ce czynno ci: za adowanie klasy serwletu, utworzenie instancji serwletu, wywo anie metody init(), wywo anie metody service(). Gdy serwlet znajdzie si w trakcie wywo ania metody service(), mo e on rozpocz normaln obs ug da. Od tego momentu w przypadku otrzymania przeze dowolnego dania HTTP, nast pi próba wywo ania odpowiedniej metody serwletu, wed ug schematu nazwa/donazwa(), np. GET/doGet(), POST/doPost(), itd. Sporo pracy, nieprawda? Na szcz cie do obowi zków programisty nale y obs uga wybranych metod ze s owem do w nazwie. Je li wi c chcesz, aby serwlet obs ugiwa tylko danie GET, zadeklaruj jedynie metod doget(). W przypadku klasy serwletu utworzonej przez Netbeans, proces tworzenia serwletu zosta uproszczony jeszcze bardziej. Twórcy szablonu za o yli (sk din d s usznie), e znamienita wi kszo programistów korzysta jedynie z metod HTTP GET i POST. Z tego wzgl du w klasie serwletu s przes aniane dwie metody doget() i dopost(), które odwo uj si do jednej i tej samej metody o nazwie processrequest(). Z jednej strony u atwia to ycie w wi kszo ci sytuacji, z drugiej jednak mog si zdarzy sytuacje, w których inaczej chcemy zareagowa w przypadku dania GET, a inaczej w przypadku POST. W takiej sytuacji nale y usun wygenerowany mechanizm i napisa w asne metody obs ugi doget() i/lub dopost(). Serwlet pod lup Przed chwil pozna e przep yw sterowania w serwlecie; najwy sza pora, aby zapozna si pokrótce z kluczowymi klasami powi zanymi z obs ug serwletów. Omówi jedynie najwa niejsze elementy; warto je zapami ta, poniewa b d si one pojawia tak e w dalszych przyk adach, ilustruj cych kolejne omawiane technologie. Jak ju wspomnia em, serwlety, którymi zajmujemy si w niniejszej ksi ce, dziedzicz po klasie HttpServlet. Ze wzgl du na fakt, e serwlet z za o enia jest konstrukcj niezwykle uniwersaln, w hierarchii dziedziczenia pojawiaj si dodatkowe elementy, które ow uniwersalno wprowadzaj. Oto krótki opis elementów hierarchii dziedziczenia, pocz wszy od tych najbardziej ogólnych:
Rozdzia 3. Serwlet na dobry pocz tek 27 Interfejs Servlet okre la najwa niejsze metody, które musz implementowa wszystkie serwlety. Metody te s niezale ne od stosowanych protoko ów przesy ania danych, a dotycz one g ównie zarz dzania cyklem ycia serwletu (init(), service(), destroy()). Abstrakcyjna klasa GenericServlet podstawowa implementacja interfejsów Servlet i ServletConfig, daj ca dost p do parametrów i ustawie serwletu. Klasa ta zawiera proste implementacje metod obu interfejsów, dzi ki czemu stanowi podstaw dla klasy HttpServlet i wszystkich innych klas serwletów. Klasa HttpServlet to w a nie po tej klasie b dziesz dziedziczy, tworz c w asne serwlety. Poza w asnymi implementacjami metod ze wspomnianych wcze niej interfejsów, klasa HttpServlet udost pnia metody do*, czyli doget(), dopost() etc. Dzi ki temu we w asnych serwletach musisz zdefiniowa jedynie te metody, które Twój serwlet zamierza obs ugiwa. Protokó HTTP zawiera definicje o miu metod: GET, POST, PUT, HEAD, OPTIONS, TRACE, DELETE, CONNECT. Serwlety mog obs ugiwa wszystkie metody, na wy ej omówionej zasadzie. W praktyce zdecydowanie najcz ciej stosuje si metody GET i POST i to na nich skupimy si w dalszej cz ci tego rozdzia u. danie odpowied Mimo niew tpliwie istotnej roli klasy HttpServlet, w trakcie pracy z serwletami cz - ciej przyjdzie Ci zapewne korzysta z interfejsów HttpServletRequest/HttpServlet Response. Reprezentuj one odpowiednio obiekty dania i odpowiedzi, przekazywane do metod doget(), dopost() etc. Pe ny nag ówek metody doget() wygl da nast puj co: protected void doget(httpservletrequest req, HttpServletResponse resp) throws ServletException, java.io.ioexception Twoim zadaniem jest takie zdefiniowanie metod do*, aby generowa y one odpowied, zazwyczaj zale n od przes anych parametrów. Wszystkie niezb dne metody znajdziesz w dwóch wy ej wspomnianych klasach. Zacznijmy od interfejsu HttpServletRequest to na jego podstawie b dziemy w kolejnych przyk adach generowa odpowiedzi przesy ane za pomoc interfejsu HttpServletResponse. Niemal wszystkie metody HttpServletRequest s faktycznie przydatne, niemniej w tym miejscu omówimy metody najistotniejsze z punktu widzenia samych serwletów: Object getparameter(string nazwa) pobiera parametr o danej nazwie przes any w daniu. Enumeration<String> getparameternames() pobiera nazwy wszystkich parametrów znajduj cych si w danym daniu. String getremoteuser() zwraca login uwierzytelnionego u ytkownika lub null, w przypadku braku uwierzytelnienia.
28 Cz I Podstawy Cookie[] getcookies() zwraca tablic ciasteczek specjalnych plików przechowywanych na komputerze u ytkownika. String getquerystring() zwraca a cuch parametrów, przes anych w adresie URL (za znakiem zapytania). String getheader(string nazwa) zwraca warto nag ówka HTTP o podanej nazwie. int getintheader(string nazwa) zwraca warto nag ówka HTTP o podanej nazwie jako liczb ca kowit. long getdateheader(string nazwa) zwraca warto nag ówka HTTP o podanej nazwie jako liczb milisekund, pocz wszy od pocz tku epoki (1 stycznia 1970 roku). Warto ta mo e by przekazana w konstruktorze klasy Date. String getcontextpath() zwraca cie k kontekstu aplikacji. String getservletpath() zwraca cie k dost pu do serwletu. String getpathinfo() zwraca dodatkowe informacje zawarte w cie ce. Trzy ostatnie metody s ze sob zwi zane, poniewa zwracaj one kolejne elementy adresu URL, wykorzystanego do wykonania dania. Przeanalizujmy poni szy przyk ad, prezentuj cy wiadomo o okre lonym identyfikatorze: http://localhost:8080/mojaaplikacja/serwlety/info/235/ Pomijamy oczywi cie nazw protoko u (http) i nazw serwera z portem (localhost:8080). Zostaje nam wi c ci g: /MojaAplikacja/serwlety/info/235/ Metoda getcontextpath() zwraca fragment adresu okre laj cy nasz aplikacj : /MojaAplikacja cie ka do kontekstu zawsze zaczyna si od uko nika (ale nigdy na nim si nie ko czy!), chyba e aplikacja zostanie umieszczona w katalogu g ównym serwera wtedy zwracana warto to a cuch pusty. Fragment ten jest wspólny dla wszystkich plików wchodz cych w sk ad tej aplikacji. Kolejny fragment adresu okre la cie k do serwletu. W naszym przypadku jest to fragment: /serwlety/info Powy szy a cuch znaków musi pasowa do odpowiednich wzorców, zdefiniowanych w deskryptorze wdro enia (pami tasz znacznik <url-pattern> z poprzedniego rozdzia u?). Zasady okre lania odpowiednich cie ek do serwletów omówimy w nast pnym rozdziale; na razie wystarczy Ci informacja, e ten fragment adresu umo liwia jednoznaczne zidentyfikowanie serwletu. Ostatni fragment cie ki (/235/) zostanie zwrócony przez metod getpathinfo(). Dok adnie rzecz bior c, metoda getpathinfo() zwraca fragment adresu URL od cie ki serwletu do pocz tku a cucha parametrów (czyli do znaku zapytania). Oznacza to, e nawet do czenie parametrów, tak jak w poni szym przyk adzie, nie zmieni warto- ci cie ki. http://localhost:8080/mojaaplikacja/serwlety/info/235?param=1
Rozdzia 3. Serwlet na dobry pocz tek 29 Przesy anie odpowiedzi Po przeanalizowaniu wszystkich mo liwych atrybutów dania musisz odes a klientowi odpowied. Do tego celu s u y obiekt interfejsu HttpServletResponse. W jego przypadku otrzymujemy nieco mniejszy zestaw metod, jednak nie oznacza to wcale mniejszych mo liwo ci. Przede wszystkim musimy okre li, jakie operacje chcemy wykonywa w zwi zku z przesy aniem odpowiedzi do klienta: przes anie odpowiedzi w postaci danych tekstowych lub binarnych, utworzenie i przes anie ciasteczek, dodanie do odpowiedzi dowolnych nag ówków, przekierowanie dania lub przes anie kodu b du. Transmisja danych Chocia technologie internetowe maj swoj specyfik, nie zapominajmy, e yjemy w wiecie Javy. Z tego wzgl du operacje zarówno odczytu, jak i zapisu wi si z wykorzystaniem strumieni i/lub obiektów klas Reader/Writer. Nie inaczej jest w tym przypadku: zanim prze lemy jakiekolwiek dane, musimy uzyska odpowiednie obiekty zapisuj ce: ServletOutputStream getoutputstream() zwraca strumie zapisu dla danych binarnych PrintWriter getwriter() zwraca obiekt zapisuj cy dla danych tekstowych. W przypadku danych binarnych mo emy skorzysta z obiektu klasy ServletOutput Stream. Jest to zwyk y strumie zapisu, rozszerzony o mo liwo zapisywania dowolnych danych typów prymitywnych, a tak e a cuchów znaków (za pomoc metod print() i println()). Z tej klasy nale y korzysta w przypadku przesy ania plików je li serwer musi w dynamiczny sposób wygenerowa tre takiego pliku. Znacznie cz ciej przyjdzie Ci jednak korzysta z danych tekstowych. W tym przypadku zazwyczaj b dziesz korzysta z obiektu klasy PrintWriter i jego metody println(). Nag ówki i ciasteczka O ile w przypadku dania mamy do czynienia z odczytem nag ówków i ciasteczek przes anych przez klienta, o tyle w przypadku odpowiedzi wyst puje proces odwrotny. Aby doda ciasteczko, wystarczy skorzysta z metody addcookie(): void addcookie(cookie c) Wi cej na temat ciasteczek w osobnym podrozdziale. W przypadku nag ówków sytuacja jest nieco bardziej skomplikowana do dyspozycji mamy dwie metody (wraz z odpowiednikami dla liczb i dat): void addheader(string nazwa, String warto ) void setheader(string nazwa, String warto )
30 Cz I Podstawy Na czym polega ró nica? Otó metoda addheader() doda podan warto do ju istniej cej zawarto ci nag ówka, natomiast metoda setheader() zast pi warto, je li takowa ju istnieje. Tak samo dzia aj bli niacze metody addintheader(), adddateheader(), setintheader() i setdateheader(). Kody odpowiedzi, b dy i przekierowania Do obowi zków odpowiedzi HTTP nale y tak e przekazywanie kodów odpowiedzi, je li chcemy zaznaczy, e odpowied nie zostanie zako czona w zwyk y sposób. Aby przekaza kod odpowiedzi, korzystamy z metody setstatus(): void setstatus(int kod) W ten sposób przekazujemy kody, które nie okre laj sytuacji problematycznych. W przypadku b dów (np. 404 brak zasobu) zaleca si zdecydowanie wykorzystywanie metody senderror(): void senderror(int kod) void senderror(int kod, String komunikat) Jak wida, istnieje mo liwo przes ania dodatkowej informacji na temat samego b du. Ostatni funkcjonalno zwi zan z kodami odpowiedzi stanowi przekierowanie. Chocia z technicznego punktu widzenia przekierowanie jest te rodzajem kodu odpowiedzi, do przekierowania wykorzystuje si oddzieln metod : void sendredirect(string adres) Korzystaj c z metod senderror() i sendredirect(), nale y pami ta o subtelnych kwestiach zwi zanych z fizycznym przesy aniem danych do klienta. Przesy anie komunikatów o b dach lub przekierowa wi e si z do brutaln ingerencj w proces przesy ania odpowiedzi. Proces ten jest natychmiast przerywany, a klient otrzymuje odpowied z wybranym kodem odpowiedzi. Co jednak stanie si, gdy zd ymy wys a do klienta jakie dane? Odpowied jest prosta nast pi b d. Po wys aniu danych nie mo esz ingerowa w tre nag ówków, przez co nie mo esz ustawi kodu odpowiedzi, a co za tym idzie tak e przekierowania. Czy oznacza to, e musisz uwa a, gdzie wywo ujesz metod println() obiektu PrintWriter? Na szcz cie nie do ko ca. Domy lnym zachowaniem obiektu w przypadku odpowiedzi jest zapisywanie danych do bufora. Oznacza to, e dane zostan wys ane po zako czeniu metody lub w przypadku wywo ania metody flush() tego obiektu. Co za tym idzie, poni sza konstrukcja (wewn trz metody doget()) nie spowoduje wygenerowania b du: PrintWriter out = response.getwriter(); out.println("test"); response.sendredirect("url/do/innego/serwletu"); Je li przed wywo aniem metody sendredirect() wywo asz metod out.flush(), wtedy b d nast pi. Zazwyczaj jednak takie wywo anie jest pomijane, dzi ki czemu problem wyst puje stosunkowo rzadko.
Rozdzia 3. Serwlet na dobry pocz tek 31 Om nom nom, czyli ciasteczka w pe nej krasie Twórcy aplikacji webowych, podobnie jak Ciasteczkowy Potwór, maj szczególny sentyment do ciasteczek (ang. cookies). S to niewielkie pliki przechowywane na komputerach u ytkowników aplikacji webowych, dzi ki czemu jeste my w stanie zapami tywa ich preferencje, loginy i has a itd. Metody operuj ce na ciasteczkach poznali my w poprzednim podrozdziale, ale teraz zaprezentujemy ich dzia anie w praktycznym przyk adzie (listing 3.1): Listing 3.1. Przyk ad obs ugi ciasteczek protected void processrequest(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { response.setcontenttype("text/html;charset=utf-8"); PrintWriter out = response.getwriter(); try { Cookie lastvisit = null; for (Cookie c : request.getcookies()) if (c.getname().equals("obecnosc")) { lastvisit = c; break; if (lastvisit!= null) out.println("twoja ostatnia wizyta na stronie mia a miejsce w dniu " + lastvisit.getvalue()); else out.println("do tej pory nie odwiedzi e /a naszej strony. Wstyd si!"); lastvisit = new Cookie("obecnosc", new Date().toString()); response.addcookie(lastvisit); finally { out.close(); Zadaniem powy szego serwletu jest przechowywanie informacji o dacie ostatniej wizyty na stronie i wy wietlanie jej. W przypadku braku ciasteczka z dat (co jest równoznaczne z pierwszymi odwiedzinami na tej stronie, przynajmniej od czasu wyczyszczenia ciasteczek w przegl darce) wy wietlamy inn informacj. Warto zwróci uwag na dwie kwestie. Po pierwsze, je li chcemy odczyta ju istniej ce ciasteczka korzystamy z metody getcookies() znajduj cej si w obiekcie request. Je li chcemy doda ciasteczko korzystamy z obiektu response. Nigdy odwrotnie! Sprawa druga, znacznie bardziej przykra powy szy sposób dost pu do ciasteczek u ytkownika (p tla for..in) stanowi jedyn metod znajdywania ciasteczek o okre lonej nazwie. W przypadku tworzenia prawdziwych aplikacji trzeba zdefiniowa osobn metod do wyszukiwania ciasteczek. Sesje nie tylko dla studentów Obs uga sesji jest kolejnym nieod cznym elementem niemal wszystkich aplikacji webowych. W przypadku JEE interakcje z sesj mo emy prowadzi na ró ne sposoby,
32 Cz I Podstawy tak e za pomoc poznanych ju klas. W tym rozdziale poznamy sposób na dost p do sesji za pomoc obiektu klasy HttpServletRequest. Kluczow rol odgrywa metoda getsession(), wyst puj ca w dwóch wariantach: HttpSession getsession() HttpSession getsession(boolean czytworzyc) Na wst pie zaznacz, e pierwszy wariant tej metody jest równowa ny drugiemu wywo anemu z parametrem true. Drugi wariant post puje ró nie w zale no ci od przekazanej warto ci logicznej: Je li parametr ma warto true, metoda zwraca obiekt sesji lub tworzy nowy, je li ten nie istnieje. Je li parametr ma warto false, metoda zwraca obiekt sesji lub null, je li ten nie istnieje. Jak wida, warto true nale y przekaza, je li chcesz po prostu uzyska dost p do sesji. Warto false stosuje si, gdy chcesz sprawdzi, czy sesja istnieje. Mo na skorzysta z tego mechanizmu, aby sprawdzi, czy dane danie jest pierwszym daniem u ytkownika w danej sesji. Mechanizm ten jest realizowany w poni szym przyk adzie z listingu 3.2: Listing 3.2. Przyk ad wykorzystania sesji protected void processrequest(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { response.setcontenttype("text/html;charset=utf-8"); PrintWriter out = response.getwriter(); try { if (request.getsession(false)==null) { out.println("witaj na stronie po raz pierwszy!"); request.getsession(); else out.println("witaj na stronie po raz kolejny!"); finally { out.close(); Je li po utworzeniu sesji chcesz sprawdzi, czy sesja zosta a dopiero co utworzona, skorzystaj z metody isnew(): boolean isnew() zwraca true, je li obiekt sesji zosta utworzony podczas tego dania. Korzystanie z obiektu sesji Podstawowa funkcjonalno obiektu sesji sprowadza si do dwóch metod: Object getattribute(string nazwa) zwraca atrybut sesji o podanej nazwie.
Rozdzia 3. Serwlet na dobry pocz tek 33 void setattribute(string nazwa, Object warto ) dodaje obiekt do sesji, przypisuj c mu podany klucz (nazw ). Je li jaki obiekt o takiej samej nazwie ju istnia, zostanie on zast piony. Wiemy ju, jak utworzy sesj, wiemy te, jak z niej skorzysta. Pozosta o nam omówienie, jakie s warunki zako czenia sesji. Mo e ono nast pi w wyniku kilku ró nych sytuacji: r czne zako czenie sesji przez programist, up yni cie czasu ycia sesji, zamkni cie okna przegl darki przez u ytkownika. Ostatni przypadek, jest rzecz jasna, najprostszy nie wymaga on naszej ingerencji. R czne zako czenie sesji wi e si z wywo aniem nast puj cej metody: void invalidate() ko czy sesj. Najciekawiej sytuacja wygl da w przypadku okre lania terminu wa no ci sesji. Istniej bowiem dwie mo liwo ci okre lenia tej warto ci pierwsza z nich jest stosowana w pliku konfiguracyjnym web.xml: <web-app> <session-config> <session-timeout>10</session-timeout> </session-config> </web-app> Podana warto okre la czas wa no ci sesji w minutach. Obowi zuje on dla wszystkich sesji, chyba e skorzystasz z mo liwo ci okre lenia czasu ycia sesji w kodzie: void setmaxinactiveinterval(int czas) okre la czas ycia sesji w sekundach. Podanie warto ci 0 i ujemnych powoduje, e sesja nigdy nie wygasa (do jej zako czenia jest wi c konieczne wywo anie metody invalidate() lub zamkni cie okna przegl darki przez u ytkownika). Konfiguracja w kodzie Javy mo na tego unikn Podczas tworzenia wi kszo ci aplikacji programi ci musz zmierzy si z problemem obs ugi ró nego rodzaju ustawie wp ywaj cych na dzia anie aplikacji. Problemem staje si lokalizacja tych ustawie. Z jednej strony nikt nie chce utrudnia sobie ycia w ko cu nie ma nic prostszego, ni wczyta warto umieszczon w sta ej/zmiennej. Z drugiej jednak strony zmiana takich ustawie wymaga aby rekompilacji ca ego projektu, w najlepszym przypadku jednej biblioteki. Z tego wzgl du powszechnym standardem sta o si umieszczanie ró nego rodzaju ustawie w zewn trznych ród ach danych plikach binarnych, tekstowych, XML;
34 Cz I Podstawy rzadziej w bazach danych. W przypadku aplikacji webowych JEE miejscem takim jest deskryptor wdro enia plik web.xml. Poza licznymi ustawieniami zwi zanymi z funkcjonowaniem aplikacji jako takiej (cz z nich ju pozna e ), w pliku web.xml mo esz tak e zdefiniowa parametry dla poszczególnych serwletów, a tak e ca ej aplikacji webowej. Parametry serwletów Parametry serwletów mo esz okre la za pomoc znacznika <init-param> w nast puj cy sposób: <servlet> <servlet-name>parameterservlet</servlet-name> <servlet-class>pl.helion.jeeweb.parameterservlet</servlet-class> <init-param> <param-name>autor</param-name> <param-value>krzysztof Rychlicki-Kicior</param-value> </init-param> </servlet> Po dwóch znanych ju znacznikach (servlet-name i servlet-class) nast puje dowolna liczba znaczników init-param. Ka dy taki znacznik zawiera dwa kolejne, okre laj ce nazw i warto parametru. Parametry serwletów mo na te dodawa w rodowisku Netbeans, podczas tworzenia serwletu (w ostatnim kroku kreatora). Pierwszy parametr utworzony, najwy sza pora, aby odczyta go we wn trzu serwletu. Do zarz dzania parametrami serwletów s u y interfejs ServletConfig, który jest implementowany przez znane nam klasy GenericServlet i HttpServlet. Dwie metody tego interfejsu, które interesuj nas w tej chwili najbardziej, to: String getinitparameter(string nazwa) zwraca warto parametru o podanej nazwie. String[] getinitparameternames() zwraca wszystkie nazwy parametrów danego serwletu. protected void processrequest(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { response.setcontenttype("text/html;charset=utf-8"); PrintWriter out = response.getwriter(); try { out.println("autorem serwletu jest " + this.getinitparameter("autor")); finally { out.close(); Dzi ki umieszczeniu konfiguracji w pliku XML odnie li my wymiern korzy. Zmiana warto ci w pliku XML nie wymaga rekompilacji kodów ród owych, a jedynie prze- adowania aplikacji (w przypadku Tomcata istnieje tak e opcja automatycznego wykrywania zmian i prze adowywania aplikacji).
Rozdzia 3. Serwlet na dobry pocz tek 35 Interfejs ServletConfig poza dwoma poznanymi metodami udost pnia metod get ServletName(), zwracaj c nazw serwletu, a tak e metod getservletcontext(). Zwraca ona (a jak eby inaczej) kontekst serwletów jeden z najwa niejszych obiektów w ca ym wiecie aplikacji webowych JEE. Kontekst serwletów Kontekst serwletów to obiekt, który s u y do komunikacji serwletów z kontenerem. Dzi ki niemu mo esz dynamicznie dodawa serwlety do aplikacji, uzyskiwa dost p do zasobów znajduj cych si w jej obr bie, zapisywa logi do serwerowego dziennika, a co najwa niejsze z obecnego punktu widzenia mo esz korzysta z parametrów aplikacji webowej (kontekstu). Od parametrów serwletów ró ni je zasi g oddzia ywania. Ka dy parametr kontekstu jest widoczny we wszystkich serwletach i innych plikach. Parametry serwletu s okre lane w podobny sposób jak w przypadku serwletów: <web-app> <context-param> <param-name>tytul </param-name> <param-value>java EE 6. Tworzenie aplikacji webowych</param-value> </context-param> </web-app> Równie sposób wykorzystywania parametrów kontekstu przypomina ten znany z serwletów: try { out.println("wszystkie przyk ady pochodz z ksi ki " + this.getservletcontext().getinitparameter("tytul")); finally { out.close(); Jedyn ró nic stanowi odwo anie si do obiektu kontekstu. Reszta pozostaje bez zmian nawet nazwa metody. Ciekawostk stanowi metoda wprowadzona w specyfikacji Java Servlets 3.0. Otó a do momentu wprowadzenia tej specyfikacji parametry, zarówno serwletów, jak i kontekstu, by y warto ciami tylko do odczytu. Jedyn mo liwo ci zmiany parametrów by a edycja pliku web.xml. W wersji JavaServlet 3.0 API pojawi a si jednak innowacja mo liwo dynamicznego ustawiania parametrów kontekstu za pomoc metody setinitparameter(). Wynika to z wprowadzenia du ej elastyczno ci klasa ServletContext w wersji 3.0 uzyska a wiele metod, takich jak addservlet(), czy addfilter(), które umo liwiaj dynamiczne dodawanie ró nych sk adników aplikacji, do tej pory deklarowanych jedynie w pliku web.xml. Nie nale y jednak nadu ywa tej metody. Kontekst serwletów pojawi si ponownie ju niebawem, tymczasem nadszed czas, aby zmierzy si z przeciwnikiem o wiele wa niejszym od parametrów mowa o atrybutach.
36 Cz I Podstawy Trzech muszkieterów? Parametry, czy to serwletów, czy to aplikacji, maj swoje zastosowania i bywaj niezwykle przydatne. Mimo to g ównym rodkiem komunikacji mi dzy serwletami, kontenerem, sesj, u ytkownikiem i obiektem dania czyli z grubsza mi dzy wszystkimi elementami aplikacji s atrybuty. Z technicznego punktu widzenia mi dzy parametrami i atrybutami wyst puj dwie zasadnicze ró nice: W przypadku parametrów zarówno klucz, jak i warto s a cuchami znaków, za w przypadku atrybutów klucz jest a cuchem, warto mo e by obiektem. Parametry z za o enia s tylko do odczytu (cho w wietle ostatniej wersji specyfikacji wygl da to inaczej ), natomiast atrybuty s przeznaczone zarówno do odczytu, jak i do zapisu. Niezwyk e znaczenie ma tak e wprowadzenie zasi gu atrybutów. Atrybut dodany w zasi gu dania (request) nie b dzie widoczny w innych zasi gach. Tabela 3.1 przedstawia zestawienie parametrów i atrybutów w poszczególnych zakresach. Tabela 3.1. Mo liwo ci zapisywania i odczytywania parametrów i atrybutów w poszczególnych zakresach Zakres Parametry Atrybuty Zapis Odczyt Zapis Odczyt danie nie tak tak tak Serwlet nie tak brak brak Sesja brak brak tak tak Kontekst aplikacji tak (od wersji 3.0) tak tak tak Na podstawie powy szej tabeli wyda wyra nie, e parametry pe ni jedynie funkcj ustawie, opcji konfiguracyjnych, które u atwiaj zmian w dzia aniu aplikacji bez konieczno ci ponownej rekompilacji kodu. Atrybuty natomiast maj zastosowanie o wiele szersze s u do wymiany informacji pomi dzy poszczególnymi elementami aplikacji. W dalszej cz ci rozdzia u skupimy si tylko na atrybutach. Ich ogromna przydatno ma bowiem pewne ograniczenia. Jedno z nich jest zwi zane z najwa niejsz chyba cech odró niaj c aplikacje webowe od aplikacji typu standalone konieczno jednoczesnej obs ugi wielu u ytkowników. Atrybuty a mnogo da Jedna aplikacja webowa mo e by u ywana nawet przez setki czy tysi ce u ytkowników jednocze nie. Ka de danie (HTTP request) jest obs ugiwane przez kontener w osobnym w tku. Istotn kwesti jest wi c zapewnienie integralno ci operacji wyko-
Rozdzia 3. Serwlet na dobry pocz tek 37 nywanych przez ka dego z nich nie mo e by tak, e operacje jednego u ytkownika wp yn na efekt operacji innego. W przypadku parametrów problem ten raczej nie wyst puje. Co prawda, w wersji 3.0 pojawi a si mo liwo modyfikowania parametrów kontekstu aplikacji, jednak mo liwo ta powinna by u ywana w bardzo sporadycznych sytuacjach, gdy obs uga wielu u ytkowników nie powinna sprawia problemów (np. z powodu wywo ywania takiego kodu przez superadministratora witryny). Je li jednak zabezpieczenie jest konieczne, mo na zrealizowa je w sposób analogiczny do tego, który zaprezentuj za chwil. Zdecydowanie bardziej skomplikowana sytuacja wyst puje w przypadku atrybutów. Wszystkie trzy przypadki omówi w kolejnych podrozdzia ach. Atrybuty dania W przypadku atrybutów dania sytuacja jest stosunkowo prosta. danie jest realizowane przez jednego u ytkownika; w dodatku pojedyncze danie nie wi e si w aden sposób z innymi daniami (nawet tego samego u ytkownika), dlatego problem jednoczesnego dost pu przez wielu u ytkowników nie wyst puje. Pojawia si jednak inne pytanie skoro obiekt dania nie wchodzi w interakcje z innymi daniami, po co mia by korzysta z atrybutów? Takie rozwi zanie wynika ze stosowanych w praktyce mechanizmów obs ugi stron. Serwlety same w sobie rzadko generuj tre na ogó wykonuj one ró norodne operacje (np. pobranie danych z bazy, realizacja logiki biznesowej cho w wi kszych aplikacjach i te zadania s delegowane), a nast pnie przekazuj sterowanie do pliku JSP. W takiej sytuacji konieczne jest przekazanie informacji mi dzy serwletem a plikiem JSP. Voilà! znale li my zastosowanie atrybutów dania. Dok adne wyja nienie i przyk ady poznasz w rozdziale po wi conym JSP. Atrybuty sesji W nieco gorszej sytuacji s atrybuty sesji. Wiemy ju, e jedna sesja jest powi zana z konkretnym u ytkownikiem. Teoretycznie nie powinno wi c by problemów. Ale u ytkownicy bywaj okrutni wyobra sobie, co mog oby si sta, gdyby u ytkownik uruchomi Twoj aplikacj webow w dwóch zak adkach i próbowa jednocze nie adowa ró ne (lub te same) serwlety? Odpowied jest prosta: mog oby doj do jednoczesnego dost pu do sesji. Odczyt danych nie stanowi by problemu, ale atrybuty sesyjne mog by przecie równie zapisywane. Taka sytuacja to potencjalny problem. Jak wi c mu zaradzi? Powiem krótko: nale y skorzysta ze standardowego mechanizmu Javy, chroni cego dane przed zapisem przez wiele w tków jednocze nie synchronizacji. Teraz musimy okre li, dost p do czego dok adnie chcemy synchronizowa. Na pocz tek odrzu my obiekt dania (klasy HttpServletRequest). Jest to obiekt zwi zany tylko z jednym, konkretnym daniem, wi c zablokowanie dost pu do niego nie wp yn oby na inne obiekty da nadal wszystkie one mog yby korzysta bez
38 Cz I Podstawy skr powania z sesji. Nie ma sensu równie blokada obiektu serwletu dost p do sesji maj ró ne serwlety, wi c zablokowanie jednego z nich nie powstrzyma innych od zapisu do sesji. Jedynym sensownym rozwi zaniem pozostaje zablokowanie obiektu sesji, do którego uzyskujemy dost p za pomoc obiektu dania. Poni szy kod, wstawiony we wszystkich serwletach, pozwoli na zliczenie wszystkich wywo a serwletów, które mia y miejsce w aplikacji webowej dla danego u ytkownika: HttpSession sesja = request.getsession(); synchronized(sesja) { if (sesja.isnew()) sesja.setattribute("licznik", 1); else { int licznik = Integer.parseInt(sesja.getAttribute("licznik").toString()); sesja.setattribute("licznik", licznik + 1); W ten sposób, gdy jeden serwlet wejdzie w blok synchronizowany, uzyskujemy gwarancj, e aden inny serwlet w tym momencie dost pu do sesji nie uzyska. Wszystkie inne serwlety b d musia y czeka, a pierwszy serwlet zwolni blokad. Atrybuty kontekstu serwletów Najwi ksze niebezpiecze stwo niesie za sob korzystanie z atrybutów nale cych do kontekstu aplikacji. Ka dy taki atrybut mo e by odczytany i zmodyfikowany w dowolnym niemal miejscu aplikacji. Z tego wzgl du ka da próba korzystania z atrybutów (zw aszcza zapisu) powinna by synchronizowana. Zasada dzia ania jest taka sama, jak w przypadku sesji. W tym przypadku musimy jednak synchronizowa obiekt kontekstu. Kod synchronizuj cy przedstawia si nast puj co: ServletContext sc = this.getservletcontext(); synchronized(sc) { Object licznik = sc.getattribute("licznik"); if (licznik == null) sc.setattribute("licznik", 1); else { licznik = sc.getattribute("licznik"); sc.setattribute("licznik", Integer.parseInt(licznik.toString()) + 1); Powy szy kod realizuje funkcjonalno podobn do przyk adu z sesj tym razem zliczamy jednak wszystkie wywo ania serwletów wykonane przez wszystkich u ytkowników. Z obiektami da, sesji i kontekstu, jak równie z ich atrybutami, wi si wa ne klasy s uchaczy zdarze. Cho istnieje mo liwo tworzenia ca ych aplikacji webowych bez wiadomo ci istnienia tych klas, zdarzaj si sytuacje, w których znajomo tego typu mechanizmów jest niezb dna.
Rozdzia 3. Serwlet na dobry pocz tek 39 S uchowisko S uchacze zdarze to obiekty spotykane w Javie niezwykle cz sto. Pocz tkuj cy programi ci Javy spotykaj si z nimi np. podczas tworzenia prostych aplikacji graficznych. S uchacz zdarze powi zany z przyciskiem pozwala na wykonanie dowolnego kodu np. po jego klikni ciu. Poj cie s uchacza zdarze nie ogranicza si oczywi cie do tworzenia aplikacji z graficznym interfejsem równie aplikacje webowe daj s uchaczom zdarze spore pole do popisu. W poni szych podrozdzia ach przedstawi interfejsy s uchaczy zdarze przeznaczone do u ycia w aplikacjach webowych. Nie jest to mo e najciekawszy fragment niniejszej ksi ki, ale pr dzej czy pó niej znajdziesz si w sytuacji, w której b dziesz musia skorzysta z opisanych w nast pnych akapitach mechanizmów. ServletContextListener Jest to najrzadziej chyba wykorzystywany s uchacz zdarze. Zawiera dwie metody: contextinitialized() i contextdestroyed(), które s wywo ywane w momencie utworzenia/usuni cia kontekstu aplikacji, czyli w momencie startu i zako czenia aplikacji. Obydwie metody przyjmuj parametr typu ServletContextEvent umo liwia on pobranie kontekstu aplikacji za pomoc metody getservletcontext(). ServletContextAttributeListener Drugim s uchaczem zdarze zwi zanym z kontekstem aplikacji jest s uchacz obserwuj cy kolekcj atrybutów kontekstu. Reaguje on na dodawanie (metoda attribute Added()), usuwanie (attributeremoved()) i zamian (attributereplaced()) atrybutów. Wszystkie trzy metody przyjmuj jeden parametr typu ServletContextAttribute Event umo liwia on pobranie nazwy modyfikowanego atrybutu (getname()), jego warto ci (getvalue()). ServletRequestAttributeListener i ServletRequestListener Obydwa interfejsy pe ni analogiczne funkcje, co ich kontekstowi koledzy nawet nazwy metod s podobne (w przypadku pierwszego interfejsu identyczne, w przypadku drugiego requestinitialized() i requestdestroyed()). Jedyn realn zmian jest wprowadzenie dodatkowej funkcjonalno ci do klas argumentów zdarze ServletRequestAttributeEvent i ServletRequestEvent. Udost pniaj one metod getservletrequest(). Pozwala ona na skorzystanie z obiektu dania, którego zdarzenia dotycz.
40 Cz I Podstawy HttpSessionAtributteListener i HttpSessionListener Równie s uchacze zdarze powi zani z sesjami zosta y utworzone zgodnie z omówionymi powy ej zasadami. S uchacz HttpSessionListener jest wykorzystywany przy tworzeniu (metoda sessioncreated()) i ko czeniu sesji (sessiondestroyed()). Przekazywany argument obiekt klasy HttpSessionEvent udost pnia metod getsession(), która daje dost p do utworzonej (zako czonej) sesji. W przypadku interfejsu HttpSessionAttributeListener mamy do dyspozycji te same trzy metody, co w poprzednich przypadkach. Typ zdarzenia to HttpSessionBindingEvent. Jego mo liwo ci sprowadzaj si do pobrania obiektu sesji i nazwy/warto ci dodawanego/usuwanego/ zmienianego atrybutu. HttpSessionBindingListener Nareszcie co ciekawego! Tytu owy interfejs odbiega nieco od schematu, z jakim mieli my do czynienia przez ostatnie trzy podrozdzia y. Wszystkie trzy interfejsy z cz onem AttributeListener w nazwie odpowiada y za informowanie o zmianach zachodz cych w kolekcji atrybutów. Dla odmiany interfejs HttpSessionBindingListener powinien by implementowany przez klasy, których obiekty b d umieszczane w sesji! Je li wi c tworzysz w asne klasy do przechowywania danych, które w momencie zapisu do sesji powinny by w jaki sposób przetworzone, powiniene skorzysta z tego interfejsu. Metody tego interfejsu to valuebound() i valueunbound(), wywo ywane odpowiednio w momencie do czenia obiektu do sesji lub jego usuni cia. Klasa argumentu zdarze to znana z poprzedniego akapitu HttpSessionBindingEvent. Sesja + wiele JVM = HttpSessionActivationListener Java EE to technologia uniwersalna, która mo e by z powodzeniem stosowana w rozbudowanych aplikacjach webowych i biznesowych. Jednym z wa nych aspektów tworzenia takich aplikacji jest skalowalno mo liwo poprawnego i wydajnego dzia ania aplikacji w dowolnych warunkach (niewielkiego, jak i bardzo du ego obci enia), bez konieczno ci zmiany samej aplikacji. Bardzo cz sto, w celu poprawy wydajno ci, ta sama aplikacja jest instalowana na wielu komputerach po czonych w sie, a specjalny serwer, b d cy bram do wiata zewn trznego (czyli do klientów), kieruje ruchem i przydziela poszczególne dania do tych komputerów, które w danym momencie s najmniej obci one. Taka technika nosi nazw równowa enia obci enia (ang. load balancing). Nie b dziemy zag bia si teraz w szczegó y tej techniki; w niniejszej ksi ce b dzie nas interesowa co najwy ej wp yw tej techniki na kod aplikacji lub informacje zawarte w deskryptorze wdro enia. W tym podrozdziale zajmiemy si s uchaczem zdarze, który jest zwi zany z dwoma istotnymi zagadnieniami: obs ug sesji i równowa- eniem obci enia.
Rozdzia 3. Serwlet na dobry pocz tek 41 Gdy u ytkownik tworzy obiekt sesji, jest on zapisywany (np. w postaci pliku) na komputerze, który obs ugiwa w danej chwili danie. Nast pne danie u ytkownika mo- e jednak by przydzielone do zupe nie innego komputera wewn trz sieci dlatego konieczne jest wprowadzenie mechanizmu, który przeniesie obiekt sesji z pierwszego komputera na drugi. Na szcz cie mechanizm ten jest automatyczny. Jedynym (opcjonalnym) zadaniem programisty jest wykonanie operacji przed przeniesieniem sesji z komputera pierwotnego i po przeniesieniu sesji na komputer docelowy. S u do tego celu metody: void sessionwillpassivate(httpsessionevent hse) metoda wywo ywana tu przed przes aniem sesji do innego komputera; void sessiondidactivate(httpsessionevent hse) metoda wywo ywana tu po otrzymaniu sesji od pierwszego komputera. Filtry Do tej pory wszystkie przyk ady omawiali my, korzystaj c z modelu obs ugi dania/ odpowiedzi. danie HTTP przes ane przez klienta powodowa o utworzenie nowego w tku, wykorzystuj cego obiekt odpowiedniego serwletu. Na podstawie metody dania HTTP nast powa wybór odpowiedniej metody klasy HttpServlet (doget(), dopost() itd.). Model ten mo na jednak rozszerzy o dodatkowe elementy filtry. Filtr umo liwia wykonywanie operacji w momencie nadej cia da do serwletów i wygenerowania przeze odpowiedzi, przy czym nie ingeruje on w dzia anie samego serwletu. Mo na zatem np. zapisa w dzienniku dat ka dego dania, jego parametry, a tak e sprawdzi, jaka jest d ugo odpowiedzi wygenerowanej przez serwlet. W praktyce serwlety stosuje si równie do kontroli, a ewentualnie tak e modyfikacji obiektów dania i odpowiedzi. Dzi ki filtrom mo esz skompresowa ca tre odpowiedzi, zanim zostanie przes ana ostatecznie do klienta. Mo esz te w uniwersalny sposób odrzuca dania, które nie spe niaj okre lonych warunków (np. warto ustalonych parametrów). Najwi ksz zalet filtrów jest mo liwo pod czenia ich do dowolnej grupy serwletów filtry s czone z serwletami za pomoc znacznika url-pattern, dzia aj cego analogicznie jak w przypadku serwletów. Jak wida, dodanie jednego znacznika pozwala na w czenie szyfrowania, kompresji lub kontroli dost pu dla ca ej grupy serwletów. Techniczny aspekt filtrów Z technicznego punktu widzenia filtr jest klas implementuj c interfejs javax.servlet. Filter. Interfejs ów sk ada si z trzech metod: void init(filterconfig fc) metoda wywo ywana przy utworzeniu filtru. Pozwala na uzyskanie obiektu ustawie filtru obiektu interfejsu FilterConfig.
42 Cz I Podstawy void dofilter(servletrequest request, ServletResponse response, FilterChain chain) metoda wywo ywana w momencie nadej cia dania. Dok adny opis w dalszej cz ci podrozdzia u. void destroy() metoda wywo ywana przez serwer w momencie zako czenia dzia ania filtru. Najwi ksze znaczenie ma, rzecz jasna, metoda dofilter(). Typowy sposób jej wykorzystania przedstawiam poni ej: public void dofilter(servletrequest req, ServletResponse res, FilterChain chain) { if (!req.issecure()) ((HttpServletResponse)res).sendError(HttpServletResponse.SC_RESPONSE); chain.dofilter(req, res); bool spakowany = false; if (req.getparameter("format")!= null && req.getparameter("format").equals("spakowany")) spakowany = true; if (spakowany) { // pobierz tre odpowiedzi, spakuj j, a nast pnie // zapisz, korzystaj c z obiektu res. Tre powy szej metody mo na podzieli na trzy cz ci. Na pocz tku sprawdzamy, czy dane danie jest realizowane w trybie bezpiecznym, czyli z wykorzystaniem protoko u SSL. Je li nie odsy amy u ytkownikowi kod b du 403 forbidden (brak uprawnie do zrealizowania dania). Najwa niejszym fragmentem metody jest wywo anie dofilter() obiektu chain. Zbie no nazw w tej sytuacji jest przypadkowa (klasy FilterChain i Filter nie s ze sob w aden formalny sposób zwi zane). Zadaniem interfejsu FilterChain jest zapewnienie komunikacji mi dzy filtrem (lub grup filtrów) a serwletem. W zale no ci od kolejno ci deklaracji filtrów w deskryptorze wdro enia danie HTTP przechodzi przez kolejne filtry (dzi ki wywo aniom metody dofilter() w ka dym filtrze), a w ko cu dociera do serwletu. Po zako czeniu obs ugi przez serwlet, sterowanie powraca do kolejnych filtrów (w naszym przypadku od deklaracji zmiennej spakowany, a do opuszczenia ostatniego filtru). Konfiguracja filtrów w pliku web.xml Samo utworzenie klas filtrów to za ma o. Musisz doda tak e odpowiednie wpisy w pliku web.xml. Zasada dzia ania filtrów przypomina t znan z serwletów, dlatego równie informacje podawane w deskryptorze wdro enia powinny wyda Ci si znajome: <filter> <filter-name>pierwszy filtr</filter-name> <filter-class>pl.helion.jeeweb.filtr<filter-class> </filter> <filter-mapping> <filter-name>pierwszy filtr</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> Czytaj dalej...