Core Java Servlets i JavaServer Pages. Tom II. Wydanie II

Core Java Servlets
i JavaServer Pages.
Tom II. Wydanie II
Autor: Marty Hall,
Larry Brown, Yaakov Chaikin
T³umaczenie: Daniel Kaczmarek
ISBN: 978-83-246-1726-5
Tytu³ orygina³u: Core Servlets
and Javaserver Pages: Advanced
Technologies, Vol. 2 (2nd Edition)
Format: 172x245, stron: 632

• Jak wykorzystaæ strumienie?
• Jak stworzyæ efektowny interfejs u¿ytkownika?
• Jak zapewniæ bezpieczeñstwo w tworzonych aplikacjach?
Co spowodowa³o, ¿e jêzyk programowania Java zyska³ tak wielk¹ popularnoœæ?
Przyczyn jest kilka: mo¿liwoœæ przenoszenia kodu miêdzy programami, wydajnoœæ i to,
co programiœci lubi¹ najbardziej – mechanizm automatycznego oczyszczania pamiêci.
Nie bez znaczenia jest równie¿ to, ¿e Java jest jêzykiem zorientowanym obiektowo,
udostêpnia obs³ugê programowania rozproszonego oraz œwietn¹ dokumentacjê.
Ponadto liczne publikacje oraz pomocna spo³ecznoœæ sprawiaj¹, ¿e Java zajmuje
poczesne miejsce wœród innych jêzyków programowania.
Kolejne wydanie ksi¹¿ki zosta³o zaktualizowane o wszystkie te elementy, które pojawi³y
siê w wersji szóstej platformy Java Standard Edition. Dziêki tej ksi¹¿ce dowiesz siê,
w jaki sposób wykorzystaæ strumienie, jak parsowaæ dokumenty XML czy te¿ w jaki
sposób tworzyæ aplikacje sieciowe. Poznasz interfejs JDBC, sposób wykorzystania
transakcji oraz wykonywania zapytañ SQL. Autorzy w szczegó³owy sposób poka¿¹ Ci,
jak tworzyæ aplikacje z wykorzystaniem biblioteki Swing. Dodatkowo przedstawi¹,
w jaki sposób zapewniæ bezpieczeñstwo w tworzonych przez Ciebie aplikacjach.
Wszystkie te - oraz wiele innych – zagadnienia zostan¹ przedstawione w przystêpny
i sprawdzony sposób!
• Wykorzystanie strumieni
• Dokumenty XML i ich wykorzystanie w jêzyku Java
• Programowanie aplikacji sieciowych
• Wykorzystanie interfejsu JDBC
• Tworzenie aplikacji wielojêzycznych
• Mo¿liwoœci pakietu Swing
• Wykorzystanie biblioteki AWT
• Bezpieczeñstwo w aplikacjach
• Zastosowanie podpisu cyfrowego
• Sposoby wykorzystania obiektów rozproszonych (RMI)
Wykorzystaj zaawansowane mo¿liwoœci jêzyka Java w swoich projektach!

Spis treÊci
Wprowadzenie ................................................................................................................................................ 11

PodziÂkowania ............................................................................................................................................... 15

O autorach ...................................................................................................................................................... 16

RozdziaÄ 1. UÑywanie i wdraÑanie aplikacji internetowych ......................................................................... 17
1.1. Cele aplikacji internetowych .................................................................................... 18
Organizacja ....................................................................................................... 18
PrzenoĈnoĈè ..................................................................................................... 18
Separacja ......................................................................................................... 18
1.2. Struktura aplikacji internetowych ............................................................................... 19
Lokalizacje poszczególnych rodzajów plików ......................................................... 19
1.3. Rejestrowanie aplikacji internetowych na serwerze ..................................................... 23
Rejestrowanie aplikacji internetowych na serwerze Tomcat ................................... 24
Rejestrowanie aplikacji internetowych na innych serwerach ................................... 26
1.4. Strategie rozwoju i wdraĔania aplikacji internetowych .................................................. 28
Kopiowanie struktury do skrótu lub dowiñzania symbolicznego .............................. 29
Wykorzystanie funkcji wdraĔania udostöpnianych przez IDE ................................... 30
UĔywanie narzödzi ant, maven i im podobnych ..................................................... 30
UĔywanie IDE wraz z narzödziem Ant ................................................................... 31
1.5. Umieszczanie aplikacji internetowych w plikach WAR .................................................. 31
1.6. Tworzenie prostej aplikacji internetowej ..................................................................... 32
Pobranie aplikacji app-blank i zmiana jej nazwy na testApp ................................... 33
Pobranie plików test.html, test.jsp oraz TestServlet.java ....................................... 33
Dodanie plików test.html i test.jsp do aplikacji internetowej testApp ..................... 33
Umieszczenie pliku TestServlet.java w katalogu
testApp/WEB-INF/classes/coreservlets .......................................................... 34
Kompilacja pliku TestServlet.java ........................................................................ 34
Zadeklarowanie w pliku web.xml klasy TestServlet.class oraz adresu URL,
który jñ wywoäuje ........................................................................................... 35
Skopiowanie aplikacji testApp do katalogu katalog_tomcat/webapps .................... 36

4 Core Java Servlets i JavaServer Pages

Uruchomienie serwera Tomcat ............................................................................ 36
Wywoäanie aplikacji testApp przy uĔyciu adresu URL
w postaci http://localhost/testApp/zasób ...................................................... 37
1.7. WspóäuĔytkowanie danych przez aplikacje internetowe ................................................ 39

RozdziaÄ 2. Kontrolowanie dziaÄania aplikacji przy uÑyciu deskryptora web.xml ....................................47
2.1. Przeznaczenie deskryptora wdroĔenia ........................................................................ 48
2.2. Definiowanie elementu gäównego i elementu nagäówka ............................................... 48
2.3. Elementy deskryptora web.xml .................................................................................. 50
Wersja 2.4 specyfikacji serwletów ....................................................................... 50
Wersja 2.3 specyfikacji serwletów ....................................................................... 53
2.4. Przypisywanie nazw i wäasnych adresów URL .............................................................. 55
Przypisywanie nazw ............................................................................................ 56
Definiowanie wäasnych adresów URL ................................................................... 57
Nazewnictwo stron JSP ...................................................................................... 62
2.5. Wyäñczanie serwletu wywoäujñcego ............................................................................ 64
Zmiana odwzorowania wzorca adresu URL /servlet/ ............................................. 65
Globalne wyäñczanie serwletu wywoäujñcego na serwerze Tomcat .......................... 66
2.6. Inicjalizowanie i wstöpne äadowanie serwletów i stron JSP .......................................... 68
Przypisywanie serwletom parametrów inicjalizacyjnych .......................................... 68
Przypisywanie parametrów inicjalizacyjnych JSP .................................................... 71
Parametry inicjalizacyjne na poziomie caäej aplikacji ............................................. 74
ãadowanie serwletów w momencie uruchamiania serwera .................................... 74
2.7. Deklarowanie filtrów ................................................................................................ 78
2.8. Definiowanie stron powitalnych ................................................................................. 81
2.9. Wyznaczanie stron obsäugujñcych bäödy ..................................................................... 81
Element error-code ............................................................................................ 82
Element exception-type ...................................................................................... 84
2.10. Definiowanie zabezpieczeþ ...................................................................................... 86
Definiowanie metody uwierzytelniania ................................................................. 86
Ograniczanie dostöpu do zasobów sieciowych ...................................................... 88
Przypisywanie ról ............................................................................................... 91
2.11. Kontrolowanie czasu wygasania sesji ....................................................................... 92
2.12. Dokumentowanie aplikacji internetowych .................................................................. 92
2.13. Przypisywanie plikom typów MIME ............................................................................ 93
2.14. Konfigurowanie stron JSP ........................................................................................ 94
Lokalizacja deskryptorów bibliotek znaczników ..................................................... 94
Konfigurowanie wäaĈciwoĈci stron JSP ................................................................. 95
2.15. Kodowanie znaków ............................................................................................... 100
2.16. Tworzenie procesów nasäuchujñcych zdarzeþ aplikacji .............................................. 100
2.17. Tworzenie rozwiñzaþ przeznaczonych dla Ĉrodowisk klastrowych ............................... 101
2.18. Elementy J2EE ..................................................................................................... 104

RozdziaÄ 3. Zabezpieczenia deklaratywne ................................................................................................. 109
3.1. Uwierzytelnianie przy uĔyciu formularza .................................................................... 111
Definiowanie nazw uĔytkowników, haseä i ról ...................................................... 113
Wäñczanie na serwerze uwierzytelniania przy uĔyciu formularzy
i wskazywanie lokalizacji strony logowania oraz strony obsäugi bäödu logowania .... 114
Tworzenie strony logowania .............................................................................. 115
Tworzenie strony z informacjñ o bäödzie logowania ............................................. 118
Wskazywanie adresów URL, które majñ byè zabezpieczone hasäem ..................... 118
Zdefiniowanie listy wszystkich abstrakcyjnych ról ............................................... 122

Spis treÊci 5

Wskazywanie adresów URL dostöpnych wyäñcznie
za poĈrednictwem protokoäu SSL .................................................................. 122
Wyäñczanie serwletu wywoäujñcego .................................................................... 124
3.2. Przykäad. Uwierzytelnianie przy uĔyciu formularzy ..................................................... 125
Strona gäówna ................................................................................................. 125
Deskryptor wdroĔenia ....................................................................................... 126
Plik z hasäami .................................................................................................. 129
Strony logowania i obsäugi bäödu logowania ....................................................... 130
Katalog investing ............................................................................................. 131
Katalog ssl ..................................................................................................... 134
Katalog admin ................................................................................................. 137
Serwlet NoInvokerServlet ................................................................................. 140
Strony niezabezpieczone .................................................................................. 141
3.3. Uwierzytelnianie metodñ BASIC ............................................................................... 144
Definiowanie nazw uĔytkowników, haseä i ról ...................................................... 146
Wäñczanie na serwerze uwierzytelniania metodñ BASIC
i definiowanie nazwy obszaru ....................................................................... 146
Wskazywanie adresów URL, które majñ byè zabezpieczone hasäem ..................... 146
Zdefiniowanie listy wszystkich abstrakcyjnych ról ............................................... 147
Wskazywanie adresów URL dostöpnych wyäñcznie
za poĈrednictwem protokoäu SSL .................................................................. 147
3.4. Przykäad. Uwierzytelnianie metodñ BASIC ................................................................. 147
Strona gäówna ................................................................................................. 148
Deskryptor wdroĔenia ....................................................................................... 149
Plik haseä ........................................................................................................ 151
Plan finansowy ................................................................................................ 151
Biznesplan ...................................................................................................... 152
Serwlet NoInvokerServlet ................................................................................. 154
3.5. Konfigurowanie obsäugi protokoäu SSL na serwerze Tomcat ....................................... 155
3.6. WebClient. Interaktywna komunikacja z serwerami WWW .......................................... 161
3.7. Podpisywanie certyfikatu serwera ............................................................................ 164
Eksport certyfikatu CA ...................................................................................... 166
Komunikacja klienta WebClient z serwerem Tomcat przy uĔyciu protokoäu SSL ..... 170

RozdziaÄ 4. Zabezpieczenia programistyczne ........................................................................................... 173
4.1. ãñczenie zabezpieczeþ programistycznych i zabezpieczeþ
zarzñdzanych przez kontener ..................................................................... 175
Odwoäania do ról ............................................................................................. 176
4.2. Przykäad. ãñczenie zabezpieczeþ programistycznych i zabezpieczeþ
zarzñdzanych przez kontener ..................................................................... 177
4.3. Zastosowanie wyäñcznie zabezpieczeþ programistycznych ......................................... 180
4.4. Przykäad. Zastosowanie wyäñcznie zabezpieczeþ programistycznych ........................... 184
4.5. Zabezpieczenia programistyczne i protokóä SSL ......................................................... 187
Ustalenie, czy uĔywany jest protokóä SSL ........................................................... 188
Przekierowywanie wywoäaþ, które nie dotyczñ protokoäu SSL ............................... 188
Odczytanie liczby bitów w kluczu ....................................................................... 189
Sprawdzenie algorytmu szyfrowania .................................................................. 189
Dostöp do certyfikatu X.509 klienta .................................................................. 189
4.6. Przykäad. Zabezpieczenia programistyczne i protokóä SSL .......................................... 190


RozdziaÄ 5. Filtry serwletów i stron JSP ................................................................................................... 195
5.1. Tworzenie prostych filtrów ...................................................................................... 196
Tworzenie klasy implementujñcej interfejs Filter ................................................. 197
Implementacja filtra w metodzie doFilter ............................................................ 198
Wywoäanie metody doFilter obiektu FilterChain ................................................... 198
Rejestrowanie filtra dla serwletów lub stron JSP ................................................. 198
Wyäñczenie serwletu wywoäujñcego .................................................................... 200
5.2. Przykäad. Filtr raportujñcy ........................................................................................ 201
5.3. Dostöp do kontekstu serwletu z poziomu filtra ......................................................... 207
5.4. Przykäad. Filtr zapisujñcy do dziennika ..................................................................... 208
5.5. UĔywanie parametrów inicjalizujñcych dla filtrów ...................................................... 210
5.6. Przykäad. Filtr czasu udostöpnienia .......................................................................... 212
5.7. Blokowanie odpowiedzi .......................................................................................... 215
5.8. Przykäad. Filtr blokujñcy stronö ................................................................................ 215
5.9. Modyfikowanie odpowiedzi ..................................................................................... 221
Obiekt przechowujñcy odpowiedĒ, gotowy do wielokrotnego wykorzystania ............ 222
5.10. Przykäad. Filtr zastöpujñcy ..................................................................................... 224
Ogólny filtr modyfikujñcy ................................................................................... 224
Konkretny filtr modyfikujñcy .............................................................................. 225
5.11. Przykäad. Filtr kompresujñcy .................................................................................. 230
5.12. Konfigurowanie wspóäpracy filtra z obiektem RequestDispatcher ............................. 235
5.13. Przykäad. ãatanie potencjalnej dziury w zabezpieczeniach ........................................ 237
5.14. Peäna definicja deskryptora wdroĔenia ................................................................... 243

RozdziaÄ 6. Model zdarzeÆ aplikacji ........................................................................................................... 249
6.1. Monitorowanie zdarzeþ polegajñcych na utworzeniu i zniszczeniu kontekstu serwletu ..... 252
6.2. Przykäad. Inicjalizowanie wspóäuĔytkowanych danych ................................................. 253
6.3. Wykrywanie zmian wartoĈci atrybutów kontekstu serwletu ......................................... 258
6.4. Monitorowanie zmian we wspóäuĔytkowanych danych ................................................ 259
6.5. Umieszczanie obiektów nasäuchujñcych w bibliotekach znaczników ............................ 267
6.6. Przykäad. Pakiet zawierajñcy obiekty Ĉledzñce nazwö firmy ........................................ 269
6.7. Wykrywanie zdarzeþ tworzenia i niszczenia sesji ....................................................... 275
6.8. Przykäad. Obiekt nasäuchujñcy, który zlicza sesje ...................................................... 276
Wyäñczanie obsäugi plików cookie ...................................................................... 282
6.9. Wykrywanie zmian w atrybutach sesji ...................................................................... 283
6.10. Przykäad. Monitorowanie zamówieþ na jachty ......................................................... 283
6.11. Wykrywanie inicjalizacji i zniszczenia Ĕñdania serwletu ............................................ 290
6.12. Przykäad. Obliczanie obciñĔenia serwera Ĕñdaniami ................................................. 291
6.13. Wykrywanie zmian atrybutów w Ĕñdaniach serwletów .............................................. 296
6.14. Przykäad. Zatrzymywanie obiektu zbierania statystyk Ĕñdaþ ...................................... 297
6.15. Wykorzystanie wielu obiektów nasäuchujñcych wspóäpracujñcych ze sobñ ................. 299
ćledzenie zamówieþ na towary z oferty dnia ....................................................... 300
Resetowanie licznika zamówieþ na oferty dnia ................................................... 306
6.16. Peäna definicja deskryptora wdroĔenia ................................................................... 311

RozdziaÄ 7. Podstawowe informacje na temat bibliotek znaczników ....................................................... 317
7.1. Komponenty biblioteki znaczników .......................................................................... 318
Klasa obsäugi znacznika ................................................................................... 319
Plik deskryptora biblioteki znaczników ............................................................... 320
Plik JSP .......................................................................................................... 321

Spis treÊci 7

7.2. Przykäad. Prosty znacznik liczby pierwszej ................................................................. 322
7.3. Przypisywanie znacznikom atrybutów ....................................................................... 326
Atrybuty znacznika a klasa obsäugi znacznika ..................................................... 326
Atrybuty znacznika a deskryptor biblioteki znaczników ......................................... 327
Atrybuty znacznika a plik JSP ............................................................................ 328
7.4. Przykäad. Znacznik liczby pierwszej o zmiennej däugoĈci ............................................ 328
7.5. Zamieszczanie treĈci znacznika w danych zwracanych przez znacznik ......................... 330
TreĈè znacznika a klasa obsäugi znacznika ......................................................... 330
TreĈè znacznika a deskryptor biblioteki znaczników ............................................ 331
TreĈè znacznika a plik JSP ................................................................................ 331
7.6. Przykäad. Znacznik nagäówka ................................................................................... 332
7.7. Przykäad. Znacznik debugowania ............................................................................. 335
7.8. Tworzenie plików znaczników .................................................................................. 337
7.9. Przykäad. Prosty znacznik liczby pierwszej z uĔyciem pliku znacznika ........................... 339
7.10. Przykäad. Znacznik liczby pierwszej o zmiennej däugoĈci z uĔyciem pliku znacznika ...... 340
7.11. Przykäad. Znacznik nagäówka z uĔyciem pliku znacznika ............................................ 341

RozdziaÄ 8. Biblioteki znaczników. Funkcje zaawansowane .................................................................... 345
8.1. Operacje na treĈci znacznika .................................................................................. 346
8.2. Przykäad. Znacznik filtrujñcy kod HTML ..................................................................... 347
8.3. Przypisywanie atrybutom znaczników wartoĈci dynamicznych ..................................... 350
Dynamiczne wartoĈci atrybutów a klasa obsäugi znacznika .................................. 351
Dynamiczne wartoĈci atrybutów a deskryptor biblioteki znaczników ...................... 351
Dynamiczne wartoĈci atrybutów a plik JSP ......................................................... 351
8.4. Przykäad. Prosty znacznik wykonujñcy pötlö .............................................................. 352
8.5. Przypisywanie atrybutom znaczników wartoĈci w postaci zäoĔonych obiektów .............. 356
Dynamiczne, zäoĔone wartoĈci atrybutów a klasa obsäugi znacznika ..................... 356
Dynamiczne, zäoĔone wartoĈci atrybutów a deskryptor biblioteki znaczników ......... 356
Dynamiczne, zäoĔone wartoĈci atrybutów a plik JSP ............................................ 357
8.6. Przykäad. Znacznik formatujñcy tabele ..................................................................... 357
8.7. Tworzenie znaczników wykonujñcych pötle ............................................................... 362
8.8. Przykäad. Znacznik forEach ..................................................................................... 363
8.9. Tworzenie funkcji jözyka wyraĔeþ ............................................................................. 367
8.10. Przykäad. Ulepszony znacznik debugowania ............................................................. 369
8.11. Obsäuga zagnieĔdĔonych znaczników niestandardowych ........................................... 372
8.12. Przykäad. Znacznik If-Then-Else ............................................................................... 373

RozdziaÄ 9. Biblioteka standardowych znaczników JSP (JSTL) ............................................................... 379
9.1. Instalacja biblioteki JSTL ........................................................................................ 380
9.2. Znacznik c:out ....................................................................................................... 381
9.3. Znaczniki c:forEach i c:forTokens ............................................................................ 382
9.4. Znacznik c:if .......................................................................................................... 383
9.5. Znacznik c:choose ................................................................................................. 384
9.6. Znaczniki c:set i c:remove ...................................................................................... 386
9.7. Znacznik c:import .................................................................................................. 388
9.8. Znaczniki c:url i c:param ........................................................................................ 391
9.9. Znacznik c:redirect ................................................................................................ 392
9.10. Znacznik c:catch .................................................................................................... 394


RozdziaÄ 10. Podstawy platformy Struts ................................................................................................... 397
10.1. Podstawy Struts ................................................................................................... 398
RóĔne strony Struts ......................................................................................... 398
Zalety platformy Apache Struts w porównaniu z MVC
z obiektem RequestDispatcher i JSP EL ........................................................ 398
Wady platformy Apache Struts w porównaniu z MVC
z obiektem RequestDispatcher i EL .............................................................. 400
10.2. Instalacja i konfiguracja platformy Struts ................................................................ 402
Instalacja Struts .............................................................................................. 402
Testowanie platformy Struts ............................................................................. 404
Tworzenie wäasnych aplikacji Struts ................................................................... 405
Dodawanie Struts do juĔ istniejñcej aplikacji internetowej ................................... 405
10.3. Proces przetwarzania Struts i szeĈè kroków do jego implementacji ........................... 406
Proces przetwarzania na platformie Struts ......................................................... 406
SzeĈè podstawowych kroków w pracy ze Struts .................................................. 410
10.4. Przetwarzanie Ĕñdaþ przez obiekty Action ................................................................ 414
Dziaäanie obiektów Action ................................................................................. 415
Przykäad. Odwzorowanie jednego wyniku ............................................................ 418
Przykäad. Odwzorowanie kilku wyników ............................................................... 424
ãñczenie wspóäuĔytkowanych odwzorowaþ warunków .......................................... 432
10.5. Obsäuga parametrów Ĕñdaþ w komponentach bean formularzy .................................. 434
Proces przetwarzania na platformie Struts z uwzglödnieniem komponentów bean ..... 434
Dziaäanie komponentów bean formularzy ........................................................... 438
WyĈwietlanie wäaĈciwoĈci komponentu bean ...................................................... 440
Przykäad. Komponenty bean formularza i danych wynikowych ............................... 442
10.6. Wstöpne wypeänianie formularzy danymi i ich ponowne wyĈwietlanie ......................... 453
Proces przetwarzania na platformie Struts ......................................................... 454
Wykorzystanie znaczników html: platformy Struts ............................................... 458
Wypeänianie formularzy danymi poczñtkowymi .................................................... 459
Przykäad. Wypeänianie formularzy danymi poczñtkowymi ...................................... 460
Strategie tworzenia adresów URL dla obiektów Action ........................................ 469
Ponowne wyĈwietlanie formularzy ..................................................................... 472
Przykäad. Ponowne wyĈwietlanie formularza ....................................................... 475

RozdziaÄ 11. Platforma Struts. Funkcje dodatkowe ................................................................................... 485
11.1. Wykorzystanie plików wäaĈciwoĈci .......................................................................... 486
Zalety plików wäaĈciwoĈci ................................................................................. 486
Dziaäanie platformy Struts z uwzglödnieniem plików wäaĈciwoĈci .......................... 486
Sposób uĔywania plików wäaĈciwoĈci ................................................................ 487
Przykäad. Proste komunikaty ............................................................................. 491
Klucze dynamiczne .......................................................................................... 496
Komunikaty parametryzowane .......................................................................... 497
11.2. Umiödzynaradawianie aplikacji ............................................................................... 498
ãadowanie jözykowych wersji pliku wäaĈciwoĈci .................................................. 498
Definiowanie ustawieþ jözykowych w przeglñdarkach .......................................... 498
Przykäad. Polska, hiszpaþska i francuska wersja jözykowa ................................... 499
Wyniki ............................................................................................................ 500

Spis treÊci 9

11.3. Definiowanie ukäadu stron przy uĔyciu moduäu Tiles ............................................... 501
Powody, dla których warto uĔywaè Tiles ............................................................. 501
Wymagania wstöpne moduäu Tiles .................................................................... 502
Cztery kroki w pracy z Tiles ............................................................................... 503
Prosta aplikacja wykorzystujñca Tiles ................................................................ 506
Obsäuga wzglödnych adresów URL .................................................................... 510
Przykäad. Aplikacja e-boats ............................................................................... 511
11.4. Wykorzystanie Tiles Definitions .............................................................................. 519
Powody, dla których warto uĔywaè Tiles Definitions ............................................ 521
Piöè kroków w pracy z Tiles Definitions .............................................................. 522
Przykäad. Aplikacja e-boats wykorzystujñca moduä Tiles Definitions ...................... 525

RozdziaÄ 12. Platforma Struts. Weryfikacja poprawnoÊci danych wpisanych przez uÑytkownika ...... 529
12.1. Weryfikacja poprawnoĈci danych w klasie Action ..................................................... 530
Proces przetwarzania Struts ............................................................................. 531
Przeprowadzenie weryfikacji danych w klasie Action ............................................ 531
Przykäad. Wybór kolorów i rozmiarów czcionek wykorzystywanych w Ĕyciorysie ....... 534
12.2. Weryfikacja poprawnoĈci danych w komponencie bean formularza ............................ 541
Przeprowadzenie weryfikacji danych w komponencie ActionForm .......................... 542
Przykäad. Wybór kolorów i rozmiarów czcionek
wykorzystywanych w Ĕyciorysie (wersja druga) ................................................ 546
Parametryzowane komunikaty o bäödach ........................................................... 553
Przykäad. Weryfikacja poprawnoĈci danych
z wykorzystaniem parametryzowanych komunikatów ....................................... 553
12.3. Wykorzystanie platformy automatycznej weryfikacji poprawnoĈci danych .................... 556
Weryfikacja röczna a weryfikacja automatyczna .................................................. 556
Weryfikacja na kliencie a weryfikacja na serwerze .............................................. 557
Konfiguracja mechanizmu automatycznej weryfikacji danych ................................ 559
Przykäad. Automatyczna weryfikacja poprawnoĈci danych .................................... 565

Dodatek A Tworzenie aplikacji przy uÑyciu Apache Ant ........................................................................... 575
A.1. NajwaĔniejsze zalety Ant ......................................................................................... 576
A.2. Instalacja i konfiguracja Ant .................................................................................... 576
A.3. Tworzenie projektu Ant ........................................................................................... 577
Definiowanie projektu Ant ................................................................................. 578
Definiowanie celów .......................................................................................... 580
Przypisywanie zadaþ do celów .......................................................................... 581
Uruchamianie celu Ant ..................................................................................... 581
A.4. Przeglñd najczöĈciej uĔywanych zadaþ Ant ............................................................... 582
Zadanie echo .................................................................................................. 582
Zadanie tstamp ............................................................................................... 583
Zadanie mkdir ................................................................................................. 584
Zadanie delete ................................................................................................ 584
Zadanie copy .................................................................................................. 586
Zadanie javac .................................................................................................. 588
A.5. Przykäad. Prosty projekt Ant .................................................................................... 591
A.6. Tworzenie aplikacji internetowej przy uĔyciu Ant ...................................................... 596
ZaleĔnoĈci miödzy celami Ant ........................................................................... 597


A.7. Przykäad. Wykonanie aplikacji internetowej ............................................................... 598
Cel prepare ..................................................................................................... 600
Cel copy ......................................................................................................... 601
Cel build ......................................................................................................... 602
A.8. Tworzenie pliku WAR przy uĔyciu Ant ........................................................................ 603
Zadanie jar ..................................................................................................... 603
Zadanie manifest ............................................................................................ 605
A.9. Przykäad. Tworzenie pliku WAR aplikacji internetowej ................................................. 606
Cel war ........................................................................................................... 607

Skorowidz ..................................................................................................................................................... 611

1
UÑywanie i wdraÑanie
aplikacji internetowych
W tym rozdziale:
Q Cele aplikacji internetowych
Q Struktura aplikacji internetowych
Q Rejestrowanie aplikacji internetowych
Q Strategie rozwoju i wdraĪania aplikacji internetowych
Q Pliki WAR
Q WspóáuĪytkowanie danych przez aplikacje internetowe

W ramach aplikacji internetowych moĪna tworzyü zwarte kolekcje serwletów, stron Java
Server Pages (JSP), bibliotek znaczników, dokumentów HTML (Hypertext Markup Language),
obrazków, arkuszy stylów i innych treĞci przeznaczonych dla internetu. Z kolekcji tych moĪna
korzystaü na dowolnym serwerze zgodnym ze specyfikacją serwletów. Prawidáowo zaprojek-
towane aplikacje internetowe moĪna przenosiü z jednego serwera na inny albo umieszczaü
w innej lokalizacji na tym samym serwerze bez koniecznoĞci wprowadzania zmian do ser-
wletów, stron JSP czy plików HTML wchodzących w skáad aplikacji.

W ten sposób nawet záoĪone aplikacje moĪna przenosiü bez wiĊkszego wysiáku, uáatwiając ich
wielokrotne wykorzystywanie. Ponadto dziĊki temu, Īe kaĪda aplikacja internetowa posiada
wáasną strukturĊ katalogów, sesje, kontekst ServletContext i moduá áadowania klas, uĪywanie
aplikacji internetowej upraszcza nawet początkowe etapy rozwoju, poniewaĪ znacznie
mniej uwagi trzeba poĞwiĊcaü na koordynacjĊ poszczególnych elementów caáego opraco-
wanego rozwiązania.


1.1. Cele aplikacji internetowych
Aplikacje internetowe mają trzy gáówne zalety — uáatwiają odpowiednie zorganizowanie
zasobów, wdroĪona aplikacja charakteryzuje siĊ przenoĞnoĞcią, a ponadto áatwiej jest uniknąü
konfliktów miĊdzy róĪnymi aplikacjami internetowymi. KaĪda z tych zalet zostanie omówiona
nieco szerzej.

Organizacja
Pierwsza zaleta aplikacji internetowych wypáywa z faktu, Īe wszystko ma w nich swoje miejsce
— dla kaĪdego rodzaju zawartoĞci przeznaczona jest standardowa lokalizacja. Poszczególne
pliki klas Java zawsze znajdują siĊ w katalogu o nazwie WEB-INF/classes, pliki JAR (zbiory
plików klas Java) zawsze umieszczane są w katalogu WEB-INF/lib, plik konfiguracyjny
web.xml zawsze znajduje siĊ w katalogu WEB-INF i tak dalej. Pliki bezpoĞrednio dostĊpne
dla klientów (na przykáad przeglądarek internetowych) umieszczane są w gáównym katalogu
aplikacji internetowej lub dowolnym jego podkatalogu z wyjątkiem WEB-INF.

CzĊsto zdarza siĊ, Īe programista koĔczy pracĊ nad jednym projektem i przechodzi do innego
zespoáu projektowego. DziĊki standardowej organizacji zasobów aplikacji nie trzeba na nowo
poznawaü struktury aplikacji za kaĪdym razem, gdy rozpoczyna siĊ pracĊ nad nowym pro-
jektem. Nowy programista rozpoczynający pracĊ nad aplikacją nie musi równieĪ traciü czasu
na rozpoznanie sposobu organizowania poszczególnych rodzajów plików.

PrzenoÊnoÊÀ
PoniewaĪ specyfikacja serwletów przewiduje okreĞloną organizacjĊ plików, na kaĪdym serwe-
rze zgodnym z tą specyfikacją moĪna wáaĞciwie od razu wdraĪaü i uruchamiaü aplikacjĊ.
DziĊki temu istnieje duĪa swoboda w wyborze dostawcy docelowego serwera WWW. JeĞli
tylko wybrany serwer jest zgodny ze specyfikacją, kaĪdą aplikacjĊ moĪna — w wiĊkszoĞci
przypadków bez Īadnych zmian — wdroĪyü i uruchomiü na serwerze pochodzącym od innego
producenta. MoĪna na przykáad utworzyü aplikacjĊ na darmowym serwerze WWW, a nastĊp-
nie jej wersjĊ przedprodukcyjną uruchomiü juĪ na bardziej stabilnym serwerze, dla którego
producent Ğwiadczy odpowiednie wsparcie techniczne.

Separacja
Poszczególne aplikacje internetowe wdroĪone na tym serwerze nie wchodzą ze sobą w konflikt.
KaĪda aplikacja ma wáasny adres URL, za pomocą którego moĪna do niej uzyskaü dostĊp,
wáasny obiekt ServletContext i tak dalej. Dwie aplikacje wdroĪone na tym samym serwerze
dziaáają tak, jakby byáy uruchamiane na dwóch oddzielnych serwerach, Īadna z tych aplikacji
nie musi równieĪ mieü dostĊpu do drugiej.

RozdziaÄ 1. Q UÑywanie i wdraÑanie aplikacji internetowych 19

Fakt ten jeszcze bardziej upraszcza proces tworzenia i wdraĪania aplikacji internetowych.
Programista nie musi bowiem w ogóle zastanawiaü siĊ nad tym, w jaki sposób powinno siĊ
integrowaü tworzoną aplikacjĊ z aplikacjami juĪ dziaáającymi na tym samym serwerze.
Obecnie istnieje kilka sposobów, dziĊki którym aplikacje mogą ze sobą wspóápracowaü
— zostaną one opisane w dalszej czĊĞci rozdziaáu. Jednak w znakomitej wiĊkszoĞci przy-
padków aplikacje wdraĪa siĊ niezaleĪnie od siebie.

1.2. Struktura aplikacji internetowych
Jak juĪ wczeĞniej wspomniano, aplikacja internetowa ma standardowy format i jest przenoĞna
do wszystkich serwerów WWW lub serwerów aplikacji zgodnych ze specyfikacją. Gáówny
katalog aplikacji to zwykáy katalog o dowolnej nazwie. Wewnątrz tego katalogu znajdują
siĊ lokalizacje przeznaczone dla poszczególnych elementów. W tym punkcie opisane zostaną
rodzaje elementów, z jakich moĪe skáadaü siĊ aplikacja, oraz lokalizacje, w których elementy
powinny siĊ znajdowaü.

Lokalizacje poszczególnych rodzajów plików
Na rysunku 1.1 przedstawiono standardową strukturĊ przykáadowej aplikacji internetowej.
Aby wykonaü kolejne kroki procesu tworzenia wáasnej aplikacji internetowej, naleĪy pobraü
z serwera ftp://ftp.helion.pl/przyklady/jsp2w2.zip aplikacjĊ app-blank i wykonaü instrukcje opi-
sane w punkcie 1.6 („Tworzenie prostej aplikacji internetowej”).

Rysunek 1.1.
Struktura
standardowej
aplikacji
internetowej

Strony JSP

Strony JSP naleĪy umieszczaü w gáównym katalogu aplikacji internetowej lub w jego pod-
katalogu o dowolnej nazwie, innej niĪ WEB-INF i META-INF. Serwery nigdy nie udostĊp-
niają klientom plików znajdujących siĊ w katalogach WEB-INF i META-INF. Gdy aplikacja
internetowa zostanie juĪ zarejestrowana (wiĊcej na ten temat w punkcie 1.3), naleĪy wskazaü
serwerowi prefiks URL wskazujący aplikacjĊ oraz zdefiniowaü lokalizacjĊ, w której znaj-
duje siĊ katalog aplikacji internetowej. Zazwyczaj — choü nie jest to obowiązkowe — jako


prefiks URL wskazuje siĊ po prostu nazwĊ gáównego katalogu aplikacji. Po zarejestrowaniu
prefiksu strony JSP staną siĊ dostĊpne za poĞrednictwem adresów URL w postaci http://
´komputer/prefiksAplikacji/nazwapliku.jsp (jeĪeli strony JSP znajdują siĊ w gáównym kata-
logu aplikacji) albo http://komputer/prefiksAplikacji/podkatalog/nazwapliku.jsp (gdy strony
znajdują siĊ w podkatalogu).

Od ustawieĔ serwera zaleĪy, czy plik domyĞlny, taki jak index.jsp, bĊdzie dostĊpny po wpi-
saniu adresu URL wskazującego jedynie katalog (na przykáad http://komputer/prefiksAplikacji/)
bez zapisania odpowiedniego ustawienia w pliku konfiguracyjnym WEB-INF/web.xml. JeĪeli
index.jsp ma byü domyĞlnym plikiem aplikacji, zalecane jest dodanie w pliku web.xml tej
aplikacji odpowiedniego elementu welcome-file-list. Na przykáad poniĪszy fragment pliku
web.xml wskazuje, Īe jeĪeli adres URL zawiera nazwĊ katalogu, a nie zawiera nazwy pliku,
wówczas serwer powinien w pierwszej kolejnoĞci zwróciü plik index.jsp, a w drugiej kolej-
noĞci plik index.html. JeĪeli na serwerze nie ma Īadnego z tych dwóch plików, odpowiedĨ
bĊdzie zaleĪeü od serwera (na przykáad wyĞwietlona zostanie zawartoĞü katalogu).
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
<welcome-file>index.html</welcome-file>
</welcome-file-list>

WiĊcej informacji na temat sposobu uĪywania pliku web.xml znajduje siĊ w rozdziale 2.,
„Kontrolowanie dziaáania aplikacji przy uĪyciu deskryptora web.xml”.

Dokumenty HTML, obrazki i inne standardowe elementy aplikacji internetowej

Moduá obsáugi serwletów i stron JSP stosuje identyczne reguáy dla stron JSP oraz dla plików
HTML, obrazków GIF i JPEG, arkuszy stylów i innych dokumentów internetowych. Wszystkie
wymienione elementy są umieszczane dokáadnie w tych samych lokalizacjach i udostĊpniane
za poĞrednictwem adresów URL w identycznej formie.

Pojedyncze serwlety, komponenty JavaBeans i klasy pomocnicze

Serwlety oraz inne pliki z rozszerzeniem .class umieszcza siĊ w katalogu WEB-INF/classes
albo w podkatalogu katalogu WEB-INF/classes o nazwie odpowiadającej nazwie pakietu.

Aby uzyskaü dostĊp do jednego z serwletów trzeba wskazaü dla niego odpowiedni adres URL.
W tym celu w deskryptorze wdroĪenia web.xml, znajdującym siĊ w katalogu WEB-INF,
trzeba zdefiniowaü element servlet-mapping. WiĊcej informacji na ten temat znajduje siĊ
w punkcie 1.3, „Rejestrowanie aplikacji internetowych na serwerze”.

DostĊp do serwletów moĪna takĪe uzyskiwaü w inny sposób, który nie wymaga definiowania
odpowiedniego adresu URL. Do tego celu moĪna uĪyü adresu o postaci http://komputer/prefiks
´Aplikacji/servlet/nazwaPakietu.NazwaSerwletu. UĪywanie adresu o takiej postaci przy-
daje siĊ w trakcie testowania moĪliwoĞci aplikacji, natomiast nie zaleca siĊ jego uĪywania
w aplikacjach produkcyjnych. Powodów jest kilka. Po pierwsze, jeĪeli dla tego samego
serwletu zostanie równieĪ zdefiniowany element servlet-mapping, bĊdzie moĪna go wywo-
áywaü na dwa róĪne sposoby, a to z kolei szybko zacznie utrudniaü utrzymywanie aplikacji.


Po drugie, poniewaĪ deklaratywne zabezpieczenia aplikacji zaleĪą od adresu URL, przy uĪyciu
którego zasób jest udostĊpniany, moĪe w ten sposób powstaü luka w zabezpieczeniach. Po
trzecie, uĪytkownik jest zmuszony wpisaü adres URL, w którym znajduje siĊ nazwa serwletu
ze wszystkimi jego kwalifikatorami, a takie adresy wyglądają maáo elegancko i są trudne do
zapamiĊtania. Zatem w kategorii uĪytecznoĞci aplikacji internetowej taki sposób wywoáywania
serwletów zyskaáby bardzo niskie noty. Po czwarte, jeĪeli kiedykolwiek zajdzie potrzeba, by
zmieniü nazwĊ klasy albo umieĞciü klasy w nowym pakiecie, zmieniü trzeba bĊdzie równieĪ
sam adres URL. To z kolei pociągnie za sobą wymóg zmiany wszystkich odwoáaĔ znajdu-
jących siĊ w aplikacji, w których uĪywano dotychczasowego adresu URL. Oprócz tego, Īe
sama ta czynnoĞü bĊdzie doĞü uciąĪliwa, to jej wynik spowoduje zamieszanie równieĪ wĞród
samych uĪytkowników, którzy przecieĪ mogli zapisaü adres wĞród swoich ulubionych
zakáadek, a po zmianie adresu serwletu adres ten przestanie dziaáaü i uĪytecznoĞü aplikacji
znowu ucierpi.

Zalecamy jawne blokowanie dostĊpu do serwletów wchodzących w skáad aplikacji internetowej
bez odpowiednio odwzorowanego adresu URL. Odwzorowanie takie moĪna zdefiniowaü za
pomocą elementu servlet-mapping pliku web.xml. Przykáadowe odwzorowanie znajduje
siĊ w pliku web.xml aplikacji app-blank, którą moĪna pobraü z witryny ftp://ftp.helion.pl/
´przyklady/jsp2w2.zip.

Serwlety, komponenty JavaBeans i klasy pomocnicze znajduj¾ce siÂ w pakietach JAR

JeĪeli serwlety lub inne pliki z rozszerzeniem .class wchodzą w skáad pakietów JAR, wów-
czas pliki JAR powinny siĊ znajdowaü w katalogu WEB-INF/lib. JeĪeli klasy znajdują siĊ
w pakietach, wówczas wewnątrz pliku JAR klasy te powinny znajdowaü siĊ w katalogu
o nazwie odpowiadającej nazwie ich pakietu. WiĊkszoĞü serwerów umoĪliwia wspóáuĪyt-
kowanie plików JAR przez róĪne aplikacje internetowe. Funkcja ta nie jest jednak standardem,
a konkretny sposób jej dziaáania zaleĪy od rodzaju serwera. Na serwerze Tomcat wspóáuĪyt-
kowane pliki JAR umieszcza siĊ w katalogu katalog_tomcat/shared/lib.

Deskryptor wdroÑenia

Deskryptor wdroĪenia, czyli plik web.xml, powinien znajdowaü siĊ w podkatalogu WEB-INF
katalogu gáównego aplikacji internetowej. Szczegóáowe informacje na temat sposobu uĪywania
pliku web.xml znajdują siĊ w rozdziale 2., „Kontrolowanie dziaáania aplikacji przy uĪyciu
pliku web.xml”. Warto zwróciü uwagĊ, Īe niektóre serwery mogą obsáugiwaü globalny plik
web.xml, dotyczący wszystkich aplikacji internetowych. Na przykáad serwer Tomcat wyko-
rzystuje plik katalog_tomcat/conf/web.xml, w którym znajdują siĊ globalne ustawienia
konfiguracyjne. Plik taki jest jednak cechą charakterystyczną tylko tego serwera. Standardem
jest wyáącznie plik web.xml definiowany dla kaĪdej aplikacji oddzielnie i umieszczany w ka-
talogu WEB-INF aplikacji internetowej.

Deskryptory bibliotek znaczników

Pliki bĊdące deskryptorami bibliotek znaczników (ang. Tag Library Descriptor — TLD)
umieszcza siĊ w katalogu WEB-INF lub jego dowolnym podkatalogu. Zaleca siĊ jednak, by
deskryptory te umieszczaü w podkatalogu tlds katalogu WEB-INF. Grupowanie deskryptorów


w jednym katalogu (na przykáad o nazwie tlds) upraszcza proces zarządzania nimi. Strony
JSP uzyskują dostĊp do plików TLD znajdujących siĊ w WEB-INF za pomocą dyrektywy
taglib o nastĊpującej postaci:
<%@ taglib uri="/WEB-INF/tlds/mójPlikTaglib.tld" … %>

PoniewaĪ nie mamy do czynienia z klientem (takim jak choüby przeglądarka internetowa),
lecz z serwerem, który wykorzystuje plik TLD, blokada dostĊpu do zawartoĞci znajdującej
siĊ w katalogu WEB-INF w tym przypadku nie obowiązuje.

Gdy plik z rozszerzeniem .tld jest umieszczany wewnątrz pliku JAR, powinien siĊ on znaj-
dowaü w katalogu META-INF lub w którymĞ z jego podkatalogów. KoniecznoĞü zmiany
lokalizacji z WEB-INF na META-INF wynika z tego, Īe pliki JAR nie są archiwami aplikacji
WWW, a wiĊc nie zawierają katalogu WEB-INF. WiĊcej informacji na temat plików TLD
znajduje siĊ w rozdziale 7., „Biblioteki znaczników. Zagadnienia podstawowe”.

Pliki znaczników

Pliki znaczników powinny znajdowaü siĊ w katalogu WEB-INF/tags lub jego podkatalogu.
Podobnie jak w przypadku plików TLD, pliki znaczników pozostają dostĊpne dla stron JSP
nawet wówczas, gdy znajdują siĊ w katalogu WEB-INF. Pliki znaczników równieĪ deklaruje
siĊ na stronie JSP przy uĪyciu dyrektywy taglib. Jednak zamiast uri naleĪy w ich przypadku
zdefiniowaü atrybut tagdir. JeĪeli na przykáad plik mójPlikZnaczników.tag umieszczony
zostanie w katalogu WEB-INF/tags aplikacji internetowej, dyrektywa taglib strony JSP
powinna mieü nastĊpującą postaü:
<%@ taglib tagdir="/WEB-INF/tags" …%>

W takim przypadku serwer automatycznie wygeneruje plik TLD dla plików znaczników,
zatem nie trzeba samodzielnie definiowaü odpowiedniego odwzorowania.

Pliki znaczników moĪna takĪe doáączaü do plików JAR. Sam plik JAR powinien zostaü
umieszczony w katalogu WEB-INF/lib, zgodnie z tym, co wspomniano juĪ wczeĞniej. Jednak
wewnątrz pliku JAR pliki znaczników powinny znajdowaü siĊ w katalogu META-INF/tags.
W takim przypadku serwer nie wygeneruje automatycznie TLD, dlatego konieczne jest zadekla-
rowanie plików znaczników i ĞcieĪki dostĊpu w pliku z rozszerzeniem .tld. Warto zauwaĪyü, Īe
plik z rozszerzeniem .tld moĪe zawieraü równieĪ deklaracje wáasnych znaczników innych
typów. WiĊcej informacji na temat plików znaczników znajduje siĊ w rozdziale 7., „Biblioteki
znaczników. Zagadnienia podstawowe”.

Plik manifestu WAR

Gdy tworzony jest plik WAR (wiĊcej na ten temat w punkcie 1.5), plik MANIFEST.MF zostaje
umieszczony w podkatalogu META-INF. Zazwyczaj narzĊdzie jar automatycznie tworzy
plik MANIFEST.MF i umieszcza go w katalogu META-INF, a w przypadku rozpakowywania
pliku WAR plik manifestu jest ignorowany. Czasami jednak trzeba jawnie zmodyfikowaü
plik MANIFEST.MF, dlatego warto wiedzieü, gdzie siĊ on znajduje.


1.3. Rejestrowanie aplikacji internetowych
na serwerze
Jak wspominano juĪ wczeĞniej, aplikacje internetowe są przenoĞne. Bez wzglĊdu na to, jaki
serwer jest uĪywany, pliki aplikacji są przechowywane w takiej samej strukturze katalogów, a
dostĊp do nich uzyskuje siĊ za poĞrednictwem adresów URL w takiej samej postaci. Na ry-
sunku 1.2 przedstawiono strukturĊ adresów URL, których naleĪaáoby uĪyü dla najprostszej
aplikacji o nazwie myWebApp. W tym punkcie opisane zostaną sposoby instalowania i wyko-
nywania prostej aplikacji internetowej na róĪnych platformach.

Rysunek 1.2.
Struktura
aplikacji
internetowej
myWebApp

Same aplikacje internetowe są w peáni przenoĞne, natomiast juĪ przebieg procesu rejestracji
aplikacji zaleĪy od serwera. Aby na przykáad przenieĞü aplikacjĊ myWebApp z jednego serwera
na drugi, nie trzeba wprowadzaü Īadnych zmian w strukturze katalogów widocznej na ry-
sunku 1.2, natomiast umiejscowienie katalogu gáównego aplikacji (w tym przypadku jest to
myWebApp) zaleĪy od rodzaju uĪywanego serwera. Podobnie od rodzaju serwera zaleĪy sam
sposób wskazywania serwerowi, Īe aplikacja powinna byü wywoáywana przy uĪyciu adresu
URL w postaci http://komputer/myWebApp/.

W tym punkcie przyjĊto zaáoĪenie, Īe wszystkie kroki zmierzające do zainstalowania i skon-
figurowania serwera zostaáy juĪ wykonane. WiĊcej informacji na temat konfiguracji serwe-
ra moĪna znaleĨü w jego dokumentacji, w pierwszym rozdziale pierwszego tomu niniejszej
ksiąĪki lub (w przypadku uĪytkowników serwera Tomcat) w uaktualnianym na bieĪąco prze-
wodniku po instalacji i konfiguracji serwera, dostĊpnym w witrynie http://www.coreservlets.
´com. W tym miejscu zaprezentowany zostanie tylko krótki przykáad, a nastĊpnie w jednym
z kolejnych podpunktów opisana zostanie procedura rejestracji na serwerze Tomcat. Szcze-
góáowy opis procesu wdroĪenia przykáadowej aplikacji internetowej na serwerze Tomcat
zostanie przedstawiony w punkcie 1.6, „Tworzenie prostej aplikacji internetowej”.

Zgodnie z informacjami zawartymi w punkcie 1.4, „Strategie rozwoju i wdraĪania aplikacji
internetowych”, standardową strategią jest tworzenie aplikacji w Ğrodowisku programistycz-
nym i regularne kopiowanie jej do poszczególnych katalogów wdroĪeniowych w celu przete-
stowania rozwiązania na róĪnych serwerach. Odradza siĊ umieszczanie katalogu rozwojowego


bezpoĞrednio w katalogu wdroĪeniowym serwera, poniewaĪ znacznie utrudni to wdroĪenie
aplikacji na kilku serwerach, trudno bĊdzie pracowaü nad aplikacją w czasie jej dziaáania,
a takĪe utrudnione zostanie nadanie odpowiedniej organizacji plików. Lepszym rozwiązaniem
jest uĪycie oddzielnego katalogu rozwojowego i zastosowanie jednej ze strategii opisanych
w punkcie 1.4, „Strategie rozwoju i wdraĪania aplikacji internetowych”. Najprostszym rozwią-
zaniem jest utworzenie skrótu (w systemie Windows) lub dowiązania symbolicznego (w Ğro-
dowisku UNIX/Linux), prowadzącego do katalogów wdroĪeniowych poszczególnych serwe-
rów, oraz kopiowanie caáego katalogu rozwojowego za kaĪdym razem, gdy przyjdzie czas na
wdroĪenie aplikacji. Na przykáad w systemie Windows przy uĪyciu prawego przycisku myszy
moĪna przeciągnąü folder rozwojowy do utworzonego skrótu, zwolniü przycisk i wybraü
polecenie Kopiuj.

Rejestrowanie aplikacji internetowych na serwerze Tomcat
Tworzenie aplikacji internetowej na serwerze Tomcat polega na utworzeniu odpowiedniej
struktury katalogów i skopiowanie jej do katalogu katalog_tomcat/webapps. Za caáą resztĊ
odpowiada juĪ sam serwer. MoĪliwoĞü wdraĪania aplikacji internetowych przez kopiowanie
struktury katalogów do jednego z katalogów serwera to tak zwane wdraĪanie na gorąco
(ang. hot-deployment) albo wdraĪanie automatyczne (ang. auto-deployment). Katalog
w strukturze katalogów serwera, który odpowiada za tĊ funkcjĊ, to tak zwany katalog
wdraĪania na gorąco (ang. hot-deploy directory) albo katalog wdraĪania automatycznego
(ang. auto-deploy directory). WiĊkszoĞü serwerów WWW, jeĞli nie wszystkie wspóáczesne
serwery WWW, obsáuguje taki wáaĞnie sposób wdraĪania aplikacji. Aby zwiĊkszyü kontrolĊ
nad procesem wdroĪenia, moĪna odpowiednio zmodyfikowaü zawartoĞü pliku katalog_
´tomcat/conf/server.xml (jest to plik charakterystyczny tylko dla serwera Tomcat), tak aby
odwoáywaá siĊ on do aplikacji.

PoniĪej przedstawiono kolejne czynnoĞci, jakie trzeba wykonaü, aby utworzyü aplikacjĊ inter-
netową dostĊpną za poĞrednictwem adresu URL rozpoczynającego siĊ od http://komputer/
´myWebApp.
1. Utworzyü strukturĊ katalogów dla aplikacji internetowej, w której katalog
gáówny bĊdzie nosiü nazwĊ myWebApp. PoniewaĪ jest to nasza wáasna struktura
rozwojowa, moĪna ją umieĞciü w dowolnie wybranej lokalizacji. Struktura katalogów
powinna byü zgodna ze strukturą przedstawioną w punkcie 1.2, „Struktura aplikacji
internetowych”. Aby zmniejszyü liczbĊ czynnoĞci, jakie naleĪy wykonaü w ramach
tego kroku, z ftp://ftp.helion.pl/przyklady/jsp2w2.zip moĪna pobraü aplikacjĊ app-
blank. Zawiera ona wszystkie niezbĊdne katalogi oraz przykáadowy deskryptor
wdroĪenia web.xml. Pozostaje wówczas tylko zmieniü nazwĊ katalogu gáównego
app-blank na myWebApp.
JeĪeli natomiast zapadnie decyzja o rĊcznym utworzeniu wymaganych katalogów,
naleĪy postĊpowaü zgodnie z dalszym opisem. Najpierw trzeba utworzyü katalog
o nazwie myWebApp — moĪe siĊ on znajdowaü w dowolnej lokalizacji w systemie
poza katalogiem instalacyjnym serwera. W katalogu tym trzeba utworzyü podkatalog
o nazwie WEB-INF, w nim zaĞ utworzyü kolejny katalog classes. NastĊpnie naleĪy
utworzyü deskryptor wdroĪenia web.xml i umieĞciü go w katalogu WEB-INF.
Szczegóáowe informacje na temat deskryptora wdroĪenia znajdują siĊ w rozdziale 2.,
„Kontrolowanie dziaáania aplikacji przy uĪyciu deskryptora web.xml”. Na razie


wystarczy tylko skopiowaü plik web.xml znajdujący siĊ w katalogu katalog_tomcat/
´webapps/ROOT/WEB-INF albo uĪyü wersji deskryptora znajdującej siĊ w aplikacji
app-blank.
Po utworzeniu odpowiedniej struktury katalogów naleĪy w katalogu myWebApp
umieĞciü prostą stronĊ JSP, a do katalogu WEB-INF/classes skopiowaü prosty
serwlet o nazwie MyServlet.class.
2. Zadeklarowaü serwlet i skierowaü go na odpowiedni adres URL przez
wprowadzenie odpowiednich zmian w pliku web.xml bĊdącym deskryptorem
wdroĪenia. W odróĪnieniu od stron JSP serwlety muszą byü deklarowane jawnie.
NaleĪy zatem podaü peáną ĞcieĪkĊ dostĊpu do klasy serwletu, aby wskazaü serwerowi,
Īe serwlet ten istnieje. Dodatkowo konieczne jest wskazanie serwerowi adresów
URL, które po wpisaniu przez uĪytkownika powinny wywoáaü serwlet MyServlet.class.
Obydwie wspomniane czynnoĞci moĪna zrealizowaü przez wstawienie w pliku
web.xml poniĪszego kodu:
<servlet>
<servlet-name>MyName</servlet-name>
<servlet-class>mypackage.MyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MyName</servlet-name>
<url-pattern>/MyAddress</url-pattern>
</servlet-mapping>

Element servlet oraz jego podelementy wskazują serwerowi nazwĊ, za pomocą
której serwlet bĊdzie deklarowany, a takĪe peáną ĞcieĪkĊ dostĊpu do klasy serwletu.
Element servlet-mapping oraz jego podelementy wskazują serwerowi serwlet,
który ma byü wywoáywany, gdy klient wywoáa adres URL odpowiadający wzorcowi
wskazanemu jako wartoĞü elementu url-pattern. Zatem serwlet zadeklarowany
jako MyName bĊdzie wywoáywany przez adres w postaci http://komputer/
´myWebApp/MyAddress.
3. Skopiowaü katalog myWebApp do katalogu katalog_tomcat/webapps. ZaáóĪmy,
Īe serwer Tomcat zostaá zainstalowany w katalogu C:katalog_tomcat. Katalog
myWebApp powinno siĊ zatem skopiowaü do katalogu webapps i uzyskaü w ten
sposób nastĊpujące ĞcieĪki dostĊpu: C:katalog_tomcatwebappsmyWebApp
´HelloWebApp.jsp, C:katalog_tomcatwebappsmyWebAppWEB-INFclasses
´HelloWebApp.class oraz C:katalog_tomcatwebappsmyWebAppWEB-INF
´web.xml. Katalog ten moĪna by nastĊpnie zawrzeü w pliku WAR (wiĊcej na ten
temat w punkcie 1.5) i umieĞciü go w katalogu C:katalog_tomcatwebapps.
4. Opcjonalnie — w pliku server.xml dopisaü element Context. DomyĞlnie Tomcat
skonfiguruje aplikacjĊ internetową w taki sposób, by prefiks jej adresu URL dokáadnie
odpowiadaá nazwie gáównego katalogu tej aplikacji. JeĪeli takie rozwiązanie bĊdzie
wystarczające, moĪna pominąü krok opisywany w tym punkcie. JeĪeli natomiast
konieczne jest zmodyfikowanie tego etapu rejestracji aplikacji, w pliku katalog_tomcat/
´conf/server.xml moĪna dodaü element Context. Przed rozpoczĊciem edycji
zawartoĞci pliku server.xml naleĪy utworzyü jego kopiĊ bezpieczeĔstwa, poniewaĪ
nawet drobny báąd skáadniowy uniemoĪliwi prawidáowe uruchomienie serwera Tomcat.
Natomiast w nowszych wersjach serwera Tomcat zaleca siĊ, by element Context
(oraz jego podelementy) umieszczaü w pliku context.xml. Plik context.xml trzeba
wówczas umieĞciü obok pliku web.xml, w katalogu WEB-INF aplikacji internetowej.


Element Context ma kilka atrybutów, które są udokumentowane na stronie pod
adresem http://tomcat.apache.org/tomcat-5.5-doc/config/context.html. Za pomocą
tego elementu moĪna decydowaü, czy naleĪy uĪywaü plików cookies albo czy
naleĪy przepisywaü adresy URL w celu Ğledzenia sesji; moĪna takĪe wáączaü
i wyáączaü moĪliwoĞü przeáadowywania serwletów (to znaczy monitorowaü klasy
pod kątem zachodzących w nich zmian i przeáadowywaü serwlety tych klas,
których pliki na dysku ulegáy zmianie). MoĪna równieĪ ustawiaü poziomy
debugowania. Jednak w przypadku prostych aplikacji internetowych wystarczy
uĪycie tylko dwóch wymaganych atrybutów: path (prefiks adresu URL) oraz
docBase (bazowy katalog instalacyjny dla aplikacji internetowych wzglĊdem
katalogu katalog_tomcat/webapps). Definicja elementu Context powinna wyglądaü
podobnie do poniĪszej:
<Context path="/jakaħ-aplikacja" docBase="myWebApp" />

NaleĪy pamiĊtaü, by jako prefiks adresu URL nie podawaü prefiksu /examples,
poniewaĪ jest on juĪ uĪywany przez Tomcat jako prefiks dla przykáadowych aplikacji
internetowych.

Na serwerze Tomcat nie naleĔy uĔywaè prefiksu /examples w roli prefiksu adresów
URL aplikacji internetowych.

5. Wywoáaü stronĊ JSP i serwlet. Adres URL http://komputer/myWebApp/
´myPage.jsp wywoáa stronĊ JSP, zaĞ adres http://komputer/myWebApp/MyAddress
spowoduje wywoáanie serwletu. W trakcie rozwoju aplikacji prawdopodobnie jako
nazwa komputera uĪywana bĊdzie nazwa localhost. W podawanych adresach URL
zaáoĪono, Īe plik konfiguracyjny serwera Tomcat (katalog_tomcat/conf/server.xml)
zmodyfikowano w taki sposób, by uĪywany byá port numer 80, zgodnie z zaleceniami
w instrukcji instalacji i konfiguracji serwera, znajdującej siĊ w witrynie
http://www.coreservlets.com/. JeĪeli takiej zmiany nie wprowadzono,
naleĪy uĪyü adresów w postaci http://komputer:8080/myWebApp/myPage.jsp
oraz http://komputer:8080/myWebApp/MyAddress.

Rejestrowanie aplikacji internetowych na innych serwerach
Pierwsze dwie czynnoĞci opisane w poprzednim podrozdziale dotyczą tworzenia przenoĞnej
czĊĞci aplikacji internetowej i bĊdą przebiegaü identycznie na kaĪdym serwerze zgodnym
ze specyfikacją serwletów. Natomiast czynnoĞci dotyczące juĪ samego procesu rejestracji
są charakterystyczne dla serwera Tomcat. Nie zmienia to jednak faktu, Īe rejestrowanie
aplikacji na innych serwerach przebiega bardzo podobnie. W kolejnych podpunktach krótko
zostaną opisane sposoby rejestrowania aplikacji na kilku najbardziej popularnych obecnie
serwerach.


Serwer BEA WebLogic

Podobnie jak Tomcat, serwer WebLogic udostĊpnia katalog automatycznego wdraĪania,
sáuĪący do rejestrowania i wdraĪania aplikacji internetowych. Najpierw, jeĪeli jeszcze nie
zostaáo to zrobione, trzeba utworzyü nową domenĊ o nazwie myDomain. DomenĊ moĪna
utworzyü przy uĪyciu kreatora konfiguracji serwera WebLogic config.cmd w systemie Win-
dows lub config.sh w Ğrodowiskach UNIX/Linux (obydwie wersje znajdują siĊ w katalogu
bea/katalog_weblogic/common/bin). Gdy domena zostanie juĪ utworzona, naleĪy skopiowaü
caáą strukturĊ katalogów aplikacji internetowej (w tym równieĪ jej katalog gáówny) lub plik
WAR do katalogu bea/user_projects/domains/myDomain/applications. Do wdroĪenia aplikacji
moĪna takĪe uĪyü konsoli WWW serwera WebLogic. W tym celu naleĪy zalogowaü siĊ do
konsoli pod adresem http://localhost:7001/console/ (przy zaáoĪeniu, Īe nie zmieniono domyĞl-
nych ustawieĔ portu oraz Īe serwer jest uruchomiony na komputerze lokalnym). W panelu
konsoli po lewej stronie naleĪy rozwinąü wĊzeá Deployments i kliknąü pozycjĊ Web Application
Modules, po czym kliknąü polecenie Deploy a New Web Application Module. W ten sposób
uruchomiony zostanie kreator wdroĪenia dziaáający w przeglądarce, w którym wystarczy
wykonywaü kolejne wyĞwietlane instrukcje. Po wdroĪeniu aplikacji internetowej strona JSP
bĊdzie dostĊpna pod adresem http://localhost:7001/myWebApp/myPage.jsp, zaĞ serwlet bĊdzie
dostĊpny pod adresem http://localhost:7001/myWebApp/MyAddress.

JBoss

Zarejestrowanie aplikacji internetowej na serwerze JBoss jest niemal równie proste, jak
w przypadku serwera Tomcat. Tak naprawdĊ JBoss domyĞlnie uĪywa osadzonego serwera
WWW Tomcat. Aby zarejestrowaü aplikacjĊ, naleĪy najpierw zmieniü nazwĊ katalogu
gáównego myWebApp na myWebApp.war. W istocie nie jest tworzony plik WAR, lecz jedynie
nazwa katalogu gáównego jest zmieniana w taki sposób, by koĔczyáa siĊ sáowem .war. JBoss
wymaga, by sáowem .war koĔczyáy siĊ nie tylko nazwy plików WAR (co jest zresztą wy-
magane na mocy specyfikacji serwletów), lecz równieĪ nazwa gáównego katalogu aplikacji
internetowej. Po zmianie nazwy katalogu katalog myWebApp.war naleĪy skopiowaü do
katalogu katalog_jboss/server/default/deploy. JeĪeli w trakcie instalacji serwera JBoss
Īadne domyĞlne ustawienia nie ulegáy zmianie, strona JSP bĊdzie dostĊpna pod adresem
http://localhost:8080/myWebApp/myPage.jsp, natomiast serwlet bĊdzie wywoáywany adresem
http://localhost:8080/myWebApp/MyAddress. JeĪeli aplikacja zostaáa spakowana w pliku
WAR, w celu jej wdroĪenia plik myWebApp.war trzeba umieĞciü w tym samym katalogu
serwera JBoss.

Caucho Resin

Aby skorzystaü z funkcji automatycznego wdraĪania na serwerze Caucho Resin, naleĪy skopio-
waü caáą strukturĊ katalogów aplikacji internetowej (wáącznie z jej katalogiem gáównym)
lub plik WAR do katalogu katalog_resin/webapps. JeĪeli domyĞlne ustawienia serwera nie
zostaáy zmienione, strona JSP stanie siĊ dostĊpna pod adresem http://localhost:8080/myWebApp/
´myPage.jsp, zaĞ serwlet bĊdzie dostĊpny pod adresem http://localhost:8080/myWebApp/
´MyAddress.


1.4. Strategie rozwoju i wdraÑania
aplikacji internetowych
Gdy wszystko bĊdzie juĪ przygotowane do rozpoczĊcia procesu tworzenia nowej aplikacji
internetowej, naleĪy wykonaü nastĊpujące trzy czynnoĞci:
1. Utworzyü strukturĊ katalogów aplikacji. W katalogu rozwojowym trzeba
utworzyü nową strukturĊ katalogów, zgodną ze strukturą aplikacji internetowej
(wáączając w to plik web.xml znajdujący siĊ w katalogu WEB-INF), opisaną
we wczeĞniejszej czĊĞci tego rozdziaáu. Najprostszym sposobem wykonania tej
czynnoĞci jest skopiowanie i zmiana nazwy aplikacji app-blank. (Jak pamiĊtamy,
aplikacjĊ app-blank oraz wszystkie inne przykáadowe kody Ĩródáowe prezentowane
w ksiąĪce moĪna pobraü z ftp://ftp.helion.pl/przyklady/jsp2w2.zip).
2. Napisaü kod Ĩródáowy aplikacji. Strony HTML i JSP trzeba umieĞciü w katalogu
gáównym lub jego podkatalogach, z wyjątkiem podkatalogu WEB-INF i META-INF.
Poszczególne pliki klas jĊzyka Java naleĪy umieĞciü w katalogu WEB-INF/classes/
´podkatalog_o_nazwie_zgodnej_z_nazwą_pakietu. Pliki JAR powinny trafiü
do katalogu WEB-INF/lib, pliki z rozszerzeniami .tag i .tagx do katalogu
WEB-INF/tags i tak dalej.
3. WdroĪyü aplikacjĊ. Caáą strukturĊ katalogów aplikacji internetowej
(w tym równieĪ jej katalog gáówny) trzeba skopiowaü do katalogu wdraĪania
automatycznego serwera. Istnieje kilka rozwiązaĔ upraszczających to zadanie,
a najczĊĞciej stosowanymi są:
Q Skopiowanie struktury do skrótu lub dowiązania symbolicznego.
Q Wykorzystanie funkcji wdraĪania udostĊpnianych przez zintegrowane Ğrodowisko
programistyczne (IDE).
Q Wykorzystanie narzĊdzia Ant lub podobnego.
Q UĪycie Ğrodowiska IDE wraz z narzĊdziem Ant.

UĪytkownicy dopiero poznający dziaáanie serwletów i stron JSP mogą pozostaü przy pierwszej
opcji, zaĞ rozpoznawanie sposobu dziaáania narzĊdzia Ant lub konkretnego Ğrodowiska IDE
moĪna rozpocząü po zaznajomieniu siĊ przynajmniej z podstawami serwletów i stron JSP.
Trzeba jednak zaznaczyü, Īe nie wspomniano o opcji polegającej na umieszczeniu kodu
bezpoĞrednio w katalogu wdroĪeniowym serwera. Wprawdzie to wáaĞnie rozwiązanie najczĊ-
Ğciej wybierają początkujący programiĞci, wachlarz jego zastosowaĔ w bardziej zaawansowa-
nych zadaniach jest tak skromny, Īe zaleca siĊ, by nie stosowaü go juĪ na samym początku.

W kolejnych podpunktach opisane zostaną wszystkie cztery wspomniane opcje.


Kopiowanie struktury do skrótu lub dowi¾zania symbolicznego
W systemie Windows naleĪy przejĞü do katalogu nadrzĊdnego wobec katalogu automatycz-
nego wdroĪenia serwera. W przypadku serwera Tomcat bĊdzie to gáówny katalog instalacyjny
katalog_tomcat. Katalog automatycznego wdroĪenia naleĪy kliknąü prawym przyciskiem
myszy (na serwerze Tomcat bĊdzie to katalog webapps) i wybraü polecenie Kopiuj. NastĊpnie
trzeba przejĞü do katalogu bezpoĞrednio nadrzĊdnego wobec gáównego katalogu rozwojowego
(czyli katalogu o jeden wyĪszego w hierarchii niĪ myWebApp), kliknąü go prawym przyci-
skiem myszy i wybraü polecenie Wklej skrót (a nie zwykáe polecenie Wklej). Od teraz za kaĪ-
dym razem, gdy przyjdzie juĪ czas na wdroĪenie aplikacji internetowej, naleĪy kliknąü i przy-
trzymaü wciĞniĊty prawy przycisk myszy na katalogu rozwojowym (na przykáad myWebApp)
i przeciągnąü go do skrótu do katalogu wdroĪenia, po czym zwolniü przycisk myszy. Pojawi
siĊ wówczas menu podrĊczne, w którym naleĪy wybraü polecenie Kopiuj tutaj. Na rysunku 1.3
przedstawiono przykáadową konfiguracjĊ, która uáatwi wdraĪanie i testowanie aplikacji
prezentowanych w tym rozdziale na serwerach Tomcat, WebLogic, JBoss i Resin. W systemie
UNIX moĪna uĪyü dowiązaĔ symbolicznych (tworzonych poleceniem ln –s) w sposób po-
dobny do sposobu uĪywania skrótów w systemie Windows.

Rysunek 1.3.
Wykorzystanie
skrótów w celu
uproszczenia
procesu
wdraĔania
aplikacji

Zaletą tego rozwiązania jest to, Īe jest ono bardzo proste. Jest ono zatem dobre dla osób
początkujących, które chcą siĊ skupiü na poznawaniu dziaáania serwletów i stron JSP, a nie
na narzĊdziach do wdraĪania aplikacji czy Ğrodowiskach IDE.

Wadą przedstawionego rozwiązania jest to, Īe gdy uĪywanych jest kilka serwerów, konieczne
jest powtarzanie operacji kopiowania. ZaáóĪmy na przykáad, Īe w Ğrodowisku rozwojowym
funkcjonuje kilka róĪnych serwerów (Tomcat, Resin i tak dalej), na których regularnie trzeba
testowaü implementowany kod Ĩródáowy. Druga wada polega na tym, Īe w takim rozwiązaniu
na serwer kopiowane są zarówno pliki z kodem Ĩródáowym Javy, jak i pliki klas, choü tak
naprawdĊ niezbĊdne są tylko te ostatnie. Na serwerze biurkowym nie ma to wiĊkszego zna-
czenia, lecz gdy przyjdzie do wdroĪenia aplikacji na „prawdziwym” serwerze produkcyjnym,
pliki z kodem Ĩródáowym nie powinny na niego trafiü.


Wykorzystanie funkcji wdraÑania udostÂpnianych przez IDE
WiĊkszoĞü Ğrodowisk programistycznych do tworzenia serwletów i stron JSP (takich jak IBM
WebSphere Studio Application Developer, Sun ONE Studio, NetBeans, Oracle JDeveloper,
Borland JBuilder, Eclipse z MyEclipseIDE czy wtyczkami NitroX) pozwala na stosowanie
takich konfiguracji, w których jednym klikniĊciem myszy moĪliwe jest wdroĪenie aplikacji
internetowej na serwerze testowym, rozwojowym lub produkcyjnym.

Mimo iĪ Ğrodowiska IDE mają wiele niekwestionowanych zalet, nie są one jednak wolne od
wad. WiĊkszoĞü prawdziwych Ğrodowisk IDE trzeba najpierw poznaü, co zajmuje trochĊ
czasu. Nie moĪna siĊ wiĊc skoncentrowaü na zadaniach stricte programistycznych, przynajm-
niej na początku. Ponadto czĊsto siĊ zdarza, Īe programiĞci są przerzucani z jednego projektu na
drugi, a programiĞci pracujący wspólnie nad daną aplikacją muszą korzystaü z takiego samego
Ğrodowiska IDE. Gdy wiĊc programista przejdzie do innego zespoáu projektowego, w którym
kompilacja i wdraĪanie aplikacji bĊdą wykonywane w innym Ğrodowisku IDE niĪ to, którego
dotąd uĪywaá programista, konieczne bĊdzie poznanie nowego narzĊdzia i przyzwyczajenie
siĊ do pracy w nim. To z kolei bĊdzie wymagaü poĞwiĊcenia dodatkowego czasu.

UÑywanie narzÂdzi ant, maven i im podobnych
NarzĊdzie ant zaimplementowane przez Apache Foundation dziaáa podobnie jak make w Ğrodo-
wisku UNIX. Jednak ant zostaá napisany w Javie (dziĊki czemu jest przenoĞny) i powszech-
nie uwaĪa siĊ, Īe w porównaniu z make jest prostszy w uĪyciu i bardziej rozbudowany. Wielu
programistów serwletów i stron JSP kompiluje i wdraĪa aplikacje wáaĞnie przy uĪyciu ant.
Sposób uĪywania narzĊdzia ant zostaá opisany w dodatku „Tworzenie Aplikacji przy uĪyciu
narzĊdzia Apache ant”.

Ogólne informacje o ant są dostĊpne na stronie pod adresem http://ant.apache.org/manual/,
natomiast wskazówki dotyczące uĪywania ant z serwerem Tomcat znajdują siĊ pod adresem
http://tomcat.apache.org/tomcat-5.5-doc/appdev/processes.html.

Gáówną zaletą takiego rozwiązania jest elastycznoĞü — ant jest tak rozbudowany, Īe obsáu-
guje wszystkie etapy od kompilacji kodu Ĩródáowego Javy, przez kopiowanie plików aĪ po
generowanie plików archiwum WAR (wiĊcej na ten temat w punkcie 1.5).

Kolejnym narzĊdziem, które przyciąga uwagĊ programistów Javy, jest narzĊdzie maven. Na-
rzĊdzie to rozszerza moĪliwoĞci ant, dlatego w niektórych przypadkach bardzo je przypomina,
a w niektórych zasadniczo siĊ od niego róĪni. Wprawdzie maven jest równie elastyczny jak
ant, lecz jego twórcy skupili siĊ przede wszystkim na prostocie jego uĪywania. Dlatego teĪ
waĪną rolĊ odgrywają w nim konwencje. maven moĪe na przykáad skompilowaü kod Ĩródáowy
nawet wówczas, gdy programista nie wskaĪe go w folderze projektowym. Jest to moĪliwe
dziĊki temu, Īe w maven przyjĊto, iĪ zgodnie z konwencją kod Ĩródáowy jĊzyka Java znajduje
siĊ w folderze src/main/java. OczywiĞcie, zaáoĪenie to moĪna zmieniaü, ale po co? DziĊki
zastosowaniu konwencji pliki konfiguracyjne programu maven są, w odróĪnieniu od ant, bardzo
krótkie i zrozumiaáe. WiĊcej informacji na temat tego narzĊdzia moĪna znaleĨü na stronie
http://maven.apache.org.


Wadą zarówno ant, jak i maven jest koniecznoĞü poĞwiĊcenia okreĞlonego czasu na naukĊ
pracy z nimi. Zasadniczo krzywa uczenia siĊ ant i maven jest bardziej stroma niĪ w przypadku
dwóch pierwszych technik prezentowanych w tym podrozdziale. Natomiast istotną róĪnicą
miĊdzy poĞwiĊcaniem czasu na naukĊ konkretnego Ğrodowiska IDE a poznawaniem narzĊdzia
ant albo maven jest to, Īe w coraz wiĊkszej liczbie Ğrodowisk ant i maven są uĪywane jako
rozwiązanie standardowe, zamiast narzĊdzi charakterystycznych tylko dla tych Ğrodowisk.
MoĪna siĊ wiĊc spodziewaü, Īe wiadomoĞci na temat ant lub maven bĊdzie moĪna wyko-
rzystywaü równieĪ w dalszej przyszáoĞci.

UÑywanie IDE wraz z narzÂdziem Ant
ĝrodowiska IDE zwiĊkszają efektywnoĞü pracy programistów, poniewaĪ pomagają tworzyü
kod Ĩródáowy, natomiast ograniczają moĪliwoĞci jego przenoszenia. NarzĊdzie ant z kolei
pozwala na tworzenie aplikacji przenoĞnych, lecz w Īadnej mierze nie pomaga pisaü kodu
Ĩródáowego. Co z tym zrobiü?

PrzepaĞü dzielącą ant i IDE moĪna nieco zmniejszyü przez uĪywanie Ğrodowiska IDE zinte-
growanego z ant. DziĊki temu nadal moĪna pracowaü z ulubionym Ğrodowiskiem programi-
stycznym, które wspiera proces pisania kodu Ĩródáowego, a jednoczeĞnie jednym klikniĊ-
ciem myszy wywoáuje skrypty ant odpowiadające za skompilowanie i wdroĪenie aplikacji.
Takiego rozwiązania moĪna uĪywaü nawet w Ğrodowiskach, które z ant nie są zintegrowane
(choü wiĊkszoĞü wspóáczesnych Ğrodowisk taką integracjĊ juĪ posiada), lecz bĊdzie to wyma-
gaü przeáączania siĊ miĊdzy wierszem poleceĔ a Ğrodowiskiem programistycznym.

Takie podejĞcie doskonale sprawdza siĊ w prawdziwych projektach. ProgramiĞci uĪywają
ulubionych IDE, w których pisanie kodu jest bardziej efektywne, zaĞ sam projekt nie jest
naraĪony na powstawanie niespójnoĞci w trakcie wdroĪenia, poniewaĪ kompilacja i wdro-
Īenie są przeprowadzane przez ten sam przenoĞny skrypt ant. UczestniczyliĞmy w projektach,
w których poszczególni programiĞci naleĪący do zespoáu projektowego tworzącego jedną
aplikacjĊ internetową korzystali z róĪnych IDE; niektórzy z nich pracowali nawet w odmien-
nych systemach operacyjnych. Proces wdraĪania aplikacji natomiast pozostawaá spójny, a sami
programiĞci byli zadowoleni z moĪliwoĞci uĪywania swoich ulubionych narzĊdzi progra-
mistycznych. A czyĪ zadowolenie programisty nie jest najwaĪniejsze?

1.5. Umieszczanie aplikacji internetowych
w plikach WAR
Pliki archiwum WWW (ang. Web archive — WAR) doskonale nadają siĊ do áączenia w poje-
dynczym archiwum caáych aplikacji internetowych. Jeden duĪy plik z aplikacją zastĊpujący
wiele maáych plików znacznie áatwiej jest przenosiü z serwera na serwer.

Archiwum WAR jest tak naprawdĊ plikiem JAR z rozszerzeniem .war i tworzy siĊ go zwykáym
poleceniem jar. Aby na przykáad umieĞciü caáą aplikacjĊ aplikacja_internetowa w pliku
WAR o nazwie aplikacja_internetowa.war, naleĪy przejĞü do katalogu aplikacja_internetowa
i wykonaü nastĊpujące polecenie:


jar cvf aplikacja_internetowa.war *

Pliku WAR nie áączy z poleceniem jar Īadna specjalna zaleĪnoĞü. Polecenie jar jest tak
naprawdĊ jednym z wielu narzĊdzi, dziĊki któremu moĪna tworzyü archiwa plików. Takie
samo archiwum moĪna utworzyü na przykáad przy uĪyciu programu WinZip (albo tar
w systemie UNIX). Wystarczy w tym celu wskazaü nazwĊ pliku docelowego z rozszerzeniem
.war zamiast rozszerzenia .zip.

OczywiĞcie, nic nie stoi na przeszkodzie, by w trakcie tworzenia archiwów WAR wykorzy-
staü inne opcje narzĊdzia jar (na przykáad cyfrowo podpisywaü klasy), tak samo jak wobec
standardowych plików JAR. WiĊcej szczegóáowych informacji na ten temat moĪna znaleĨü
pod adresem http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/jar.html (dotyczy sys-
temu Windows) oraz http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/jar.html (dotyczy
systemów UNIX/Linux).

1.6. Tworzenie prostej aplikacji internetowej
Czas juĪ przejĞü od sáów do czynów, czyli utworzyü pierwszą aplikacjĊ internetową. Jako
serwer uĪyty zostanie serwer Tomcat, lecz opisywane czynnoĞci bĊdą przebiegaü podobnie
równieĪ w przypadku wykorzystania innych serwerów. WiĊcej informacji na ten temat przed-
stawiono w punkcie 1.3, „Rejestrowanie aplikacji internetowych na serwerze”.

W celu utworzenia aplikacji naleĪy wykonaü nastĊpujące kroki:
1. Z ftp://ftp.helion.pl/przyklady/jsp2w2.zip pobraü aplikacjĊ app-blank i zmieniü jej
nazwĊ na testApp.
2. Z tej samej witryny pobraü pliki test.html, test.jsp oraz TestServlet.java.

3. Dodaü do tej aplikacji pliki test.html i test.jsp.

4. UmieĞciü plik TestServlet.java w katalogu testApp/WEB-INF/classes/coreservlets.

5. Skompilowaü plik TestServlet.java.

6. Zadeklarowaü w pliku web.xml klasĊ TestServlet.class oraz adres URL,
który bĊdzie ją wywoáywaü.
7. Skopiowaü aplikacjĊ testApp do katalogu katalog_tomcat/webapps.

8. Uruchomiü serwer Tomcat.

9. Wywoáaü aplikacjĊ testApp, wpisując adres URL w postaci
http://localhost/testApp/nazwaZasobu.

Wymienione czynnoĞci zostaną szczegóáowo opisane w kolejnych sekcjach.


Pobranie aplikacji app-blank i zmiana jej nazwy na testApp
Ten krok jest bardzo prosty. Wystarczy z ftp://ftp.helion.pl/przyklady/jsp2w2.zip pobraü plik
app-blank.zip. Zawiera on odpowiednią strukturĊ katalogów dla kaĪdej aplikacji internetowej
zgodnej ze specyfikacją J2EE. Archiwum to zawiera takĪe wyjĞciową wersjĊ deskryptora wdro-
Īenia web.xml, w którym znajduje siĊ odwzorowanie wyáączające wywoáywacz serwletu. WiĊ-
cej na temat odwzorowywania serwletów powiemy przy okazji odwzorowywania adresu
URL na serwlet TestServlet. Na razie wystarczy rozpakowaü archiwum app-blank.zip do
wybranego katalogu i zmieniü nazwĊ katalogu na testApp. Trzeba równieĪ pamiĊtaü, by katalog
testApp trafiá do katalogu, który bĊdzie siĊ znajdowaá poza strukturą katalogów serwera Tomcat.

Pobranie plików test.html, test.jsp oraz TestServlet.java
Podobnie jak w poprzednim kroku, wymagane pliki moĪna pobraü z ftp://ftp.helion.pl/
´przyklady/jsp2w2.zip. Pliki moĪna pobraü oddzielnie jeden po drugim bądĨ teĪ w postaci po-
jedynczego archiwum testAppFiles.zip, a nastĊpnie rozpakowaü je w wybranym katalogu.

Dodanie plików test.html i test.jsp do aplikacji internetowej testApp
Pliki test.html i test.jsp naleĪy umieĞciü w katalogu testApp, a nastĊpnie utworzyü w nim
katalog someDirectory i wstawiü w nim kopiĊ plików test.html i test.jsp. Plik test.html zawiera
treĞü statyczną, natomiast test.jsp zawiera skrypt zwracający adres URL, z którego wywoáano
stronĊ. Na listingach 1.1 i 1.2 przedstawiono kompletne kody Ĩródáowe obydwóch plików.

Listing 1.1. test.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD><TITLE>Test HTML</TITLE></HEAD>
<BODY BGCOLOR="#FDF5E6">
<H1>Test HTML</H1>
Witaj.
</BODY></HTML>

Listing 1.2. test.jsp
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD><TITLE>Test JSP</TITLE></HEAD>
<BODY BGCOLOR="#FDF5E6">
<H1>Test JSP</H1>
Uľyto nastúpujæcego adresu URL:
<%= request.getRequestURL() %>
</BODY></HTML>


Umieszczenie pliku TestServlet.java w katalogu
testApp/WEB-INF/classes/coreservlets
W pliku TestServlet.java znajduje siĊ deklaracja, wedáug której serwlet naleĪy do pakietu
coreservlets. Zatem plik TestServlet.java musi znaleĨü siĊ w tym pakiecie, zanim bĊdzie
moĪna go skompilowaü. Podobnie jak plik test.jsp, plik TestServlet.class zawiera kod zwra-
cający adres URL, za pomocą którego nastąpiáo wywoáanie serwletu. Peány kod Ĩródáowy
serwletu TestServlet.java znajduje siĊ na listingu 1.3.

Listing 1.3. TestServlet.java
package coreservlets;

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
response.setCharacterEncoding("UTF-8");
PrintWriter out = response.getWriter();
String docType =
"<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 " +
"Transitional//EN">n";
out.println
(docType +
"<HTML>n" +
"<HEAD><TITLE>Test serwletu</TITLE></HEAD>n" +
"<BODY BGCOLOR="#FDF5E6">n" +
"<H1>Test serwletu</H1>n" +
"Uľyto nastúpujæcego adresu URL: " + request.getRequestURL() + "n" +
"</BODY></HTML>");
}
}

Kompilacja pliku TestServlet.java
NaleĪy pamiĊtaü, by w zmiennej Ğrodowiskowej CLASSPATH wskazaü interfejs programistyczny
(API) serwletów. Serwer Tomcat udostĊpnia interfejs w postaci pliku servlet-api.jar, znajdu-
jącym siĊ w katalogu katalog_tomcat/common/lib. W systemie Windows zmienną CLASSPATH
moĪna zdefiniowaü w wierszu poleceĔ systemu operacyjnego, przez wykonanie nastĊpującego
polecenia:
set CLASSPATH=katalog_tomcatcommonlibservlet-api.jar

Natomiast w Ğrodowiskach zgodnych z UNIX/Linux zmienną CLASSPATH moĪna zdefiniowaü
przy uĪyciu konsoli, przez wykonanie polecenia o nastĊpującej treĞci:
CLASSPATH=katalog_tomcat/common/lib/servlet-api.jar

Po odpowiednim zdefiniowaniu zmiennej CLASSPATH moĪna juĪ skompilowaü plik TestServlet.
´java. W tym celu naleĪy przejĞü do katalogu testApp/WEB-INF/classes/coreservlets i wpi-
saü nastĊpujące polecenie:
javac TestServlet.java

Gdy kompilacja dobiegnie koĔca, w katalogu testApp/WEB-INF/classes/coreservlets powinna
pojawiü siĊ klasa TestServlet.class.

Zadeklarowanie w pliku web.xml klasy TestServlet.class
oraz adresu URL, który j¾ wywoÄuje
NaleĪy przejĞü do katalogu testApp/WEB-INF i otworzyü w ulubionym edytorze jĊzyka XML
(Extensible Markup Language) albo edytorze tekstu plik web.xml. Aby zadeklarowaü klasĊ
TestServlet.class naleĪy bezpoĞrednio za komentarzem  umieĞciü poniĪsze wiersze kodu:
<servlet>
<servlet-name>Test</servlet-name>
<servlet-class>coreservlets.TestServlet</servlet-class>
</servlet>

Przedstawiony fragment zawiera deklaracjĊ serwletu o nazwie Test, który reprezentuje kla-
sĊ TestServlet.class. Warto zwróciü uwagĊ, Īe element <servlet-class> wskazuje w peáną
nazwĊ klasy serwletu w postaci nazwaPakietu.nazwaKlasy (bez rozszerzenia .class).

W nastĊpnym kroku trzeba wskazaü serwerowi Tomcat adresy URL, które mają wywoáywaü
serwlet Test. W tym celu w pliku web.xml naleĪy bezpoĞrednio po zamkniĊciu elementu
</servlet> umieĞciü nastĊpujące wiersze kodu:
<servlet-mapping>
<servlet-name>Test</servlet-name>
<url-pattern>/test</url-pattern>
</servlet-mapping>

PowyĪsze wiersze wskazują serwerowi Tomcat, Īe gdy klient wywoáa aplikacjĊ internetową
testApp przy uĪyciu adresu URL w postaci http://komputer/testApp/test, powinien zostaü
wywoáany wczeĞniej zadeklarowany serwlet Test. ZawartoĞü pliku web.xml przedstawiono
na listingu 1.4.

Listing 1.4. web.xml
<?xml version="1.0" encoding="ISO-8859-1"?>

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">

Core Java Servlets i JavaServer Pages. Tom II. Wydanie II

Core Java Servlets i JavaServer Pages. Tom II. Wydanie II

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to Core Java Servlets i JavaServer Pages. Tom II. Wydanie II

Similar to Core Java Servlets i JavaServer Pages. Tom II. Wydanie II (20)

More from Wydawnictwo Helion

More from Wydawnictwo Helion (20)

Core Java Servlets i JavaServer Pages. Tom II. Wydanie II